Re: GPL and command-line libraries
Anthony DeRobertis wrote: Nathanael Nerode wrote: (The FSF's statements that linking with a library creates a derviative work of the library confuse people; it may help to remember that this only applies to the *binary image* created by the linkage, which contains elements of the library, not to the source code of the program using the library.) A derivative work requires creative input. Neither a compiler nor a linker can provide that. There is no creative input in typing make, so the binary can't be a derivative work if the inputs were not. What is the correct term for a work that combines two other works, created without creative input? -- Lewis Jardine IANAL, IANADD
Re: GPL and command-line libraries
Lewis Jardine [EMAIL PROTECTED] writes: Anthony DeRobertis wrote: Nathanael Nerode wrote: (The FSF's statements that linking with a library creates a derviative work of the library confuse people; it may help to remember that this only applies to the *binary image* created by the linkage, which contains elements of the library, not to the source code of the program using the library.) A derivative work requires creative input. Neither a compiler nor a linker can provide that. There is no creative input in typing make, so the binary can't be a derivative work if the inputs were not. What is the correct term for a work that combines two other works, created without creative input? An anthology, or a compilation, I think. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL and command-line libraries
Måns Rullgård wrote: Lewis Jardine [EMAIL PROTECTED] writes: What is the correct term for a work that combines two other works, created without creative input? An anthology, or a compilation, I think. From Title 17, Sec 101: A ''collective work'' is a work, such as a periodical issue, anthology, or encyclopedia, in which a number of contributions, constituting separate and independent works in themselves, are assembled into a collective whole. A ''compilation'' is a work formed by the collection and assembling of preexisting materials or of data that are selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship. The term ''compilation'' includes collective works. I don't think those are the appropriate terms; it would appear that a compilation (including collective works) need to be original works of authorship. That requires creative input. If it isn't creative, it isn't a work under copyright law. See, e.g., Fesit v. Rural Telephone Service, holdings (a) and (b). http://caselaw.lp.findlaw.com/scripts/getcase.pl?navby=casecourt=USvol=499invol=340 AFAICT, the output of the compiler is treated under copyright law the same way the source code would be; I supect the best term we have for this situation is mere aggregation of two seperate works. IOW, 'ld' in this case is performing the same function 'tar' normally would.
Re: GPL and command-line libraries
I am concerned there might have been some confusion about terms here. Code here can mean three things: source code -- my copyrighted implementation of an: error correcting code -- an algorithm I developed which operates on: encoded data -- the data being transmitted in a special form In this reply I try to use exactly those phrases and never 'code' alone. On Fri, Nov 26, 2004 at 10:42:27PM -0500, Nathanael Nerode wrote: Wesley W. Terpstra [EMAIL PROTECTED] wrote: What I am concerned about is the following scenario: Mr. John Wontshare writes a streaming multicast client. To deal with packet loss, he uses my error-correcting library. Without my library, Mr. Wontshare's client can't work at all. That statement is probably incorrect! If your library has a well-specified API, anyone could make a library with the same API, and his client could use that. I am perfectly fine with this. If he uses someone else's source code to implement my API, so be it. Of course, that new source code would have to be able to decode the same encoded data, which I am also fine with. They could also reuse the same algorithm since I don't find it ethical to patent algorithms. Under those circumstances, his client is not a derivative work of your library I don't see the difference here between a real library and a command-line interface. Any library could have a command-line interface wrapped around it in order to avoid 'linking'. So how can the FSF talk about linked applications being derivative works. [I've moved your later paragraph to here]: (The FSF's statements that linking with a library creates a derviative work of the library confuse people; it may help to remember that this only applies to the *binary image* created by the linkage, which contains elements of the library, not to the source code of the program using the library.) This is the case I care about. Mr. Wontshare is shipping a binary version of his program which has hooks via 'system' or whatever into my binary command-line library which he also ships. What is a binary image? I think it makes most sense that it includes the entire shipped product---both my executable and it's dependent: his. Whether the library and binary form a single file seems irrelevant. Otherwise, .dll's or .so's would also avoid this 'binary image' issue. What is the difference between 'dlopen' and 'system'? The readline/editline situation is a good parallel here. A program which can be linked to either library is not a derivative work of readline, and does not need to be under GPL. I admit to being mostly clueless about legal issues, but it feels to me that the difference here of 'can be linked' and 'requires to be linked' are two different things. Are they or aren't they? Regardless, this is not the main thrust of my argument. My main point is that he is shipping a product including his compiled program and mine. His compiled program is 'linked' via 'system' to my application. If you deleted my application, his will stop working. I am not taking away any of his rights; he is shipping my code! Without a grant of licence from me, he can't do that. (Incidentally, if your error correcting code or your API spec is in fact copyrightable, you could put that under the GPL, which would achieve your goal. If it's really quite simple, as you said, then it's probably not subject to copyright.) The error-correcting code algorithm and implementing source code are not themselves simple---only the API is simple. As I understood it, however, the algorithm and would be protected by a patent, not a copyright. In what way can I protect this with the GPL? What are you proposing I could copyright as 'error correcting code'? I think confusion of terms is perhaps the problem here? He then distributes his client along with my library to end-users. These users don't get Mr. Wontshare's code, even though he uses my library. (but they do get your library's code). Even worse, he refuses to port his client to MacOS X for business reasons. (intentionally giving an unfair competitive advantage to another platform) To me anyways, this sounds like exactly the situation the GPL is supposed to protect against. It isn't. You've misunderstood the GPL. The GPL is supposed to protect against modified versions of your library being taken proprietary; that's the exact situation it's supposed to protect against. As far as I can see, I haven't misunderstood it at all; what you describe is what's happening here. Mr. Wontshare has taken my work and integrated it as a critical component into his project which he then ships together with my work. Yes, he supplies my source code, but not the source code of the rest of the combined project. He has taken a modified version of my library proprietary. His project is a modified/enhanced version of my library and his own work. Is this _not_ a derivative work? That's a factual question. It's most
Re: GPL and command-line libraries
On Sat, Nov 27, 2004 at 11:07:02AM -0500, Anthony DeRobertis wrote: If it isn't creative, it isn't a work under copyright law. See, e.g., Fesit v. Rural Telephone Service, holdings (a) and (b). http://caselaw.lp.findlaw.com/scripts/getcase.pl?navby=casecourt=USvol=499invol=340 A problem comes in determining what's creative and what's not. While the rules for patents aren't quite the same as the rules for copyrights, it's perhaps illustrative to consider what the government has considered creative in the context of patents to see just how different the legal context can vary from the views of experts in some field. [Fortunately, most (unfortunately, not all) of those cases are so egregious that they can be ignored.] That said, in the U.S. at least, fair use would seem to cover most shell scripts and such. That said, if a shell script is so large that fair use wouldn't cover it -- if it's doing things where there are significant sections which are radically different from the obvious sorts of things that everyone else is doing -- then we're probably out of the area where it isn't creative adequately describes what's happening. In other words: most of the time shell scripts aren't going to matter, but it's not safe to make a general rule that that's always the case. -- Raul
Re: GPL and command-line libraries
Anthony DeRobertis [EMAIL PROTECTED] writes: Måns Rullgård wrote: Lewis Jardine [EMAIL PROTECTED] writes: What is the correct term for a work that combines two other works, created without creative input? An anthology, or a compilation, I think. From Title 17, Sec 101: A ''collective work'' is a work, such as a periodical issue, anthology, or encyclopedia, in which a number of contributions, constituting separate and independent works in themselves, are assembled into a collective whole. A ''compilation'' is a work formed by the collection and assembling of preexisting materials or of data that are selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship. The term ''compilation'' includes collective works. I don't think those are the appropriate terms; it would appear that a compilation (including collective works) need to be original works of authorship. That requires creative input. Was the question concerning the term for a work consisting of other works, each in itself the product of creative work (and thus copyrightable), combined into a single work without any additional creative work, or was the question for combination of parts which are not by themselves copyrightable, combined without creative effort, or a combination of non-creative parts in a creative fashion? Producing a compilation may or may not involve creative work. For instance, in the production of a literary anthology, there may be significant amounts of work in the selection of parts to include, as well as their order. In this case, the compilation might be protected by copyright law. On the other end, a collection consisting of all works published during some specific time interval, is not the result of creative work. If it isn't creative, it isn't a work under copyright law. See, e.g., Fesit v. Rural Telephone Service, holdings (a) and (b). http://caselaw.lp.findlaw.com/scripts/getcase.pl?navby=casecourt=USvol=499invol=340 This case is about a telephone directory. Quite obviously, each individual entry cannot be considered a creative work (it is an arbitrary number assigned to a name), and simply collecting all of them is not considered to add any creative element. AFAICT, the output of the compiler is treated under copyright law the same way the source code would be; I supect the best term we have for this situation is mere aggregation of two seperate works. IOW, 'ld' in this case is performing the same function 'tar' normally would. The compiler outputs a mechanical transformation of its input. If the input was covered by copyright, then the output will be as well, otherwise it will not. Mechanically transforming something does not add any creative value, and hence does not alter the copyright status of whatever is being transformed. Mechanically combining two works into one, as might be done by the linker, does not either add any creative element. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL and command-line libraries
On Sat, Nov 27, 2004 at 05:20:46PM +0100, Wesley W. Terpstra wrote: What is a binary image? I think it makes most sense that it includes the entire shipped product---both my executable and it's dependent: his. Whether the library and binary form a single file seems irrelevant. Otherwise, .dll's or .so's would also avoid this 'binary image' issue. What is the difference between 'dlopen' and 'system'? You're almost right. The technical method by which derivation or aggregation is accomplished is irrelevant. Varying the method will not change the state from derivation to aggregation, or vice versa: ld is not automatically derivation, nor is tar automatically aggregation. The state of a work being derived is intrinsic to the work itself. It doesn't become derived because you add a useless unnecessary -l argument to the compiler, and it doesn't stop being derived because you have a trained monkey copying the data around by hand between processes. When we talk about 'linking', we're really referencing the fact that it's normally used in a certain way. It's not magic, it just happens that linking to a library will normally occur in the cases where you've got a derived work, because anything else is insane from a technical perspective. Getting overly attached to the notion of 'linking' leads to navel-gazing exercises and not much else. The exact determination of what is and is not derived is notoriously fuzzy and ultimately a matter for the courts (yeah, copyright sucks). I find a good rule of thumb to be: If your application will only work in the presence of some specific other code, it's a derived work, otherwise it's not, which leads neatly to the library API thing. In essence: playing games at the interface boundary cannot exempt you from license requirements. Only a sufficiently expensive lawyer can do that. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL and command-line libraries
Scripsit Wesley W. Terpstra [EMAIL PROTECTED] If your library has a well-specified API, anyone could make a library with the same API, and his client could use that. I am perfectly fine with this. If he uses someone else's source code to implement my API, so be it. Of course, that new source code would have to be able to decode the same encoded data, which I am also fine with. Not necessarily. It is quite possible that someone could find mr. Wontshare's application useful when linked against a library that encodes data in a different way from your library. It is not a given that everybody will find interoperability with instances that use your library important. Under those circumstances, his client is not a derivative work of your library I don't see the difference here between a real library and a command-line interface. Agreed. So how can the FSF talk about linked applications being derivative works. They use a legal loophole known as freedom of speech, which enables them to make claims that may not be actually be true as stated. If the question of whether a given work is derived from a GPLed library ends up in court (whit, ttbomk it yet never has), there is no guarantee that the court will accept the FSF's claim as the natural basis for making the judgement. One can certainly imagine cases where any judge in his right mind (and of sufficient technical understanding) would rule that this particular program using that particular GPL'ed library is in fact a derived work in a pro forma technical disguise, and should therefore be covered by the library's licensing terms. However, one can also imagine cases where any judge in his right mind would rule differently. And there is a large grey area between those two extremes. The only thing that is certain is that the matter is not as clear-cut as the FSF would like to make people think. Whether the library and binary form a single file seems irrelevant. Otherwise, .dll's or .so's would also avoid this 'binary image' issue. What is the difference between 'dlopen' and 'system'? Not very large, legally speaking. It is a common error for people with a primarily technical viewpoint to think that the legal questions are decided primarily by the tecnical nature of the connection between the two works. In fact, the technical details make little difference once we get past the opening question of does this directly contain some of his bits or not?. The important consideration is the high-level *intention* of the connection, including what the different parts actually *do*. If library L provides to program P an well-defined generic service with a simple black-box interface, and it is provided in a way that is essentially independent that the client is P rather than an unrelated program Q, then I think it is very hard to argue that the source code for P is derived from L (and similarly for compiled versions of P that do not include a statically linked L). On the other hand, if L exports a lot of hooks for P to inject its own code into whatever L does, or P depends intensively on internals of L that are not easily decribed as a generic service interface, then a good case could be made that P is effectively derived from L. Between these two extremes are, as always, a big scary grey area. I am not taking away any of his rights; he is shipping my code! Without a grant of licence from me, he can't do that. It is of course completely true that you as an author have the power to forbid him from distributing your code, and you can set any odd conditions for giving a license that you want. However, you can forbid this and still give your source code a license that Debian would consider free is a more difficult question. Here I am inclined to think that the answer is no. The error-correcting code algorithm and implementing source code are not themselves simple---only the API is simple. But that does mean that your library provides a generic black-box service, which makes is *unlikely* that you cound succesfully argue in court that the source code for the application is derived from your work. It isn't. You've misunderstood the GPL. The GPL is supposed to protect against modified versions of your library being taken proprietary; that's the exact situation it's supposed to protect against. As far as I can see, I haven't misunderstood it at all; what you describe is what's happening here. No, there is no modified version of your library in your scenario. Mr. Wontshare has taken my work and integrated it as a critical component into his project which he then ships together with my work. As far as you have described it, there is no real integration going on. He has taken a modified version of my library proprietary. No, he hasn't. He hasn't even *created* a modified version of your library. In my case, it would be a 'black box'. Exactly. I've never advocated preventing him from writing a compatible program. What
