From owner-freebsd-chat Mon Dec 17 4:52: 6 2001 Delivered-To: freebsd-chat@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id C5E7837B416; Mon, 17 Dec 2001 04:51:59 -0800 (PST) Received: from pool0066.cvx22-bradley.dialup.earthlink.net ([209.179.198.66] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16FxFI-0004kI-00; Mon, 17 Dec 2001 04:51:52 -0800 Message-ID: <3C1DEA69.93892A66@mindspring.com> Date: Mon, 17 Dec 2001 04:51:53 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Gary W. Swearingen" Cc: Greg Lehey , Brett Glass , chat@FreeBSD.ORG Subject: Re: IBM's intentions with JFS (was: IBM suing (was: RMS Suing was [SUGGESTION] - JFS for FreeBSD)) References: <3C1875D6.5DE4F996@mindspring.com> <20011213051012.Y56723-100000@turtle.looksharp.net> <3C186381.6AB07090@yahoo.com> <3C1875D6.5DE4F996@mindspring.com> <3C186381.6AB07090@yahoo.com> <20011214122837.O3448@monorchid.lemis.com> <3C19807D.C441F084@mindspring.com> <4.3.2.7.2.20011214175450.02da2a90@localhost> <4.3.2.7.2.20011215232233.00e74cc0@localhost> <4.3.2.7.2.20011216221810.031b6820@localhost> <20011217163427.A2885@monorchid.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Gary W. Swearingen" wrote: > Terry says the kernel has some non-GPL-compatible parts. No, RMS states that the 4 clause license isn't compatible. One example of the 4 clause license is at: There are tons of other examples, but one is enough. The license can not be changed without the consent of all the authors. > Even if it didn't, the GPL quote above says that the both parts (the > whole) must be distributed under the terms of the GPL. This requires > a change of licensing (even if just to dual-license) on the kernel. Actually, it requires GPL on the distribution. Technically, it is an aggregate license in that case. The real bearing it has is on whether or not a distributor can link the code and then sunsequently distribute it, or if the code after linking is not redistributable, but can be created in that form by an end user. Currently, the generally accepts answers are "no, to the former, yes to the latter". Dual licensing is a tertiary issue: it would be one possible way of legally doing the former. > The GPL makes it a condition of the license that the kernel be licensed > for distribution under the terms of the GPL. (It doesn't prevent it from > also being licensed under the BSDL.) But the important point is that it > requires a change of license, and only the copyright owners may do that. It's OK with an aggregate license, but since you can't use an aggregate license because of the incompatability, it's moot. > IS there a single copyright owner who can do that? Do the copyright > owners want the kernel to be dual-licensed? It's a slippery slope. "No", and "No", for some instances of Copyright holders. The real slippery slope is: hacing obtained the BSDL'ed code under an aggreegate GPL, is it even legally possible for derivative works to not also fall under the GPL? If the answer is "No" (I think it is), then you have effectively ended developement rights on the code. The way you would have to get around this is to insist on a relinking of the kernel by the user, in that case, rather than the use of modules, should the modules be derived from the original BSDL'ed code. This would work, if we took special care to ensure the aggregate license only applied to the binaries on the distribution, and that the sources were distributed to comply with the aggregate license, bute were not, themselves subject to that license. This would probably require parallel distribution of the sources, since in order to comply with the GPL terms, you must distribute the code that is under the GPL terms under the terms of the GPL. Probably, you would have to have two version, with parallel boiler plate, with additional boiler plate for the GPL "version". It gets very ugly, but it's theoretically doable. But the entire argument is redicated on license compatability, and the "no additional restrictions" of the GPL means that the "claim credit" and "non-endorsement of derivative works" clauses of the 3 and 4 clause BSDL are restrictions over and obove of the GPL restrictions... not to mention PHK's "BeerWare" license on some of the kernel requring you to give him a beer "if you meet hom and if you like the code". Bill Paul also has a nice "additional restriction" in his Ethernet driver boilerplate, in terms of who (or what, in this case 8^)) is covered by the "hold harmless" portion of the license. > > I interpret this to mean "after linking". It would appear to be the > > kernel binary which falls under the GPL. About the only obligation of > > the FreeBSD project would be to make the corresponding source code > > available. > > But you could also be said to be distributing a work which consists of > the source code of both parts as a whole. Maybe the ports scheme gets > around that, but then maybe the lawyers will call that a "work-around" > of the license and judge it the same as a statically linked program. Yes. Hence the "dual distribution", since the requirements are that you distribute the sources under the same terms of the binary come into effect. > Since the kernel has some incompatible code, that's a problem. > Actually, I consider it a good thing. I don't want to see a GPL kernel > with a lot of BSDL code in it, which is what we're looking at here. And that's the boat I think most of us are in... 8^). As I said before, I think most of us in the BSD camps would put the code in the public domain, if we could get away with it, but since we can't, it's just as convenient that the GPL poison pills itself against the BSDL in the same way that putting the code in the public domain would prevent someone from taking it out of the intellectual commons and restricting derivative works. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message