On Fri, May 22, 2015 at 01:14:54PM -0400, James Carlson wrote: > On 05/22/15 12:27, David Lamparter wrote: > > My uninformed opinion is that incorporating function names and #include > > statements does not make something a derivative work. > > ... and then linking to it? That's central to the matter, and makes it > very much different than the Oracle/Google problem. It's not just > copying an API. > > If it were true, though, that creating build, link, and run-time > dependencies on a GPL library doesn't automatically trip over clause 2, > then that would be simply wonderful for those making non-GPL software. > It would also, interestingly, mean that there's no reason at all to have > an LGPL, because the lesser license doesn't permit anything extra; they > wrote the "work that uses the Library" clause for no reason.
It don't think it would be, because as soon as you ship the binary (which of course is derivative of all of its sources) you're back under GPL obligations. (In reverse, if you don't ship anything, you can do what you want. That's why the AGPL exists. If someone does routing in the "cloud" as a service, with Quagga, we have no legal means to get their sources.) The nice thing about the MIT license is that it's GPL-compatible, meaning that people who build binaries of mixed GPL & MIT sources can fulfill their GPL obligations for the MIT code. There has been another argument in the discussion, which is that source and binary can't be separated in this regard. I don't think that makes sense, not only because this contradicts cases like OpenSSL integration (where the binary becomes illegal to distribute, but not the source), but also because there's a simple non-code analogy in copper engraving. Creator A creates a copper plate. S/he owns copyright not only on the plate, but on the prints created from it. Creator B creates another copper plate. Same situation. Now someone, with permission from A and B creates a composite print. The print is now a collective work where copyrights from A and B apply. But of course, this doesn't propagate back to the copper plates. Last, assume Creator B specifically created their plate so that it looks nice when combined with the one from A. It's a separate, new plate, but the question whether it is derived is a _distinct_ "Fair Use" question from the combined print. The print is always derivative of both, but for plate B to be derivative of A it needs to be substantially dependent. There is probably some established limit for that. But the fact that plates A and B can combine to a common work doesn't have some automatic meaning, the combined print is a distinct work. The GPL works by saying "you can combine with my plate A, if you ship your plate B". MIT permits shipping plate B, but makes no such requirement. That's "compatible". The existence of the combined print will force the creator of the combination to ship plate B, as A has required, but doesn't prevent other things from happening to B. The real question is still, IMHO, "are the babeld sources derivative of libzebra sources?" > You're (of course) right that unmodified files can't be touched, but > Paul's right that touching them generally requires some kind of license > for his work unless the changes are "trivial." (This is in response to Jim's original mail? My associative parser is failing to process this paragraph.) > > P.S.: I find it rather amusing that Paul keeps citing his historical > > advice from lawyers at Sun. If it doesn't hold up in court, I'd say > > that wasn't "advice" as much as wishful thinking, on Sun/Oracle's end. > > Sun's lawyers were (like all lawyers) conservative in their advice. My > experience with Sun's lawyers was that the answer to nearly all "can I > ..." questions was simply "no." You had to dive into risk/benefit to > get more details. :-/ Well, yeah, they're (probably?) liable if they tell you something's legal, and then it isn't... -David _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
