Date: Wed, 10 Apr 2002 15:53:18 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "Gary W. Swearingen" <swear@blarg.net> Cc: freebsd-chat@FreeBSD.ORG Subject: Re: Incompatibility of the GPL (was: Use/Utilize) Message-ID: <3CB4C25E.18AE7C81@mindspring.com> References: <3CB2125B.8F11C442@mindspring.com> <200204090020.g390KTPL059689@grimreaper.grondar.org> <3CB2733E.F98DD29B@mindspring.com> <20020409132012.F48437@lpt.ens.fr> <3CB3737A.1551931@mindspring.com> <20020410043451.GA1013@lpt.ens.fr> <3CB3DF33.5B677641@mindspring.com> <20020410073309.GA279@lpt.ens.fr> <3CB41997.214F408C@mindspring.com> <20020410130629.A16154@lpt.ens.fr> <3CB424E4.629016E0@mindspring.com> <crbscrxnzv.scr_-_@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
"Gary W. Swearingen" wrote: > Terry Lambert <tlambert2@mindspring.com> writes: > > Rahul Siddharthan wrote: > > > But the people who should be worried are the people who are writing > > > code mixing the two licences; they should read those licences first, > > > and then there will be no doubt about the meaning. > > > > Yes, no doubt: it is not possible to comply with both licenses > > simultaneously because of section 6 of the GPL, which requires > > that you perform an act for which the right has not been granted > > (or assigned by license) to you by the copyright holder: relicensing > > the code under the GPL. > > No, there's always plenty of doubt about licenses; even the BSDL and > certainly the GPL and this issue of compatibility. > > I'll grant you that incompatibility can easily be read into these > licenses, but as much as I dislike the GPL, I also want to believe that > the BSDL is compatible with any use which doesn't violate the few > explicit terms of the BSDL. Of course, if a license said "this can't > be used with BSDL'd software", I guess I'd have to admit defeat. The GPL poison-pills itself with the "no additional restrictions" clause. It's not an incompatability of the BSD license, it's an incompatability of the GPL. FWIW, I think you could safely call the requirement of keeping the BSD license attached as an "additional restriction". > I can't get around the idea that similar reasoning would make illegal > most use of BSDL software under licenses at least as restrictive as the > GPL. I doubt if there is a single license on binary-only code which is > derived in part from BSDL code which doesn't claim to be a license on > the derivative and that most have terms something like the GPL's > "distribution of the whole must be on the terms of this License". Not unless they poison-pilled themselves against keeping the BSD License attached to that portion of the code that was BSD Licensed. Most licenses don't have a "relicense under our license" requirement, so for most licenses, it's not a problem. The eCOS license might be an issue, since it makes specific calims with regard to granting of patent rights, which you might not be able to do, if the BSD Licensed code from which your code is partly derived embodied patents. But if that were the case, you're in a bit of trouble there anyway. 8-). > As for actual support for their compatibility, I claim that the GPL is > overreaching in it's claim to be a license on the whole of the > derivative (more below) and people see no need to heed the claim, > especially since GPL licensors have apparently not claimed a desire to > enforce it. (And some have claimed a desire to not enforce it.) Yes. I think a U.S. court test of the issue would probably hold that section to be unenforcible, and the severability clause would basically turn it into the BSD license. > The part of the GPL that is supposed to cause incompatibility does not > cause it because it is not an effective, enforcible part of the license. That's my opinion, too. I'd like to see it tested in court. > It might as well not be there (except for the problems it causes). In > any case, the BSDL is all the license needed to use the BSDL code in a > GPL'd or other restrictively-licensed derivative as long as the BSDL's > terms are honored, which is easily done, even in a GPL'd derivative. I think it can't be, if you hold forth section 6 as enforcible. If you don't, then I agree with your analysis. This was my argument pro the USL use of the BSD licensed code in SVR4, and the basis of the UCB countersuit, the settlement of which, among other things, compelled them to add it back in (this was an effect; the terms of the settlement are undisclosed). > Such overreaching on the part of the GPL-using deriver is something the > deriver needs to worry about, I suppose, but he certainly needn't worry > any more about violationg his own GPL than he would if he was the sole > licensor. And because the BSDL licensor has already licensed his work > in the derivative (which shall be forever under the BSDL, regardless of > the other owner's license on his work in the derivative), no relicense > or sublicense is necessary. I think the deriver also needs to worry about their ability to compel subsequent derivers derivative works to be licensed under the same license, more than they need to worry about any compulsion on themselves. Maybe this is what you are trying to say, and the first and second use of "deriver" in your first sentence refer to different people? > From 17USC103: > > (b) The copyright in a compilation or derivative work extends only > to the material contributed by the author of such work, as > distinguished from the preexisting material employed in the work, > and does not imply any exclusive right in the preexisting material. > The copyright in such work is independent of, and does not affect or > enlarge the scope, duration, ownership, or subsistence of, any > copyright protection in the preexisting material. > > So the license "on the derivative" may extend only to "the material > contributed by the author of such work" and does not cover the > "preexisting material employed in the work" which is still under BSDL > and for which no relicense or sublicense is needed. > > Maybe that explains some author's preference for saying "license in the > work" instead of "license on the work". Yes. It's a nice point about "does not affect or enlarge the scope". I particularly think that the use of "affect" rather than "effect" is intentional here, though, so I think they meant "negatively", as in "the opposite of enlarge". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CB4C25E.18AE7C81>