Raul Miller wrote:
Raul, I will say that many times before in -legal I agreed with you -- this time is not one of those, unfortunately. I have a great deal of respect for you and I want to re-state that I am not arguing with you, but with your particular arguments about your reading of the GPL.And, if you allow the full definition of a "work based on the Program" from section 0 of the GPL to apply, it's clear that when these collective works are being protected as intellectual creations that you're talking about a "work based on the Program" and so can be granted license by the GPL.
That aside, I will try to chart my personal, based on my law experience, points about the whole issue:
1. Brazilian Law reads the concepts of "anthology works", "collective works" and "derivative works" separately and disjointly. A single work cannot be more than one of the above three at the same time; usually what happens is that you have a derivative of an anthology or an anthology that contains a derivative.
1.a. the difference between "collective works" and "anthology works" is that in the former, the individual quality of each work disappears, that is to say, (quoting our Author's Rights Law) "the individual contributions meld in an authonomous work"; in the latter, the anthologist's work is considered to be the "selection, organization or disposition of content".
2. You are 100% right in one point: the intellectual derivation/anthological/collective status of a work is "given" to it in the moment of its actual creation.
These points lead me to:3. The disputed (by me and you, at least) phrase in clause 0 would be most probably read (by a Brazilian Judge at least) as a definition of "work based on the Program" as begin "derivative work". The part after the colon would be striked out as an (incorrect) example or explanation, because the judge would be compelled to use the most strict definition, that is, the most advantageous for the licensee.
4. The grant to distribute anthological and collective works would be given by section 1, combined with section 2, paragraph 3 (the dreaded mere aggregation one), and sections 5 and 10. So, these are not no-ops. They are a broad grant to distribute anthological and collective works, notwithstanding the "mere" word.
4.a. A Brazilian Judge would strike the "mere" word out, for lack of a practical definition. What constitutes mere aggregation as opposed to "non-mere" aggregation? This is an impossible question.
Which lead me to a conclusion similar to Linus Torvalds' one, about kernel loadable modules:
5. The fact of linking and #include'ing a file from another work does not make your work a derivative work, nor obligates you in any way to put your work under the terms of the GPL, when the original work is licensed undef such terms. It's the creative content of your work that will determine (and there are the abstraction, filtration and comparison tests to assert) the derivative status of a work.
5.a. In the case of the Linux kernel, the EXPORT_SYMBOL_GPL() documentation macros are in place to help determine if a loadable kernel module is a derivative work of the kernel or not. I consider them (and I said this before here in -legal) as part of the licensing information for the kernel and I wouldn't touch them if I was making my own tree of the kernel. They stand out, in my view, as would the following comment in the copyright file: "hey, it's difficult to say if a loadable kernel module is a derivative work of the kernel, but I warn you that if you use the functions xxx_1, xxx_2, etc you probably are creating a derivative work."
6. There is the issue of the APIs being "uncopyrightable". Ok, I will try to define it correctly: the bits and pieces that one computer program/library pulls from another computer program/library, binary or source, in order to define a boundary of interconnection, are not protected by copyrights. The work (such as errno.h) is still copyrightable, only the bits and pieces that were pulled from it, and similar expressions of the same interface, are considered not infringing.
6.a. In Brasil, this is stated in our Computer Programs Law, article 6 (too long to quote)
7. This (number 6 above) is relevant because even when a work is dynamically linked, the binary contains parts of libraries and/or headers that were not "included" in the source nor make a part of it, but they are "pulled in" (in a grinded form, possibly) into the binary. What I am arguing here is that these bits are not protected, and henceforth the binary's derivative/collective/anthology status is unchanged by this process.
8. I argue further: it's my opinion that even when you redistribute a binary statically linked, what you are distributing is an anthology work, and in the case of using a GPL'd program, you are allowed to do that by means of sections 1, 2§3, 5 and 10.
IMHO the conclusion is:9. There is no reason for panicking and "oh my god someone get a GPL compatible libsnmp5-dev replacement", because there is no problem in linking a GPL program with a non-GPL'd library (or vice-versa) *at* *all*, as long as said program is not a derivative work of said library.
9.a. And I think that the facts that (I) those programs and libraries are dynamically-linked to each other and (II) the libraries are implementing documented APIs add weight to my opinion.
9.b. As a side comment: If there *is* a GPL compatible libsnmp5-dev with all its functionality, even better! I am in favour of getting GNUTLS in shape! It would help cut down the license proliferation issues. But I think it's not necessary to yank half the repository just because of (dynamic) linking issues.
Disclaimer #1: IANAL TINLA IANADD(Un-)Disclaimer #2: I am a paralegal with a couple of years experience in legal research.
Disclaimer #3: In Brasil. HTH, Massa