Re: What is Copyleft?
On Friday 23 February 2001 08:32 am, Dave J Woolley wrote: > [DJW:] In the normal course of programming the host > program will be combined with the header files (or typelib) > from the libary to produce the object code and the further > reference will be made to the library in producing the > final, executable. You would need clean room development > to avoid this. It would depend upon the specific header file. Although they are read in by the compiler, they do not always get translated into any bits. A header that is pure API (only function declarations) are in this class. The names of the functions get copied over into the resulting object file, but the header file itself does not. I believe that there was a case once that ruled you couldn't copyright an API. Header files that contain macros, inlines or templates would be a different matter. I think that even these things would be usable under fair use, since their intent is to support the interface. > One other point is that the argument is about whether the > letter of the GPL allows something rather than whether the > spirit does. Sometimes the "spirit" of one part of a license is in conflict with the "spirit" of another. In the case of the GPL, I feel that the spirit of "we won't restrict usage" could be in direct conflict with the spirit of "don't combine this in any way with 'foreign' stuff". And of course, the whole general spirit of "only use this particular license if you value freedom" is irrelevant. -- David Johnson ___ http://www.usermode.org
Re: What is Copyleft?
"Ryan S. Dancey" <[EMAIL PROTECTED]> writes: > If a court found that the first and third results Mr. Woolley enumerated > were not derivative works (and thus could ignore the terms of the LGPL or > the GPL for non-free code), I suspect that a case could be made to the FSF > for abandoning the use of the LGPL. The FSF is already abandoning the LGPL in any case. See http://www.gnu.org/philosophy/why-not-lgpl.html Ian
Re: What is Copyleft?
Dave J Woolley <[EMAIL PROTECTED]> writes: > > So, since glibc is available as a dynamic library, most uses of glibc > > do not conflict with the LGPL. The only way to conflict would be link > > against the static version of glibc and distribute the resulting > > binary without distributing the unlinked objects. > [DJW:] > But the whole point of this thread is that the FSF > consider running ld against dynamic libraries to > create a derivative work, even though the bulk of > the library is only accessed at run time. Sure, and that is a problem if the library is licensed under the GPL, but it is not a problem for a dynamic library licensed under the LGPL. The LGPL has the appropriate escape clauses in the way it defines a ``work which uses the Library.'' > Moreover, if that ld step didn't create a derivative > work, the unlinked object code would represent > a "work that uses the Library", and clause 6(b) would never apply. > The existence of clause 6(b) implies that the intention was that executables > that are dynamically linked should still be subject to the first paragraph > of > section 6. My reading is that section 6 only applies to binaries which are distributed with the library, or after they are linked with the library. That is not the case of typical binaries linked against glibc. I do think the binary which needs to be dynamically linked with glibc is ``work that uses the Library.'' Clause 6(b) is an escape hatch similar to clause 6(a) if you provide a way to replace the LGPL library which is being distributed with your binary. That is, you can provide unlinked objects, or you can provide some dynamic library mechanism. Ian
Re: What is Copyleft?
"Rod Dixon, J.D., LL.M." <[EMAIL PROTECTED]> writes: > I don't understand your last sentence, and it sounds as if you might be > making an important distinction. I am confused by your reference to linked > to static version and "unlinked objects." How could both be occurring with > the same library? The paragraph in question: > > So, since glibc is available as a dynamic library, most uses of glibc > > do not conflict with the LGPL. The only way to conflict would be link > > against the static version of glibc and distribute the resulting > > binary without distributing the unlinked objects. glibc is distributed as both a dynamic library (libc.so) and a static library (libc.a). The LGPL says that if you distributed a binary linked with a static library, you must also distribute, in addition, the unlinked objects. That way, if the library is updated, the recipient will be able to relink against the new version of the library, producing a new binary. You are correct that one would not normally have both a binary linked to a static library, and unlinked objects. The LGPL, however, says that you must provide both. Does that make more sense? I've been working with linker internals for so long that I'm no longer sure what is general knowledge and what is weird stuff that only a few people know. Ian
Re: What is Copyleft?
From: "Dave J Woolley" <[EMAIL PROTECTED]> > or you link it against the dynamic version to create a dynamically > *linked* executable, which can load the full text of the library > and run time. > There are three possibilities here: > > - unlinked (LGPL gives a dispensation on the headers used); In my opinion, not a derivative work. LGPL neither grants nor restricts rights to this situation, except as relates to the distribution of the source code of the LGPL'd material, and in that sense, the code might as well be GPL'd. The function prototypes in header files almost certainly cannot be copyrighted, thus there's no point in licensing their use. In fact, you can almost always call an exported function by ordinal number, thus I wouldn't even have to include the actual function names in my non-licensed code; I could just call the functions by ordinal rather than by name. > - statically linked; In my opinion, a derivative work of all the sources of the object code, because they're all combined into one work when the compilation is complete. With the GPL, all of that code would also have to be GPL'd. With the LGPL, nothing but the LGPL'd library code needs to be covered by the LGPL. This, I think, is the most valuable use of the LGPL for programmers working in a mixed free/non-free environment. It allows a free-software library to be used with non-free code. From the standpoint of the FSF, this is a very suboptimal situation (because it tends to allow non-free code to proliferate by leveraging free code). If a court found that the first and third results Mr. Woolley enumerated were not derivative works (and thus could ignore the terms of the LGPL or the GPL for non-free code), I suspect that a case could be made to the FSF for abandoning the use of the LGPL. I suspect that the "statically linked" scenario is permitted because allowing unlinked and dynamically linked code essentially means that not allowing it would just be frustrating, requiring a program to dynamically link at program start, essentially achieving the same result. > - dynamically linked. In my opinion, not a derivative work, because the parts are never combined into one work. In my opinion, from the standpoint of making a work a derivative work, the law does not understand or care about the concept of a thread of execution, no more than the law cares about the order you read pages in a collection of books. Furthermore, I would argue that the GPL doesn't cover this situation, because the GPL explicitly disclaims any authority over what the program does once it starts to execute. "The act of running the program is not restricted." The only part of the free code that is actually combined with the non-free code are the function prototypes, which I maintain cannot be copyrighted, and thus are not governed by the terms of either the LGPL or the GPL. Ryan
RE: What is Copyleft?
> From: Rod Dixon, J.D., LL.M. [SMTP:[EMAIL PROTECTED]] > > I don't understand your last sentence, and it sounds as if you might be > making an important distinction. I am confused by your reference to linked > to static version and "unlinked objects." How could both be occurring with > the same library? > [DJW:] When you build an executable that uses glibc, you first compile the various parts to create unlinked object files. You then either link those against the static version of the library to create a completely self contained executable, or you link it against the dynamic version to create a dynamically *linked* executable, which can load the full text of the library and run time. There are three possibilities here: - unlinked (LGPL gives a dispensation on the headers used); - statically linked; - dynamically linked. You can build glibc as either a static library or a dynamic library, and development systems would normally have both. -- --- 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: What is Copyleft?
> From: Rod Dixon, J.D., LL.M. [SMTP:[EMAIL PROTECTED]] > > Dave, I don't have the LGPL right in front of me, if you could quote the > provision you are referring to, it might help us respond. Even so, which > part of the license do you think is disobeyed, and why? > [DJW:] Last phrase in: 6. 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. E.g. Acrobat Reader is dynamically linked (see other reply and note clause 6(b) is reachable, but has no modification clauses).
Re: What is Copyleft?
I don't understand your last sentence, and it sounds as if you might be making an important distinction. I am confused by your reference to linked to static version and "unlinked objects." How could both be occurring with the same library? Rod > Dave J Woolley <[EMAIL PROTECTED]> writes: > > > I had a look over the LGPL and it seems to have some interesting > > restrictions on derivative works that are almost certainly > > violated more often than obeyed, at least for the glibc. > > It seems to require that limited licesnses be given to modify > > the code and to reverse engineer it to aid in modifying it. There > > are also requirements with regard to notifying the library copyright. > > > > As I read it, if you want to completely avoid restrictions, you > > must distribute the proprietory code as unlinked object files > > and let the end user create the final executable. (This only > > works for the LGPL as it contains exemptions for common uses of > > header files.) > > The LGPL, unlike the GPL, was intended to permit linking against > dynamic libraries covered by the LGPL without thereby bringing the > program which is linking against the dynamic library under the [L]GPL. > That is, in the case of an LGPL dynamic library, you can provide the > unlinked object files in the form of an executable which is linked to > the dynamic library by the dynamic linker (i.e., by the end user). > > So, since glibc is available as a dynamic library, most uses of glibc > do not conflict with the LGPL. The only way to conflict would be link > against the static version of glibc and distribute the resulting > binary without distributing the unlinked objects. > > Ian >
RE: What is Copyleft?
> From: Ian Lance Taylor [SMTP:[EMAIL PROTECTED]] > > So, since glibc is available as a dynamic library, most uses of glibc > do not conflict with the LGPL. The only way to conflict would be link > against the static version of glibc and distribute the resulting > binary without distributing the unlinked objects. [DJW:] But the whole point of this thread is that the FSF consider running ld against dynamic libraries to create a derivative work, even though the bulk of the library is only accessed at run time. Moreover, if that ld step didn't create a derivative work, the unlinked object code would represent a "work that uses the Library", and clause 6(b) would never apply. The existence of clause 6(b) implies that the intention was that executables that are dynamically linked should still be subject to the first paragraph of section 6. [DJW:] -- --- 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: What is Copyleft?
Dave, I don't have the LGPL right in front of me, if you could quote the provision you are referring to, it might help us respond. Even so, which part of the license do you think is disobeyed, and why? Rod > > From: Frank Hecker [SMTP:[EMAIL PROTECTED]] > > > > makes a distinction between licenses that are "copyleft" licenses, > > licenses that are "not a strong copyleft", and "non-copyleft" licenses. > > Thus the GPL is described as a "copyleft license", but the LGPL is > > described as "not a strong copyleft license, because it permits linking > > with non-free modules"; the MPL (which permits both static and dynamic > > > [DJW:] > I had a look over the LGPL and it seems to have some interesting > restrictions on derivative works that are almost certainly > violated more often than obeyed, at least for the glibc. > It seems to require that limited licesnses be given to modify > the code and to reverse engineer it to aid in modifying it. There > are also requirements with regard to notifying the library copyright. > > As I read it, if you want to completely avoid restrictions, you > must distribute the proprietory code as unlinked object files > and let the end user create the final executable. (This only > works for the LGPL as it contains exemptions for common uses of > header files.) > > IANAL > -- > --- 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: What is Copyleft?
Dave J Woolley <[EMAIL PROTECTED]> writes: > I had a look over the LGPL and it seems to have some interesting > restrictions on derivative works that are almost certainly > violated more often than obeyed, at least for the glibc. > It seems to require that limited licesnses be given to modify > the code and to reverse engineer it to aid in modifying it. There > are also requirements with regard to notifying the library copyright. > > As I read it, if you want to completely avoid restrictions, you > must distribute the proprietory code as unlinked object files > and let the end user create the final executable. (This only > works for the LGPL as it contains exemptions for common uses of > header files.) The LGPL, unlike the GPL, was intended to permit linking against dynamic libraries covered by the LGPL without thereby bringing the program which is linking against the dynamic library under the [L]GPL. That is, in the case of an LGPL dynamic library, you can provide the unlinked object files in the form of an executable which is linked to the dynamic library by the dynamic linker (i.e., by the end user). So, since glibc is available as a dynamic library, most uses of glibc do not conflict with the LGPL. The only way to conflict would be link against the static version of glibc and distribute the resulting binary without distributing the unlinked objects. Ian
RE: What is Copyleft?
> From: Frank Hecker [SMTP:[EMAIL PROTECTED]] > > makes a distinction between licenses that are "copyleft" licenses, > licenses that are "not a strong copyleft", and "non-copyleft" licenses. > Thus the GPL is described as a "copyleft license", but the LGPL is > described as "not a strong copyleft license, because it permits linking > with non-free modules"; the MPL (which permits both static and dynamic > [DJW:] I had a look over the LGPL and it seems to have some interesting restrictions on derivative works that are almost certainly violated more often than obeyed, at least for the glibc. It seems to require that limited licesnses be given to modify the code and to reverse engineer it to aid in modifying it. There are also requirements with regard to notifying the library copyright. As I read it, if you want to completely avoid restrictions, you must distribute the proprietory code as unlinked object files and let the end user create the final executable. (This only works for the LGPL as it contains exemptions for common uses of header files.) IANAL -- --- 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: What is Copyleft?
On Fri, 23 Feb 2001, Rod Dixon, J.D., LL.M. wrote: > Interesting point. In the ordinary course of programming, I suspect there > would be no derivative work created, hence the GPL should provide no > obstacle for distributing the program as open source. As you mentioned, > there could be a counter-example such as the development of a text editor > for Windows that not only makes calls to print drivers that MS has thrown in > its OS, but also to DLLs written by printer manufacturers. Add to that fact > that the windows text editor reads into those drivers additional True Type > fonts (independently copyrightable) and you my have a genuine derivative > work question. Something similar first turned up long ago when GNU software first was ported to PCs. Even regular compilers link programs to libraries that come with the compiler, and there was concern that the GPL did not allow this since those libraries didn't come with the OS, but with the compiler. The "solution" was for RMS to state that standard compiler libraries count as operating system components even if they don't really come with the operating system. I still find this unconvincing; but I would expect that a similar rationalization would work with printer drivers. (One of the biggest reasons this is unconvincing is that it doesn't bind anyone else. RMS can only redefine OS components on GPL software that is his, not on GPL software from other people.)
RE: What is Copyleft?
> From: Rod Dixon, J.D., LL.M. [SMTP:[EMAIL PROTECTED]] > > Interesting point. In the ordinary course of programming, I suspect there > would be no derivative work created, hence the GPL should provide no > obstacle for distributing the program as open source. As you mentioned, > [DJW:] In the normal course of programming the host program will be combined with the header files (or typelib) from the libary to produce the object code and the further reference will be made to the library in producing the final, executable. You would need clean room development to avoid this. One other point is that the argument is about whether the letter of the GPL allows something rather than whether the spirit does. If the letter is found defective, it is resonable to assume that the next version of the [L]GPLed code will have a licence that is no longer defective. You would then be stuck with having to maintain a separate development branch. IANAL [DJW:] -- --- 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: Fw: What is Copyleft?
> Imagine I have two novels. > > On page 100 of Novel A, there is an instruction: Open up Novel B, turn to > Chapter 7. When finished, come back to this point and continue reading. > > As the reader, (the processor in this analogy) I follow these instructions. > My "thread of execution" takes me from Page 100 in Novel A, to Chapter 7 of > Novel B, and back to page 100 of Novel A again. > > Are Novel A and B now a derivative work? > > Ryan A derivative work of what? each other? The short answer is No. (BTW, in the context of copyright, one ought not view source code as an instruction to a computer. Remember, it's speech). :-) Rod
Re: What is Copyleft?
> > > How can that create a derivative work? > > > > Well, the question is why wouldn't it? > > Because you're not modifying the original work. You're not adding anything > to it. The two parts (the Program and the Library) aren't ever combined > into one work. If you would argue that they are combined because they're > both loaded into memory together, than you'd have to say that >everything< > in the computer's memory formed a derivative work, so you could >never< use > a GPL'd program unless every byte of information in the computer's memory > was also GPL'd. If by "adding anything" you mean an adaptation of the pre-exsisting work sufficient to make an original work, then, yes, I agree with you. If you are referring to the fact that the work vanishes in seconds, then I disagree. I was not sure which point you were really making, and the two are quite distinct. > > Try a better hypo or simply state what you are driving at. > > My above example is flawed. It should have read "a database management > program". > > I'm suggesting that the definition of a derivative work can't include data > being passed between two independent pieces of code, via file, via a > network, or via an internal process communication. Making a function call > is not the same thing as actually incorporating the code of that function > into the body of the calling code. > > When you make a function call in compile-time linked code, you are creating > a derivative work, because the function code itself will be compiled into > the Program and inextricably combined with your code. When the two are > separated by a run-time linking, there can be no derivative work. > Imagine this example: > > I write a program which runs interactively. It takes an input of the name > of a DLL. > The program loads the DLL, which will cause some of the code in that DLL to > excecute automatically when the library is loaded, even if the calling > program does nothing. > > If the hypothosis that run-time linking created derivative works is true, > the above program could never be covered by the GPL, because the person who > distributed it would not be able to provide permission to create the > derivative work of the Program + DLL when run. Interesting point. In the ordinary course of programming, I suspect there would be no derivative work created, hence the GPL should provide no obstacle for distributing the program as open source. As you mentioned, there could be a counter-example such as the development of a text editor for Windows that not only makes calls to print drivers that MS has thrown in its OS, but also to DLLs written by printer manufacturers. Add to that fact that the windows text editor reads into those drivers additional True Type fonts (independently copyrightable) and you my have a genuine derivative work question. Under copyright law, the adaptation of the print drivers may be considered fair use. (particularly those deemed part of the OS...although I could think of a hypo that could produce instant lititgation on both sides involving the copyright holders of the drivers developed by the printer manufacturers). The GNU GPL, however, would seem to permit an open source windows text editor to exist in this manner as well. You might say that the derivative work is evanescent, and under such cases the GNU GPL is silent. Indeed, as I stated before, I do not think the GPL should preclude participation of the Program as an open source project under such cases. Why should the GPL control the copyright interests in all of the libraries that are used by open source software? I have not read RMS as saying this, but perhaps he has done so. No question there is some risk or tension in reliance on closed DLLs, but those issues should probably be addressed as they arise (e.g., the use of the GNU LGPL). > > This is not such a far-fetched example. This is how printer and video > drivers work in Windows, for example; and many are not distributed with the > OS. It would be impossible to write a GPL'd program that used the standard > device-driver model for printing using Windows if this run-time linking > hypothesis were valid. You are correct, but this point is not unique to the GPL. If common dynamic liking to OS drivers created derivative works (which is not to say that this can never be so...just that it is not the usual case), Microsoft may have controlled the market for third party applications running on its OS to a far greater extent than commonly understood. Rod
Nortel Networks Open Source License - comments?
Please find Nortel's open source license attached - it is a couple of years old, but not generally used apart from with FIPA-OS. It says it is based on the OpenTelecom license. Any views on this would be appreciated. It seems to be good on intellectual property... and not too onerous. Regards, Rghoo FIPA_OS_Public_License.pdf
RE: What is Copyleft?
> From: Ryan S. Dancey [SMTP:[EMAIL PROTECTED]] > > > Is the argument that a run-time link to external code creates a derivative > work (in the sense that the copyright statutes define a derivative work) > of [DJW:] I don't think so. It think the argument is about taking GPLed code that doesn't link with the library and deriving a work that does link with the library. Whilst it is arguable as to whether the FSF's current interpretation of their licence is consistent with what the licence actually says, a copyright owner does have the power to license code with a restriction that derived works may not be dynamically linked with certain categories of shared library. > the Program and the external code? Under this theory, you couldn't use > GPL'd code with RPC or HTML or SMPT or any other inter-process > communication > system unless the whole system was GPL'd! [DJW:] I don't believe there is any problem in using it even with proprietory shared libraries providing that the shared library is being substituted for a licence compatible one. The problem is in producing a derived work specifically intended to be used with a proprietory library, including the thorny cases of various devices intended to artificially create the first situation. You can also do what you like for internal use. To be more concrete, if you develop a library that implements an algorithm for predicting future prices in the widgets market but decide that, to save development costs, you should use a GPLed user interface library, if you could dynamically link without restriction, you could create a GPLed user interface that was only useable with your program to achieve something that you would not be allowed to do if you statically linked. You would therefore have produced a complete work in which the GPLed part was only useable as part of the proprietory whole. > If I understand the internals of the situation correctly (which I may > not), > a program that binds to a DLL at runtime does so through the mediation of > the OS. Data is packaged, handed to the OS, the OS moves it from the [DJW:] In general no. In general a few addresses in the code are fixed up by the loader. A small amount of code may get added in some implementations, but that code is normally self contained. IANAL -- --- 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.
