Re: [CODE4LIB] GPL incompatible interfaces
On 02/17/11 19:48, Jonathan Rochkind wrote: On 2/17/2011 12:50 PM, Eric Hellman wrote: If list members would like to name and shame GPL incompatible interfaces that they're stuck working with, have at it. If I'm mistaken and there are none left, then I'd like to know it. Well, the problem with viral licenses like GPL is that other licenses are essentially incompatible with them _unless_ they are open source -- at least if you want to share the product of your combination of those two libraries. You can't combine non-open-source code and GPL code in a single project. That's very different from saying something with a GPL license can't use a proprietary interface. As if for example Xerxes couldn't use the Metalib API - without which it would be pointless. As I understand him Eric is saying that there are interfaces to library software which actually have a license or contract which blocks GPLed software from using them. It would be a kind of 'viral BSD' license, killing free software (in the FSF sense) but leaving proprietary or open source (in your Apache/MIT sense) untouched. I haven't seen any examples myself, and can't quite see how it would be done legally. Personally, I much prefer non-viral type open source licenses like Apache or MIT for this reason. The GPL advocates argue that viral-type licenses like GPL are more free because nobody can take GPL code and turn it into a proprietary product. I see what they're trying to do. But from my perspective 'non-viral' open source licenses like Apache are 'more free' because it gives the user the freedom to combine Apache code with non-open-source code in a project. You can't do that with GPL, which seems less free to me. This is a classic position which is now 20 years or so old; I don't think anyone on either side is likely to come up with a new argument - you take your pick, and then try to find the best way to live with the people you don't agree with, because neither side is going away in a hurry. Graham Jonathan
Re: [CODE4LIB] GPL incompatible interfaces
Since the Metalib API is not public, to my knowledge, I don't know whether it gets disclosed with an NDA. And you can't run or develop Xerxes without an ExLibris License, because it depends on a proprietary and unspecified data set. I'm sure that's legal, but it's not true to the spirit of copyleft. The main effect of using GPL for Xerxes is that it prevents ExLibris from distributing (but not using) proprietary versions of Xerces. If that is the intent of the developers, then perhaps AGPL would be a better tool for them to wield. None of this should be taken as a criticism of the Xerxes developers. On Feb 18, 2011, at 3:50 AM, graham wrote: That's very different from saying something with a GPL license can't use a proprietary interface. As if for example Xerxes couldn't use the Metalib API - without which it would be pointless. As I understand him Eric is saying that there are interfaces to library software which actually have a license or contract which blocks GPLed software from using them. It would be a kind of 'viral BSD' license, killing free software (in the FSF sense) but leaving proprietary or open source (in your Apache/MIT sense) untouched. I haven't seen any examples myself, and can't quite see how it would be done legally. Eric Hellman President, Gluejar, Inc. 41 Watchung Plaza, #132 Montclair, NJ 07042 USA e...@hellman.net http://go-to-hellman.blogspot.com/ @gluejar
Re: [CODE4LIB] GPL incompatible interfaces
On Fri, Feb 18, 2011 at 9:30 AM, Eric Hellman e...@hellman.net wrote: Since the Metalib API is not public, to my knowledge, I don't know whether it gets disclosed with an NDA. And you can't run or develop Xerxes without an ExLibris License, because it depends on a proprietary and unspecified data set. This is a very good point (and neither here nor there on the licensing issue). Ex Libris, in particular, has always had an awkward relationship between the NDA-for-customers-eyes-only policy regarding their X-Services documentation and their historic tolerance for open source applications built upon said services. The latter undermines the former significantly, since the documentation could theoretically be reverse-engineered if the open source projects' uses of it are comprehensive enough. I'll leave whether or not having an NDA on API documentation makes sense as an exercise of the reader. It does mean, however, that Ex Libris could at any point claim that these projects violate those terms, which is a risk, although probably a risk worth taking. On the opposite end of the spectrum, you have SirsiDynix who refuse the distribution of applications written using their Symphony APIs to anybody but SD customers-in-good-standing-that-have-received-API-training. While SD's position is certainly draconian (and, in my opinion, rather counter-productive), it does let the developer know where she or he stands with no sense of ambiguity coming from the company. -Ross.
Re: [CODE4LIB] GPL incompatible interfaces
On Fri, Feb 18, 2011 at 3:50 AM, graham gra...@theseamans.net wrote: On 02/17/11 19:48, Jonathan Rochkind wrote: Personally, I much prefer non-viral type open source licenses like Apache or MIT for this reason. The GPL advocates argue that viral-type licenses like GPL are more free because nobody can take GPL code and turn it into a proprietary product. I see what they're trying to do. But from my perspective 'non-viral' open source licenses like Apache are 'more free' because it gives the user the freedom to combine Apache code with non-open-source code in a project. You can't do that with GPL, which seems less free to me. This is a classic position which is now 20 years or so old; I don't think anyone on either side is likely to come up with a new argument - you take your pick, and then try to find the best way to live with the people you don't agree with, because neither side is going away in a hurry. Quite true. It's a boring, old argument. Let's try to avoid the brambles of whether copyleft licenses are more or less free.
Re: [CODE4LIB] GPL incompatible interfaces
On Fri, Feb 18, 2011 at 1:29 PM, Ross Singer rossfsin...@gmail.com wrote: On Fri, Feb 18, 2011 at 9:30 AM, Eric Hellman e...@hellman.net wrote: Since the Metalib API is not public, to my knowledge, I don't know whether it gets disclosed with an NDA. And you can't run or develop Xerxes without an ExLibris License, because it depends on a proprietary and unspecified data set. This is a very good point (and neither here nor there on the licensing issue). Ex Libris, in particular, has always had an awkward relationship between the NDA-for-customers-eyes-only policy regarding their X-Services documentation and their historic tolerance for open source applications built upon said services. The latter undermines the former significantly, since the documentation could theoretically be reverse-engineered if the open source projects' uses of it are comprehensive enough. I'll leave whether or not having an NDA on API documentation makes sense as an exercise of the reader. It does mean, however, that Ex Libris could at any point claim that these projects violate those terms, which is a risk, although probably a risk worth taking. On the opposite end of the spectrum, you have SirsiDynix who refuse the distribution of applications written using their Symphony APIs to anybody but SD customers-in-good-standing-that-have-received-API-training. While SD's position is certainly draconian (and, in my opinion, rather counter-productive), it does let the developer know where she or he stands with no sense of ambiguity coming from the company. Thanks for grounding the discussion, Ross. The way I read this, then, is that it's a risk to release code under any license for an API with an NDA. So is there such a thing as an interface that's specifically GPL-incompatible?
Re: [CODE4LIB] GPL incompatible interfaces
On Thu, Feb 17, 2011 at 5:48 PM, Jonathan Rochkind rochk...@jhu.edu wrote: You can't combine non-open-source code and GPL code in a single project. Yes you can, as long as as it is an in-house project. The viral aspect of the GPL affects only distribution to third parties, not your own use of the GPL code. Lots of people do it all the time. For instance, Google reportedly heavily patches and otherwise integrates the GPL'd Linux kernel with their own proprietary software, and they can do it without any infringement because they do not distribute the resulting systems, but just use it within their infrastructure. That is exactly why the AGPL was created, by the way. To provide a way to make companies like Google share the changes they make to GPL software they use to provide services to third parties. -- Luciano Ramalho programador repentista || stand-up programmer Twitter: @luciano
Re: [CODE4LIB] GPL incompatible interfaces
On 2/17/2011 12:50 PM, Eric Hellman wrote: If list members would like to name and shame GPL incompatible interfaces that they're stuck working with, have at it. If I'm mistaken and there are none left, then I'd like to know it. Well, the problem with viral licenses like GPL is that other licenses are essentially incompatible with them _unless_ they are open source -- at least if you want to share the product of your combination of those two libraries. You can't combine non-open-source code and GPL code in a single project. Personally, I much prefer non-viral type open source licenses like Apache or MIT for this reason. The GPL advocates argue that viral-type licenses like GPL are more free because nobody can take GPL code and turn it into a proprietary product. I see what they're trying to do. But from my perspective 'non-viral' open source licenses like Apache are 'more free' because it gives the user the freedom to combine Apache code with non-open-source code in a project. You can't do that with GPL, which seems less free to me. Jonathan
Re: [CODE4LIB] GPL incompatible interfaces
Somewhat on topic - I thought this might be relevant - The most recent episode of the Free as in Freedom Podcast/Oggcast is entirely about Copyleft and the basics of compatibility. You can check out the episode here: http://www.softwarefreedom.org/podcast/2011/feb/15/free-freedom-episode-0x09-copyleft-or-later-and-ba/ cheers! -nruest On 11-02-17 02:48 PM, Jonathan Rochkind wrote: On 2/17/2011 12:50 PM, Eric Hellman wrote: If list members would like to name and shame GPL incompatible interfaces that they're stuck working with, have at it. If I'm mistaken and there are none left, then I'd like to know it. Well, the problem with viral licenses like GPL is that other licenses are essentially incompatible with them _unless_ they are open source -- at least if you want to share the product of your combination of those two libraries. You can't combine non-open-source code and GPL code in a single project. Personally, I much prefer non-viral type open source licenses like Apache or MIT for this reason. The GPL advocates argue that viral-type licenses like GPL are more free because nobody can take GPL code and turn it into a proprietary product. I see what they're trying to do. But from my perspective 'non-viral' open source licenses like Apache are 'more free' because it gives the user the freedom to combine Apache code with non-open-source code in a project. You can't do that with GPL, which seems less free to me. Jonathan attachment: ruestn.vcf
