Re: Concurrent Licenses?
On Mon, 10 Apr 2000 10:51:16 -0400, "Rod Dixon, J.D., LL.M." [EMAIL PROTECTED] wrote: I have noticed this A to B to C argument before, but I am uncertain whether it is applicable if the GPL has a strong copyleft provision. The GNU GPL is better viewed as A to B; A to B/C; A to C; A to D; and so on. But doesn't this omit the fact that B's derivative 'bits' may evoke copyright subsistence, thereby requiring a concurrent license from B to C in addition to the license from A to C? Otherwise, C only has license to the initial program, but not the derivative 'bits'? I think this situation is particularly so in Berne signatories where copyright does not have to be registered in order to subsist. The bottom line is that A cannot license what he does not own. And A certainly cannot own B's copyright to the derivative 'bits' if these indeed do subsist. If you keep in mind that the GNU GPL's purpose is to recapture copyright in instances where the public domain could not, then you should be better able to focus on why A is the only party who may bring suit if the GPL is violated. This fact changes dramatically under open source public licenses that do not have a strong copyleft. Indeed, your example, generally, is correct for GPLs with no copyleft. Please explain what is "GPLs with no copyleft". I do not agree that only the copyright holder can sue. Surely an owner of copyright to the derivative bits has sufficient interest at stake to have standing to sue? No doubt he first has to show copyright subsistence, but once he has established that, I don't see a reason why he can't sue.
Re: Concurrent Licenses?
On Tue, Apr 11, 2000 at 01:05:39PM +0100, W . Yip wrote: The bottom line is that A cannot license what he does not own. And A certainly cannot own B's copyright to the derivative 'bits' if these indeed do subsist. I think this is why the copyleft in the GPL is worded like this: b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. The GPL does not attempt to regulate what C does with B's work. The GPL regulates the terms under which B licenses the work to C (something B does). I think there are two ways to look at this, and I'm not sure which is right: -- A has implicitly given B permission to sublicense under these terms, and C gets only a single license from B. -- C gets a concurrent or joint license from A and B In either case B plays a role in licensing here, and should be able to take action against an infringer. I do not agree that only the copyright holder can sue. Surely an owner of copyright to the derivative bits has sufficient interest at stake to have standing to sue? No doubt he first has to show copyright subsistence, but once he has established that, I don't see a reason why he can't sue. This is why I have this controversial clause in my license, which everyone thinks is going to be difficult to get right: For the sole purpose of taking action to remedy the unlawfull distribution of our software and recover damages, lawfull distributors shall be considered beneficial owners of the right to copy and distribute it, and so shall have the authority to pursue such actions. (Note: the wording has changed slightly since I last posted it). I want to make sure that every major stake holder has the right to sue, even if their stake is that they profit by distributing the software. For example, a distributor like Red Hat depends on everyone else following the license as they do. If a competitor could access all of Red Hat's improvements to Linux, but refused to share their own, then surely that harms Red Hat in some way and they ought to be able to sue someone. Without a clause like this, Red Hat could maybe sue the copyright holder for failing to uphold the license. But that's not really what's wanted here. Justin
Apache v. GPL
Hi. I have some trouble grasping why Apache license is incompatible with the GPL. Is it because of the naming restrictions in Apache constituting additional restrictions that are prohibited by the GPL? Or is it because of: Redistributions of any form whatsoever must retain the following *acknowledgment: *"This product includes software developed by the Apache Group *for use in the Apache HTTP server project (http://www.apache.org/)." The above sounds like the obnoxious advert clause in the dreaded 'old-BSD'. Then again, how does an advertisement clause such as the above amount to incompatibility with GPL? My final question is this. When literature mentions 'compatibility', do they refer to compatibility of licenses in a situation involving: (i) dual licensing (eg. Perl under both Artistic and GPL); or (ii) intermixing of code released under different licenses. Help appreciated.
Re: Apache v. GPL
W. Yip writes: Hi. I have some trouble grasping why Apache license is incompatible with the GPL. Is it because of the naming restrictions in Apache constituting additional restrictions that are prohibited by the GPL? Or is it because of: Redistributions of any form whatsoever must retain the following *acknowledgment: *"This product includes software developed by the Apache Group *for use in the Apache HTTP server project (http://www.apache.org/)." The above sounds like the obnoxious advert clause in the dreaded 'old-BSD'. Then again, how does an advertisement clause such as the above amount to incompatibility with GPL? The GPL requires people relying on its permissions to grant the same permissions to others in order to distribute code. The GPL gives you permission to distribute with no advertising clause, so if you distribute with a requirement to retain an advertising clause, you have not successfully cause[d] any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. and you may also be in trouble because [y]ou may not impose any further restrictions on the recipients' exercise of the rights granted herein. The conventional view on GPL compatibility, which has been disputed sometimes, is that a license must be strictly less restrictive than the GPL in every regard, or else allow sublicensing under the GPL, in order to be GPL-compatible. I shouldn't say "or else" -- because of the passages quoted above, we can argue that "strictly less restrictive than the GPL in every regard" _implies_ allowing sublicensing or dual licensing under the GPL. And that is what the GPL expects. My final question is this. When literature mentions 'compatibility', do they refer to compatibility of licenses in a situation involving: (i) dual licensing (eg. Perl under both Artistic and GPL); or It seems unlikely that a license would be successful in the free software world if it attempted to prohibit dual licensing, so no. (ii) intermixing of code released under different licenses. Yes -- as Jim Dennis said yesterday, "the ability to merge two projects" into one, or to excerpt code from one project and re-use it in another, releasing the end result to the public as a free software program. -- Seth David Schoen [EMAIL PROTECTED] | And do not say, I will study when I Temp. http://www.loyalty.org/~schoen/ | have leisure; for perhaps you will down: http://www.loyalty.org/ (CAF) | not have leisure. -- Pirke Avot 2:5
Re: Concurrent Licenses?
"W. Yip" wrote: But doesn't this omit the fact that B's derivative 'bits' may evoke copyright subsistence, thereby requiring a concurrent license from B to C in addition to the license from A to C? Otherwise, C only has license to the initial program, but not the derivative 'bits'? Indeed. B has to grant C this license, though, under the terms of his conditional right to create a derivative work from A's code. So: A licensed code to B under the GNU GPL A licensed code to C under the GNU GPL A licensed code to D under the GNU GPL ... B made a derivative work from A's code B distributes the derivative work to C B must license his parts to C under the GNU GPL, because if he does not, he has no rights from A any more. The bottom line is that A cannot license what he does not own. And A certainly cannot own B's copyright to the derivative 'bits' if these indeed do subsist. No, but A can make it a condition of B's license to create derivative works that he license his bits under the GNU GPL. Please explain what is "GPLs with no copyleft". The term "GPL" is used equivocally in the literature: usually it means the specific GNU General Public License; sometimes it refers to any general public license, such as the X/MIT/newBSD license, the oldBSD/Apache license, the Artistic License, and even unfree ones like the Aladdin Public License. These licenses do not impose any restrictions on the makers of derivative works, and so lack the essential copyleft principle. They have been called "copycenter" licenses: i.e., take the code to the copy center and make as many copies (or derivative works) as you want. -- Schlingt dreifach einen Kreis um dies! || John Cowan [EMAIL PROTECTED] Schliesst euer Aug vor heiliger Schau, || http://www.reutershealth.com Denn er genoss vom Honig-Tau, || http://www.ccil.org/~cowan Und trank die Milch vom Paradies.-- Coleridge (tr. Politzer)
Re: Concurrent Licenses?
Justin Wells wrote: I think there are two ways to look at this, and I'm not sure which is right: -- A has implicitly given B permission to sublicense under these terms, and C gets only a single license from B. -- C gets a concurrent or joint license from A and B C has a license from A anyway for A's original content, because everybody has such a license. -- Schlingt dreifach einen Kreis um dies! || John Cowan [EMAIL PROTECTED] Schliesst euer Aug vor heiliger Schau, || http://www.reutershealth.com Denn er genoss vom Honig-Tau, || http://www.ccil.org/~cowan Und trank die Milch vom Paradies.-- Coleridge (tr. Politzer)
Re: Apache v. GPL
"W. Yip" wrote: Is it because of the naming restrictions in Apache constituting additional restrictions that are prohibited by the GPL? No, the GPL can survive that. Or is it because of: Redistributions of any form whatsoever must retain the following *acknowledgment: *"This product includes software developed by the Apache Group *for use in the Apache HTTP server project (http://www.apache.org/)." The above sounds like the obnoxious advert clause in the dreaded 'old-BSD'. Yes, and it is in essence the same restriction. Then again, how does an advertisement clause such as the above amount to incompatibility with GPL? Clause 6 says: # You may not impose any further restrictions on the recipients' exercise # of the rights granted herein. Consider a program X that derives from Apache/old-BSD licensed code A and GNU licensed code G. Using G requires that X be distributed with a license no more restrictive than the GPL; in other words, it may not impose restrictions that the GPL does not impose. Using A imposes the restriction that every copy of X must contain the ad from A. These requirements being contradictory, X may not be distributed at all. My final question is this. When literature mentions 'compatibility', do they refer to compatibility of licenses in a situation involving: (i) dual licensing (eg. Perl under both Artistic and GPL); or (ii) intermixing of code released under different licenses. (ii). -- Schlingt dreifach einen Kreis um dies! || John Cowan [EMAIL PROTECTED] Schliesst euer Aug vor heiliger Schau, || http://www.reutershealth.com Denn er genoss vom Honig-Tau, || http://www.ccil.org/~cowan Und trank die Milch vom Paradies.-- Coleridge (tr. Politzer)
Re: Apache v. GPL
Seth David Schoen wrote: It seems unlikely that a license would be successful in the free software world if it attempted to prohibit dual licensing, so no. Indeed, it would be nonsense. Nobody but the author can license code under any particular license, so saying "I license my code under license X and no other" is a promise to one's self alone. -- Schlingt dreifach einen Kreis um dies! || John Cowan [EMAIL PROTECTED] Schliesst euer Aug vor heiliger Schau, || http://www.reutershealth.com Denn er genoss vom Honig-Tau, || http://www.ccil.org/~cowan Und trank die Milch vom Paradies.-- Coleridge (tr. Politzer)
Re: Apache v. GPL
I should point out that V1.1 of the Apache licence has followed the model of new-BSD; see http://www.apache.org/LICENSE. Is this new licence now GPL-compatible? -- #kenP-)} Ken Coarhttp://Golux.Com/coar/ Apache Software Foundation http://www.apache.org/ "Apache Server for Dummies" http://Apache-Server.Com/ "Apache Server Unleashed" http://ApacheUnleashed.Com/
Re: Apache v. GPL
On Tue, 11 Apr 2000, Rodent of Unusual Size wrote: I should point out that V1.1 of the Apache licence has followed the model of new-BSD; see http://www.apache.org/LICENSE. Note that this new license has only been applied to the current tree, both 1.3 branch and 2.0 branch; apache 1.3.12 and previous releases are all under the older license. Also, the Jakarta and XML Apache projects have been using this new license since their initial releases. I'm not sure if mod_perl has picked this up yet, nor mod_jserv. Is this new licence now GPL-compatible? When I asked Stallman he said he found it much less troublesome than the older one, but didn't issue an official declaration or anything. Brian
Re: Apache v. GPL
John Cowan writes: Seth David Schoen wrote: It seems unlikely that a license would be successful in the free software world if it attempted to prohibit dual licensing, so no. Indeed, it would be nonsense. Nobody but the author can license code under any particular license, so saying "I license my code under license X and no other" is a promise to one's self alone. I'm thinking of something like this: If the copyright holder of this package has granted permission to anyone to redistribute it under the copyright laws on any terms other than these, or by any instrument other than this license, then this permission is void, and you have no right under this license to distribute the software. In other words, a license could get so offended when an author dual-licensed some code that it cancels itself. :-) So it should be possible to have a license which is resistent to use in dual licensing situations. The author of the licensed code wouldn't be prohibited from granting the permissions; instead, one of the permission grants, by its own terms, might be inoperative. -- Seth David Schoen [EMAIL PROTECTED] | And do not say, I will study when I Temp. http://www.loyalty.org/~schoen/ | have leisure; for perhaps you will down: http://www.loyalty.org/ (CAF) | not have leisure. -- Pirke Avot 2:5
RE: Concurrent Licenses?
A licensed code to B under the GNU GPL A licensed code to C under the GNU GPL A licensed code to D under the GNU GPL ... B made a derivative work from A's code B distributes the derivative work to C B must license his parts to C under the GNU GPL, because if he does not, he has no rights from A any more. This is a very good diagram. I would only quibble with the last line. Since under copyright law the copyright to all derivative works is owned by the original copyright holder (in this instance "A"), A owns B's derivative, but B is free distribute it. Hence, the GNU GPL controls the distribution terms of B's work and operates as the license between A and C. B's contractual relationship under the GPL is between A and B only. A is always a party to the license. If we were dsicussing a GPL with a weak copyleft provision (like the NPL), then you my have contractual relationships that do not include A at all. The bottom line is that A cannot license what he does not own. And A certainly cannot own B's copyright to the derivative 'bits' if these indeed do subsist. No, but A can make it a condition of B's license to create derivative works that he license his bits under the GNU GPL. Please explain what is "GPLs with no copyleft". The term "GPL" is used equivocally in the literature: usually it means the specific GNU General Public License; sometimes it refers to any general public license, such as the X/MIT/newBSD license, the oldBSD/Apache license, the Artistic License, and even unfree ones like the Aladdin Public License. These licenses do not impose any restrictions on the makers of derivative works, and so lack the essential copyleft principle. They have been called "copycenter" licenses: i.e., take the code to the copy center and make as many copies (or derivative works) as you want. The copycenter metaphor is more cute than descriptive of the weak copyleft. The caution is that it does not distinguish the two types of licenses since works under any public license may be freely copied. It's the fact that the terms of the GPL, itself, may be altered when there is a weak or no copyleft. (The Public Domain problem that copyleft avoids). Rod Dixon, J.D., LL.M. www.cyberspaces.org [EMAIL PROTECTED]
Re: Apache v. GPL
G'day all. W. Yip writes: Then again, how does an advertisement clause such as the above amount to incompatibility with GPL? On Tue, Apr 11, 2000 at 09:13:21AM -0700, Seth David Schoen wrote: The GPL requires people relying on its permissions to grant the same permissions to others in order to distribute code. Of course the copyright holder does not rely on any permissions in order to distribute their own code. If I create GPL'd code which I attempt to combine with pre-existing Apache-licensed code, I am not bound by the GPL on my own code. That suggests that for me the two licenses are "compatible", doesn't it? I may have effectively stopped others from redistributing my code, of course, but that's my fault for choosing an "incompatible" licence. Cheers, Andrew Bromage
