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
GPL License question
Hello all, A product has piqued my interest and claims to be GPL but the disclaimers and general tone of their license explanation gives me pause. Any opinions of how truly open source this project is would be greatly appreciated: http://easyco.com/initiative/openqm/opensource/faq.htm In particular, passages that seem (to me at least) to want to make programs written for QM fall into the realm of derivative works. Seems a bit as if gnu would want anything compiled with gcc (or written in a flavour of C that is intended for gcc) to become a derivative work. Am I reading this the wrong way? Thanks in advance, -Tom
Re: Copyright Question
[EMAIL PROTECTED] wrote: I have a copyright question for you. To the extent my company wants to use the Debian Linux O/S as an embedded O/S in a device, can you please advise what copyright notice I should cite to? I understand I must include the GPL language but after reading your policy manual, I am unclear if I must cite to a Debian copyright for the version we may use. Debian is not solely under the GPL, and does not have only one copyright holder. Debian consists of a large set of packages from various sources, with individual copyright holders and licenses. I'm not entirely sure what you mean by what copyright notice I should cite to. I assume that you are attempting to ensure that your product is distributed in compliance with the various Free Software licenses that cover Debian. (Please note that I am not a lawyer, and this is not legal advice. The authoritative source for this information would be the actual licenses for the packages you include.) Assuming you use only packages from the Debian distribution (in main), all of the licenses on those packages satisfy the Debian Free Software Guidelines (if they don't, that's a release-critical bug), which greatly limits the types of conditions they may impose. If you post the list of packages you are using to debian-legal, along with which ones are modified and which ones are used by software written by you, we may be able to supply more detailed information about the conditions of the licenses on those packages. The primary ones you may need to work with are: * Preserving copyright notices and licenses Any requirements to preserve the copyright notice and license for a particular package are already satisfied by the Debian binary package, as long as the file /usr/share/doc/[package-name]/copyright is included. You also need to include the files in /usr/share/common-licenses from the package base-files, which are referenced by many of these copyright files. Note that since you are creating an embedded system, the size of all these files may be an issue. I believe you could legally supply them separately as long as they are supplied in the same distribution; can anyone else on debian-legal confirm that? Also note that many of these files are identical amonst several binary packages; I don't think you'd need to supply the duplicates. * Requirements to supply the source for the packages you use. Every Debian binary package has a corresponding source package (which may be the source for several binary packages). Not all Debian packages require that you distribute source for the binaries you distribute, but many do. The easiest solution is to distribute the source packages for all the binary packages you include; if you want to be more selective in what you include, you will need to check the licenses on the individual packages you are using. You can either distribute the source packages along with the binaries (such as by putting them on a CD included with the product), or you can distribute an offer to supply source. If you choose the latter option, the offer needs to be good for at least 3 years, and needs to allow anyone with a copy of the offer to order the source (on a medium customarily used for software interchange, such as a CD) for no more than the costs of distribution. Note also that while supplying the source on your website and pointing users to that does not actually satisfy the requirement, it does satisfy almost all users, such that very few will actually exercise the offer for physical media, saving you time and effort. * Requirements on modifications you make If you distribute your own software that is a derivative work of a copylefted program, such as if you distribute a program linked to a GPLed library, or make any modifications to a GPLed work, you must supply the full source (including both the original work and your modifications). The above possibilities for distributing source apply here as well. Other licenses may place requirements on derivative works as well; again, we'd need to know more details about which packages your software is based on to supply more information. I hope that helps you with your project. Thank you for contacting debian-legal, and for taking the time and consideration to comply with Free Software licenses. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: GPL License question
Tom deL wrote: A product has piqued my interest and claims to be GPL but the disclaimers and general tone of their license explanation gives me pause. Any opinions of how truly open source this project is would be greatly appreciated: http://easyco.com/initiative/openqm/opensource/faq.htm Others have mentioned this project on debian-legal as well, with similar concerns. See the thread Is this software really GPL? back in October, starting at http://lists.debian.org/debian-legal/2004/10/msg00331.html In particular, passages that seem (to me at least) to want to make programs written for QM fall into the realm of derivative works. Seems a bit as if gnu would want anything compiled with gcc (or written in a flavour of C that is intended for gcc) to become a derivative work. Am I reading this the wrong way? While their explanatory material is slightly biased towards making you believe you need one of their Commercial QM [sic; should be Proprietary] licenses, I think they have the correct interpretation of derivative works. Just as a program written against a GPLed library is (generally) a derivative work of that library, a program written against OpenQM is (generally) a derivative work of OpenQM, and as such, is subject to the terms of the GPL on OpenQM. Furthermore, they acknowledge that they implement a superset of a particular standard, which has multiple implementations, so if your program requires *only* the standard and nothing specific to their program, it is not subject to the GPL. Finally, they explicitly state that nothing in their explanation provides any further restrictions beyond those of the GPL; see the How do you resolve any conflicts between what you say and what the GPL says section. They even seem to be rather strong advocates of Free Software, judging by some of their comments. The only issue I note with their explanatory document is that it occasionally confuses commercial and proprietary, or places for-profit and Free Software as opposing ideas. They do however explicitly note in one point that you are permitted to charge for GPLed software, as long as you satisfy the requirements of the GPL. Their restrictions on code using their proprietary QM license are far stricter, but then any proprietary software is too strict by definition. They place restrictions on the object code built against the proprietary QM, but restrictions on derivative works are quite possible legally; in this case, however, the restrictions are being used for a non-free purpose, rather than a Free purpose such as a copyleft. Overall, they seem to be just like any other company that supplies both a Free copylefted version and a proprietary buy this if you want to keep your stuff secret version of their software. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Copyright Question
Wouldn't a typical install of Debian also properly install all the licenses required? Do the Debian install scripts break the licenses of the component software? Disk space is so cheap I can't see any developer spending time to remove anything put in by an install. Why would he have to do more than say this product contains Debian xxx see http://www.debian.org/ for license information and add a list of packages installed similar to what dpkg -l would show. I'm not saying that it is good enough right now but I that think it should be. Why should anyone but the source be required to keep or distribute source code when it is freely available from Debian. The web was not available when the license was conceived. If I were a judge, and I looked at the intent of the license, I'd say the flavour and intent is served by proper attribution, and reasonable access to the source as intended, especially if it was by reference to the source web site.and I'd note that this user was not tring to assume ownership. Law is about damages, not about forcing people to do what you want.. What would be the damages to someone giving away their software on the web if he gave the notice I suggest? He is not creating a competing proprietary product out of their work, he is not interfering with their income stream, he is even promoting them. This is quite different from a company misappropriating GPL code. However if he made modification to the code in order to support embedding and did not release the code back to the community then damages to the extent of reproducing such modifications would be liable. Chris
RE: Copyright Question
Hi Chris Very pragmatic reasoning. I wondered the same thing. From a practical standpoint, why would someone ask us for source code (ie, order it, pay for replication costs, then wait for it to be shipped) when you could download immediately for free. In any event we want to error on the side of caution and will cite the applicable language from the GPL. Thanks for taking the time to reply. Regards, Mike Skaggs -Original Message- From: Christopher Priest [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 07, 2004 1:05 PM To: Josh Triplett; [EMAIL PROTECTED] Cc: debian-legal@lists.debian.org Subject: Re: Copyright Question Wouldn't a typical install of Debian also properly install all the licenses required? Do the Debian install scripts break the licenses of the component software? Disk space is so cheap I can't see any developer spending time to remove anything put in by an install. Why would he have to do more than say this product contains Debian xxx see http://www.debian.org/ for license information and add a list of packages installed similar to what dpkg -l would show. I'm not saying that it is good enough right now but I that think it should be. Why should anyone but the source be required to keep or distribute source code when it is freely available from Debian. The web was not available when the license was conceived. If I were a judge, and I looked at the intent of the license, I'd say the flavour and intent is served by proper attribution, and reasonable access to the source as intended, especially if it was by reference to the source web site.and I'd note that this user was not tring to assume ownership. Law is about damages, not about forcing people to do what you want.. What would be the damages to someone giving away their software on the web if he gave the notice I suggest? He is not creating a competing proprietary product out of their work, he is not interfering with their income stream, he is even promoting them. This is quite different from a company misappropriating GPL code. However if he made modification to the code in order to support embedding and did not release the code back to the community then damages to the extent of reproducing such modifications would be liable. Chris
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: Copyright Question
On Tue, Dec 07, 2004 at 11:47:34AM -0800, Josh Triplett wrote: (Please note that I am not a lawyer, and this is not legal advice. The authoritative source for this information would be the actual licenses for the packages you include.) [snip] Excellent text. Could someone put this on www.d.o somewhere? 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 License question
Josh, thank you for taking the time to point me to some great reading! -Tom Josh Triplett wrote: Tom deL wrote: A product has piqued my interest and claims to be GPL but the disclaimers and general tone of their license explanation gives me pause. Any opinions of how truly open source this project is would be greatly appreciated: http://easyco.com/initiative/openqm/opensource/faq.htm Others have mentioned this project on debian-legal as well, with similar concerns. See the thread Is this software really GPL? back in October, starting at http://lists.debian.org/debian-legal/2004/10/msg00331.html In particular, passages that seem (to me at least) to want to make programs written for QM fall into the realm of derivative works. Seems a bit as if gnu would want anything compiled with gcc (or written in a flavour of C that is intended for gcc) to become a derivative work. Am I reading this the wrong way? While their explanatory material is slightly biased towards making you believe you need one of their Commercial QM [sic; should be Proprietary] licenses, I think they have the correct interpretation of derivative works. Just as a program written against a GPLed library is (generally) a derivative work of that library, a program written against OpenQM is (generally) a derivative work of OpenQM, and as such, is subject to the terms of the GPL on OpenQM. Furthermore, they acknowledge that they implement a superset of a particular standard, which has multiple implementations, so if your program requires *only* the standard and nothing specific to their program, it is not subject to the GPL. Finally, they explicitly state that nothing in their explanation provides any further restrictions beyond those of the GPL; see the How do you resolve any conflicts between what you say and what the GPL says section. They even seem to be rather strong advocates of Free Software, judging by some of their comments. The only issue I note with their explanatory document is that it occasionally confuses commercial and proprietary, or places for-profit and Free Software as opposing ideas. They do however explicitly note in one point that you are permitted to charge for GPLed software, as long as you satisfy the requirements of the GPL. Their restrictions on code using their proprietary QM license are far stricter, but then any proprietary software is too strict by definition. They place restrictions on the object code built against the proprietary QM, but restrictions on derivative works are quite possible legally; in this case, however, the restrictions are being used for a non-free purpose, rather than a Free purpose such as a copyleft. Overall, they seem to be just like any other company that supplies both a Free copylefted version and a proprietary buy this if you want to keep your stuff secret version of their software. - Josh Triplett
Re: Copyright Question
Christopher Priest [EMAIL PROTECTED] writes: Why should anyone but the source be required to keep or distribute source code when it is freely available from Debian. The web was not available when Debian may not be around forever. Many embedded devlopers don't publicize which distribution they derive from. the license was conceived. If I were a judge, and I looked at the intent of the license, I'd say the flavour and intent is served by proper attribution, The license -- the GPL -- very specifically says that the source must be included with the software. It goes to some effort to detail what notice is an acceptable alternative, and it involves three-year guarantees. and reasonable access to the source as intended, especially if it was by reference to the source web site.and I'd note that this user was not tring to assume ownership. Law is about damages, not about forcing people to do what you want.. No, in the case of copyright law it is explicitly about granted permissions. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Copyright Question
[EMAIL PROTECTED] writes: Hi Chris Very pragmatic reasoning. I wondered the same thing. From a practical standpoint, why would someone ask us for source code (ie, order it, pay for replication costs, then wait for it to be shipped) Not everybody who will get ahold of your product has a network connection. Debian won't be around forever. when you could download immediately for free. In any event we want to error on the side of caution and will cite the applicable language from the GPL. The short form is that you probably have to distribute the source with the binary -- say, on a CD -- or you have to offer to distribute the source for three years. That last is pretty onerous; it's probably easier to drop a CD with a copy of the source *you use*, not just the pure Debian source, into each box. Just think -- you might end up with a community of people making improvements to your firmware, and distributing them under the GPL such that you can take advantage of it. -Brian -- Brian Sniffen [EMAIL PROTECTED]
