Re: [POSITION SUMMARY] Re: Plugins, libraries, licenses and Debian
On Tue, 2003-12-09 at 17:22, Andrew Suffield wrote: > Actually, it's closer than you think. Any "product" [arbitrary > definition] that requires all three components is a derivative work of > all of them; that will almost certainly violate one or more of the > licenses. It may be; it may not be. Not even the FSF contents that a shell script which requires bash is a derivative work of bash; a perl script of perl; etc. That's why its a discussion for another thread :-) signature.asc Description: This is a digitally signed message part
Re: [POSITION SUMMARY] Re: Plugins, libraries, licenses and Debian
Andrew Suffield <[EMAIL PROTECTED]> writes: > On Tue, Dec 09, 2003 at 11:10:05AM -0500, Anthony DeRobertis wrote: >> Now, there is a potential problem. Remember that scripting language >> mentioned before? If someone were to write a script that used both >> INVERT and STENOG, and then distribute that script, there might be a >> problem. But that's an issue for another thread. > > Actually, it's closer than you think. Any "product" [arbitrary > definition] that requires all three components is a derivative work of > all of them; that will almost certainly violate one or more of the > licenses. > > Hmm, that's actually interesting. We have an emergent licensing > constraint that is a property of none of the works involved, but only > appears when they are put together. I don't think we can even discuss > the DFSG-freeness of such a constraint in any meaningful way. Since Debian distributes an Operating System (base, essential, etc) and a number of additional packages (optional, contrib, non-free) from which a user might wish to build an Operating System, I think it's quite reasonable to discuss the Freeness of such a constraint: it logically isn't Free by DFSG #1 to #9, but is (I think) under DFSG #10: the GPL and BSD licenses are explicitly Free.
Re: [POSITION SUMMARY] Re: Plugins, libraries, licenses and Debian
On Tue, Dec 09, 2003 at 11:10:05AM -0500, Anthony DeRobertis wrote: > Now, there is a potential problem. Remember that scripting language > mentioned before? If someone were to write a script that used both > INVERT and STENOG, and then distribute that script, there might be a > problem. But that's an issue for another thread. Actually, it's closer than you think. Any "product" [arbitrary definition] that requires all three components is a derivative work of all of them; that will almost certainly violate one or more of the licenses. Hmm, that's actually interesting. We have an emergent licensing constraint that is a property of none of the works involved, but only appears when they are put together. I don't think we can even discuss the DFSG-freeness of such a constraint in any meaningful way. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: [POSITION SUMMARY] Re: Plugins, libraries, licenses and Debian
On Tue, 2003-12-09 at 18:00, Anthony DeRobertis wrote: > On Dec 9, 2003, at 11:52, Brian T. Sniffen wrote: > > > I will > > point out that further distributors who wish to distribute AIE and > > INVERT will essentially be bound by the GPL with regards to AIE, even > > though it is under the MIT/X11 license: they received it under the > > terms of the GPL, not under the terms of the X11 license. > > They had to receive it under the terms of the GPL. They also received > AIE under the terms of the MIT X11 license. The work is sort-of > dual-licensed, in the sense that the X11 license is compatible with the > GPL. > Indeed, one can distribute MIT/X11 licensed software under the terms of the GPL without breaking any of the terms of either licence (hence the term "compatible with the GPL"). If you were to separate INVERT and AIE again, then thanks to this clause in the GPL, you are free to distribute AIE under the pure terms of MIT/X11 without the additional restriction of the GPL terms. These requirements apply to the modified work as a whole. 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. (lit. that a combined non-GPL work and GPL-work must be licenced under the terms of the GPL, but if you separate them again the non-GPL work may be considered unencumbered again). Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: [POSITION SUMMARY] Re: Plugins, libraries, licenses and Debian
Anthony DeRobertis <[EMAIL PROTECTED]> writes: > They had to receive it under the terms of the GPL. They also received > AIE under the terms of the MIT X11 license. The work is sort-of > dual-licensed, in the sense that the X11 license is compatible with > the GPL. Yes, but they can't distribute AIE+INVERT+STENOG on the same CD labeled "A complete solution to your inverted stegonography needs!" And when they distribute AIE+INVERT they're required by the license on INVERT to distribute the source of AIE. But I'm just nitpicking now; I also agree with your summation. -- Jeremy Hankins <[EMAIL PROTECTED]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: [POSITION SUMMARY] Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) writes: > [EMAIL PROTECTED] (Brian T. Sniffen) writes: > >> Anthony DeRobertis <[EMAIL PROTECTED]> writes: >> >>> I have thus, even with STENOG included, satisfied the terms of the >>> INVERT license. >>> >>> Now, there is a potential problem. Remember that scripting language >>> mentioned before? If someone were to write a script that used both >>> INVERT and STENOG, and then distribute that script, there might be a >>> problem. But that's an issue for another thread. >>> >>> This is no different from perl/python/whatever modules under different >>> licenses. >> >> I think this is a quite reasonable summary of the situation. I will >> point out that further distributors who wish to distribute AIE and >> INVERT will essentially be bound by the GPL with regards to AIE, even >> though it is under the MIT/X11 license: they received it under the >> terms of the GPL, not under the terms of the X11 license. > > *If* the program is derived from the plugin, which it isn't, since the > program existed first. Besides the GPL says this: I wasn't clear about what I meant, I'm sorry: when distributing AIE+INVERT, INVERT is under the GPL, AIE+INVERT is a derivative work of INVERT, and so must be treated as under the GPL, and so AIE, in the context of AIE+INVERT, must be treated as under the GPL. > These requirements apply to the modified work as a whole. 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. Yes, if you pull AIE out separately and distribute it alone, you don't need to provide source. > BTW, what's up with gnu.org? > > -- > Måns Rullgård > [EMAIL PROTECTED] -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [POSITION SUMMARY] Re: Plugins, libraries, licenses and Debian
On Dec 9, 2003, at 11:52, Brian T. Sniffen wrote: Anthony DeRobertis <[EMAIL PROTECTED]> writes: I have thus, even with STENOG included, satisfied the terms of the INVERT license. Now, there is a potential problem. Remember that scripting language mentioned before? If someone were to write a script that used both INVERT and STENOG, and then distribute that script, there might be a problem. But that's an issue for another thread. This is no different from perl/python/whatever modules under different licenses. I think this is a quite reasonable summary of the situation. I'm glad to hear that. I hope this means we will reach consensus soon! I will point out that further distributors who wish to distribute AIE and INVERT will essentially be bound by the GPL with regards to AIE, even though it is under the MIT/X11 license: they received it under the terms of the GPL, not under the terms of the X11 license. They had to receive it under the terms of the GPL. They also received AIE under the terms of the MIT X11 license. The work is sort-of dual-licensed, in the sense that the X11 license is compatible with the GPL.
Re: [POSITION SUMMARY] Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Brian T. Sniffen) writes: > Anthony DeRobertis <[EMAIL PROTECTED]> writes: > >> I have thus, even with STENOG included, satisfied the terms of the >> INVERT license. >> >> Now, there is a potential problem. Remember that scripting language >> mentioned before? If someone were to write a script that used both >> INVERT and STENOG, and then distribute that script, there might be a >> problem. But that's an issue for another thread. >> >> This is no different from perl/python/whatever modules under different >> licenses. > > I think this is a quite reasonable summary of the situation. I will > point out that further distributors who wish to distribute AIE and > INVERT will essentially be bound by the GPL with regards to AIE, even > though it is under the MIT/X11 license: they received it under the > terms of the GPL, not under the terms of the X11 license. *If* the program is derived from the plugin, which it isn't, since the program existed first. Besides the GPL says this: These requirements apply to the modified work as a whole. 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. BTW, what's up with gnu.org? -- Måns Rullgård [EMAIL PROTECTED]
Re: [POSITION SUMMARY] Re: Plugins, libraries, licenses and Debian
Anthony DeRobertis <[EMAIL PROTECTED]> writes: > I have thus, even with STENOG included, satisfied the terms of the > INVERT license. > > Now, there is a potential problem. Remember that scripting language > mentioned before? If someone were to write a script that used both > INVERT and STENOG, and then distribute that script, there might be a > problem. But that's an issue for another thread. > > This is no different from perl/python/whatever modules under different > licenses. I think this is a quite reasonable summary of the situation. I will point out that further distributors who wish to distribute AIE and INVERT will essentially be bound by the GPL with regards to AIE, even though it is under the MIT/X11 license: they received it under the terms of the GPL, not under the terms of the X11 license. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
[POSITION SUMMARY] Re: Plugins, libraries, licenses and Debian
On Dec 8, 2003, at 10:00, Måns Rullgård wrote: What I'm trying to find out is, whether or not it's allowed to write a plugin, using GPL,d libraries, for a program with MIT license, for which there also exists plugins using OpenSSL (or anything GPL-incompatible). As long as its really a plugin, I'd say so. By plugin, I mean it provides additional features, through a generic API, which may optionally be invoked by the user, through menu items, command keys, scripts, etc. To explain my position, I'm going to use a fictional program, Anthony's Image Editor (AIE), distributed under the MIT X11 license. Like GIMP, Photoshop, and most other image editors, AIE has plugins that let the user manipulate the images. In addition, it has scripting that lets the user automate image manipulations. Among AIE's many plugins, are these two: STENOG, which uses OpenSSL to encrypt a message, and stenography to hide it in the image. License: OpenSSL INVERT, which inverts the image. License: GPL Now, for the argument. Let's assume that the plugins are a derivative work of AIE. We know that AIE is not a derivative work of the plugins, because a derivative work must be based on a pre-existing work. Now, can we distribute both the STENOG and INVERT plugin? Clearly, we can distribute either one separately: The X11 license is compatible with most everything. The only thing that would prevent me from distributing both is the GPL. But I argue that GPL 3(a) clearly gives me permission to distribute INVERT, no matter if STENOG is there. In particular, 3(a) gives me permission: 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, ... For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. I will accompany INVERT with complete source code, as defined above. Since we're assuming INVERT is a derivative work of AIE, I will include the source code of AIE as well. The source of INVERT is under the GPL, clearly quite legal to distribute "under the terms of Sections 1 and 2." The source of AIE is under the MIT X11 license, clearly quite legal to distribute under those terms as well. I have thus, even with STENOG included, satisfied the terms of the INVERT license. Now, there is a potential problem. Remember that scripting language mentioned before? If someone were to write a script that used both INVERT and STENOG, and then distribute that script, there might be a problem. But that's an issue for another thread. This is no different from perl/python/whatever modules under different licenses.
