Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Brian T. Sniffen) writes: The only problem is when you start loading both GPL plugins and GPL-incompatible plugins. Here, your license is irrelevant; it's the plugin licenses that are in conflict. A permissive license shouldn't add any new problems, at least. There is a plugin that uses OpenSSL... You want to distribute a package which makes takes advantage of code others have written and distributed under the GPL. Part of the deal they offered you was that you could use their code, but in exchange there would be no restrictions on what you distribute but the GPL's. I'm not placing any restrictions on the distribution of their code, nor on any of my code that uses GPL'd libraries. You *also* want to have functionality in your package from Eric Young's SSLeay. Part of the deal under which he lets you use his code is the requirement that you advertise for him. The OpenSSL license has these requirements (typos copied verbatim): * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the copyright *notice, this list of conditions and the following disclaimer. I'm not distributing the OpenSSL source code. I'm distributing code that, when compiled, will be linked dynamically with OpenSSL libraries at runtime. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. Again, I'm not distributing any OpenSSL code as binaries. * 3. All advertising materials mentioning features or use of this software *must display the following acknowledgement: *This product includes cryptographic software written by * Eric Young ([EMAIL PROTECTED]) *The word 'cryptographic' can be left out if the rouines from the library *being used are not cryptographic related :-). Strictly speaking, my program doesn't include anything written by Eric Young. It makes calls to software written by him, but that is not the same as including it. I'd venture to guess that this was written thinking of programs copying (parts of) the SSL library as source code into a bigger program or library. * 4. If you include any Windows specific code (or a derivative thereof) from *the apps directory (application code) you must include an acknowledgement: *This product includes software written by Tim Hudson ([EMAIL PROTECTED]) Not applicable. This is followed by two identical sections with these requirements, more or less equivalent with the above, with the addition of 4 and 5: * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit. (http://www.openssl.org/) * * 4. The names OpenSSL Toolkit and OpenSSL Project must not be used to *endorse or promote products derived from this software without *prior written permission. For written permission, please contact *[EMAIL PROTECTED] * * 5. Products derived from this software may not be called OpenSSL *nor may OpenSSL appear in their names without prior written *permission of the OpenSSL Project. * * 6. Redistributions of any form whatsoever must retain the following *acknowledgment: *This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit (http://www.openssl.org/) You can't distribute a package which combines all of this and satisfies all of these requirements. You have to either forgo the functionality offered by one of these otherwise generous authors and write it yourself, or find a way to do it that doesn't involve the copyrights of these authors. The question is about when something is to be considered a derived work. Keep in mind that the GPLv2 is dated 1991, and is based on the even older GPLv1 (I can't find an exact date). The OpenSSL license originated in the early 1990's. Back in those days, dynamic linking wasn't nearly as common as it is today, if it was used at all, and may not have been thoroughly considered by the authors of licenses. Today, dynamic linking is commonplace, and thus the question of whether dynamic linking
Re: Bug#221761: elfutils: licence seems not DFSG-free, was: Open Software License and patent/reciprocity issues (fwd)
It seems that the maintainer doesn't object too strongly about this. The bug is 221761 and now titled Please remove elfutils from the archive -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ [EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/
Re: Plugins, libraries, licenses and Debian
Don Armstrong [EMAIL PROTECTED] writes: On Sat, 06 Dec 2003, Måns Rullgård wrote: In my particular case, a plugin must implement one or more predefined interfaces. Several implementations of an interface can (and do) exist independently. Does this affect the situation in any way? Yes, assuming one of those implementation's licenses is compatible with the plugin, or the plugin is written to a generic interface and thus is a derived work of the generic interface as opposed to the implementation of that interface. It's worth distinguishing between a few different things several implementations can mean: - Multiple modules, each doing different things, using the interface - Multiple modules doing the same thing, all using the interface - Multiple programs implementing the interface that can use the modules. If Måns means the first of these, my understanding is that that would be considerably less significant than the latter. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Binaries under GPL(2)
Scripsit Alexander Cherepanov [EMAIL PROTECTED] What prevents you from distributing binaries produced from sources under Section 2? Hm, that's a good question. It seems to be another wording oversight. -- Henning MakholmJeg køber intet af Sulla, og selv om uordenen griber planmæssigt om sig, så er vi endnu ikke nået dertil hvor ordentlige mennesker kan tillade sig at stjæle slaver fra hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er.
Re: Plugins, libraries, licenses and Debian
Jeremy Hankins [EMAIL PROTECTED] writes: In my particular case, a plugin must implement one or more predefined interfaces. Several implementations of an interface can (and do) exist independently. Does this affect the situation in any way? Yes, assuming one of those implementation's licenses is compatible with the plugin, or the plugin is written to a generic interface and thus is a derived work of the generic interface as opposed to the implementation of that interface. It's worth distinguishing between a few different things several implementations can mean: - Multiple modules, each doing different things, using the interface - Multiple modules doing the same thing, all using the interface - Multiple programs implementing the interface that can use the modules. If Måns means the first of these, my understanding is that that would be considerably less significant than the latter. I'm doing the first two of those. -- Måns Rullgård [EMAIL PROTECTED]
Re: Plugins, libraries, licenses and Debian
On Sun, Dec 07, 2003 at 09:35:15AM -0700, Joel Baker wrote: On Sat, Dec 06, 2003 at 03:25:01PM -0800, Don Armstrong wrote: If the code was licensed under something that was not GPL compliant, the issue is less clear. I'd guess that it is probably a no for most libraries, save ones with well defined interfaces, like POSIX or the STD C. But I could be swayed either way, frankly. It's much easier to judge these things when you're looking at the code, and even then it's still quite possible that you could find enough of an issue to enter litigation. And people wonder why they call it the Gnu Public Virus... Because people keep talking nonsense about it. I mean, I can understand not wanting people to use GNU Readline as part of a GPL-incompatible app unless it in no way actually depends on it being GNU Readline, rather than something else with the same API. But claiming that a GPLed *plugin* created *after* a program with a defined plugin API, and after another plugin with a GPL-incompatible license, causes the distribution of a package of program plus some plugins that work with it to become a derived work, is just frigging silly. So why are you even suggesting it? It's not just silly, it's wrong. Taking the plugin and the core application and creating a derived work from the two of them is what causes the result to become a derived work of the two of them. A case where this is a reasonable interpretation is putting them both into a .deb and shipping them in a fashion that always uses the plugin (for example, by adding a NEEDED entry to the application binary to load the plugin; we conventionally call this linking). At the other end of the scale, burning each component onto a CD and putting them in a bag is fairly clearly not a derived work. Anything between these two is probably unclear and a court could go either way. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) writes: Then read the section Can I use the GPL for a plug-in for a non-free program? in the GPL FAQ: http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF If there are any other interpretations of that section, please enlighten me. When we see a plugin written under the GPL for a GPL-incompatible work, we have two choices: - Assume the author of the plugin was confused, and that the plugin isn't even distributable, or - Assume that the author intends that the plugin have an implicit exception for the gpl-incompatible work. We generally go with the latter, simply because it makes more sense. But that does have implications, namely that the plugin isn't actually under the GPL, but under a sort of GPL+exception hybrid license. Which, in turn, means that it's not really GPL compatible -- GPL code from other sources and other authors can not be used with this GPL plugin. That may (or may not) be what Steve Langasek was thinking. But as others have said, this is not a clear-cut area at all. When we talk about whether it is or is not a problem we're theorizing on what a judge would decide were the case presented in court. And that's risky business. The important thing for us, as programmers, to keep in mind is that the intentions and thinking of the people involved is likely to be the deciding factor, not technical details of implementation. In fact, things like whether there's a well-defined interface are generally only relevant because they suggest that the author of the code *intended* the work to be separate from the plugins. But like most folks here, IANAL, so YMMV. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Plugins, libraries, licenses and Debian
Steve Langasek [EMAIL PROTECTED] writes: When we see a plugin written under the GPL for a GPL-incompatible work, we have two choices: - Assume the author of the plugin was confused, and that the plugin isn't even distributable, or - Assume that the author intends that the plugin have an implicit exception for the gpl-incompatible work. - Assume that the author knows what he's doing after all, and only intends for the plugin to be distributable in source format until a GPL-compatible framework comes along. But the framework *is* GPL compatible. It's another plugin that's not. -- Måns Rullgård [EMAIL PROTECTED]
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) writes: Jeremy Hankins [EMAIL PROTECTED] writes: If you want a simply answer, the answer is: No (insert disclaimers here) as others have pointed out. As someone said, writing is always allowed, it's distribution that's restricted. True as far as the GPL is concerned, but not true generally. There have been some indications that a source distribution is allowed, even if a binary distribution is not. Could someone clarify? I must have missed the message that talked about this. My understanding is that the only case this might apply is when the source isn't actually intended for compilation (e.g., it's in book form). The idea is that if I distribute a work in source form that requires an incompatible lib I'm simply trying to get around the law, and generally courts don't like that. The rest of the discussion is only appropriate if you want to understand why that is. But it has to do with intent, sneaky ways one might try to get around the GPL, how provable your position is in court, and (perhaps most importantly) how deep your pockets are. I use plugins for purely technical reasons. If, as a side effect, otherwise incompatible libraries can be used, it's all the better for the users of the program. I don't generally trust courts, so I'd rather not end up there. Then you (like most of the rest of the world) are best off taking the conservative view and assuming that they're still incompatible even as plugins, even if you think you have a valid argument to the contrary. Once again, we end up at the words derived work. Where should I look for precise definitions this term? For the record, I am doing this work in Sweden and Norway, in case it makes a difference. You could look at the law, but I'd be surprised if it were specific enough to answer your question. It certainly isn't in the US; here you'd need to look at case law, and even there you're not going to get a clear answer because there isn't one. Frankly, the most comprehensive attempt to answer the question that I know of is on the FSF site, though they clearly do have an angle. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Plugins, libraries, licenses and Debian
On Mon, Dec 08, 2003 at 09:27:30AM -0500, Jeremy Hankins wrote: [EMAIL PROTECTED] (Måns Rullgård) writes: Then read the section Can I use the GPL for a plug-in for a non-free program? in the GPL FAQ: http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF If there are any other interpretations of that section, please enlighten me. When we see a plugin written under the GPL for a GPL-incompatible work, we have two choices: - Assume the author of the plugin was confused, and that the plugin isn't even distributable, or - Assume that the author intends that the plugin have an implicit exception for the gpl-incompatible work. - Assume that the author knows what he's doing after all, and only intends for the plugin to be distributable in source format until a GPL-compatible framework comes along. We generally go with the latter, simply because it makes more sense. We'd better not, without a clarifying statement from the copyright holder; see above. But that does have implications, namely that the plugin isn't actually under the GPL, but under a sort of GPL+exception hybrid license. Which, in turn, means that it's not really GPL compatible -- GPL code from other sources and other authors can not be used with this GPL plugin. GPL+exceptions is still GPL-compatible, regardless of whether the thing being given an exception is GPL-compatible. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Plugins, libraries, licenses and Debian
M?ns Rullg?rd wrote: Arnoud Engelfriet [EMAIL PROTECTED] writes: If I understand the FSF correctly, they claim that a package containing both 'afe' and the 'barnitz' plugin is a derivative work of the 'barnitz' plugin. Afe by itself of course isn't a derivative, but someone who bundles the two is creating something new based on two pre-existing works. I think it's more logical to call it an aggregation, as used in the GPL. Me too. But the two do work together and are bundled precisely to enable the end user to use them together. I am not sure that is _mere_ aggregation. And since the FSF's logic is linking at runtime means derivative work before runtime, it follows that the bundle is a derivative work of the plugin. I'd personally like to see that logic put to test. I don't have the cash to ensure the outcome is what I want, though. And those who do have the cash, do not want the PR nightmare you'd get if you did that. Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: I don't know the details of who writes the SSL support for Konq or how it's done, nor do I have any machines with Konqueror on them in front of me right now, so I can't comment on that. Ah, found it -- Debian KDE list, late July 2002: Konqueror doesn't link against OpenSSL. It runs a separate process (kcm_crypto, it looks like), which links against openssl... but does so in a way that *doesn't* invoke OpenSSL's advertising clause. Thus, the GPL prohibition on additional restrictions isn't invoked, and what KDE's doing is fine. And *that* wasn't done just to get around the legalities? Oh, sure it was -- but to get around the legality of obnoxiously having to advertise for others, as opposed to the legality of sharing and sharing alike. If Eric Young advertised all OpenSSL-using software I'd be a lot more tolerant of its license. -Brian
Re: Plugins, libraries, licenses and Debian
On Mon, Dec 08, 2003 at 03:09:06PM -0500, Brian T. Sniffen wrote: Ah, found it -- Debian KDE list, late July 2002: Konqueror doesn't link against OpenSSL. It runs a separate process (kcm_crypto, it looks like), which links against openssl... but does so in a way that *doesn't* invoke OpenSSL's advertising clause. Thus, the GPL prohibition on additional restrictions isn't invoked, and what KDE's doing is fine. I don't quite follow. It doesn't matter if extra restrictions are invoked or not; they're GPL-incompatible regardless. (Don't use this software to make bombs is GPL-incompatible, even if you don't happen to be using it to make bombs.) Could you link to the thread you're referencing? -- Glenn Maynard
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: 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). If you want a simply answer, the answer is: No (insert disclaimers here) as others have pointed out. As someone said, writing is always allowed, it's distribution that's restricted. That's not quite what I said, and has a critical difference. I said writing *the plugin itself* is allowed. Writing the combined work of the framework, the OpenSSL-using-plugin, and the Readline-using-plugin is not allowed by the GPL. If that's the case, we should put the entire KDE development team in jail. KDE is licensed under GPL, and uses both GPL stuff and OpenSSL. It also uses Java and Netscape plugins, which are very much non-free. Why would we put them in jail? They haven't done anything criminal. KDE is also manifestly not a single work: I use konquerer but no other part of it, for example. The KDE folks have, from what I've seen, been quite careful with licensing issues. Can you provide any specific examples of single works incorporating pure-GPL work and linking against OpenSSL? The rest of the discussion is only appropriate if you want to understand why that is. But it has to do with intent, sneaky ways one might try to get around the GPL, how provable your position is in court, and (perhaps most importantly) how deep your pockets are. I use plugins for purely technical reasons. If, as a side effect, otherwise incompatible libraries can be used, it's all the better for the users of the program. Ask yourself this: is what you're doing in compliance with the wishes of the authors of the various pieces of software you're using? I don't know what the authors wish, I'll have to ask them. They've told you in the license. You can ask for a new, broader license, but remember in the case of GPL'd works that this requires permission from *all* the authors. -Brian
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) writes: [EMAIL PROTECTED] (Brian T. Sniffen) writes: 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). If you want a simply answer, the answer is: No (insert disclaimers here) as others have pointed out. As someone said, writing is always allowed, it's distribution that's restricted. That's not quite what I said, and has a critical difference. I said writing *the plugin itself* is allowed. Writing the combined work of the framework, the OpenSSL-using-plugin, and the Readline-using-plugin is not allowed by the GPL. If that's the case, we should put the entire KDE development team in jail. KDE is licensed under GPL, and uses both GPL stuff and OpenSSL. It also uses Java and Netscape plugins, which are very much non-free. Why would we put them in jail? They haven't done anything criminal. When I run Konqueror to visit secure sites, both QT (which I obtained under the GPL) and OpenSSL are loaded in the same address space, which is enough to create a derived work, according to the FSF. You said yourself that even writing code capable of doing this was illegal. I certainly did not. emacs ~/src/qt/* ~/src/openssl/* loads all that code in the same address space, but is not illegal. I said that creating a single work which does that probably violates the license of the GPL'd code. I don't know the details of who writes the SSL support for Konq or how it's done, nor do I have any machines with Konqueror on them in front of me right now, so I can't comment on that. KDE is also manifestly not a single work: I use konquerer but no other part of it, for example. Any typical use of my program would use only a few of the available plugins. What's the difference? That you're making a single work which benefits from the generosity of the authors who released their code under the GPL, but don't seem willing to abide by the rules they set for derivation from their code. The KDE folks have, from what I've seen, been quite careful with licensing issues. In case you hadn't noticed, I'm trying to be, too. You seem to be looking for a way to do what you want while claiming it's within the bounds the authors set. Can you provide any specific examples of single works incorporating pure-GPL work and linking against OpenSSL? KDE is distributed as a few huge tar files, obviously intended to be used together. Someone said that was enough to make the GPL apply to all of it. Who? Where? That looks much more like mere aggregation to me. Ask yourself this: is what you're doing in compliance with the wishes of the authors of the various pieces of software you're using? I don't know what the authors wish, I'll have to ask them. They've told you in the license. They haven't told me their intent with choosing that particular license. That's not *what* they want you to do, that's *why* they want what they want. -Brian
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Brian T. Sniffen) writes: I don't know the details of who writes the SSL support for Konq or how it's done, nor do I have any machines with Konqueror on them in front of me right now, so I can't comment on that. Ah, found it -- Debian KDE list, late July 2002: Konqueror doesn't link against OpenSSL. It runs a separate process (kcm_crypto, it looks like), which links against openssl... but does so in a way that *doesn't* invoke OpenSSL's advertising clause. Thus, the GPL prohibition on additional restrictions isn't invoked, and what KDE's doing is fine. -Brian
Re: Plugins, libraries, licenses and Debian
On Mon, Dec 08, 2003 at 10:20:16AM -0600, Steve Langasek wrote: On Mon, Dec 08, 2003 at 10:44:13AM -0500, Jeremy Hankins wrote: Steve Langasek [EMAIL PROTECTED] writes: On Mon, Dec 08, 2003 at 09:27:30AM -0500, Jeremy Hankins wrote: When we see a plugin written under the GPL for a GPL-incompatible work, we have two choices: - Assume the author of the plugin was confused, and that the plugin isn't even distributable, or - Assume that the author intends that the plugin have an implicit exception for the gpl-incompatible work. - Assume that the author knows what he's doing after all, and only intends for the plugin to be distributable in source format until a GPL-compatible framework comes along. Hrm. I hadn't thought of that one. Do you know of a case where someone's actually done this? Not specifically, no; but it's a real possibility, and especially with scum like SCO tangling with the GPL now, we could even find this to be the case retroactively if there hasn't been an explicit grant to distribute binaries. How can you forget java? :P -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Binaries under GPL(2)
Alexander Cherepanov [EMAIL PROTECTED] wrote: 4-Dec-03 20:44 Walter Landry wrote: Alexander Cherepanov [EMAIL PROTECTED] wrote: 30-Nov-03 16:37 Don Armstrong wrote: If you read section 2 this way, then there is no need for a section 3 at all. And that (together with the intention of the license expressed in Preamble) seems to be the only reason why Section 2 cannot be interpreted as permitting to distribute binaries. There are no direct arguments. Sadly... You still need section 3 if you want to distribute modified binaries and remain sane, Why? If you can distribute some binaries under Section 2 that means that there is no requirement of source form in it. Then you can distribute any binaries under Section 2. Well, that is why I put in the remain sane part. If I give you GPL'd source, then there is only two ways in which you can make modifications, Section 2 and Section 3. Section 3 allows a particular kind of modification (compilation), and Section 2 allows any kind of modification. Distributing binaries under Section 2 probably means editting the binaries with a hex editor. You also need to have the rights to distribute everything in the binary under the GPL. With non-free compilers, that may be a problem. With gcc, that probably means more hex editing to include the FSF, HP, SGI, etc. copyrights. However, it does now seem like a hole in the copyleft. While possible in principle, I won't stay awake at nights worrying about it. As Henning said, it is really just an oversight. The intent is clear, which may sway a court more than the explicit wording. Regards, Walter Landry [EMAIL PROTECTED]
Re: Binaries under GPL(2)
8-Dec-03 11:15 Henning Makholm wrote: Scripsit Alexander Cherepanov [EMAIL PROTECTED] What prevents you from distributing binaries produced from sources under Section 2? Hm, that's a good question. It seems to be another wording oversight. I can't get rid of the thought that there is something else here. Mere wording oversight in the second version of the most famous/popular/important/put your favorite here free license in the world, not changed for more then ten years, written by a real lawyer, which puts the whole idea of copyleft at risk? Maybe... Sasha
