Re: LGPL clarification
On Wednesday 01 November 2000 06:57 pm, Bryan George wrote: > Under current copyright law, reproducing a similar concept, even using > different language, would be a violation once I've been exposed to the > original work, so I couldn't write a license from scratch that resembled > the LGPL either without FSF permission. Given that the probability that > FSF would give that permission to someone outside FSF is roughly, oh, > zero, that means that the LGPL is for practical purposes the only Open > Source license that can ever exist to cover libraries. Copyright only covers a specific expression of an idea, not the idea itself. If the FSF held a patent (hah!) on the idea of copyleft, then you would be right. But they only have rights to specific expressions of that idea as contained in the GPL and LGPL. So go ahead and write a license that covers all the points of the LGPL, but don't follow it's structure or wording. I would say that the odds of RMS approving it are pretty good as long as it complies with his Free Software definition. He might counsel you to use the LGPL instead, but he won't take you to court over it. -- David Johnson ___ http://www.usermode.org
Re: Choosing the right license
On Wednesday 01 November 2000 07:02 pm, Mark Hatch wrote: > The intention here sounds similar to the Open Motif Public License (sic) > and the QPL. The OMPL requires royalties for use on non-"open systems" and > the original QPL was open source only for non-commercial uses. The OMPL is > *not* an open source license because of this clause. I've heard mixed > opinions on the QPL, although I've a hard time understanding how it is > different. This is a mischaracterization of the QPL, probably unintentional. The original Qt license (The Qt Free Edition License), prohibited commercial use. However, the QPL only prohibited closed source and proprietary use. A license cannot be open source if it contains a blanket prohibition against commercial use. -- David Johnson ___ http://www.usermode.org
Re: Choosing the right license
On Wednesday 01 November 2000 05:35 pm, Charlie Stross wrote: > What we want to do is make our application available under a license > that complies with the open source definition (as a minimum -- the > FSF's definitions would be better), but that makes it difficult for a > commercial entity to charge third parties for the use of the software. > That is: there should be no problems for a business using the application > for its own internal use, but it should be difficult to charge customers > a fee for using it as a service. If the license forbids charging customers for any service that is theirs to provide then it will have a very tough time being approped as either OSS or FS. To translate your wishes another way, you want "to make it difficult for Redhat to include your software on its distribution". -- David Johnson ___ http://www.usermode.org
Re: LGPL clarification
On Wednesday 01 November 2000 06:04 pm, Ken Arromdee wrote: > > But the LGPL puts no restrictions on the distribution of P, which is > > what the proprietary user cares about. > > That is not, however, what RMS believes. If there is only one shared > library that exists, he considers P to be derivative of it even before it > is linked; and this triggers all licensing conditions on L even if P is not > distributed with L. Remember readline? I can vaguely recall RMS arguing both ways on different occasions. The last that I heard, he said that the (L)GPL fully allows runtime linkage, but that dynamic linkage is not runtime linkage. Since I don't have his quotes readily available, I won't comment on his words further. I may be remembering them totally wrong. However, there are a lot of people that confuse derivations of copyrighted works with derivations of code. They are two different things. Just because code A is dependant upon code B does not make A a derivative work of B. One thing that "classic" copyright law does not address is referencing. If a code base dynamically links to another, is it only referencing that other code base, or is it a derivative work? I would argue the former (and find ample debating opponents), but I don't believe that there is any case law that addresses the issue. The license is a whole other ball of wax, however! Linking your proprietary code improperly to GPL or LGPL code might not be a violation of copyright, but it could be a breach of contract. For this reason I am much more amenable to licenses that solely grant permissions rather than those that impose restrictions along with the permissions. -- David Johnson ___ http://www.usermode.org
Re: LGPL clarification
Ian Lance Taylor wrote: > >Date: Wed, 1 Nov 2000 11:52:01 -0800 (PST) >From: Ken Arromdee <[EMAIL PROTECTED]> > >RMS's analysis is not directly about the GPL, but about what "derivative >work" means. If he's correct, he's correct independently of the actual >license; *any* license that restricts derivative works will be triggered, >whether GPL (readline), LGPL, or otherwise. Ken, can you point to specific quotes from RMS making this analysis? I'd be very interested to read them. > LGPL, section 5: > > 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > I read this as saying that the LGPL specifically defines a program > designed to work with the library as not being a derivative work in > the context of the LGPL. As do I, for dynamically linked executables. But the OMAREC still seems to apply to statically linked programs. Even if, as I suspect, any jury in the known universe would throw out such an arbitrary distinction between dynamic and statically linked executables, its mere presence in the license text is a damper. > Ian Again, thanks for the input. Now comes the fun part - sending a message to '[EMAIL PROTECTED]' asking their opinion of a modified LGPL essentially without Sections 5 and 6. Flame-proof suit - on... :) Bryan
Re: LGPL clarification
Ian Lance Taylor wrote: > >Date: Wed, 01 Nov 2000 13:19:57 -0500 >From: Bryan George <[EMAIL PROTECTED]> > >At any rate, I think this particular discussion thread is largely >academic. In the .com world, you have to make a strong case to convince >management that it's worth employing a library that places ANY >restrictions on ANY proprietary program that uses it under ANY >circumstances. Especially in large companies where existing >infrastructure works just fine, thank you, that's more trouble and >career risk than the average engineer is willing to accept. > > Note that the C library on GNU/Linux is under the LGPL. People who > believe as you describe should avoid GNU/Linux. Hey, it's not me - I'll use my Linux box, as they say, till they pry my cold, dead hands off it - I'm just playing the Devil's advocate. But you raise a good point - if I statically compile program P using gcc, and apply a harsh interpretation of LGPL, then I'd have to provide object files so users could relink against a modified glibc, allow reverse engineering of my app, etc.. That certainly can't be what LGPL was designed to do. Indeed, if RMS were to assert that it was, I think you _would_ see a mass exodus away from GNU software - it's one thing to act like you own the world, it's quite another to _say_ you own the world... :) > Ian Bryan
Re: LGPL clarification
Date: Wed, 1 Nov 2000 11:52:01 -0800 (PST) From: Ken Arromdee <[EMAIL PROTECTED]> On Wed, 1 Nov 2000, Bryan George wrote: > > > The LGPL puts restrictions on P when it is linked with L. But so > > > what? That linking will only happen on the end user system. ... > > > But the LGPL puts no restrictions on the distribution of P, which is > > > what the proprietary user cares about. > > That is not, however, what RMS believes. If there is only one shared library > > that exists, he considers P to be derivative of it even before it is linked; > > and this triggers all licensing conditions on L even if P is not distributed > > with L. Remember readline? > Readline is GPL'd, not LGPL'd, though, so I'm not sure how that applies > in the present discussion. RMS's analysis is not directly about the GPL, but about what "derivative work" means. If he's correct, he's correct independently of the actual license; *any* license that restricts derivative works will be triggered, whether GPL (readline), LGPL, or otherwise. LGPL, section 5: 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. I read this as saying that the LGPL specifically defines a program designed to work with the library as not being a derivative work in the context of the LGPL. Ian
Re: LGPL clarification
Date: Wed, 01 Nov 2000 13:19:57 -0500 From: Bryan George <[EMAIL PROTECTED]> At any rate, I think this particular discussion thread is largely academic. In the .com world, you have to make a strong case to convince management that it's worth employing a library that places ANY restrictions on ANY proprietary program that uses it under ANY circumstances. Especially in large companies where existing infrastructure works just fine, thank you, that's more trouble and career risk than the average engineer is willing to accept. Note that the C library on GNU/Linux is under the LGPL. People who believe as you describe should avoid GNU/Linux. Ian
Re: LGPL clarification
Date: Wed, 1 Nov 2000 10:04:17 -0800 (PST) From: Ken Arromdee <[EMAIL PROTECTED]> On 1 Nov 2000, Ian Lance Taylor wrote: > The LGPL puts restrictions on P when it is linked with L. But so > what? That linking will only happen on the end user system. The > typical effect is that the end user is not permitted to distribute the > executable now found in memory, because it is impossible to satisfy > both the conditions of the vendor of P and the conditions of the LGPL. > > But the LGPL puts no restrictions on the distribution of P, which is > what the proprietary user cares about. That is not, however, what RMS believes. If there is only one shared library that exists, he considers P to be derivative of it even before it is linked; and this triggers all licensing conditions on L even if P is not distributed with L. Remember readline? readline is under the GPL. I believe that the LGPL is supposed to permit this. I've never heard RMS claim otherwise. Ian
Re: LGPL clarification
On Wed, 1 Nov 2000, Bryan George wrote: > > > The LGPL puts restrictions on P when it is linked with L. But so > > > what? That linking will only happen on the end user system. ... > > > But the LGPL puts no restrictions on the distribution of P, which is > > > what the proprietary user cares about. > > That is not, however, what RMS believes. If there is only one shared library > > that exists, he considers P to be derivative of it even before it is linked; > > and this triggers all licensing conditions on L even if P is not distributed > > with L. Remember readline? > Readline is GPL'd, not LGPL'd, though, so I'm not sure how that applies > in the present discussion. RMS's analysis is not directly about the GPL, but about what "derivative work" means. If he's correct, he's correct independently of the actual license; *any* license that restricts derivative works will be triggered, whether GPL (readline), LGPL, or otherwise.
Re: LGPL clarification
Naturally, I thought about the CVW license, but since the alternatives are the MPL, which FSF specifically doesn't like, and GPL, which precludes binary distribution sans code under any circumstances, it doesn't quite hit the spot. I'm beginning to settle in on the notion of invoking GPL + special dispensation for linked executables, plus maybe CVW-like government contract rights (is that necessary if the license if GPL-derived?). Have I proposed any gotchas as far as OSI is concerned? I can't imagine FSF barking too loudly, since they have similar licenses for Guile, etc.. Thanks for the lively discussion - very enlightening! Bryan Frank Hecker wrote: > > Bryan George wrote: > > MITRE (and similar organizations) regularly develop infrastructure > > libraries that we would like to see used in both non-commercial and > > commercial contexts, and that we would like to be considered standards, > > de facto or otherwise. For these reasons, I have taken a very keen > > interest in OSS licensing in general, and the LGPL in particular. > > Incidentally, you may be aware of this already, but Mitre has already > created its own open source license, for use with the publicly released > version of the Collaborative Virtual Workspace (CVW) software: > > http://cvw.mitre.org/cvw/licenses/source/license.html > > The Mitre CVW license agreement is basically a dual license scheme > involving the GPL and the Mozilla Public License, plus some > Mitre-specific language relating to the fact that the software was > developed under US government contract, plus a provision for copyright > assignment of changes sent back to Mitre. > > You couldn't use the Mitre CVW license as is, because it is specific to > CVW; also, to be up to date the license should refer to version 1.1 of > the MPL, not version 1.0. However with changes it might be suitable for > your purposes; as an MPL/GPL dual license scheme it has similar features > to those Karsten Self mentioned in connection with his proposed GPL/BSD > dual license scheme. Plus the Mitre CVW license has been certified as > OSI-compliant, and also has been reviewed and approved by Mitre > management and legal counsel, so I suspect a variant of it would be able > to get similar approval relatively easily. > > Frank > -- > Frank Heckerwork: http://www.collab.net/ > [EMAIL PROTECTED]home: http://www.hecker.org/ -- Dr. Bryan George Phone: +1 (703) 883-5458 Lead Signal Processing Engineer FAX: +1 (703) 883-6708 The MITRE CorporationEmail: [EMAIL PROTECTED] 1820 Dolley Madison Blvd., M/S W622 Internet: http://www.mitre.org McLean, VA 22102-3481 USA
RE: LGPL clarification
> From: Bryan George [SMTP:[EMAIL PROTECTED]] > [DJW:] > Under current copyright law, reproducing a similar concept, even using > different language, would be a violation once I've been exposed to the > [DJW:] Are you sure of this. I thought that this was one of the key differences between patents and copyright. (Obviously a straight translation into a foreign language would be a violation, but I thought that paraphrasing was different.) > original work, so I couldn't write a license from scratch that resembled > the LGPL either without FSF permission. Given that the probability that > FSF would give that permission to someone outside FSF is roughly, oh, > zero, that means that the LGPL is for practical purposes the only Open > Source license that can ever exist to cover libraries. [DJW:] I would have thought that refusing permission would have been in conflict with the position on patents taken by the GPL and key members of the FSF, even if you are correct about copyrighting concepts. -- --- DISCLAIMER - Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of BTS. >
Re: LGPL clarification
Bryan George wrote: > If I create and distribute a license which is a "derivative work" based > on the LGPL without permission from the FSF, I could be sued for > copyright violation. I couldn't claim "fair use" exemption either, > since the license would benefit commercial interests. Right. > Under current copyright law, reproducing a similar concept, even using > different language, would be a violation once I've been exposed to the > original work, You are overgeneralizing from the case of software to the much broader case of natural-language text. Writing a work on French history does not require that you have never read any books about French history! It merely requires that you express the borrowed ideas in your own words, organization, etc. > so I couldn't write a license from scratch that resembled > the LGPL either without FSF permission. It couldn't substantially incorporate the *text* of the LGPL. But it could use the same *ideas* as the LGPL in your own words. > Given that the probability that > FSF would give that permission to someone outside FSF is roughly, oh, > zero, Actually not true. The FSF *has* authorized the creations of variant GPLs and LGPLs before, with a change of name of course. > Seriously, though, if there are copyright issues involved with license > surgery, I'd like more information on what they are and how to avoid > them. One thing you can do is add a statement to the documentation of your library stating that section N of the LGPL does not apply to the library. But I think the GPL + "you can link this with any program without infecting that program with the GPL" will serve you better, because it is simpler and clearer. The LGPL isn't all it's cracked up to be. -- There is / one art || John Cowan <[EMAIL PROTECTED]> no more / no less|| http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
Re: LGPL clarification
Bryan George wrote: > MITRE (and similar organizations) regularly develop infrastructure > libraries that we would like to see used in both non-commercial and > commercial contexts, and that we would like to be considered standards, > de facto or otherwise. For these reasons, I have taken a very keen > interest in OSS licensing in general, and the LGPL in particular. Incidentally, you may be aware of this already, but Mitre has already created its own open source license, for use with the publicly released version of the Collaborative Virtual Workspace (CVW) software: http://cvw.mitre.org/cvw/licenses/source/license.html The Mitre CVW license agreement is basically a dual license scheme involving the GPL and the Mozilla Public License, plus some Mitre-specific language relating to the fact that the software was developed under US government contract, plus a provision for copyright assignment of changes sent back to Mitre. You couldn't use the Mitre CVW license as is, because it is specific to CVW; also, to be up to date the license should refer to version 1.1 of the MPL, not version 1.0. However with changes it might be suitable for your purposes; as an MPL/GPL dual license scheme it has similar features to those Karsten Self mentioned in connection with his proposed GPL/BSD dual license scheme. Plus the Mitre CVW license has been certified as OSI-compliant, and also has been reviewed and approved by Mitre management and legal counsel, so I suspect a variant of it would be able to get similar approval relatively easily. Frank -- Frank Heckerwork: http://www.collab.net/ [EMAIL PROTECTED]home: http://www.hecker.org/
Re: Choosing the right license
>Nearest thing I can think of is to start off with the GPL, then add a >rider along the lines of "if you sell this software or derived works, or >if you sell any service based on this software, then with every fee- >carrying transaction you must notify the customer of the full text of >this license, including the phrase IF YOU ARE PAYING FOR THIS SERVICE >YOU CAN GET THE SOFTWARE THAT SUPPLIES IT FOR FREE AT http://somewhere/". > The intention here sounds similar to the Open Motif Public License (sic) and the QPL. The OMPL requires royalties for use on non-"open systems" and the original QPL was open source only for non-commercial uses. The OMPL is *not* an open source license because of this clause. I've heard mixed opinions on the QPL, although I've a hard time understanding how it is different. Mark - Integrated Computer Solutions, Inc. Visual Development Tools for Professionals 617-621-0060 x108 (voice) 617-621-9555 (fax) 201 Broadway Cambridge, MA 02139 Visit the MotifZone (www.motifzone.org) for info on Motif!
Re: LGPL clarification
[EMAIL PROTECTED] wrote: > I'd be interested in seeing a discussion of the relative merits of a > BSD/GPL dual license for cases like this. The rationale is as follows. > This is an idea I've been rolling around for a while, there are a couple > of possible holes in it, but I'd be interested in seeing a read from > others. I am sympathetic to your reasoning here; this is essentially the same reasoning that's led a number of projects (Mozilla, OpenOffice, etc.) to adopt or look at adopting dual license schemes with the GPL (or LGPL) as one of the alternative licenses. However I should note that dual license schemes in and of themselves are not with their own issues and ambiguities; even if these issues can be resolved and ambiguities clarified to most people's satisfaction, there still might be enough dissenting voices to lend an air of uncertainty around the licensing arrangements, uncertainty that might deter adoption of the software in some commercial contexts. I think to a large part dual licensing is intended to address a gap in the overall open source licensing picture: the lack of a well-known and universally usable open source license that promotes code sharing within the scope of the original software and modifications to it, allows combination with proprietary code above or below it in the software "stack", and is acknowledged as GPL-compatible by RMS and the FSF (or, failing that, is not claimed to be GPL-incompatible by RMS and the FSF). The LGPL has issues as previously described, and the Mozilla Public License (which otherwise fulfills the above conditions) is claimed by RMS and the FSF to be incompatible with the GPL. However if it were possible to create such a license and have it be generally accepted, I think it could greatly reduce the perceived need for dual licensing, at least for new projects. Frank -- Frank Heckerwork: http://www.collab.net/ [EMAIL PROTECTED]home: http://www.hecker.org/
Re: LGPL clarification
That's an interesting notion - let's follow it: If I create and distribute a license which is a "derivative work" based on the LGPL without permission from the FSF, I could be sued for copyright violation. I couldn't claim "fair use" exemption either, since the license would benefit commercial interests. Under current copyright law, reproducing a similar concept, even using different language, would be a violation once I've been exposed to the original work, so I couldn't write a license from scratch that resembled the LGPL either without FSF permission. Given that the probability that FSF would give that permission to someone outside FSF is roughly, oh, zero, that means that the LGPL is for practical purposes the only Open Source license that can ever exist to cover libraries. Sorry, but that sounds a little too much like giving FSF ownership of truth and beauty, if you ask me... :) Seriously, though, if there are copyright issues involved with license surgery, I'd like more information on what they are and how to avoid them. Bryan John Cowan wrote: > > Bryan George wrote: > > > >- If not, would it be difficult to surgically alter the LGPL to remove > > >the OMAREC and maintain GPL compatibility? > > > > > > No. All you have to do is retain section 3. > > > > Sounds like it may be the way to go. > > Unfortunately, the very first line of the LGPL prevents this solution: > variants of the LGPL may not be created. > > -- > There is / one art || John Cowan <[EMAIL PROTECTED]> > no more / no less|| http://www.reutershealth.com > to do / all things || http://www.ccil.org/~cowan > with art- / lessness \\ -- Piet Hein -- Dr. Bryan George Phone: +1 (703) 883-5458 Lead Signal Processing Engineer FAX: +1 (703) 883-6708 The MITRE CorporationEmail: [EMAIL PROTECTED] 1820 Dolley Madison Blvd., M/S W622 Internet: http://www.mitre.org McLean, VA 22102-3481 USA
Re: LGPL clarification
Ken Arromdee wrote: > > On 1 Nov 2000, Ian Lance Taylor wrote: > > The LGPL puts restrictions on P when it is linked with L. But so > > what? That linking will only happen on the end user system. The > > typical effect is that the end user is not permitted to distribute the > > executable now found in memory, because it is impossible to satisfy > > both the conditions of the vendor of P and the conditions of the LGPL. > > > > But the LGPL puts no restrictions on the distribution of P, which is > > what the proprietary user cares about. > > That is not, however, what RMS believes. If there is only one shared library > that exists, he considers P to be derivative of it even before it is linked; > and this triggers all licensing conditions on L even if P is not distributed > with L. Remember readline? Readline is GPL'd, not LGPL'd, though, so I'm not sure how that applies in the present discussion. The LGPL does seem to be remarkably vague about the definitions and implications of linking, yes? Bryan
Choosing the right license
I need an open source license; trouble is, I don't know whether one that suits my specific requirements already exists or not. Here's the situation; do any of you guys have any suggestions? A friend and I intend to write an application that has some commercial utility. In particular, similar software is used by a number of ASPs who charge their customers on a per-usage basis. What we want to do is make our application available under a license that complies with the open source definition (as a minimum -- the FSF's definitions would be better), but that makes it difficult for a commercial entity to charge third parties for the use of the software. That is: there should be no problems for a business using the application for its own internal use, but it should be difficult to charge customers a fee for using it as a service. Do you know of any open source compliant licenses that accomplish this, i.e. make it difficult to sell the use of the software, while remaining open-source compliant? Nearest thing I can think of is to start off with the GPL, then add a rider along the lines of "if you sell this software or derived works, or if you sell any service based on this software, then with every fee- carrying transaction you must notify the customer of the full text of this license, including the phrase IF YOU ARE PAYING FOR THIS SERVICE YOU CAN GET THE SOFTWARE THAT SUPPLIES IT FOR FREE AT http://somewhere/". In addition the license needs a rider along the lines of "this software, as supplied, has been certified for connection to the XYZ proprietary networks; if you modify it you acknowledge that you are breaking the terms of this certification and are no longer authorized to connect to the XYZ networks under the original certificate of compliance". But I figure this should be fairly straightforward. Any suggestions? -- Charlie
Re: LGPL clarification
Ian Lance Taylor wrote: > >>- Assuming I'm interpreting the LGPL text correctly, are there any >>reasonable circumstances under which a company might be able to develop >>and deploy a binary executable without being subject to the stated >>conditions? >> >> Distribute your package as a shared library. > >Sure, and all that has to happen then is for every company developing >embedded systems to design a dynamic linker into their next-generation >products. I'm sure they'd be happy to comply. %b > > I didn't realize that this was for an embedded system. The LGPL won't > help you. I'm not thinking of any specific cases - not yet, anyway - but yes, embedded systems would come into the mix as well as desktop platforms. At any rate, I think this particular discussion thread is largely academic. In the .com world, you have to make a strong case to convince management that it's worth employing a library that places ANY restrictions on ANY proprietary program that uses it under ANY circumstances. Especially in large companies where existing infrastructure works just fine, thank you, that's more trouble and career risk than the average engineer is willing to accept. > Ian Bryan
Re: LGPL clarification
Bryan George wrote: > >- If not, would it be difficult to surgically alter the LGPL to remove > >the OMAREC and maintain GPL compatibility? > > > > No. All you have to do is retain section 3. > > Sounds like it may be the way to go. Unfortunately, the very first line of the LGPL prevents this solution: variants of the LGPL may not be created. -- There is / one art || John Cowan <[EMAIL PROTECTED]> no more / no less|| http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
Re: LGPL clarification
begin [EMAIL PROTECTED] quotation: > In addition to the two examples given, the Linux kernel itself contains > an exception to allow linking of proprietary drivers (in non-source > form) directly with the Linux kernel. That is my recollection, as well -- except my recollection was that it concerned specifically hardware drivers. I recently had reason to try to find where it's documented, and couldn't. It's not in the kernel source, which has a standard GPL "COPYING" file with a brief preface by Torvalds clarifying (for execu-twits' benefit) that the licence covers the kernel, and not userspace programs that use the kernel only through normal kernel calls. I vaguely recall that Torvalds claimed the bit about proprietary [hardware?] drivers was his "interpretation" of the GPL as applied to the kernel, rather than an explicit exception. If so, that might mean this is documented only in a long-ago thread on the Linux kernel mailing list. Anyone have a reference? -- Cheers, "Teach a man to make fire, and he will be warm Rick Moen for a day. Set a man on fire, and he will be warm [EMAIL PROTECTED] for the rest of his life." -- John A. Hrastar
Re: LGPL clarification
On 1 Nov 2000, Ian Lance Taylor wrote: > The LGPL puts restrictions on P when it is linked with L. But so > what? That linking will only happen on the end user system. The > typical effect is that the end user is not permitted to distribute the > executable now found in memory, because it is impossible to satisfy > both the conditions of the vendor of P and the conditions of the LGPL. > > But the LGPL puts no restrictions on the distribution of P, which is > what the proprietary user cares about. That is not, however, what RMS believes. If there is only one shared library that exists, he considers P to be derivative of it even before it is linked; and this triggers all licensing conditions on L even if P is not distributed with L. Remember readline?
Re: LGPL clarification
Date: Wed, 01 Nov 2000 12:37:07 -0500 From: Bryan George <[EMAIL PROTECTED]> > The LGPL is basically designed to support shared libraries. If you > can distribute your package as a shared library, then the LGPL does > not put any restrictions on the program which uses the library. This > is how you avoid the restriction in section 5--the work is linked with > the library at run time, so there are restrictions on the end user > (the end user effectively can not distribute the linked program), but > not on the program which uses the library. Unfortunately, what you say doesn't seem to square with what the LGPL says on the subject of static vs. dynamic linking (from the Preamble): "When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library..." Since dynamically-linked executables are considered derivative works, Sections 5 and 6 apply. Yes. But think about when the two cases happen. If you distribute a shared library L, and somebody distributes a proprietary program P which is intended to use L, then P has not been linked against L. The LGPL puts no restrictions on P. The LGPL puts restrictions on P when it is linked with L. But so what? That linking will only happen on the end user system. The typical effect is that the end user is not permitted to distribute the executable now found in memory, because it is impossible to satisfy both the conditions of the vendor of P and the conditions of the LGPL. But the LGPL puts no restrictions on the distribution of P, which is what the proprietary user cares about. >- Assuming I'm interpreting the LGPL text correctly, are there any >reasonable circumstances under which a company might be able to develop >and deploy a binary executable without being subject to the stated >conditions? > > Distribute your package as a shared library. Sure, and all that has to happen then is for every company developing embedded systems to design a dynamic linker into their next-generation products. I'm sure they'd be happy to comply. %b I didn't realize that this was for an embedded system. The LGPL won't help you. Ian
Re: LGPL clarification
Ian Lance Taylor wrote: > >Date: Wed, 01 Nov 2000 11:13:38 -0500 >From: Bryan George <[EMAIL PROTECTED]> > >As I said, that is how the LGPL _appears_. However, a close reading of >the license text reveals what again appears to be a poison pill where >commercial interests are concerned. Sections 5 and 6, in particular, >seem in fact to put strings on executables that a company might want to >sell. Section 5 states: > >"... linking a "work that uses the Library" with the Library creates an >executable that is a derivative of the Library (because it contains >portions of the Library), rather than a "work that uses the library". >The executable is therefore covered by this License. Section 6 states >terms for distribution of such executables." > >And Section 6 states: > >"... As an exception to the Sections above, you may also combine or link >a "work that uses the Library" with the Library to produce a work >containing portions of the Library, and distribute that work under terms >of your choice, provided that the terms permit modification of the work >for the customer's own use and reverse engineering for debugging such >modifications." > >These statements are very unfortunate, because they cross the boundary >that the LGPL intends to establish between the OSS and commercial >worlds, and dictate terms on the distribution of executable programs >using LGPL-covered libraries. > > The LGPL is basically designed to support shared libraries. If you > can distribute your package as a shared library, then the LGPL does > not put any restrictions on the program which uses the library. This > is how you avoid the restriction in section 5--the work is linked with > the library at run time, so there are restrictions on the end user > (the end user effectively can not distribute the linked program), but > not on the program which uses the library. Unfortunately, what you say doesn't seem to square with what the LGPL says on the subject of static vs. dynamic linking (from the Preamble): "When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library..." Since dynamically-linked executables are considered derivative works, Sections 5 and 6 apply. > If you can not distribute your package as a shared library, then you > will indeed have difficulties getting it adopted by proprietary > interests. It is technically possible, because the proprietary code > can be distributed in object code form, but I've never heard of > anybody actually doing that, and I think that most companies would > balk. Indeed. >- Assuming I'm interpreting the LGPL text correctly, are there any >reasonable circumstances under which a company might be able to develop >and deploy a binary executable without being subject to the stated >conditions? > > Distribute your package as a shared library. Sure, and all that has to happen then is for every company developing embedded systems to design a dynamic linker into their next-generation products. I'm sure they'd be happy to comply. %b >- If not, would it be difficult to surgically alter the LGPL to remove >the OMAREC and maintain GPL compatibility? > > No. All you have to do is retain section 3. Sounds like it may be the way to go. > Ian Thanks! Bryan
Re: LGPL clarification
on Wed, Nov 01, 2000 at 06:06:19PM +0100, Mark Wielaard ([EMAIL PROTECTED]) wrote: > Hi, > > On Wed, Nov 01, 2000 at 11:13:38AM -0500, Bryan George wrote: > > > - Assuming there are no such circumstances, are there any GPL-compatible > > licenses that behave similarly to the LGPL, but without the "obnoxious > > modification and reverse engineering clause"? > > I am not sure about your interpretation of the LGPL. But you might be > interested in the way the FSF distributes for example guile and classpath. > They are distributed as GPL plus an exception when you link the whole > library. It could be seen as a simplified version of the LGPL. In addition to the two examples given, the Linux kernel itself contains an exception to allow linking of proprietary drivers (in non-source form) directly with the Linux kernel. This sort of exception has been used in a number of other contexts. I'll let the lawyers apply the final gloss, but my understanding is this: - The GPL claims rights of authorship under copyright law, then cedes some of these rights back to the recipient of a copy, provided rules are adhered to. - A special exception applies yet another level of ceding of rights back to recipients, under special conditions. I believe this allows compatibility of the base source with GPLd code, while allowing for broader application in certain cases (though a codebase in which the exception has been exercised -- e.g.: non-GPLd code is included, might not be GPL compatible itself). Other options might include using an alternative license -- the Mozilla style was designed to address issues similar to those you seem to be tackling. A BSD (w/o advertising clause) license might be good for promoting a technology, though it does allow for a proprietary derivative of the work to be created (feature/bug discussion omitted). I'd be interested in seeing a discussion of the relative merits of a BSD/GPL dual license for cases like this. The rationale is as follows. The GNU GPL is a license which has the advantage of denying any single entity a control locus. As Chris Rasch wrote recently on the FSB list, it avoids a prisoners' dilemma -- neither side in a transaction can get an upper hand. Others have noted that the GPL avoids creating any points of control. This creates a credible trust zone, if you will. However, one of the foundations on which free software is based is open standards. The BSD/MIT licenses are essentially standards-propogation licenses. While the GPL creates credibility, there may be aversions to adoption, as Bryan indicates. Yoking the two licenses together might be the sugar-coating that the GPL needs. BSD means that the terms of the GPL need not persist into proprietary implementations of the codebase. However, the existence of a GPLd primary base means that any codefork which is attempted under BSD or other terms must compete against the credibility of assured public existence of the GPLd variant. This is an idea I've been rolling around for a while, there are a couple of possible holes in it, but I'd be interested in seeing a read from others. IANAL, this is not legal advice. -- Karsten M. Self <[EMAIL PROTECTED]> http://www.netcom.com/~kmself Evangelist, Opensales, Inc.http://www.opensales.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org PGP signature
Re: LGPL clarification
Hi, On Wed, Nov 01, 2000 at 11:13:38AM -0500, Bryan George wrote: > - Assuming there are no such circumstances, are there any GPL-compatible > licenses that behave similarly to the LGPL, but without the "obnoxious > modification and reverse engineering clause"? I am not sure about your interpretation of the LGPL. But you might be interested in the way the FSF distributes for example guile and classpath. They are distributed as GPL plus an exception when you link the whole library. It could be seen as a simplified version of the LGPL. This how Classpath says it: GNU Classpath is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. GNU Classpath is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with GNU Classpath; see the file COPYING. If not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. As a special exception, if you link this library with other files to produce an executable, this library does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. And this is how guile says it: [... GPL ...] * As a special exception, the Free Software Foundation gives permission * for additional uses of the text contained in its release of GUILE. * * The exception is that, if you link the GUILE library with other files * to produce an executable, this does not by itself cause the * resulting executable to be covered by the GNU General Public License. * Your use of that executable is in no way restricted on account of * linking the GUILE library code into it. * * This exception does not however invalidate any other reasons why * the executable file might be covered by the GNU General Public License. * * This exception applies only to the code released by the * Free Software Foundation under the name GUILE. If you copy * code from other Free Software Foundation releases into a copy of * GUILE, as the General Public License permits, the exception does * not apply to the code that you add in this way. To avoid misleading * anyone as to the status of such modified files, you must delete * this exception notice from them. * * If you write modifications of your own for GUILE, it is your choice * whether to permit this exception to apply to your modifications. * If you do not wish that, delete this exception notice. Cheers, Mark
Re: LGPL clarification
Date: Wed, 01 Nov 2000 11:13:38 -0500 From: Bryan George <[EMAIL PROTECTED]> As I said, that is how the LGPL _appears_. However, a close reading of the license text reveals what again appears to be a poison pill where commercial interests are concerned. Sections 5 and 6, in particular, seem in fact to put strings on executables that a company might want to sell. Section 5 states: "... linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables." And Section 6 states: "... As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications." These statements are very unfortunate, because they cross the boundary that the LGPL intends to establish between the OSS and commercial worlds, and dictate terms on the distribution of executable programs using LGPL-covered libraries. The LGPL is basically designed to support shared libraries. If you can distribute your package as a shared library, then the LGPL does not put any restrictions on the program which uses the library. This is how you avoid the restriction in section 5--the work is linked with the library at run time, so there are restrictions on the end user (the end user effectively can not distribute the linked program), but not on the program which uses the library. If you can not distribute your package as a shared library, then you will indeed have difficulties getting it adopted by proprietary interests. It is technically possible, because the proprietary code can be distributed in object code form, but I've never heard of anybody actually doing that, and I think that most companies would balk. - Am I interpreting the aforementioned sections of the LGPL correctly? I am not a lawyer, so if there is a reasonable interpretation of the license that renders the objections I've raised moot, please enlighten me. I'm not sure whether you are, but you may be. - Assuming I'm interpreting the LGPL text correctly, are there any reasonable circumstances under which a company might be able to develop and deploy a binary executable without being subject to the stated conditions? Distribute your package as a shared library. - If not, would it be difficult to surgically alter the LGPL to remove the OMAREC and maintain GPL compatibility? No. All you have to do is retain section 3. Ian
LGPL clarification
Greetings, I've been lurking on the list for a bit, haven't seen this come up, and am unaware of a FAQ or list archive, so I'm going to go ahead and fire off a few questions related to the LGPL and the possible development of an LGPL-derived license - my apologies if it's an old topic. MITRE (and similar organizations) regularly develop infrastructure libraries that we would like to see used in both non-commercial and commercial contexts, and that we would like to be considered standards, de facto or otherwise. For these reasons, I have taken a very keen interest in OSS licensing in general, and the LGPL in particular. At first glance, the LGPL appears to be exactly what an organization such as ours requires. It provides protection against fragmentation of the infrastructure itself through closed development, and provides a mechanism whereby free software developers (including ourselves) can contribute to and evolve the infrastructure without concern that their good work will "go private". At the same time, the LGPL appears to make provisions for the infrastructure to be used in reasonable ways by profit-making enterprises, without strings attached to the source code making use of the infrastructure or executables thus derived. Without such provisions, companies would simply ignore our work, develop their own in-house code, and nothing would be accomplished at all. As I said, that is how the LGPL _appears_. However, a close reading of the license text reveals what again appears to be a poison pill where commercial interests are concerned. Sections 5 and 6, in particular, seem in fact to put strings on executables that a company might want to sell. Section 5 states: "... linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables." And Section 6 states: "... As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications." These statements are very unfortunate, because they cross the boundary that the LGPL intends to establish between the OSS and commercial worlds, and dictate terms on the distribution of executable programs using LGPL-covered libraries. I have seen some discussion of these issues in other lists, and the responses to such objections are along the lines of "Well, modification and reverse-engineering happen anyway, and it's been determined to be legal in some European countries and probably will be here soon as well, so it doesn't really matter." But it _does_ matter. As I said before, one of our goals in covering code under the LGPL is to get companies to adopt the libraries instead of developing the infrastructure in-house. If there are any, and I do mean _any_, restrictions added to the sale and distribution of a company's executable product, the desired adoption will happen rarely, and certainly not by any large corporations with the means to develop in-house code. To put it another way: I guarantee that, as soon as a corporate lawyer gets a sniff of either of these provisions, whether they "don't matter" or not, that lawyer will immediately turn to the company's technical staff and say "Thou shalt not use library x for any product development purposes whatsoever." So, with that background, here are my questions: - Am I interpreting the aforementioned sections of the LGPL correctly? I am not a lawyer, so if there is a reasonable interpretation of the license that renders the objections I've raised moot, please enlighten me. - Assuming I'm interpreting the LGPL text correctly, are there any reasonable circumstances under which a company might be able to develop and deploy a binary executable without being subject to the stated conditions? - Assuming there are no such circumstances, are there any GPL-compatible licenses that behave similarly to the LGPL, but without the "obnoxious modification and reverse engineering clause"? - Assuming there is no such single license, is there a multi-license approach that might accomplish what I'm after? - If not, would it be difficult to surgically alter the LGPL to remove the OMAREC and maintain GPL compatibility? - If a "text-snipping" approach is inappropriate, can anyone give me an idea of where the "third rail" is with respect to modifying the LGPL to create a license that maintains anti-forking, remove all strings from the distribution of executable (but not library) products using the library, and preserves GPL compatibility? - If it is intractable to modify the LGPL, wou
