Re: GPL and command-line libraries
Brian Thomas Sniffen wrote: But in the case of the DFSG and the GPL it does. Saying You may not distribute this work along with a frame designed to hold it violates DFSG 1. But saying You may only distribute this work with a frame designed to hold it if that frame is freely distributed is Free. No it isn't. DFSG 9 (For example, the license must not insist that all other programs distributed on the same medium must be free software.) And the GPL does not attempt to cover the frame; the GPL explicitly defines a work based on the Program as either the Program or any derivative work under copyright law. And it further clarifies *that* to be a work containing the Program or a portion of it, either verbatim or with modifications. So if you ld or tar some programs together, you now have a work containing the Program verbatim. The full sentense is: The Program, below, refers to any such program or work, and a work based on the Program means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term modification.) I think that is to say introduces a laymans explanation of what a derivative work is. In order to accept the alternate explanation --- that it seeks to define derivative work --- we'd have to (a) disregard its explicit definition as a derivative work under copyright law and (b) grant the FSF powers generally reserved to congress and the courts. Further, we can not say that tar can create a work containing the program because copyright law concerns itself only with creative works; tar can not do such a thing. Instead, we just have two seperate works. I would *almost* say you're right. It seems very close. Your argument is persuasive. But there is an assumption you're making which you haven't made explicit: that any combination of two works is either a derivative work, involving creative addition, or else is mere aggregation. This is the fallacy of the excluded middle. The middle is excluded by Title 17 Sec. 106, not me. For a literary work (such as a computer program), there are three exclusive rights listed: To copy it, to distribute it, and to create derivative works. Some works are neither derivative works nor mere aggregation; they might be functional combinations, for example. Yes, but it's a copyright licence; under copyright law, has anything other than mere aggregation happened? Which clause of the GPL would I be violating by distributing such a functional combination with one part GPL'd and the other part not? And why isn't Debian violating this same clause? Or they might be anthologies, in which creative effort has been expended in the selection of works. Creating an anthology isn't listed as one of the copyright holder's exclusive rights; presumably, if he grants you the right to reproduce and distribute, you may create an anthology. (Remember, the copyright over an anthology only applies to the anthology itself, not to the individual works) If I tar up Emacs and a bunch of its elisp files, certainly that's not mere aggregation. http://lists.debian.org/debian-legal/2002/11/msg00217.html contains a quoted message from RMS on a similar subject.
Re: GPL and command-line libraries
Anthony DeRobertis [EMAIL PROTECTED] writes: Brian Thomas Sniffen wrote: But in the case of the DFSG and the GPL it does. Saying You may not distribute this work along with a frame designed to hold it violates DFSG 1. But saying You may only distribute this work with a frame designed to hold it if that frame is freely distributed is Free. No it isn't. DFSG 9 (For example, the license must not insist that all other programs distributed on the same medium must be free software.) This isn't talking about all other programs on the same medium. It is only talking about those programs integrated with the GPL'd program. And the GPL does not attempt to cover the frame; the GPL explicitly defines a work based on the Program as either the Program or any derivative work under copyright law. And it further clarifies *that* to be a work containing the Program or a portion of it, either verbatim or with modifications. So if you ld or tar some programs together, you now have a work containing the Program verbatim. The full sentense is: The Program, below, refers to any such program or work, and a work based on the Program means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term modification.) I think that is to say introduces a laymans explanation of what a derivative work is. In order to accept the alternate explanation --- that it seeks to define derivative work --- we'd have to (a) disregard its explicit definition as a derivative work under copyright law and (b) grant the FSF powers generally reserved to congress and the courts. I don't think the problem of interpretation is nearly so bad as you imply. It seems clear that they mean both 17USC Derivative Works and other works derivative of the Program. Since the GPL is intended to have reasonable functionality in many copyright regimes, I think any attempt to force it to a single verbatim definition of copyright law is unlikely to succeed. So we do not need to grant the FSF exceptional power to redefine law, and neither do we need to disregard any explicit definitions. As with any licensor who gives close but not exactly synonymous definitions, we treat the definition as the union or intersection of those definitions, as appropriate. The safe choice here is the union: so the GPL covers all derivative works under your local copyright regime, and also restricts any work containing the Program or a portion of it, with or without modifications. It avoids violating GPL 9 by later removing all restrictions on mere aggregation. Further, we can not say that tar can create a work containing the program because copyright law concerns itself only with creative works; tar can not do such a thing. Instead, we just have two seperate works. Certainly tar creates a work containing the program. The user who chooses which programs to tar together creates an anthology, a collective work. Additionally, some works have creative content and some do not. A work made without creative content -- say, by just tarring together to randomly selected files -- does not evade copyright restrictions on those files. It is a copy of them. If you run tar cf /tmp/foo /usr/bin/emacs21, then you have made a copy of GNU Emacs. You may only do this as permitted by its license. Some works are neither derivative works nor mere aggregation; they might be functional combinations, for example. Yes, but it's a copyright licence; under copyright law, has anything other than mere aggregation happened? Mere aggregation is not a phrase from copyright law. It is from the GPL. With relevance to copyright law, copying and distribution have each happened. The GPL permits such copying and distribution, under the conditions that the entire modified work be distributed under the terms of the GPL. Which clause of the GPL would I be violating by distributing such a functional combination with one part GPL'd and the other part not? And why isn't Debian violating this same clause? You're not distributing a verbatim copy, so you can't distribute under clause 1. You have to use clause 2. Well, under clause 2, you have modified your copy of the Program, forming a work based on the Program. You have then copied and distributed that work. Under 2b, you must cause the work you distribute, which in part contains the Program, to be licensed under the GPL. Following the text after 2c: If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which
Re: GPL and command-line libraries
On Mon, Dec 06, 2004 at 12:51:34AM -0500, Anthony DeRobertis wrote: A compiler can only perform a transformation from source to object form programmed into it by its creators; it is neither an author nor capable of creativity; it can this not produce an original work of authorship or thus a derivative work. If A is derivative work of B, then the compiled form A' is probably too. If A is not a derivative work of B, then A' is not either. I seem to recall someone arguing that A' containing inlined functions from B would constitute a form of derivation. At least distributing A' would also be distributing parts compiled from B. Regards, David -- * Customer: My palmtop won't turn on. * Tech Support: Did the battery run out, maybe? * Customer: No, it doesn't use batteries. It's Windows powered. -- http://www.rinkworks.com/stupid/cs_power.shtml
Re: GPL and command-line libraries
Alessandro Rubini wrote: Actually, I've never heard the FSF claim that the _source_code_ of a program using a (black-box) library is derived from the library. What it claims is that the executable is derived from both, Maybe there is some confusion here between derived in everyday language and derivative work in copyright law? It is, I think, as certain as any law can be that copyright (at least in the US) requires an original work of authorship, which requires an author and a creative input. I think it is fairly certain worldwide that a derivative work requires the same. A compiler can only perform a transformation from source to object form programmed into it by its creators; it is neither an author nor capable of creativity; it can this not produce an original work of authorship or thus a derivative work. If A is derivative work of B, then the compiled form A' is probably too. If A is not a derivative work of B, then A' is not either. I'd be surprised to see the FSF argue something other than the above. Then again, http://www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA seems to. and the authors of either part have their say in choosing distribution terms. That is quite true. After all, you can require any condition (within the law) you want to even allow people to copy the software; however, such conditions may (of course) not be free.
Re: GPL and command-line libraries
Compare, for example, a painting. If I make a painting with a 5' by 3' hole in it, that is not derivative of Starry Night. Even if I paint in complementary art such that if you put SN in there, it looks nice, that's probably not derivative. But if I bolt the two paintings together, and ship copies of the whole thing, then a) I'm shipping Starry Night, so its copyright holder gets a say. b) the bolts aren't a creative work c) This clearly isn't mere aggregation So whether or not it's a derivative work, in the sense of any nation's copyright laws, doesn't really matter. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: GPL and command-line libraries
On Mon, Dec 06, 2004 at 02:37:08AM -0500, Brian Thomas Sniffen wrote: Compare, for example, a painting. If I make a painting with a 5' by 3' hole in it, that is not derivative of Starry Night. Even if I paint in complementary art such that if you put SN in there, it looks nice, that's probably not derivative. But if I bolt the two paintings together, and ship copies of the whole thing, then a) I'm shipping Starry Night, so its copyright holder gets a say. b) the bolts aren't a creative work c) This clearly isn't mere aggregation So whether or not it's a derivative work, in the sense of any nation's copyright laws, doesn't really matter. You don't actually need (c). I doubt any lawyer would bother to pursue the 'derivative work' angle when they had the 'contains my stuff' one available. This does appear intuitively to be the correct answer for the case where two otherwise non-derivative works are combined into a single binary. They don't magically become derivatives, invoking that clause of the GPL, but you still have to follow its rules for binary distribution. Pathological case: link in a library you don't use. On the other hand, I can't think of a scenario where this could possibly matter. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL and command-line libraries
Brian Thomas Sniffen wrote: Compare, for example, a painting. If I make a painting with a 5' by 3' hole in it, that is not derivative of Starry Night. Even if I paint in complementary art such that if you put SN in there, it looks nice, that's probably not derivative. But if I bolt the two paintings together, and ship copies of the whole thing, then a) I'm shipping Starry Night, so its copyright holder gets a say. b) the bolts aren't a creative work c) This clearly isn't mere aggregation So whether or not it's a derivative work, in the sense of any nation's copyright laws, doesn't really matter. But in the case of the DFSG and the GPL it does. Saying You may not distribute this work along with a frame designed to hold it violates DFSG 1. And the GPL does not attempt to cover the frame; the GPL explicitly defines a work based on the Program as either the Program or any derivative work under copyright law.
Re: GPL and command-line libraries
Andrew Suffield wrote: This does appear intuitively to be the correct answer for the case where two otherwise non-derivative works are combined into a single binary. They don't magically become derivatives, invoking that clause of the GPL, but you still have to follow its rules for binary distribution. Agreed. Pathological case: link in a library you don't use. You wouldn't have to distribute the source of that library, AFAICT. Clause 3 is limited to the program (or a work based on it, under Section 2). Clause 0 explicitly defines that to mean the program or a derivative work of it. Clause 3(a) requires including the complete corresponding machine-readable source code. The complete corresponding source code to the Program does not include the library. IOW, tar vs. ld is a technical distinction that really doesn't matter. On the other hand, I can't think of a scenario where this could possibly matter. That's never stopped this mailing list before :-)
Re: GPL and command-line libraries
Anthony DeRobertis [EMAIL PROTECTED] writes: Brian Thomas Sniffen wrote: Compare, for example, a painting. If I make a painting with a 5' by 3' hole in it, that is not derivative of Starry Night. Even if I paint in complementary art such that if you put SN in there, it looks nice, that's probably not derivative. But if I bolt the two paintings together, and ship copies of the whole thing, then a) I'm shipping Starry Night, so its copyright holder gets a say. b) the bolts aren't a creative work c) This clearly isn't mere aggregation So whether or not it's a derivative work, in the sense of any nation's copyright laws, doesn't really matter. But in the case of the DFSG and the GPL it does. Saying You may not distribute this work along with a frame designed to hold it violates DFSG 1. But saying You may only distribute this work with a frame designed to hold it if that frame is freely distributed is Free. And the GPL does not attempt to cover the frame; the GPL explicitly defines a work based on the Program as either the Program or any derivative work under copyright law. And it further clarifies *that* to be a work containing the Program or a portion of it, either verbatim or with modifications. So if you ld or tar some programs together, you now have a work containing the Program verbatim. I would *almost* say you're right. It seems very close. Your argument is persuasive. But there is an assumption you're making which you haven't made explicit: that any combination of two works is either a derivative work, involving creative addition, or else is mere aggregation. This is the fallacy of the excluded middle. Some works are neither derivative works nor mere aggregation; they might be functional combinations, for example. Or they might be anthologies, in which creative effort has been expended in the selection of works. ld can be used to create mere aggregations. It can also be used to create functional combinations, and is usually used in this way. tar can be used in either way as well. If I tar up Emacs and a bunch of its elisp files, certainly that's not mere aggregation. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: GPL and command-line libraries
Henning Makholm (with my emphasis): 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). [...] 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. Actually, I've never heard the FSF claim that the _source_code_ of a program using a (black-box) library is derived from the library. What it claims is that the executable is derived from both, and the authors of either part have their say in choosing distribution terms. OTOH, I agree that source code for a program that deeply depends on the internal structure of a specific library might be considered a derived work of that library. But I don't think this point really matters here. But yes, I agree there is a vast gray area between what is clearly derived and what is clearly not. /alessandro
Re: GPL and command-line libraries
On Thu, 2 Dec 2004, Raul Miller wrote: If there is -- if Wontshare in some way tries to enforce the use of readline, then this non-distributable product is being distributed Why? Distributing X, which relies on Y, isn't the same as distributing the combination. Surely you don't think that if I distribute Word Perfect, which relies on Windows, I'm actually distributing a combination of WP and Windows and thus I'm violating Microsoft's copyright.
Re: GPL and command-line libraries
On Thu, 2 Dec 2004, Raul Miller wrote: If there is -- if Wontshare in some way tries to enforce the use of readline, then this non-distributable product is being distributed On Fri, Dec 03, 2004 at 07:31:06AM -0800, Ken Arromdee wrote: Why? Distributing X, which relies on Y, isn't the same as distributing the combination. Surely you don't think that if I distribute Word Perfect, which relies on Windows, I'm actually distributing a combination of WP and Windows and thus I'm violating Microsoft's copyright. Distribution techniques are not limited to some specific mechanical process. If I ship some product in three parts, such that the combination of those three parts is consistently assembled and used, then I'm distributing that product. If, on the other hand, I happen to be shipping the component parts for some product but that product typically does not arrive at the other end, then I'm not distributing that product. That's all. -- Raul
Re: GPL and command-line libraries
On Fri, 3 Dec 2004, Raul Miller wrote: If I ship some product in three parts, such that the combination of those three parts is consistently assembled and used, then I'm distributing that product. Says who? Shipping parts can be different from shipping a combination if for some reason you are given different rights to ship parts and ship combinations. It's just that outside free licenses that never happens.
Re: GPL and command-line libraries
Ken Arromdee [EMAIL PROTECTED] writes: On Fri, 3 Dec 2004, Raul Miller wrote: If I ship some product in three parts, such that the combination of those three parts is consistently assembled and used, then I'm distributing that product. Says who? Shipping parts can be different from shipping a combination if for some reason you are given different rights to ship parts and ship combinations. It's just that outside free licenses that never happens. It's perfectly legal to sell all the ingredients for making a bomb, but selling ready-made bombs is not. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL and command-line libraries
On Fri, 3 Dec 2004, Raul Miller wrote: If I ship some product in three parts, such that the combination of those three parts is consistently assembled and used, then I'm distributing that product. On Fri, Dec 03, 2004 at 02:36:42PM -0800, Ken Arromdee wrote: Says who? That was me that said that. As an example, some modular homes are shipped in pieces and assembled on site. Shipping parts can be different from shipping a combination if for some reason you are given different rights to ship parts and ship combinations. I agree -- it can be. In fact, that's what I said in the message you're responding to. It's just that outside free licenses that never happens. I disagree. For example, some non-free software is shipped on multiple CDs. Or, from a different point of view, software doesn't have to have a free license to be distributed using bit torrent. -- Raul
Re: GPL and command-line libraries
On Thu, Dec 02, 2004 at 10:01:04PM +, Anthony W. Youngman wrote: Hopefully that then makes them query what is going on, and they won't be keen to do business with Mr Wontshare. More likely, they'll just use editline. Since that's what Wontshare's software is built against and distributed with, there doesn't seem much reason to switch to readline. If there is -- if Wontshare in some way tries to enforce the use of readline, then this non-distributable product is being distributed, and the step where the software is linked to editline is just a smoke screen. -- Raul
Re: GPL and command-line libraries
In message [EMAIL PROTECTED], Wesley W. Terpstra [EMAIL PROTECTED] writes 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 likely dependent on whether his program simply used your library as a black box, or whether his program was really based on mucking about with the internals of your code in a way which really, absolutely, involved using parts of your code. In my case, it would be a 'black box'. So, perhaps this is not a 'derivative work' in the meaning of copyright law. However, he still needed a grant of licence from me to ship my software. Let's give a non-hypothetical example. Mr Wontshare wants to use readline. Note that readline is a GPL'd library (it is *not* LGPL, and this is important). So he links his code using the editline library. He also includes all the .o files, a makefile, and instructions on where to get hold of readline. The customer loads Mr Wontshare's software, loads readline, and runs make. The resulting executable is now non-distributable, because it contains readline, therefore must be distributed with source, but the customer has no source to distribute! However, the software IS legal and the customer CAN legally use it. So Mr Wontshare could easily get round the fact that your library is GPL and write his work based on your library. BUT it would be pretty obvious to the customer (because Mr Wontshare is forced to make the customer jump through hoops) that that is what he is doing. Hopefully that then makes them query what is going on, and they won't be keen to do business with Mr Wontshare. Cheers, Wol -- Anthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999
Re: GPL and command-line libraries
On Sun, Nov 28, 2004 at 01:49:51AM +, Henning Makholm wrote: 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. This isn't specific to the GPL; lawyers have been playing games with 'derivative' for decades. No useful precedent that I'm aware of - cases have gone both ways (courts won't accept people trying to disguise derivation via weirdness, but they don't have a good definition for that either, so the problem remains lawyer-bait). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
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
Re: GPL and command-line libraries
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. Under those circumstances, his client is not a derivative work of your library (although it may be a derivative work of the *API and other specifications*, if the specification is sufficiently clever and complex to be copyrighted). 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. (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.) Mr. Wontshare's client represents only a small investment of effort and without having had access to my library, he could have never written it. Well, if that's *really* true, then his client is probably a derivative work. 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. Is this _not_ a derivative work? That's a factual question. It's most likely dependent on whether his program simply used your library as a black box, or whether his program was really based on mucking about with the internals of your code in a way which really, absolutely, involved using parts of your code. Please note that it doesn't really have much to do with whether it's a command line interface or not. A sh script written to POSIX specs isn't a derivative work of bash. In contrast, an sh script loaded with dependencies on undocumented internal features of bash might be a derivative work of bash. (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.) If that's really the case, is it possible that a GPLv3 might address this? God, I hope not. It wouldn't be a free license, since it would restrict activities which are unrestricted under copyright law, namely the right to make compatible programs. If such a license held up in court, it would allow Microsoft to prohibit Wine, Cygwin, Mingw32, reading the FAT file system, etc. Incidentally, this kind of question is suitable for debian-legal but not for debian-devel. -- This space intentionally left blank.
Re: GPL and command-line libraries
Nathanael Nerode wrote: If your library has a well-specified API, anyone could make a library with the same API, and his client could use that. Under those circumstances, his client is not a derivative work of your library (although it may be a derivative work of the *API and other specifications*, if the specification is sufficiently clever and complex to be copyrighted). Though there is always the chance that an API might be held to be a method of operation in which case it isn't copyrightable. I don't think there have been many (any?) court cases on the subject. The closest is that the menu labels in user interfaces are not copyrightable, because that is a method of operation. I could dig up the cite if need be. Please note that it doesn't really have much to do with whether it's a command line interface or not. It might, if a command line interface is help to be a method of operation (I'm pretty sure it would be) and a binary interface is not. (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.
Re: GPL and command-line libraries
Scripsit Andrew Suffield [EMAIL PROTECTED] [On -legal we generally operate under the assumption that for any case where the outcome is in doubt, it will go against us; entities with better lawyers than ours can afford to take larger risks] Just for the record, it's not the quality of *Debian's* lawyers that is the primary consideration. I'm sure that if somebody actually sued Debian (or one of our mirror operators or ftp-masters), and we had a leg to stand on at all, the free-software community would gather together to support a very competent legal defense. What we're really worried about is that our *users* should have the rights we promise them. And if somebody sues one of our users, the user will have to mount his legal defense out of his own pockets. The software we let into main should be sufficiently unambigously licensed that a user in this situation will not need more than an ordinary consumer-grade lawyer to defend against such a lawsuit. -- Henning Makholm The great secret, known to internists and learned early in marriage by internists' wives, but still hidden from the general public, is that most things get better by themselves. Most things, in fact, are better by morning.
Re: GPL and command-line libraries
On Tue, Nov 02, 2004 at 09:53:21PM +0100, Wesley W. Terpstra wrote: I've heard all sorts of arguements in IRC that drawing the line in a good way is very hard. I believe that. However, what I want to know is, if this went to court, would things like the intention and degree of dependency be considered in determining if the client was a derivative work or not? Yes, they would. But the outcome would necessarily be in doubt. It would be primarily determined by the cost of the respective lawyers, and could go either way. [On -legal we generally operate under the assumption that for any case where the outcome is in doubt, it will go against us; entities with better lawyers than ours can afford to take larger risks] -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: GPL and command-line libraries
Måns Rullgård wrote: It's all about causality. Consider two scenarios, both involving three programs, A, B and C. Scenario 1: 1. A is written. 2. B written, and makes use of A. You argue that B is a derivative work of A. 3. C is written, and is compatible with A. B is clearly not a derivative work of C, since it existed before C. Scenario 2: 1. A is written. 2. C is written, and is compatible with A. C is not a derivative work of A. If it were, most of the GNU programs would be illegal, since they would be derivative works of non-free compatible programs. 3. B is written, and makes use of the interface shared between A and C. In the second scenario, if B is a derivative work of A, it must also be a derivative work of C, since A and C are equivalent. This conflicts with scenario 1, where B cannot possibly be a derivative work of C. In both cases, we have in the end an identical set of programs, and the derivedness relations between them must also be equal. The only solution is that B is not derived from either A or C. AFAIK, as B uses A, B depends on A. At runtime, B cannot depend on A and C at the same time. So if B is distributed to be run with A that is GPL, B must be distributed under GPL terms. I don't know if in this case B is legally a derivative work of A but the dependency seems to be enough to spread A's GPL license to B. But IANAL ;) -- Jonathan ILIAS
Re: GPL and command-line libraries
Jonathan ILIAS [EMAIL PROTECTED] writes: Måns Rullgård wrote: It's all about causality. Consider two scenarios, both involving three programs, A, B and C. Scenario 1: 1. A is written. 2. B written, and makes use of A. You argue that B is a derivative work of A. 3. C is written, and is compatible with A. B is clearly not a derivative work of C, since it existed before C. Scenario 2: 1. A is written. 2. C is written, and is compatible with A. C is not a derivative work of A. If it were, most of the GNU programs would be illegal, since they would be derivative works of non-free compatible programs. 3. B is written, and makes use of the interface shared between A and C. In the second scenario, if B is a derivative work of A, it must also be a derivative work of C, since A and C are equivalent. This conflicts with scenario 1, where B cannot possibly be a derivative work of C. In both cases, we have in the end an identical set of programs, and the derivedness relations between them must also be equal. The only solution is that B is not derived from either A or C. AFAIK, as B uses A, B depends on A. At runtime, B cannot depend on A and C at the same time. So if B is distributed to be run with A that is GPL, B must be distributed under GPL terms. At runtime, B depends on something that can be provided by A or C, it does not care which. Just like make depends on /bin/sh, not asking whether your sh is Bash, Solaris sh, or some other sh. They are all equivalent, and make isn't derived from either of them. I don't know if in this case B is legally a derivative work of A but the dependency seems to be enough to spread A's GPL license to B. Licenses do not spread across interfaces. If they did, virtually every computer program would be illegal. If you are indeed right, I will immediately install BSD or Solaris on my machines, even though many of the GNU tools are better. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL and command-line libraries
On Tue, Nov 02, 2004 at 09:53:21PM +0100, Wesley W. Terpstra wrote: 4. Writing to debian-legal and asking for advice. Now that's a good idea. Why did you do that on debian-devel instead? -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: GPL and command-line libraries
Wouter Verhelst [EMAIL PROTECTED] schrieb: On Tue, Nov 02, 2004 at 09:53:21PM +0100, Wesley W. Terpstra wrote: 4. Writing to debian-legal and asking for advice. Now that's a good idea. Why did you do that on debian-devel instead? s/instead/, too/ Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
GPL and command-line libraries
Good evening!
I'm developing an error-correcting code library which works on a lot of data
at once. Since the API is quite simple and the cost of process creation
relatively insignificant, I would like to provide a command-line API.
I feel this has several engineering advantages:
1) it's easier to debug and understand if you can interact with it
2) bugs in the library don't crash programs using it
3) multithreading can be used in the library and not the application
... and other more problem-specific benefits.
To the point: I want this library to be released under the GPL, BUT ...
Would the GPL still protect it?
If someone writes a program that does: popen('my-api');
does the GPL require that program to also be GPL?
From the short answer I got on IRC it seemed the answer was: No!
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.
Mr. Wontshare's client represents only a small investment of effort and
without having had access to my library, he could have never written it.
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.
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. Is this _not_ a derivative work?
If that's really the case, is it possible that a GPLv3 might address this?
There are several things I've considered to prevent this scenario:
1. Write in all documentation, help, etc: popen my app = derivative work
... and hope that this is enough to give me a victory in a lawsuit or at
least scare Mr. Wontshare away from even trying this.
2. Patenting the new algorithm my library uses and putting in a clause which
covers this corner-case and making it otherwise free.
3. Crafting a special (GPL-incompatible) licence which does what I want.
4. Writing to debian-legal and asking for advice.
I've heard all sorts of arguements in IRC that drawing the line in a good
way is very hard. I believe that. However, what I want to know is, if this
went to court, would things like the intention and degree of dependency be
considered in determining if the client was a derivative work or not?
What can I do to prevent the above scenario from happening?
Thank you very much for your time!
--
Wesley W. Terpstra
Re: GPL and command-line libraries
Le mardi 02 novembre 2004 à 21:53 +0100, Wesley W. Terpstra a écrit : 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. Mr. Wontshare's client represents only a small investment of effort and without having had access to my library, he could have never written it. He then distributes his client along with my library to end-users. If Mr Wontshare's client doesn't work without your software, this is what I call a derivative work. Whether it is linked to it using ELF or not is irrelevant. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: GPL and command-line libraries
Wesley W. Terpstra [EMAIL PROTECTED] writes:
Good evening!
I'm developing an error-correcting code library which works on a lot of data
at once. Since the API is quite simple and the cost of process creation
relatively insignificant, I would like to provide a command-line API.
I feel this has several engineering advantages:
1) it's easier to debug and understand if you can interact with it
2) bugs in the library don't crash programs using it
3) multithreading can be used in the library and not the application
... and other more problem-specific benefits.
To the point: I want this library to be released under the GPL, BUT ...
Would the GPL still protect it?
If someone writes a program that does: popen('my-api');
does the GPL require that program to also be GPL?
From the short answer I got on IRC it seemed the answer was: No!
That's correct. It's even in the GPL FAQ.
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.
Mr. Wontshare's client represents only a small investment of effort and
without having had access to my library, he could have never written it.
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.
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. Is this _not_ a derivative work?
Unfortunately for you, no, it's not a derivative work.
If that's really the case, is it possible that a GPLv3 might address this?
Only if GPL3 is incorporated into the copyright laws worldwide.
Doesn't seem likely to me.
There are several things I've considered to prevent this scenario:
1. Write in all documentation, help, etc: popen my app = derivative work
... and hope that this is enough to give me a victory in a lawsuit or at
least scare Mr. Wontshare away from even trying this.
Maybe it scares someone, but it can't be enforced by law.
2. Patenting the new algorithm my library uses and putting in a clause which
covers this corner-case and making it otherwise free.
Software patents don't exist in large parts of the world.
3. Crafting a special (GPL-incompatible) licence which does what I want.
Legally impossible.
4. Writing to debian-legal and asking for advice.
You got my 2 cents.
I've heard all sorts of arguements in IRC that drawing the line in a good
way is very hard. I believe that. However, what I want to know is, if this
went to court, would things like the intention and degree of dependency be
considered in determining if the client was a derivative work or not?
What can I do to prevent the above scenario from happening?
Don't release your code at all.
--
Måns Rullgård
[EMAIL PROTECTED]
Re: GPL and command-line libraries
* Wesley W. Terpstra | What can I do to prevent the above scenario from happening? I don't think you can, at least not while keeping the library DFSG free. (I guess it would be fairly trivial to write up a similar application which would not be affected by your license for the application, only by the license for the library.) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: GPL and command-line libraries
Josselin Mouette [EMAIL PROTECTED] writes: Le mardi 02 novembre 2004 à 21:53 +0100, Wesley W. Terpstra a écrit : 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. Mr. Wontshare's client represents only a small investment of effort and without having had access to my library, he could have never written it. He then distributes his client along with my library to end-users. If Mr Wontshare's client doesn't work without your software, this is what I call a derivative work. Whether it is linked to it using ELF or not is irrelevant. Mr. Wontshare's program *uses* the GPL program, but isn't derived from it. See http://www.gnu.org/licenses/gpl-faq.html#MereAggregation. Further, consider what would happen if someone else created an application with an interface compatible with the OP's program. Would Mr. Wontshare's program then become a derivative this program as well? A program compatible with the OP's could even be written before Mr. Wontshare writes his. Which one is it then derived from? The only consistent answer is that it is not derived at all. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL and command-line libraries
On Tue, Nov 02, 2004 at 09:53:21PM +0100, Wesley W. Terpstra 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. Mr. Wontshare's client represents only a small investment of effort and without having had access to my library, he could have never written it. 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. Even worse, he refuses to port his client to MacOS X for business reasons. (intentionally giving an unfair competitive advantage to another platform) Given that Mr. Wontshare's client represents only a small investment of effort, refuses to port doesn't sound like much of a problem. Regardless of whether you make your code available under a simple API, there's other possibilities: Mr. Wontshare (or someone else) puts your library behind a simply api and then builds some application which uses that api, and yet refuses to release his code. Someone works with the ecc concepts behind your code and reimplements them in some proprietary code base. Unfortunately, ideas are hard to protect in the first place, and the laws aimed at protecting ideas were originally designed based on the assumption that not sharing ideas is protecting the ideas. -- Raul
Re: GPL and command-line libraries
On Tue, Nov 02, 2004 at 11:00:54PM +0100, Josselin Mouette wrote: Le mardi 02 novembre 2004 à 21:53 +0100, Wesley W. Terpstra a écrit : 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. Mr. Wontshare's client represents only a small investment of effort and without having had access to my library, he could have never written it. He then distributes his client along with my library to end-users. If Mr Wontshare's client doesn't work without your software, this is what I call a derivative work. Whether it is linked to it using ELF or not is irrelevant. What you call a derivative work is irrelevant; the only one that matters is what copyright law calls a derivative work. Copyright law defines derivative work, not licenses. If I write a telnet daemon with a couple special escape codes, I can't say telnet clients that connect to this are derived works. That's just a false statement, even if the client requires my special escape codes. There's no free way to say only free-software clients can connect to this telnet daemon. -- Glenn Maynard
Re: GPL and command-line libraries
On Tue, Nov 02, 2004 at 05:30:36PM -0500, Raul Miller wrote: Given that Mr. Wontshare's client represents only a small investment of effort, refuses to port doesn't sound like much of a problem. I meant to say relatively small investment; sorry. Even simple applications can be hard to rewrite though. Especially, if Mr. Wontshare is evil and uses encrypted traffic protected by good old DRM. Mr. Wontshare (or someone else) puts your library behind a simply api and then builds some application which uses that api, and yet refuses to release his code. I am aware of that, this is why none of my suggested remedies were: don't make a simple API. Someone works with the ecc concepts behind your code and reimplements them in some proprietary code base. I am perfectly fine with this. If they put in the effort to write it themselves, all power to them. I just don't want people who don't share to freeload off my work. I personally hate any kind of algorithm patent, so I wouldn't opt for that solution. I just included it as an option for completeness. -- Wesley W. Terpstra [EMAIL PROTECTED]
Re: GPL and command-line libraries
On Tue, Nov 02, 2004 at 11:12:11PM +0100, Måns Rullgård wrote: If Mr Wontshare's client doesn't work without your software, this is what I call a derivative work. Whether it is linked to it using ELF or not is irrelevant. Mr. Wontshare's program *uses* the GPL program, but isn't derived from it. See http://www.gnu.org/licenses/gpl-faq.html#MereAggregation. To quote that answer: What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). My question was essentially, does the scenario I outlined constitute combining two parts into one. I believe the answer should be yes. However, IANAL and I thought FSF lawyes frequent debian-legal (?) might be able to tell me what a judge would likely think. Further, consider what would happen if someone else created an application with an interface compatible with the OP's program. Would Mr. Wontshare's program then become a derivative this program as well? A program compatible with the OP's could even be written before Mr. Wontshare writes his. Which one is it then derived from? The only consistent answer is that it is not derived at all. Or else, his is a derivative work of whichever one he makes use of. If he ships with one of them, his intention seems to be clear. I don't see how that is logically inconsistent. -- Wesley W. Terpstra [EMAIL PROTECTED]
Re: GPL and command-line libraries
Wesley W. Terpstra [EMAIL PROTECTED] writes: On Tue, Nov 02, 2004 at 11:12:11PM +0100, Måns Rullgård wrote: If Mr Wontshare's client doesn't work without your software, this is what I call a derivative work. Whether it is linked to it using ELF or not is irrelevant. Mr. Wontshare's program *uses* the GPL program, but isn't derived from it. See http://www.gnu.org/licenses/gpl-faq.html#MereAggregation. To quote that answer: What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). My question was essentially, does the scenario I outlined constitute combining two parts into one. I believe the answer should be yes. However, IANAL and I thought FSF lawyes frequent debian-legal (?) might be able to tell me what a judge would likely think. To find out what a judge might rule, you might as well flip a coin. That's what the courts do anyway, if one of the sides doesn't have much more money than the other. In that case, the side with the money wins. Further, consider what would happen if someone else created an application with an interface compatible with the OP's program. Would Mr. Wontshare's program then become a derivative this program as well? A program compatible with the OP's could even be written before Mr. Wontshare writes his. Which one is it then derived from? The only consistent answer is that it is not derived at all. Or else, his is a derivative work of whichever one he makes use of. If he ships with one of them, his intention seems to be clear. I don't see how that is logically inconsistent. It's all about causality. Consider two scenarios, both involving three programs, A, B and C. Scenario 1: 1. A is written. 2. B written, and makes use of A. You argue that B is a derivative work of A. 3. C is written, and is compatible with A. B is clearly not a derivative work of C, since it existed before C. Scenario 2: 1. A is written. 2. C is written, and is compatible with A. C is not a derivative work of A. If it were, most of the GNU programs would be illegal, since they would be derivative works of non-free compatible programs. 3. B is written, and makes use of the interface shared between A and C. In the second scenario, if B is a derivative work of A, it must also be a derivative work of C, since A and C are equivalent. This conflicts with scenario 1, where B cannot possibly be a derivative work of C. In both cases, we have in the end an identical set of programs, and the derivedness relations between them must also be equal. The only solution is that B is not derived from either A or C. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL and command-line libraries
On Wed, Nov 03, 2004 at 12:18:32AM +0100, Måns Rullgård wrote: Or else, his is a derivative work of whichever one he makes use of. If he ships with one of them, his intention seems to be clear. I don't see how that is logically inconsistent. It's all about causality. Consider two scenarios, both involving three programs, A, B and C. Scenario 1: Scenario 2: I understood your argument before. What I mean to say is, if he ships with one of them and performed his development and testing with the same one, that would seem to at least indicate his intentions. It's about which of the two implementations he picks to combine his released work with. I propose that if he shipped his work combined with mine, and required it to operate, that release would be derivative work---not a mere aggregation. Therefore, he would be violating the GPL and thus my copyright. If he shipped his client without combining it with a particular implementation and left it up to the user to perform this, I have no opinion if this is permitted or not. It probably is. This is because: the user can obtain a copy of my library and can do whatever he likes with it as long as he doesn't distribute it. Therefore, he can also combine it with Mr. Wontshare's client. In both cases, we have in the end an identical set of programs, and the derivedness relations between them must also be equal. I am not a lawyer, but I think law depends on more than just the bit values of the software. The difference between first and second degree murder is one of intention. Though that's a bit dramatic, I think the same sort of thing applies here. -- Wesley W. Terpstra [EMAIL PROTECTED]
