Re: Plugins, libraries, licenses and Debian
Steve Langasek <[EMAIL PROTECTED]> writes: >> 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. > > I don't believe that is the claim. 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. -- Måns Rullgård [EMAIL PROTECTED]
Re: Plugins, libraries, licenses and Debian
Joel Baker <[EMAIL PROTECTED]> writes: > And people wonder why they call it the Gnu Public Virus... > > 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. Finally someone who shares my views. > If it were me, I'd put the GPL plugins in ghetto-land, and not the others; > they're the ones that aren't playing nicely with the rest of the world, in > this case, so they should be the ones ostracized (program, > Recommends program-plugins, Suggests program-plugins-gpl). I'm considering splitting the package into program-free and program-gpl, just to annoy those who'd be annoyed by such a naming. > This gets back into the issue over APIs and whether using GPLed code to > satisfy those APIs creates a derived work, except sort of in reverse. > Something which the FSF, of course, has a very broad opinion on, with which > many people disagree, but if you want to avoid having it decided in court, > play it safe. Maybe it would be a good thing if someone with lots of cash got the matter tried in court, and got the dynamic linking problem solved, once and for all. I have a suspicion that most people that publish their programs under the GPL use the GPL only because it's the license they've heard of the most, without really considering all the implications. I'd like to see a bit more of a discussion on these matters, so people would realize that the GPL perhaps isn't as "free" as it's advocates want it to look like. -- Måns Rullgård [EMAIL PROTECTED]
Re: Plugins, libraries, licenses and Debian
Don Armstrong <[EMAIL PROTECTED]> writes: >> If I write a program and release it under some non-GPL licencse, and >> *later* someone writes a plugin and releases it under the GPL, how >> can the program possibly become a derived work of that plugin? > > No, the program itself doesn't, but the work plugin+program does. I found this in the GPL FAQ: "The GPL does not require you to release your modified version. You are free to make modifications and use them privately, without ever releasing them." Storing the application and the plugin on a disk certainly doesn't constitute a modification to either of them. Loading the plugin will created a derived work in RAM. The derived work will never be distributed, and is thus permitted by the above paragraph. >> 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, What does it matter how other implementations are licensed? > 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. That is the case. What about source distributions? Is it allowed to distribute source code licensed under the X11 license that uses a GPL'd library? -- Måns Rullgård [EMAIL PROTECTED]
Re: Plugins, libraries, licenses and Debian
Steve Langasek <[EMAIL PROTECTED]> writes: >> > This now gets into the hazy realm where it's best not to go - a court >> > could decide either way. > >> > The argument is, approximately, that by shipping the whole lot >> > together you are creating a derived work that violates at least once >> > of the licenses. Certainly you can concoct a case where this is >> > plausible (wrap them all up in one .deb with a default configuration >> > that uses both) - and it is not at all clear where to draw the >> > line. There are legitimate arguments in both directions (the >> > counter-argument is approximately "It's not derivation, it's >> > collation"). > >> I have a CD that contains lots of GPL stuff, as well as OpenSSL (it's >> a Slackware CD). I downloaded it as an iso file from some ftp >> server. Apparently, an iso9660 format filesystem containing tar files >> of GPL and GPL incompatible software is allowed. Where is the >> fundamental difference if the format of the wrapper is changed from >> iso9660 to tar, and the internal files are shared objects instead of >> tar files? > > The intent of the distributor in how the individual program bits should > be used together, and the feasibility of using them separately. (I.e.: > there is *no* fundamental difference between iso9660 and tar for these > purposes.) So what prevents two independent plugins, each usable on it's own, from being distributed together? That the user could possibly load both at the same time, creating a "derived work"? This derived work would only exist in the computers memory during the execution of the program, and would almost certainly not be distributed. -- Måns Rullgård [EMAIL PROTECTED]
Re: Plugins, libraries, licenses and Debian
Andrew Suffield <[EMAIL PROTECTED]> writes: >> How's that? The GPL allows distribution together with non-GPL works, >> as long as the non-GPL things are not derived from anything GPL'd. In >> my opinion, placing two shared objects in the same tar file doesn't >> make one a derived work of the other. Would it make a difference if >> the offending (to rms) plugins were distributed separately? > > "Maybe". > > This now gets into the hazy realm where it's best not to go - a court > could decide either way. > > The argument is, approximately, that by shipping the whole lot > together you are creating a derived work that violates at least once > of the licenses. Certainly you can concoct a case where this is > plausible (wrap them all up in one .deb with a default configuration > that uses both) - and it is not at all clear where to draw the > line. There are legitimate arguments in both directions (the > counter-argument is approximately "It's not derivation, it's > collation"). I have a CD that contains lots of GPL stuff, as well as OpenSSL (it's a Slackware CD). I downloaded it as an iso file from some ftp server. Apparently, an iso9660 format filesystem containing tar files of GPL and GPL incompatible software is allowed. Where is the fundamental difference if the format of the wrapper is changed from iso9660 to tar, and the internal files are shared objects instead of tar files? -- Måns Rullgård [EMAIL PROTECTED]
Re: Plugins, libraries, licenses and Debian
Arnoud Engelfriet <[EMAIL PROTECTED]> writes: >> >> OK, say I use the X11 license. Now suppose someone installs a closed >> >> source plugin. Suppose it also happens that this same user has >> >> installed some GPL plugin. Both plugins would be allowed separately, >> >> right? When the user runs the program, it will load both plugins. >> >> Would this in some magical way make the plugins derived works of each >> >> other, thus violating the GPL? >> > >> > No. But a vendor could get into trouble if they shipped both. >> >> How's that? The GPL allows distribution together with non-GPL works, >> as long as the non-GPL things are not derived from anything GPL'd. In >> my opinion, placing two shared objects in the same tar file doesn't >> make one a derived work of the other. Would it make a difference if >> the offending (to rms) plugins were distributed separately? > > The FSF seems of the opinion that a program that uses a > library is a derivative work of the library, because > at runtime the two are combined. > http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL > > It seems logical that they are of the same opinion regarding > plugins. I've read the GPL FAQ and the twisted logic therein. I can somewhat follow the argument as it applies to shared libraries, but strictly speaking, the combination of program and library only exists in the RAM on the computer, and is never distributed (unless someone distributes core dumps). Still, I can accept the argument that the program is tied to the library, even before linking, and thus should be considered a derived work. When it comes to plugins, I have to disagree with the FSF. If I write a program and release it under some non-GPL licencse, and *later* someone writes a plugin and releases it under the GPL, how can the program possibly become a derived work of that plugin? 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? BTW, what is the FSF's position on programs communicating using CORBA-like methods? -- Måns Rullgård [EMAIL PROTECTED]
Re: Plugins, libraries, licenses and Debian
Andrew Suffield <[EMAIL PROTECTED]> writes: >> OK, say I use the X11 license. Now suppose someone installs a closed >> source plugin. Suppose it also happens that this same user has >> installed some GPL plugin. Both plugins would be allowed separately, >> right? When the user runs the program, it will load both plugins. >> Would this in some magical way make the plugins derived works of each >> other, thus violating the GPL? > > No. But a vendor could get into trouble if they shipped both. How's that? The GPL allows distribution together with non-GPL works, as long as the non-GPL things are not derived from anything GPL'd. In my opinion, placing two shared objects in the same tar file doesn't make one a derived work of the other. Would it make a difference if the offending (to rms) plugins were distributed separately? -- Måns Rullgård [EMAIL PROTECTED]
Re: Plugins, libraries, licenses and Debian
Walter Landry <[EMAIL PROTECTED]> writes: >> I am working on a piece of free software that makes extensive use of >> plugins, i.e. shared objects dynamically loaded at runtime. Many of >> these plugins are linked with third-party libraries. The licenses of >> those libraries vary, including at least GPL, LGPL and X11. Now I'm >> trying to work out what choices of license for my program would allow >> distribution of binaries, and also what would be DFSG-free. I'd >> appreciate some comments about these matters. > > If you choose any of those licenses (GPL, LGPL, X11), you should be > fine. There is no problem using those plugins with your program. So > the question comes down to which one you prefer for your own work. OK, say I use the X11 license. Now suppose someone installs a closed source plugin. Suppose it also happens that this same user has installed some GPL plugin. Both plugins would be allowed separately, right? When the user runs the program, it will load both plugins. Would this in some magical way make the plugins derived works of each other, thus violating the GPL? Assume that the author of the closed source plugin doesn't have any GPL'd plugins. > However, if there are other plugins distributed with GPL-incompatible > licenses (e.g. something that links to OpenSSL), then it gets more > complicated. Hmm, now that I look closer, one plugin uses OpenSSL. How much trouble does that create? -- Måns Rullgård [EMAIL PROTECTED]
Plugins, libraries, licenses and Debian
I am working on a piece of free software that makes extensive use of plugins, i.e. shared objects dynamically loaded at runtime. Many of these plugins are linked with third-party libraries. The licenses of those libraries vary, including at least GPL, LGPL and X11. Now I'm trying to work out what choices of license for my program would allow distribution of binaries, and also what would be DFSG-free. I'd appreciate some comments about these matters. -- Måns Rullgård [EMAIL PROTECTED]
Re: Source only opensource licence.
Josselin Mouette <[EMAIL PROTECTED]> writes: >>The licence would not be so bad. The only restriction is about the >> redistribution of binaries wich would be restricted. Windows binaries >> distribution would be forbidden, but GNU/Linux (as well as GNU Hurd and >> BSDs) binary distribution would be okay without restriction. >> >> >From the GNU/Linux point of view, the licence is like GPL. Only windows >> and other non free operating system would be restricted. For them, the >> licence is like QMail's licence. > >>We would like to write the most open-source friendly licence based on >> the above terms, and we are open to any suggestion. Dual licencsing is >> an option if we find a way to make evrything working. > > It is quite difficult to make a software free, but only for some use. > Well, this is often non-free. > > If there are enough Windows-specific bits, you might want to license the > *nix version under the GPL, and the windows version under a qmail-like > license. You could license just the windows bits under any GPL-incompatible open source license. That would disallow binaries containing those bits of code. Since the Linux version would only need the GPL parts, binaries would be allowed there. It could be difficult to prevent binaries for commercial Unixes that way, though. -- Måns Rullgård [EMAIL PROTECTED]
Re: centericq and MSN support
Dylan Thurston <[EMAIL PROTECTED]> writes: > I believe courts have drawn a legal distinction between products or > code that has a reasonable legal purpose and code that has no such > legal purpose. In the case of MSN, would it be legal to run a private server, using the MSN9 protocol? Or is the protocol patented or copyrighted in some way? If such a server is legal, then a non-authorized client would also have a possible legal use. -- Måns Rullgård [EMAIL PROTECTED]
Re: BSD Protection License
Dylan Thurston <[EMAIL PROTECTED]> writes: > I also don't think the original license was at all ambiguous in the > clause 3 vs. clause 4 issue: such a license is a grant of permission, > and if I grant you permission to do X if Y, and also grant permission > to do X if Z, then if you do either Y or Z, then you can do X. If one > wanted to tie the two clauses together, then you'd have to add some > explicit language linking the two clauses. I think it's a question of how "if" is interpreted. "X if Y; X if Z" is equivalent to "X if (Y or Z)" However, "X if and only if Y; X if and only if Z" is equivalent to "X if (Y and Z)" Some choose to interpret the word "if" as meaning "if and only if", whereas others choose the meaning "if, and possibly otherwise". The word "if", as used in the English language, doesn't provide that distinction by itself. In a legal document, such as a license, care should be taken to make it clear which of these versions you actually mean, or the judge/jury/lawyers may well choose the other, if there is ever a court case. -- Måns Rullgård [EMAIL PROTECTED]
Re: BSD Protection License
MJ Ray <[EMAIL PROTECTED]> writes: >> How am I (mis)representing anything as being a work "from BSD"? >> What is "BSD", anyway, as a legal entity? (AFAIK, BSD inc. no >> longer exists.) > > I suggest that it is reasonable to expect that "BSD Protection > License" would create the impression of being a "Protection Licence" > originally from "BSD", just as "BSD License" is normally considered a > "License" originally from "BSD". In that case, BSD is generally > recognised to be the Berkeley Software Distribution, which you also My first thought when I read "BSD Protection License", was that it would have some connection to the usual BSD License. Since there appears to be no such connection, it is misleading to "BSD" in the name. Why did you choose that name? -- Måns Rullgård [EMAIL PROTECTED]
Re: BSD Protection License
Colin Percival <[EMAIL PROTECTED]> writes: >My MUA is fine; the thread was broken by the fact that I was >replied to an email Adam sent me, and I CCed my reply to >debian-legal. It's considered impolite to reply in public to private mail. >This email might break the thread again -- because I'm replying to >an email which wasn't sent to me, by copying and pasting out of the >list archives. > >> > I don't think that's necessary. Licenses are interpreted by >> > "reasonable men"; >> >>No. Licenses are interpreted by judges and/or juries. > >Judges and/or juries, who are assumed to be reasonable. I don't Your assumption is false. >see that there is any confusion inherent in a license which states >"You may do X if Y. You may do X if Z"; but even if there was >confusion, it is to be interpreted in a manner which makes sense. You should read up on some court cases. -- Måns Rullgård [EMAIL PROTECTED]
Re: Claims on game concepts
Matthew Palmer <[EMAIL PROTECTED]> writes: > So, what does everyone think? Is there any branch of law which could give > the person or company that thought up how to play a game a claim against a > separate, not-otherwise-infringing implementation of such a game? Yes, a fat wallet. -- Måns Rullgård [EMAIL PROTECTED]
Re: GFDL and Anonymity --- another problem?
Anthony DeRobertis <[EMAIL PROTECTED]> writes: >> The copyright holder can be an individual or a group, but in any case >> an entity recognized by the law. > > Sure. But he doesn't have to identify himself, and certainly not by > his actual name. I've seen lots of files copyrighted by "Monty" or "Xiphophorus". Does anyone know who they are? IMHO, it's just silly to not use your real name. What is there to fear? -- Måns Rullgård [EMAIL PROTECTED]
