| |||||||||||||
|
| |||||||||||||
Open source Skype client under developmentOpen source Skype client under developmentPosted Nov 2, 2009 18:41 UTC (Mon) by mem (subscriber, #517)In reply to: Open source Skype client under development by nye Parent article: Open source Skype client under development
Uhm... no.
The binary blob can have its own license and be happy like that.
Pidgin can have it's GPL lincense and be happy like that, too.
The mix, binary blob + pidgin, has to be licensed under the GPL's terms, which obviously isn't possible given that the binary blob is a binary blob. This effectively makes the mix non-distributable. If people really wish to use that little monster, they have to obtain the binary blob independently from Pidgin.
This is the same situation that you find when the Linux kernel loads a binary-only module. And that has been discussed and documented in a lot of places, for example: http://kerneltrap.org/node/1735
(Log in to post comments)
Open source Skype client under development Posted Nov 3, 2009 0:43 UTC (Tue) by SEMW (guest, #52697) [Link]
> If people really wish to use that little monster, they have to obtain the binary blob independently from Pidgin.
True. But modern package management surely makes that a fairly trivial detail for most people. When my Mother listens to a wma file in totem, she neither knows nor cares that the program itself came from the main Ubuntu repository wheras the necessary codec came from the Medibuntu repository. Similarly, there's surely no reason you couldn't have the binary blob, along with any necessary glue to let it be used as a pidgin plugin, distributed likewise (separately from pidgin, in distributions' non-free repositories)?
Open source Skype client under development Posted Nov 3, 2009 13:48 UTC (Tue) by nye (guest, #51576) [Link]
>The mix, binary blob + pidgin, has to be licensed under the GPL's terms, which obviously isn't possible given that the binary blob is a binary blob
I don't agree with that reasoning.
You have three pieces of software:
Component 3, the plugin, can link against any libraries without making any of them a derivative work of each other (I hope we can agree on that part).
From here we can see trivially that it is legal for one to write and use the plugin, though perhaps not distribute it.
In order to distribute it, the plugin must then obviously be released under the GPL, so the question is whether software which links to proprietary libraries may be released under the GPL.
I agree that there is a reasonable reading of the GPL which would lead to the answer being 'no', but then that would appear to make vast amounts of GPL software potentially illegal to distribute for proprietary operating systems (anything requiring any components not shipped with the OS out of the box, and now that I think about it, most of Debian's 'contrib' repositories), which is not a position I've seen taken seriously.
Open source Skype client under development Posted Nov 3, 2009 14:49 UTC (Tue) by farnz (guest, #17727) [Link] And, indeed, as long as you're not distributing all three bits together, there's a probably legal way to distribute in parts:
The only question marks are whether the plugin ends up qualifying legally as a derived work of both the blob and of Pidgin, and whether the interaction between the blob's licence for derived works and the GPL is legally acceptable. My non-lawyer's intuition is that if the blob's licence for derived works allows open source plugins, then the scenario I outline is clearly OK. Combining Pidgin with the plugin leaves you with a pure GPL work, which cannot then be distributed with the blob (but can be used with the blob - the GPL only talks about distribution). Combining the blob and the plugin gets you a GPL with exception for the blob work, which cannot be distributed with Pidgin (but again, can be used with Pidgin). So long as you don't combine all three before distribution, you can use them.
Open source Skype client under development Posted Nov 3, 2009 23:39 UTC (Tue) by Wol (guest, #4433) [Link]
wrt (3) ...
Except, as the end user, you DON'T need the GPL's permission to link the plugin to the blob.
If the distributor leaves it to the end user to get hold of the blob by other means, then everything's legal, end of.
Cheers,
Open source Skype client under development Posted Nov 4, 2009 8:19 UTC (Wed) by farnz (guest, #17727) [Link] I wouldn't be quite so confident - we're into the legally grey territory that I don't think anyone wants to get clarified by a court (they'd affect most, if not all, of the pre-packaged software industry, and not just on Linux). Yes, the end-user is OK if the only licence causing issues is the GPL, but there are two question-marks to clarify, and either Pidgin's copyright owners or the blob's copyright owners could cause the plugin to be legally impossible to distribute:
I'm not aware of precedent for either question, given that the user has accepted the blob's licence, and while I would be very surprised if the question was brought to court (by either party), I wouldn't go as far as "end of". The reason I said that this affects the entire pre-packaged software industry is that whatever a court decides determines such questions as whether any form of EULA can be enforced. This is a rather big deal, and I doubt that anyone big wants to risk a court giving the "wrong" answer.
Open source Skype client under development Posted Nov 4, 2009 2:03 UTC (Wed) by khc (subscriber, #45209) [Link]
As a pidgin developer (and I believe my opinion is shared by most, if not all, other pidgin developers), I believe that there cannot be a pidgin plugin that links to non-GPL compatible libraries and still claims to play within the rules of GPL. While some alternative reading of the GPL may make this legal, I certainly think that it violates the intent of the license.
Of course it's unlikely that anyone will sue though.
Open source Skype client under development Posted Nov 3, 2009 15:37 UTC (Tue) by mem (subscriber, #517) [Link] anything requiring any components not shipped with the OS out of the box, and now that I think about it, most of Debian's 'contrib' repositories If you examine Debian's contrib section and its dependencies wrt to the non-free section, you'll note two things: there are very few actual dependencies and the ones that do exist are mostly in the form of "free program" depending on "non-free data". You'll also note that if free data becomes available, the free program in contrib is "promoted" to the main section. You'll also note that you don't find a sinle case of "code" depending on "code". And yes, there are a handful of debatable cases, for example the game Warsow, where (at least part of) its non-free data is quite likely code from the POV of the game engine. The "ships with the OS" exception that you refer to has been subject of debate for years and if my memory serves well, it was part of the KDE/Qt case: KDE, being GPL, depended on non-free Qt, which wasn't part of the OS, even if some people tried to argue that it was. If you recall that situation, you'll remember that for a long time KDE wasn't included anywhere in Debian.
Open source Skype client under development Posted Nov 5, 2009 15:48 UTC (Thu) by nye (guest, #51576) [Link]
I see your point. I was thinking that there were pieces of software in contrib that were capable of using non-free libraries to perform certain functions[0], but perhaps they're only allowed into contrib if they add functionality by calling an inarguably standalone executable that you may choose to install from elsewhere.
This has however led me to conclude that there is a good argument for a fair bit of software compiled for Windows being technically not distributable, depending on how generously the 'system libraries' exception is interpreted.
[0] Like hugin, say - although that's a patent issue rather than a copyright one, and I think that's actually in main because it doesn't *need* the problematic part. Okay so that was a bad example :P.
|
|
||||||||||||