Re: What about LGPL? Re: Compatibility of the AFL with the GPL
My appologies. I was confused between ASL and AFL. I interperated the latter to be a misnomer referring to the first. It is currently the position of the Apache Software Foundation that the terms of the LGPL in the case of Java might cause section 6 of that license to bind the ASL licensed software. (and only in the case of Java) -Andy Lawrence E. Rosen wrote: The AFL has the same effect with the LGPL as it does with the GPL. I contend it is also fully compatible. All are free licenses. The issue has nothing to do with linking. /Larry Rosen -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Andrew C. Oliver Sent: Friday, March 14, 2003 5:12 AM To: [EMAIL PROTECTED] Subject: What about LGPL? Re: Compatibility of the AFL with the GPL Lawrence E. Rosen wrote: Richard, Today you finally gave public reasons for your assertion that the AFL is incompatible with the GPL. Because you are simply wrong on the law and wrong-headed on a matter of principle, I must file this public response. So I think I understand the controvery regarding GPL and why GPL and ASL (aka AFL) don't work together. What about LGPL and ASL in the situation of Java? Apache has a long standing ban on LGPL being used in Java projects and I want to know if its justified. I asked if Eben Moglen's comments in slashdot on the subject were sufficient to lift the ban and Roy Fielding responded: No. What the FSF needs to say is that inclusion of the external interface names (methods, filenames, imports, etc.) defined by an LGPL jar file, so that a non-LGPL jar can make calls to the LGPL jar's implementation, does not cause the including work to be derived from the LGPL work even though java uses late-binding by name (requiring that names be copied into the derived executable), and thus does not (in and of itself) cause the package as a whole to be restricted to distribution as (L)GPL or as open source per section 6 of the LGPL. Most authors of Java software using the LGPL license intend to allow linking (basically the use of the java import of classes in their jar file). Who is right? Apache with their insistance that the LGPL is viral for Java software or the masses who think LGPLing their code causes modifiers to contribute but linking/use to be uninhibited even to proprietary software? (where the term link is not wholely appropriate for Java, I interperate it to mean including a jar in the classpath at compile-time and runtime and having import statement naming classes inside of a jar) On a personal note, clearing this up would help me greatly as I would like to use Trove4J (http://trove4j.sourceforge.net/) in the Apache project I founded (http://jakarta.apache.org/poi) instead of our own collection classes. Secondly, I am considering releasing an upcoming Java codebase in LGPL or GPL, and while I understand the full ramifications of GPL, I do not feel I fully understand the ramifications of LGPL with regards to this issue. I would greatly appreciate if Mr. Stallman and Mr. Rosen could provide a definitive answer on this. Thank you, Andrew C. Oliver -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: What about LGPL? Re: Compatibility of the AFL with the GPL
The AFL has the same effect with the LGPL as it does with the GPL. I contend it is also fully compatible. All are free licenses. The issue has nothing to do with linking. /Larry Rosen -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Andrew C. Oliver Sent: Friday, March 14, 2003 5:12 AM To: [EMAIL PROTECTED] Subject: What about LGPL? Re: Compatibility of the AFL with the GPL Lawrence E. Rosen wrote: Richard, Today you finally gave public reasons for your assertion that the AFL is incompatible with the GPL. Because you are simply wrong on the law and wrong-headed on a matter of principle, I must file this public response. So I think I understand the controvery regarding GPL and why GPL and ASL (aka AFL) don't work together. What about LGPL and ASL in the situation of Java? Apache has a long standing ban on LGPL being used in Java projects and I want to know if its justified. I asked if Eben Moglen's comments in slashdot on the subject were sufficient to lift the ban and Roy Fielding responded: No. What the FSF needs to say is that inclusion of the external interface names (methods, filenames, imports, etc.) defined by an LGPL jar file, so that a non-LGPL jar can make calls to the LGPL jar's implementation, does not cause the including work to be derived from the LGPL work even though java uses late-binding by name (requiring that names be copied into the derived executable), and thus does not (in and of itself) cause the package as a whole to be restricted to distribution as (L)GPL or as open source per section 6 of the LGPL. Most authors of Java software using the LGPL license intend to allow linking (basically the use of the java import of classes in their jar file). Who is right? Apache with their insistance that the LGPL is viral for Java software or the masses who think LGPLing their code causes modifiers to contribute but linking/use to be uninhibited even to proprietary software? (where the term link is not wholely appropriate for Java, I interperate it to mean including a jar in the classpath at compile-time and runtime and having import statement naming classes inside of a jar) On a personal note, clearing this up would help me greatly as I would like to use Trove4J (http://trove4j.sourceforge.net/) in the Apache project I founded (http://jakarta.apache.org/poi) instead of our own collection classes. Secondly, I am considering releasing an upcoming Java codebase in LGPL or GPL, and while I understand the full ramifications of GPL, I do not feel I fully understand the ramifications of LGPL with regards to this issue. I would greatly appreciate if Mr. Stallman and Mr. Rosen could provide a definitive answer on this. Thank you, Andrew C. Oliver -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
The point of the law school exam being for anyone to be able to show a difference in people's behavior in re GPLed code versus AFL+GPLed code. How can the licenses be said to be incompatible if the supposed incompatibility causes no change in anyone's behavior? The presence of the AFL mutual defense clause would make a real difference to people's behavior in the following case. Suppose W is under the GPL and X is under the AFL. P combines them and distributes X+W to Q saying it is licensed under the GPL. Now suppose that Q sues some unrelated party R for patent infringement about some unrelated program Z and triggers the mutual defense clause. If the license for X+W is the GPL, this patent suit has no effect on Q's right to use X+W. Q can still use it--or any part of it--under the GPL. However, if the mutual defense clause applies to X+W, then Q loses the right to distribute X+W and could be sued for copyright infringement for using (parts of) that work in a way that he has no copyright license for. That means that the conditions on use of X+W are different from the GPL. The GPL does not permit using W in such a combination. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
What about LGPL? Re: Compatibility of the AFL with the GPL
Lawrence E. Rosen wrote: Richard, Today you finally gave public reasons for your assertion that the AFL is incompatible with the GPL. Because you are simply wrong on the law and wrong-headed on a matter of principle, I must file this public response. So I think I understand the controvery regarding GPL and why GPL and ASL (aka AFL) don't work together. What about LGPL and ASL in the situation of Java? Apache has a long standing ban on LGPL being used in Java projects and I want to know if its justified. I asked if Eben Moglen's comments in slashdot on the subject were sufficient to lift the ban and Roy Fielding responded: No. What the FSF needs to say is that inclusion of the external interface names (methods, filenames, imports, etc.) defined by an LGPL jar file, so that a non-LGPL jar can make calls to the LGPL jar's implementation, does not cause the including work to be derived from the LGPL work even though java uses late-binding by name (requiring that names be copied into the derived executable), and thus does not (in and of itself) cause the package as a whole to be restricted to distribution as (L)GPL or as open source per section 6 of the LGPL. Most authors of Java software using the LGPL license intend to allow linking (basically the use of the java import of classes in their jar file). Who is right? Apache with their insistance that the LGPL is viral for Java software or the masses who think LGPLing their code causes modifiers to contribute but linking/use to be uninhibited even to proprietary software? (where the term link is not wholely appropriate for Java, I interperate it to mean including a jar in the classpath at compile-time and runtime and having import statement naming classes inside of a jar) On a personal note, clearing this up would help me greatly as I would like to use Trove4J (http://trove4j.sourceforge.net/) in the Apache project I founded (http://jakarta.apache.org/poi) instead of our own collection classes. Secondly, I am considering releasing an upcoming Java codebase in LGPL or GPL, and while I understand the full ramifications of GPL, I do not feel I fully understand the ramifications of LGPL with regards to this issue. I would greatly appreciate if Mr. Stallman and Mr. Rosen could provide a definitive answer on this. Thank you, Andrew C. Oliver -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: What about LGPL? Re: Compatibility of the AFL with the GPL
I realize that this question was specifically addressed to Larry and RMS, but please permit me to press my point once more since I am beginning to recognize that despite the reputation of lawyers for over-complicating matters, computer scientists seem to suffer from the same affliction. The final question the poster posed about his project is entirely unrelated to the initial quoted concern whether the AFL is incompatible with the GPL? It might be easier to address these matters if the dynamic/static linking questions and the LGPL are left independent from the generalized concern about the AFL and GPL. Most importantly, in my opinion, the resolution of what it means to say that one license is incompatible with another should not be construed as resolving any specific legal question about a particular project. You are quite likely to make wrong conclusions by performing that type of mental gymnastics, if you are not a lawyer. For example, although Andrew limited his question to a matter of interpreting a couple of software licenses, the fact is his question implicitly requires an application of copyright law as well; hence, any posted answer merely addressing the LGPL is incomplete and one would be foolish to follow. I provide this precaution in order to constructively pose how one should read our discussions, which tend toward both over-complicated queries and oversimiplied answers, but not necessarily in that order. -Rod On Fri, 14 Mar 2003, Andrew C. Oliver wrote: Lawrence E. Rosen wrote: Richard, Today you finally gave public reasons for your assertion that the AFL is incompatible with the GPL. Because you are simply wrong on the law and wrong-headed on a matter of principle, I must file this public response. So I think I understand the controvery regarding GPL and why GPL and ASL (aka AFL) don't work together. What about LGPL and ASL in the situation of Java? Apache has a long standing ban on LGPL being used in Java projects and I want to know if its justified. I asked if Eben Moglen's comments in slashdot on the subject were sufficient to lift the ban and Roy Fielding responded: No. What the FSF needs to say is that inclusion of the external interface names (methods, filenames, imports, etc.) defined by an LGPL jar file, so that a non-LGPL jar can make calls to the LGPL jar's implementation, does not cause the including work to be derived from the LGPL work even though java uses late-binding by name (requiring that names be copied into the derived executable), and thus does not (in and of itself) cause the package as a whole to be restricted to distribution as (L)GPL or as open source per section 6 of the LGPL. Most authors of Java software using the LGPL license intend to allow linking (basically the use of the java import of classes in their jar file). Who is right? Apache with their insistance that the LGPL is viral for Java software or the masses who think LGPLing their code causes modifiers to contribute but linking/use to be uninhibited even to proprietary software? (where the term link is not wholely appropriate for Java, I interperate it to mean including a jar in the classpath at compile-time and runtime and having import statement naming classes inside of a jar) On a personal note, clearing this up would help me greatly as I would like to use Trove4J (http://trove4j.sourceforge.net/) in the Apache project I founded (http://jakarta.apache.org/poi) instead of our own collection classes. Secondly, I am considering releasing an upcoming Java codebase in LGPL or GPL, and while I understand the full ramifications of GPL, I do not feel I fully understand the ramifications of LGPL with regards to this issue. I would greatly appreciate if Mr. Stallman and Mr. Rosen could provide a definitive answer on this. Thank you, Andrew C. Oliver -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: What about LGPL? Re: Compatibility of the AFL with the GPL
All that being said, I'd still like an answer. -Andy Rod Dixon wrote: I realize that this question was specifically addressed to Larry and RMS, but please permit me to press my point once more since I am beginning to -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: What about LGPL? Re: Compatibility of the AFL with the GPL
On Fri, 14 Mar 2003, Andrew C. Oliver wrote: Lawrence E. Rosen wrote: Richard, Today you finally gave public reasons for your assertion that the AFL is incompatible with the GPL. Because you are simply wrong on the law and wrong-headed on a matter of principle, I must file this public response. So I think I understand the controvery regarding GPL and why GPL and ASL (aka AFL) don't work together. What about LGPL and ASL in the situation of Java? Apache has a long standing ban on LGPL being used in Java projects and I want to know if its justified. Just to keep everyone clear, the AFL in this week's discussion is the Academic Free License: http://www.opensource.org/licenses/academic.php it is NOT the Apache License. The Apache license as it currently stands is not compatible with the GPL, we recognize this; whether it's compatible with the LGPL depends on what one's definition is of interfaces and derivative works. We're looking at a second rev of the Apache license that will be GPL compatible (and thus also LGPL compatible). No promises. On a personal note, clearing this up would help me greatly as I would like to use Trove4J (http://trove4j.sourceforge.net/) in the Apache project I founded (http://jakarta.apache.org/poi) instead of our own collection classes. Since it's the Trove4J folks who would have standing in any case involving LGPL-nonconformance, *not* the FSF, it really only matters how the Trove4J folks intend the LGPL's language around derivative works and interfaces to be interpreted. If the Trove4J developers gave you a statement to the effect that they do not intend for applications that use the Trove4J interfaces to be considered derivative works, then your problem is solved, and you don't need to wait for RMS or Eben. If instead they want some sort of canonical interpretation from the authors of the GPL, then all of us have to wait, no matter what opinions are aired on license-discuss. Brian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
Lawrence E. Rosen writes: OK, guys, play with me one more round. This time, let's do it in the form of a law school exam question and let's get the lawyers and IANALs on this list to chime in: Nahhh. None of this is necessary. There's nothing in the AFL that says that you must use the same license on derivative works. Therefore, without reference to any other terms of the AFL, it is trivially compatible with the GPL insofar as derivative works get licensed under the GPL. Period. End of discussion. It's GPL-compatible. The only question is whether RMS will admit to making a mistake. -- -russ nelson angry-economist.russnelson.com | What Problem Are You Trying Crynwr sells support for free software | PGPok | To Solve? is a service mark 521 Pleasant Valley Rd. | +1 315 268 1925 voice | of Crynwr Software. Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
On Friday, 14 March 2003, Russell Nelson wrote: Lawrence E. Rosen writes: OK, guys, play with me one more round. This time, let's do it in the form of a law school exam question and let's get the lawyers and IANALs on this list to chime in: Nahhh. None of this is necessary. There's nothing in the AFL that says that you must use the same license on derivative works. Therefore, without reference to any other terms of the AFL, it is trivially compatible with the GPL insofar as derivative works get licensed under the GPL. Period. End of discussion. It's GPL-compatible. The only question is whether RMS will admit to making a mistake. No, that's not quite right. We do have to resolve one question, which is whether the effect of the AFL is to pass through the patent- retaliation provision on code which is relicensed. If so, the AFL does not permit relicensing under GPL, because GPL 2(b) requires that no additional terms be added to GPL'd code during modification and redistribution. So, here's the one case we need to be sure we agree about: A publishes program FOO under AFL. B modifies FOO by combining FOO with preexisting GPL'd code to make GOO, and releases under GPL. C modifies to make HOO, distributes under GPL, and later sues A alleging patent infringement by A in another program released under AFL. What's the result here? If C cannot continue to distribute HOO, the AFL has succeeded in imposing additional conditions not only on the FOO part of HOO, but also on other GPL'd code with which it is combined; this would be a modality for evading GPL. E -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
Eben Moglen writes: No, that's not quite right. We do have to resolve one question, which is whether the effect of the AFL is to pass through the patent- retaliation provision on code which is relicensed. Larry's taught me not to paraphrase, so let's look at the actual language: Mutual Termination for Patent Action. This License shall terminate automatically and You may no longer exercise any of the rights granted to You by this License if You file a lawsuit in any court alleging that any OSI Certified open source software that is licensed under any license containing this Mutual Termination for Patent Action clause infringes any patent claims that are essential to use that software. C modifies to make HOO, distributes under GPL, and later sues A alleging patent infringement by A in another program released under AFL. What's the result here? HOO is OSI Certified open source because it uses the GPL. However, the GPL does not contain this or any Mutual Termination for Patent Action clause. Therefore C's license is not terminated. -- -russ nelson angry-economist.russnelson.com | What Problem Are You Trying Crynwr sells support for free software | PGPok | To Solve? is a service mark 521 Pleasant Valley Rd. | +1 315 268 1925 voice | of Crynwr Software. Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
Lawrence E. Rosen writes: OK, guys, play with me one more round. This time, let's do it in the form of a law school exam question and let's get the lawyers and IANALs on this list to chime in: Nahhh. None of this is necessary. There's nothing in the AFL that says that you must use the same license on derivative works. Therefore, without reference to any other terms of the AFL, it is trivially compatible with the GPL insofar as derivative works get licensed under the GPL. Russ, the AFL is not sublicensable. If you're using AFL code (or a derivative of AFL code), you need a license from the author, regardless of who you got that code from. Greg -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the ASL and LGPL in the specific case of Java WAS: (Re: What about LGPL? Re: Compatibility of the AFL with the GPL)
Hi Brian, Thank you for taking time to reply. The Apache Software Foundation takes a cautious stance on the matter, that says you can't assume that all authors who release code under the LGPL will interpret it to allow the kind of combination you are asking about. If those authors *do* allow it, then I'd imagine the ASF board would accept that in that situation. If the FSF gave a favorable interpretation, we might relax the restriction generally, on the notion that authors generally follow the precedents the FSF sets in their interpretations. This is precisely why I'm asking for this clarification. I would like to see this restriction relaxed generally. Furthermore, I would like to see this cleared up so that Java folks who believe in OpenSource and Free Software can work together whenever minds meet. We do too! Which is why we're hoping for GPL compatability in Apache license v2. That would be nice. Especially since it would allow us to work with the KOffice folks. They were interested in compiling POI via GCJ/Classpath and maybe poi'd just be the filter for KOffice. It was judged to be too legally precarious to mess with. A resolution of that issue would be nice. . Of course...that is assuming the ASLv2 ever comes out ;-) thanks, -andy Brian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
Greg Pomerantz writes: Lawrence E. Rosen writes: OK, guys, play with me one more round. This time, let's do it in the form of a law school exam question and let's get the lawyers and IANALs on this list to chime in: Nahhh. None of this is necessary. There's nothing in the AFL that says that you must use the same license on derivative works. Therefore, without reference to any other terms of the AFL, it is trivially compatible with the GPL insofar as derivative works get licensed under the GPL. Russ, the AFL is not sublicensable. If you're using AFL code (or a derivative of AFL code), you need a license from the author, regardless of who you got that code from. One of the things you're allowed to do under the AFL is create derivative works. There is nothing in the AFL which requires you to license that work under the AFL (unlike the GPL, which *does* require GPL'ed derivative works). So, when you get an AFL-licensed work, you also receive a license from the copyright holder, licensing you to do whatever you want, modulo abusing trademarks, or suing Mutual Defense licensors. Does that bind anybody who received a copy of your derivative work? No, because that work is licensed under the GPL, and the AFL very specifically says that Mutual Defense only applies if the license says Mutual Defense. The GPL doesn't, and so while *you* lose your license to distribute, the people you have distributed the GPL'ed work to don't. Does it now suck to be you? Yes, and you should have thought about that *before* you sued. Many and subtle are the powers of Larry Rosen. -- -russ nelson angry-economist.russnelson.com | What Problem Are You Trying Crynwr sells support for free software | PGPok | To Solve? is a service mark 521 Pleasant Valley Rd. | +1 315 268 1925 voice | of Crynwr Software. Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
Russ, Sorry to have to knock that leg of the chair out from under you, but I actually believe that the AFL license *does* apply to the portion of a derivative work that consists of the work originally licensed under the AFL. Eben and I agree on that. So really, there are two licenses that the licensee is operating under, the GPL and the AFL. This is because the AFL-licensed software is not sublicenseable. It remains under its original license, even though the combination (e.g., collective or derivative work) is under the GPL. What is important is to determine whether the mutual defense provision in the AFL makes the two licenses incompatible. But I'm convinced it really doesn't. Assume someone sues the AFL program for patent infringement. Even before one can raise the AFL mutual defense clause to stop distribution of the AFL component of the GPL program, the GPL program automatically can't be distributed because of section 7 of the GPL. The AFL mutual defense pass-through is just icing on the cake. The two licenses are more compatible than some people have realized. That's why the term compatibility has been such a sore point for me. You can't just look at the plain language of the licenses, you have to think through the legal effects of the combination of the language of two licenses. Of course the mutual defense provision isn't in the GPL. That is, literally, an incompatibility of words. But the end result is the same whether the AFL passes-through or not. /Larry Rosen -Original Message- From: Russell Nelson [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2003 7:20 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Eben Moglen' Subject: Re: Compatibility of the AFL with the GPL Greg Pomerantz writes: Lawrence E. Rosen writes: OK, guys, play with me one more round. This time, let's do it in the form of a law school exam question and let's get the lawyers and IANALs on this list to chime in: Nahhh. None of this is necessary. There's nothing in the AFL thatsays that you must use the same license on derivative works.Therefore, without reference to any other terms of the AFL, it istrivially compatible with the GPL insofar as derivative works getlicensed under the GPL. Russ, the AFL is not sublicensable. If you're using AFL code (or a derivative of AFL code), you need a license from the author, regardless of who you got that code from. One of the things you're allowed to do under the AFL is create derivative works. There is nothing in the AFL which requires you to license that work under the AFL (unlike the GPL, which *does* require GPL'ed derivative works). So, when you get an AFL-licensed work, you also receive a license from the copyright holder, licensing you to do whatever you want, modulo abusing trademarks, or suing Mutual Defense licensors. Does that bind anybody who received a copy of your derivative work? No, because that work is licensed under the GPL, and the AFL very specifically says that Mutual Defense only applies if the license says Mutual Defense. The GPL doesn't, and so while *you* lose your license to distribute, the people you have distributed the GPL'ed work to don't. Does it now suck to be you? Yes, and you should have thought about that *before* you sued. Many and subtle are the powers of Larry Rosen. -- -russ nelson angry-economist.russnelson.com | What Problem Are You Trying Crynwr sells support for free software | PGPok | To Solve? is a service mark 521 Pleasant Valley Rd. | +1 315 268 1925 voice | of Crynwr Software. Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
Lawrence E. Rosen writes: Sorry to have to knock that leg of the chair out from under you, Foo. And I was on such a roll! That's why the term compatibility has been such a sore point for me. The point of the law school exam being for anyone to be able to show a difference in people's behavior in re GPLed code versus AFL+GPLed code. How can the licenses be said to be incompatible if the supposed incompatibility causes no change in anyone's behavior? -- -russ nelson angry-economist.russnelson.com | What Problem Are You Trying Crynwr sells support for free software | PGPok | To Solve? is a service mark 521 Pleasant Valley Rd. | +1 315 268 1925 voice | of Crynwr Software. Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
My answer (or rather my question) is does Larry have an alter ego known as Joe Hacker who wants to get back at people on this list making the use of his license so complicated? ;-) More seriously, I think the hypo adds to rather than substracts from the confusion on this topic. The initial question concerned compatibility of the AFL with the GPL. In that respect, it is worth keeping in mind that compatibility is not a term of legal significance in software licensing matters. As I under the term, Stallman uses it to evaluate license provisions and how he thinks they may impact the GPL. I do not find difficulty in acknowledging that FSF is the arbiter of what they deem is compatible or not; this is particularly so in an environment like a list discussion since FSF would be expected to provide some rational basis for its determinations on compatibility - - to the extent the determinations are not considered rational, no one or few will care that the determinations exist. With regard to the AFL and GPL in Larry's hypo, I think Stallman has indicated ostensibly that since the AFL restricts BigLo's choice to identify or market its software product as Whizbanger Deluxe, (without permission...yadda, yadda, yadda) the AFL imposes a restriction that exceeds those imposed by the GPL. If this makes the AFL incompatible with the GPL, I do not think we can argue away the point. I think the point the FSF may be making is that they have a fairly high threshold for compatibility with the GPL, and that may be intended to exert some control over how these licenses interact in complex transactions. I think the hypo makes the point (inadvertently or otherwise) that compatibility with the GPL is not an issue concerning who might get sued for what. Rod Rod Dixon Visiting Assistant Professor of Law Rutgers University Law School - Camden [EMAIL PROTECTED] http://www.cyberspaces.org/dixon/ My papers on the Social Science Research Network (SSRN) are available through the following url: http://papers.ssrn.com/author=240132 - Original Message - From: Lawrence E. Rosen [EMAIL PROTECTED] To: 'Brian Behlendorf' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Eben Moglen' [EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 11:46 PM Subject: RE: Compatibility of the AFL with the GPL : OK, guys, play with me one more round. This time, let's do it in the : form of a law school exam question and let's get the lawyers and IANALs : on this list to chime in: : : SCENARIO: Several faculty members at Prestigious University have created : a marvelous new package that takes input from a keyboard and displays it : on a monitor faster than any program ever has before. They decide to : release it to the public under the name WhizBanger. The P.U. general : counsel tells them to license it using the AFL. He registers, on behalf : of the University, the trademark WhizBanger for computer software that : reads from a keyboard and displays on a monitor. : : Linus Torvalds learns about WhizBanger and he and his team decide to : include WhizBanger in their new release of Linux. As usual, they : release their new Linux, with full source code, under the GPL. The : Debian project thinks the new release of Linux is wonderful. They : include the modified Linux in their new distribution, also under the : GPL. : : Brian Behlendorf learns about WhizBanger and he convinces the Apache : team to include WhizBanger in their new release of Apache. As usual, : they release with full source code under the Apache license. : : BigCo brings Debian Linux into its research labs. Its engineers, : thrilled to finally be using free software, incorporate Linux into a : computer product they call WhizBanger Deluxe. They claim in their : advertisements that this product is so wonderful that Linus Torvalds : uses it and he recommends it to his friends. WhizBanger Deluxe is : sold worldwide. There's an entry-level version that is released under : the GPL, and a full-function version that is released under a : proprietary license. : : MediumCo also brings Debian Linux and Apache into the company, using : those programs to do payroll and accounts payable functions. At a : review meeting with his patent attorney, the CEO of MediumCo discovers : that his company has a U.S. patent for a computer system that accepts : input from a keyboard and displays it on a screen. Dreaming of vast : royalties, he tells his attorneys to file a lawsuit against Prestigious : University for patent infringement by WhizBanger software. : : Meanwhile, Sally Developer, who respects and admires the Free Software : Foundation and has sworn to uphold the principles espoused by Richard : Stallman, discovers that Linus Torvalds included an AFL-licensed program : in Linux. She's pissed. She's so angry she's considering revoking her : license for a printer driver that's been a part of Linux since version : 1. : : Joe Hacker, a high school student, downloads copies of
Re: Compatibility of the AFL with the GPL
Rod Dixon, J.D., LL.M. scripsit: The initial question concerned compatibility of the AFL with the GPL. In that respect, it is worth keeping in mind that compatibility is not a term of legal significance in software licensing matters. Well, perhaps not. But it is a legal matter (and not any other kind) whether the terms of license Alpha and license Beta, both of which I have accepted, contradict each other in such a way that I can't act in a certain way that either Alpha or Beta by itself permits. As I under[stand] the term, Stallman uses it to evaluate license provisions and how he thinks they may impact the GPL. Specifically, the FSF has a canon of interpretation for the GPL that says that clause 2b, namely b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the [GPL-licensed] Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this [GPL] License. means under the terms, and under no other terms. -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --_The Hobbit_ -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
Rod Dixon scripsit: You are both wrong. The designation of whether one license is incompatible with the GPL says nothing about violation. On FSF's website, they designate some licenses as incompatible with the GPL. The question raised was why the AFL is included in that list. It is whether the of creating a work that is derivative from two other works, W licensed under license Alpha, and X licensed under the GPL, is lawful that determines whether or not Alpha is incompatible with the GPL. -- Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! -- Joyce, _Ulysses_, Oxen of the Sun [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
Lawrence E. Rosen scripsit: Nothing in the GPL prohibits such a contingent termination provision for a component of a GPL-licensed derivative work. GPL 2b is generally read to prevent any such encumbrances other than those enumerated in the GPL itself. -- A poetical purist named Cowan [that's me: [EMAIL PROTECTED] Once put the rest of us dowan. [on xml-dev] Your verse would be sweeterhttp://www.ccil.org/~cowan If it only had metrehttp://www.reutershealth.com And rhymes that didn't force me to frowan. [overpacked line!] --Michael Kay -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
On Wed, 12 Mar 2003, Mark Rafn wrote: On Wed, 12 Mar 2003, Lawrence E. Rosen wrote: [...] Linus Torvalds learns about WhizBanger and he and his team decide to include WhizBanger in their new release of Linux. As usual, they release their new Linux, with full source code, under the GPL. The Debian project thinks the new release of Linux is wonderful. They include the modified Linux in their new distribution, also under the GPL. By doing so, every distributor of Linux+WhizBanger violates the copyright of a whole lot of contributors to the Linux kernel. Yeah, I couldn't get past this part either. In this hypo, Linus has not released it under the GPL. It's under the GPL, and which requires the recipient to accept the AFL from the WhizBanger developers. The GPL forbids this, so Linus can't include WhizBanger in his release. He could distribute it separately, of course, under the same (some claim questionable) theory that allows proprietary kernel modules, etc. Brian Behlendorf learns about WhizBanger and he convinces the Apache team to include WhizBanger in their new release of Apache. As usual, they release with full source code under the Apache license. I'm less familiar with exact requirements of the Apache license. I don't know if it's compatible with the APL. The Apache license, like most licenses other than the [L]GPL, doesn't prevent people from adding restrictions to derived works. So, someone could combine Apache-licensed code and AFL-licensed code and legally redistribute it. Such redistribution would not solely be under the Apache license, though, it would be via an Apache license from the author of the derived work, and an AFL to the authors of WhizBanger. So again, the example doesn't hold water. Brian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
Bottom line: I can assure you, as the license author, that the AFL is intended to be used for software that can be incorporated into GPL-licensed software, and I will almost certainly so advise my clients: I hope you will decide that you owe it to your clients to inform them that the FSF rejects your analysis, and that if they do this with FSF-copyrighted GPL-covered software they may get into a legal dispute with us. There is no possible reason to assume that the GPL states all the important rules of behavior in the open source community or expresses each licensor's view of what is truly free software. We designed the GPL to further the goals of the free software movement, but we never said it states all the important rules of behavior in the free software community. That would be a very hard job which, fortunately, we need not try to do. What we did aim for is to produce a copyleft license: that is, a license that doesn't allow additional terms to be added, not even when the program is extended. This characteristic, of being a copyleft, is the reason so many people in our community (including supporters of the open source movement) use the GPL. Adding the AFL's license terms would not make the program non-free. But if people could in general add terms of their choosing, people could add other terms that would make the software non-free. We believe that we have designed the GPL to prohibit this. By arguing that we have failed, you are trying to destroy the underpinning of the majority of free software packages. Thousands of developers will hope and pray that judges listen to us and not to you. We are trying to design, for GPL 3, a way that people can add a certain selected range of license terms for their own code. We have not solved all the problems yet. We cannot promise that the AFL's specific requirements will be in this range. In any case, this is something for the future. For now, the GPL is incompatible with licenses that add requirements that are not in the GPL, independent of whether they are good requirements or bad requirements. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
BigCo brings Debian Linux into its research labs. The name of that distribution is Debian GNU/Linux. (It is a version of GNU/Linux.) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
Lawrence E. Rosen scripsit: And anyone who has a copy of W+X or W' has two licenses, one from Person A (for that part that was W) and one from Person B (for W+X or W'). Person A is not responsible in any respect for W+X or W'. The key question: If Person C who has W' sues Person A for patent infringement, does that void his license to do things with W'? If so, and if X is under the GPL, then W' cannot lawfully be created, because it is a derivative of two works with contradictory licensing terms. If not, I suggest a sentence be added to the AFL saying that the M.T.P.A. clause is expressly inapplicable to derivative works unless the work as a whole is licensed under a license containing the M.T.P.A. (More gracefully worded, preferably.) -- Do what you will, John Cowan this Life's a Fiction[EMAIL PROTECTED] And is made up of http://www.reutershealth.com Contradiction. http://www.ccil.org/~cowan -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
On Tue, 11 Mar 2003, Lawrence E. Rosen wrote: Brian Behlendort wrote: All IMHO, and IANAL, coz I get burned every time I post here these days... Are you afraid I'll slap you 'aside the head? Relax :-) Let's say I'm trying to be more cognizant of my own lack of formal legal training, and have a strong desire to improve it based on real-world examples. Despite these clauses being within the spirit of the GPL, they are still additional restrictions on redistribution. If the goal is just the GPL, only the GPL, nothing but the GPL, forever and ever, amen then I suppose anything that differs from it has a big hurdle to overcome. But I thought the real goal was *free software*, not simply protecting a license. So what if there are additional restrictions (although I quarrel with your use of the word restrictions)? Why is that not within the spirit of the GPL? RMS is challenging compatibility, not testing for equivalence. I can't speak for RMS and would never want to. My perception is that one of the things that attracts people to the GPL is this sense of trust - if a whole package claims to be GPL, you can combine it with other GPL or LGPL code, the net result will be GPL, and you can rely on that fact. I think most people would prefer a world where there were as few different licenses they had to read and understand and follow as possible, and the GPL biases towards that end. That's not necessarily a free software goal, but a pretty saavy practical goal. Section 2b is pretty clear: 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. As is section 6: You may not impose any further restrictions on the recipients' exercise of the rights granted herein. GPL + anything = GPL, or you can't redistribute. The GPL *does* allow for certain kinds of additional restrictions where there are laws one can't work around - see section 8. But they're extremely narrow in scope. In the case of the trademark/names, one who creates a derivative work will always have to worry that your interpretation of endorse or promote is broader than anticipated. For example, if a derivative work proudly and loudly claimed its heritage, perhaps even named itself something similar, there would always be the possibility that you would disagree, and the right to redistribute would be revoked. Sure, the GPL has other vague clauses, but I just want to point out this is a clause that essentially forms an additional restriction. Are you suggesting different words besides endorse or promote? Under U.S. trademark law, anyone can say I've built a derivative work of Apache without using Apache's good name, or yours, to endorse or promote their software. I think the words endorse and promote are clear enough. By redistributing your work I run the risk that our two interpretations of endorse and promote may differ, and to wake up one morning to find a breach of contract claim against me. That's my worry. Now, Apache has used that to *positive* advantage, as it's much easier to go to a party and tell them they're violating the Apache license by using our name, than pursuing a claim under trademark law. But, that's not something the GPL allows today. So as I've seen this, being GPL-compatible means giving up a rather useful device to protect one's name. It's a tradeoff. If instead the license simply *reminded* people that nothing gives them the right to use the trademarks or good name of the original author, then that wouldn't be an additional restriction. That is precisely what it does. Note that the provision is entitled Exclusions from License Grant, and it says, in essence, here's what you don't get with this license. It doesn't say, here's the penalty for doing these things without permission. Do you want me to add the phrase pretty please to the end of the provision so that people will recognize it is a reminder rather than an order to do or not to do something? Simply put, if an AFL-licensee infringes an AFL-licensor's trademark, he will get sued for trademark infringement rather than breach of contract. The infringer won't be able to defend himself by arguing he has an implied license, because the AFL contains an express exclusion of trademarks from the license grant. All the provision does is promote clarity of the scope of license. (That's a deficiency of the GPL, by the way!) From the way I read that section, it sounded like the clause was a condition I had to follow in order to redistribute. That is, if I publish a derived work and use language that you find objectionable on those terms, then I will have broken the contract. You may not use is, to me, much different than nothing gives you the right. Reaching here, I'm thinking that if I break the
Re: Compatibility of the AFL with the GPL
Brian Behlendorf scripsit: But but... your AFL terms persist, so I'm not really relicensing. This new one-byte-different derivative work is *not* under an Apache license - one who picks up that code and follows only the Apache license may find themselves violating your AFL license. The license on my *modification* (that whole byte) may be Apache licensed, but not the bits derived from your original work. Nope. The creator of a derivative work under license is the copyright owner of the derivative work as a whole. He cannot, of course, prevent other people from making derivative works based on the same original, but he can certainly defend his own copyright. This is why BSD-licensed code can be incorporated into proprietary binary works, e.g. (IANAL, TINLA) -- It was impossible to inveigle John Cowan [EMAIL PROTECTED] Georg Wilhelm Friedrich Hegel http://www.ccil.org/~cowan Into offering the slightest apology http://www.reutershealth.com For his Phenomenology. --W. H. Auden, from People (1953) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
Answers interspersed. /Larry -Original Message- From: John Cowan [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 11:20 AM To: [EMAIL PROTECTED] Cc: 'Bjorn Reese'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Compatibility of the AFL with the GPL Lawrence E. Rosen scripsit: And anyone who has a copy of W+X or W' has two licenses, one from Person A (for that part that was W) and one from Person B (for W+X or W'). Person A is not responsible in any respect for W+X or W'. The key question: If Person C who has W' sues Person A for patent infringement, does that void his license to do things with W'? If C sues A for patent infringement, C can no longer copy, modify or distribute W, or W+X, or W', because his license to do those things with W is terminated. If C sues B for patent infringement, A doesn't care. Unless, of course, B licenses using the Mutual Defense provision, in which case A and B defend each other by terminating both licenses! If so, and if X is under the GPL, then W' cannot lawfully be created, because it is a derivative of two works with contradictory licensing terms. What's contradictory? I agree there is an encumbrance based on the license for W, but it is a contingent encumbrance that becomes effective only when C elects to sue A for patent infringement. Nothing in the GPL prohibits such a contingent termination provision for a component of a GPL-licensed derivative work. In any case, the licensee can read about those contingencies via the license notices in the source code. (In case you were wondering, section 7 of the GPL doesn't apply to this situation.) If not, I suggest a sentence be added to the AFL saying that the M.T.P.A. clause is expressly inapplicable to derivative works unless the work as a whole is licensed under a license containing the M.T.P.A. (More gracefully worded, preferably.) I don't think the added wording is necessary because the AFL *is* compatible with the GPL. /Larry -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
So the AFL no longer applies to the derived work, is that what you are saying? So I can do whatever I want with my derived work, from a AFL work, licensing my derived work in any terms I want, and people using the derived work will not be bound by conditions of the AFL but by my terms only? --- John Cowan [EMAIL PROTECTED] wrote: Brian Behlendorf scripsit: But but... your AFL terms persist, so I'm not really relicensing. This new one-byte-different derivative work is *not* under an Apache license - one who picks up that code and follows only the Apache license may find themselves violating your AFL license. The license on my *modification* (that whole byte) may be Apache licensed, but not the bits derived from your original work. Nope. The creator of a derivative work under license is the copyright owner of the derivative work as a whole. He cannot, of course, prevent other people from making derivative works based on the same original, but he can certainly defend his own copyright. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 12 March 2003 02:46 pm, Andy Tai wrote: So the AFL no longer applies to the derived work, is that what you are saying? So I can do whatever I want with my derived work, from a AFL work, licensing my derived work in any terms I want, and people using the derived work will not be bound by conditions of the AFL but by my terms only? So long as your license terms do not contradict the license you received the original work under (the AFL), this is my understanding of the situation. - -- Alex Russell [EMAIL PROTECTED] [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+b59ioV0dQ6uSmkYRAvnfAJ9oK9zDLzYEb+sD/oHGtQefToQ/rwCg3uPs jEydBncF0oDrwSRXO39Ezv0= =m0QE -END PGP SIGNATURE- -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
The trademark clause in the AFL merely states that Neither the names of Licensor, nor the names of any contributors to the Original Work, nor any of their trademarks or service marks, may be used to endorse or promote products derived from this Original Work without express prior written permission of the Licensor. This goes beyond the requirements of trademark law, which permits some kinds of use of the trademark as fair use. Why can't a licensor prohibit the use of his trademarks or his good name even while he provides a TOTALLY FREE copyright license to his software? You are arguing against a statement I did not make. I never said that a free software license cannot include such a requirement. On the contrary, we recognize the AFL as a free software license, trademark requirement and all. The question here is compatibility with the GPL. The trademark requirement of the AFL is nontrivial because it goes beyond what trademark law requires. Therefore it is a restriction that is not in the GPL, and that makes the licenses incompatible. As it happens, I disapprove somewhat of this trademark requirement--I think it goes too far. But that disapproval is not condemnation. We recognize the AFL as a valid free software license. I'll leave for another thread any discussion about whether this is a good idea or a bad idea. But how is it incompatible with the GPL? It is a requirement that isn't in the GPL. The GPL, being a strong copyleft, does not permit adding requirements of any sort. So any license that has requirements not in the GPL is incompatible with the GPL. ***Anyone*** is free to take software licensed under the AFL and re-license it under any license, including licenses not containing the Mutual Defense provision [to use, copy, modify, merge, publish, perform, distribute and/or sell copies of the Original Work and derivative works thereof,...]. If I relicense in this way under a license such as the X11 license, which includes neither the mutual defense nor the trademark provision, does that make those provisions completely cease to apply to the code as I redistribute it? Or does it only mean that they come from the author and not from me? I assumed it was the latter, and my conclusions are based on that. If it is the former, then the AFL is indeed compatible with the GPL, but the mutual defense and trademark provisions are completely ineffective because they are so easy to weasel out of. Surely that is not what you intend; you must surely intend these provisions to bind all users of the code. That is why I expect it is the latter--that I could put on a license from me which doesn't impose such requirements from me, but that would not negate the requirements imposed by the first author. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
Andy Tai scripsit: So the AFL no longer applies to the derived work, is that what you are saying? So I can do whatever I want with my derived work, from a AFL work, licensing my derived work in any terms I want, and people using the derived work will not be bound by conditions of the AFL but by my terms only? Well, that's the sticky bit. They are bound by your terms only, except that if they sue the original AFL author on a patent violation, they are hosed w/r/t your program, at least as far as copying, modifying, or distributing it. Presumably they can still use it. -- John Cowan [EMAIL PROTECTED] www.reutershealth.com www.ccil.org/~cowan It's the old, old story. Droid meets droid. Droid becomes chameleon. Droid loses chameleon, chameleon becomes blob, droid gets blob back again. It's a classic tale. (Kryten, Red Dwarf) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
Alex Russell scripsit: So long as your license terms do not contradict the license you received the original work under (the AFL), this is my understanding of the situation. Well, contradict is fuzzy. It can be licensed under terms that are completely different from the AFL's: for example, it can be issued under a proprietary license. -- Winter: MIT, John Cowan Keio, INRIA,[EMAIL PROTECTED] Issue lots of Drafts. http://www.ccil.org/~cowan So much more to understand! http://www.reutershealth.com Might simplicity return?(A tanka, or extended haiku) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
Mr. Rosen, why don't you put your statement referenced below into the AFL, stating that You are permitted to create derived work and relicense such work under any license terms of your choice, and I waive all my rights in regard to all such derived work, including the requirements of this license (AFL). (where I means the original author or copyright holder) This should make the AFL any and all license compatible without any doubt. --- Lawrence E. Rosen [EMAIL PROTECTED] wrote: ***Anyone*** is free to take software licensed under the AFL and re-license it under any license, including licenses not containing the Mutual Defense provision [to use, copy, modify, merge, publish, perform, distribute and/or sell copies of the Original Work and derivative works thereof,...]. In fact, the AFL permits anyone to freely relicense their derivative work software under the GPL. /Larry Rosen -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
Brian, First, as to the Mutual Defense provision and its compatibility with the GPL: Person A writes W and licenses it to everyone under the AFL. Person B comes along and, in the true spirit of free software, creates and distributes collective work W+X and derivative work W' under the GPL. No surprises for B. He's read the AFL and the GPL and he understands that he's doing what's allowed. Person C gets a copy of W+X or W'. He knows it is GPL software. Person C now wants to sue Person A for patent infringement by W. He reads W's license and discovers the Mutual Defense provision. He must evaluate his risk of losing rights to copy, modify or distribute W, W+X and W', and any other W-based software, if he sues A. What's wrong with making him evaluate that risk before suing for patent infringement? It's his patent, and he's (perhaps) within his rights to sue Person A for infringement. But as the author of an open source license, I don't have to make that easy or cheap for him to do. Perhaps the LICENSE file of any GPL-licensed work that contains an AFL-licensed component should contain a warning notice: WARNING: Your license to this work may automatically terminate if you sue Person A for patent infringement. That is because this work contains a component that is licensed to you by Person A under the AFL. You get to decide whether a patent infringement lawsuit against Person A is worth the loss of your rights to copy, modify or distribute Person A's contribution to this software. You're right in suggesting that the GPL has fostered a spirit of license trust, and that is wonderful. I'm seeking compatibility between the AFL and the GPL because I want to share in that good will and to encourage people to release source code that can be incorporated into GPL-licensed programs -- as well as into proprietary and other open source programs. The mutual defense provision of the AFL doesn't detract from that goal. It just causes those who would sue free and open source software for patent infringment to do their homework first and to recognize that it is no longer cheap and risk-free to do so. They only have to crawl through the source code if they elect to sue OSI Certified open source software for patent infringement. What's wrong with that? *** Second, as to the trademark provision of the AFL: I recognize that there is inevitable confusion when one adds a new concept to the world of the GPL. But I've been following open source businesses for a while -- not as long as you, I admit! -- and I now recognize that the real source of success and profit for open source contributors and businesses is their trademarks, not just their copyrights. Contributors to free software create brand names and personal reputations [Linux (and GNU/Linux!), Apache, Red Hat, JBoss, OSI Certified, Free Software Foundation, RMS, Behlendorf] that we need to protect. I don't control the GPL so I can't do anything but encourage RMS to put a meaningful protection for trademarks into his license. But I do control the AFL, and I insist upon the importance of warning licensees that our brand names and our reputations are not included for free with our copyright licenses. That's not how this community works, and our licenses should make it explicit. That's not contradictory in any way to the GPL. You found such a trademark provision was helpful to the Apache Foundation, and quite frankly, I knew to write a trademark provision because of your lead. So please don't try to talk me out of doing what you already did so successfully. *** Finally, your question about adding whitespace to an AFL-licensed program and re-licensing it under the Apache license: I don't understand why that is confusing or of concern. Anyone who picks up the code-plus-whitespace and uses it under the Apache license or the GPL has nothing to fear from Person A. All relevant licenses are open source and free. If Person B wants to create W+X or W', he must read the license for W and any other notices in the source code. There's nothing hidden from him. His customers certainly don't need to look behind the Apache or GPL license under which they received their software. If Person C wants to create W+X+Z or W'', he must read the licenses and any other notices in the source code. Person C's customers don't need to look behind their license from C. Each of those people will be informed of the license terms applicable to them and will be told that the source code is available. What more could anyone want? Of course, if anyone in that chain wants to sue Person A for patent infringement by W But I already told that story. /Larry -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
yep. /LR -Original Message- From: John Cowan [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 11:38 AM To: Brian Behlendorf Cc: Lawrence E. Rosen; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Compatibility of the AFL with the GPL Brian Behlendorf scripsit: But but... your AFL terms persist, so I'm not really relicensing. This new one-byte-different derivative work is *not* under an Apache license - one who picks up that code and follows only the Apache license may find themselves violating your AFL license. The license on my *modification* (that whole byte) may be Apache licensed, but not the bits derived from your original work. Nope. The creator of a derivative work under license is the copyright owner of the derivative work as a whole. He cannot, of course, prevent other people from making derivative works based on the same original, but he can certainly defend his own copyright. This is why BSD-licensed code can be incorporated into proprietary binary works, e.g. (IANAL, TINLA) -- It was impossible to inveigle John Cowan [EMAIL PROTECTED] Georg Wilhelm Friedrich Hegel http://www.ccil.org/~cowan Into offering the slightest apology http://www.reutershealth.com For his Phenomenology. --W. H. Auden, from People (1953) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
Andy Tai wrote: So the AFL no longer applies to the derived work, is that what you are saying? So I can do whatever I want with my derived work, from a AFL work, licensing my derived work in any terms I want, and people using the derived work will not be bound by conditions of the AFL but by my terms only? Not quite. The derived work is bound by the conditions of your license, and the portions relating to the AFL work are bound by the AFL too. /Larry Rosen -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
Mr. Rosen, why don't you put your statement referenced below into the AFL, stating that You are permitted to create derived work and relicense such work under any license terms of your choice, and I waive all my rights in regard to all such derived work, including the requirements of this license (AFL). (where I means the original author or copyright holder) This should make the AFL any and all license compatible without any doubt. Perhaps, but I don't want to waive the author's rights under the AFL. Please explain why it would be good to do so. /Larry -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
Lawrence E. Rosen wrote: And anyone who has a copy of W+X or W' has two licenses, one from Person A (for that part that was W) and one from Person B (for W+X or W'). Person A is not responsible in any respect for W+X or W'. *Sigh*. OK, now I get it. W+X and W' has *two* licenses, one each to two different parties. The terms of *both* must be followed by Person C. My common-sense, non-lawyer brain says that if person B says W+X or W' are under the GPL, it's really GPL to Person B plus AFL to Person A. It appears to be Stallman's opinion, and it would be mine as well, that this cannot be the case, as the GPL prevents additional restrictions, without a qualifier as to which party those restrictions are enforced by. Brian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
Sorry for copying large segments; I have a feeling we're talking past each other, and I want to try to avoid that. On Wed, 12 Mar 2003, Lawrence E. Rosen wrote: First, as to the Mutual Defense provision and its compatibility with the GPL: Person A writes W and licenses it to everyone under the AFL. Person B comes along and, in the true spirit of free software, creates and distributes collective work W+X and derivative work W' under the GPL. No surprises for B. He's read the AFL and the GPL and he understands that he's doing what's allowed. Person C gets a copy of W+X or W'. He knows it is GPL software. Person C now wants to sue Person A for patent infringement by W. He reads W's license and discovers the Mutual Defense provision. He must evaluate his risk of losing rights to copy, modify or distribute W, W+X and W', and any other W-based software, if he sues A. What's wrong with making him evaluate that risk before suing for patent infringement? It's his patent, and he's (perhaps) within his rights to sue Person A for infringement. But as the author of an open source license, I don't have to make that easy or cheap for him to do. Nothing is wrong in spirit with the Mutual Defense provision. That's not the question here. When person C gets that copy of W+X or W' from B, they were told that it is covered by the GPL. C reads the GPL, understands it, and is led to believe (barring any situation that B couldn't have prevented, such as a third-party patent claim on code that W+X or W' implements) that the GPL completely describes the terms and conditions that C must follow. When someone downloads Apache software, they read the Apache license, and are led to believe that's the only license they need to be observant of in order to exercise the rights the license grants them. Apache developers can't guarantee there'll never be patent claims made by third parties of course, and we indemnify our liability in that event. But the Apache developers are very careful to make sure there's no additional clauses in third-party packages we bundle into tarballs people pull from apache.org. No one likes surprises. I think this describes the common interpretation of what it means to say a particular piece of software has a particular license. That license should include all clauses relevant to the exercise of the rights it claims to give. If there are additional licenses one must also follow, it should be included by reference. John used the example of the Apache license. What allows a vendor to pick Apache up and incorporate it into a proprietary work is that we do not require derived works to also be licensed under the Apache license. The GPL, though, *does* require derived works to be licensed under the GPL. Perhaps the LICENSE file of any GPL-licensed work that contains an AFL-licensed component should contain a warning notice: WARNING: Your license to this work may automatically terminate if you sue Person A for patent infringement. That is because this work contains a component that is licensed to you by Person A under the AFL. You get to decide whether a patent infringement lawsuit against Person A is worth the loss of your rights to copy, modify or distribute Person A's contribution to this software. So in what way does this language not constitute an additional restriction as defined by section 6 of the GPL? Every time someone pops up on license-discuss and says I have a new license, it's just like the GPL but it adds a clause that says you can't stand on your head and count to ten. Is it OSI-conformant? GPL-compatible? We may hem and haw over whether being able to stand on your head and count to ten constitutes a discrimination based on field of endeavor, but it seems that people always say, adding clauses, anything, makes it not GPL compatible. You're right in suggesting that the GPL has fostered a spirit of license trust, and that is wonderful. I'm seeking compatibility between the AFL and the GPL because I want to share in that good will and to encourage people to release source code that can be incorporated into GPL-licensed programs -- as well as into proprietary and other open source programs. We share the same objective - I'd love to see the Apache license get there too. But we hit the same brick wall, and we can't just pretend it doesn't exist. The mutual defense provision of the AFL doesn't detract from that goal. It just causes those who would sue free and open source software for patent infringment to do their homework first and to recognize that it is no longer cheap and risk-free to do so. Again, no one is criticizing the intent, though I've brought up before that I'm not sure patent lawsuits are always about evil patent holders vs. the small guy hero. That's besides the point. They only have to crawl through the source code if they elect to sue OSI Certified open source software for patent infringement. What's
Re: Compatibility of the AFL with the GPL
Brian Behlendorf scripsit: My common-sense, non-lawyer brain says that if person B says W+X or W' are under the GPL, it's really GPL to Person B plus AFL to Person A. It appears to be Stallman's opinion, and it would be mine as well, that this cannot be the case, as the GPL prevents additional restrictions, without a qualifier as to which party those restrictions are enforced by. I agree. -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --_The Hobbit_ -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
Brian Behlendorf wrote: *Sigh*. OK, now I get it. W+X and W' has *two* licenses, one each to two different parties. The terms of *both* must be followed by Person C. My common-sense, non-lawyer brain says that if person B says W+X or W' are under the GPL, it's really GPL to Person B plus AFL to Person A. It appears to be Stallman's opinion, and it would be mine as well, that this cannot be the case, as the GPL prevents additional restrictions, without a qualifier as to which party those restrictions are enforced by. I'm sorry, Brian, I just don't view these things as additional restrictions -- yet another example of vagueness in the GPL. Regardless, the explicit exclusion of a trademark license and the mutual defense provision are not going to disappear from the AFL. I've assured you, as the license author, that the AFL-licensor doesn't care if his work is incorporated into a GPL-licensed or Apache-licensed work. The GPL/Apache-licensor who includes AFL-licensed components also shouldn't care; his work is licensed as he wishes, under the GPL/Apache-license, without warranty of any kind. Neither of these parties would ever sue each other. After all, they're both into free software! You keep worrying about the downstream licensee, but let's think about his concerns more carefully. Why should he care, for the most part, about the AFL-licensed component? By law he cannot use the AFL-licensor's trademarks anyway, so as a practical matter who cares whether he's actually read the AFL license. As for the mutual defense provision, if he's planning to sue for patent infringement he would be well-advised to write a cease-and-desist letter first and understand the risks of suing against open source software that very well might have been incorporated into his own company's infrastructure by now. I simply don't care about him and our community owes him no consideration whatsoever. Bottom line: I can assure you, as the license author, that the AFL is intended to be used for software that can be incorporated into GPL-licensed software, and I will almost certainly so advise my clients: * If you combine AFL-licensed software with GPL-licensed software, * and license the result under the GPL, * nobody will ever sue you for doing so! I guess that's compatibility in fact, if not in RMS' mind. If RMS continues to believe that the licenses are incompatible, he should either change the GPL or stand out of the way of progress. There is no possible reason to assume that the GPL states all the important rules of behavior in the open source community or expresses each licensor's view of what is truly free software. No license ever could. But this obstinate refusal by FSF to declare compatibility of the AFL, or to change the GPL to allow compatibility, is encouraging the creation of islands of free software that people erroneously think cannot be re-used in GPL-licensed software. That will be our community's loss. /Larry Rosen -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
It's not you, the AFL copyright holder, who can choose not to care. It's Jimmy Q. Gplauthor, whose copyright is infringed by having a derivative work (the GPL+AFL code) distributed under more restrictive terms than the GPL. Huh? Is Jimmy == Person A, Person B or Person C? Keep your parties straight. I challenge you to find any copyright infringement in anything I suggested /Larry -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
On Wed, 12 Mar 2003, Lawrence E. Rosen wrote: Brian Behlendorf wrote: *Sigh*. OK, now I get it. W+X and W' has *two* licenses, one each to two different parties. The terms of *both* must be followed by Person C. My common-sense, non-lawyer brain says that if person B says W+X or W' are under the GPL, it's really GPL to Person B plus AFL to Person A. It appears to be Stallman's opinion, and it would be mine as well, that this cannot be the case, as the GPL prevents additional restrictions, without a qualifier as to which party those restrictions are enforced by. I'm sorry, Brian, I just don't view these things as additional restrictions -- yet another example of vagueness in the GPL. They are clauses I need to be aware of because they affect my ability to use the code. I guess we'll just have to agree to disagree, because I'm not sure what else to say that would convince you. Regardless, the explicit exclusion of a trademark license and the mutual defense provision are not going to disappear from the AFL. And I wouldn't want them to. I think they're fine, and I think if anything the GPLv3 should be amended to allow these kinds of things, if not pick them up itself. You keep worrying about the downstream licensee, but let's think about his concerns more carefully. Why should he care, for the most part, about the AFL-licensed component? By law he cannot use the AFL-licensor's trademarks anyway, so as a practical matter who cares whether he's actually read the AFL license. As for the mutual defense provision, if he's planning to sue for patent infringement he would be well-advised to write a cease-and-desist letter first and understand the risks of suing against open source software that very well might have been incorporated into his own company's infrastructure by now. I simply don't care about him and our community owes him no consideration whatsoever. Regardless of someone's intent, Larry, they are owed the honesty of being told when a license applies to them. The AFL applies to this downstream licensee. To say it's not important, because it only matters when they try and do this evil thing rally makes me queasy. Of course it's important, especially if they were led to believe that the GPL described all the conditions under which they were allowed to use and redistribute the code. If a client came to you, Larry, and told you they wanted to sue a particular company for patent infringement, would you typically recommend to them that they audit the source code of all the software they used in their organization, to make sure this company didn't plant any Mutual Defense clauses in components of that software? Imagine yourself as someone unaware of the existance of the AFL. If your answer is well of course, any entity should already be completely aware of the licenses on the software they use, you've made my point. Brian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
On Wed, 12 Mar 2003, Lawrence E. Rosen wrote: It's not you, the AFL copyright holder, who can choose not to care. It's Jimmy Q. Gplauthor, whose copyright is infringed by having a derivative work (the GPL+AFL code) distributed under more restrictive terms than the GPL. Huh? Is Jimmy == Person A, Person B or Person C? Keep your parties straight. I challenge you to find any copyright infringement in anything I suggested Jimmy is none of the above, he's the author of X. Sorry, I didn't want to dig through the archives to find the previous example. Here it is: Person A writes W and licenses it to everyone under the AFL. Person B comes along and, in the true spirit of free software, creates and distributes collective work W+X and derivative work W' under the GPL. No surprises for B. He's read the AFL and the GPL and he understands that he's doing what's allowed. I'm not sure exactly what W+X is, whether it's mere aggregation of W and X, or whether it's work derivative of both. Let's use WX to be a derivative work of both W and X, whether it be by linking, copying parts of code, or whatnot. WX is not distributable by anyone, as it cannot meet both the GPL and the AFL. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
Lawrence E. Rosen scripsit: It's not you, the AFL copyright holder, who can choose not to care. It's Jimmy Q. Gplauthor, whose copyright is infringed by having a derivative work (the GPL+AFL code) distributed under more restrictive terms than the GPL. Huh? Is Jimmy == Person A, Person B or Person C? Keep your parties straight. I challenge you to find any copyright infringement in anything I suggested He's the author of component X in your scenario, who might or might be the same as Person B. -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --_The Hobbit_ -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
Under U.S. trademark law, anyone can say I've built a derivative work of Apache without using Apache's good name, or yours, to endorse or promote their software. It looks like use of Apache's good name to me. If it isn't what it looks like, I guess these words are not clear. I think the words endorse and promote are clear enough. Perhaps this shows those words are highly confusing. Do you want me to add the phrase pretty please to the end of the provision so that people will recognize it is a reminder rather than an order to do or not to do something? Being serious rather than facetious, if this provision said This license does not grant any license to use the trademarks ... then it would clearly be a reminder and it would not be incompatible with the GPL. I put on it has to carry forward the same terms, at least on that original code, unless I indemnify those I give software to by meeting the terms on their behalf? -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
The key question: If Person C who has W' sues Person A for patent infringement, does that void his license to do things with W'? If C sues A for patent infringement, C can no longer copy, modify or distribute W, or W+X, or W', because his license to do those things with W is terminated. This means that the license for W+X is not the GPL. More precisely, that the GPL is not the whole of the license that applies to C for W+X. The GPL does not permit using X in this way. It does not permit adding any other restriction whatsoever to any work that contains or derives from X. Section 7 applies to any other license that limits the GPL rights in any way, and that includes terminating them under any conditions where the GPL itself would not terminate them. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
On Wed, 12 Mar 2003, Lawrence E. Rosen wrote: SCENARIO: Several faculty members at Prestigious University have created a marvelous new package that takes input from a keyboard and displays it on a monitor faster than any program ever has before. They decide to release it to the public under the name WhizBanger. The P.U. general counsel tells them to license it using the AFL. He registers, on behalf of the University, the trademark WhizBanger for computer software that reads from a keyboard and displays on a monitor. Linus Torvalds learns about WhizBanger and he and his team decide to include WhizBanger in their new release of Linux. As usual, they release their new Linux, with full source code, under the GPL. The Debian project thinks the new release of Linux is wonderful. They include the modified Linux in their new distribution, also under the GPL. By doing so, every distributor of Linux+WhizBanger violates the copyright of a whole lot of contributors to the Linux kernel. Brian Behlendorf learns about WhizBanger and he convinces the Apache team to include WhizBanger in their new release of Apache. As usual, they release with full source code under the Apache license. I'm less familiar with exact requirements of the Apache license. I don't know if it's compatible with the APL. QUESTIONS: - Which of the parties identified above has a possible cause of action against any other party? [For the non-lawyers in the house, consider copyright law, patent law, contract law, business torts, and fraud.] The readers of this list perhaps, for lost time over contorted examples. You lost me after the first GPL violation (putting non-GPL-compatible code in the Linux kernel). - Would anything be different if the AFL were more compatible with the GPL? At least the first case would - it would be allowed to distribute a linux kernel which included AFL-licensed code. I'm looking forward to your answers. :-) In my case, you'll need to ask simpler questions. Sorry. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
Lawrence E. Rosen scripsit: ***Anyone*** is free to take software licensed under the AFL and re-license it under any license, including licenses not containing the Mutual Defense provision [to use, copy, modify, merge, publish, perform, distribute and/or sell copies of the Original Work and derivative works thereof,...]. In fact, the AFL permits anyone to freely relicense their derivative work software under the GPL. Do WHUT The powers granted by the AFL certainly don't include, at least not explicitly, the power to relicense. It is the general understanding of the community that relicensing by anyone other than the copyright owner is not allowed; if it were, what good would the GPL be, or the Mutual Defense provision? The tortfeasor would simply claim that he had relicensed all your code under the MIT/X license. (He might need to use a dummy corporation.) No, if you want people using the AFL to be able to relicense the code, you need (as a practical matter if not a matter of law) to say so loud and clear, and one has to wonder what good the Mutual Defense provision is at all. So what's your problem? Given *that* provision, which is tantamount to licensing under every license existing or to be created later, RMS can't possibly have a problem. The rest of us might, however. -- Do what you will, John Cowan this Life's a Fiction[EMAIL PROTECTED] And is made up of http://www.reutershealth.com Contradiction. http://www.ccil.org/~cowan -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
Sorry, John, but the AFL really does allow the Original Work to be copied or modified, and those copies and derivative works to be distributed under any license, even (gasp!) the GPL and proprietary licenses. The original licensor sets the terms and conditions under which he will release his Original Work, but lets everyone downstream do whatever they want with it, AT THEIR OWN RISK and under any license of their choice. Because there's no sublicensing under the AFL, as a practical matter this really applies only for derivative works and collective works incorporating the Original Work. (So I confused you with the term re-licensed, for which I apologize.) Mere copies of the Original Work remain licensed under the original AFL license, and nothing ever relieves downstream users from obligations they may owe to the original licensor of the Original Work. Under the AFL, those downstream obligations of the licensee are minimal. One important one is the prohibition on removing copyright, trademark and other attribution notices from the source code of copies and derivative works. The only downstream license that might be incompatible with the AFL would be one that required the removal of copyright, trademark and attribution notices. :-) If you don't like the concept of letting go all those copyright rights, then license your works under the OSL instead. Such works you can't re-license into proprietary products. /Larry Rosen -Original Message- From: John Cowan [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 11:49 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Compatibility of the AFL with the GPL Lawrence E. Rosen scripsit: ***Anyone*** is free to take software licensed under the AFL and re-license it under any license, including licenses not containing the Mutual Defense provision [to use, copy, modify, merge, publish, perform, distribute and/or sell copies of the Original Work and derivative works thereof,...]. In fact, the AFL permits anyone to freely relicense their derivative work software under the GPL. Do WHUT The powers granted by the AFL certainly don't include, at least not explicitly, the power to relicense. It is the general understanding of the community that relicensing by anyone other than the copyright owner is not allowed; if it were, what good would the GPL be, or the Mutual Defense provision? The tortfeasor would simply claim that he had relicensed all your code under the MIT/X license. (He might need to use a dummy corporation.) No, if you want people using the AFL to be able to relicense the code, you need (as a practical matter if not a matter of law) to say so loud and clear, and one has to wonder what good the Mutual Defense provision is at all. So what's your problem? Given *that* provision, which is tantamount to licensing under every license existing or to be created later, RMS can't possibly have a problem. The rest of us might, however. -- Do what you will, John Cowan this Life's a Fiction[EMAIL PROTECTED] And is made up of http://www.reutershealth.com Contradiction. http://www.ccil.org/~cowan -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Compatibility of the AFL with the GPL
All IMHO, and IANAL, coz I get burned every time I post here these days... Despite these clauses being within the spirit of the GPL, they are still additional restrictions on redistribution. In the case of the trademark/names, one who creates a derivative work will always have to worry that your interpretation of endorse or promote is broader than anticipated. For example, if a derivative work proudly and loudly claimed its heritage, perhaps even named itself something similar, there would always be the possibility that you would disagree, and the right to redistribute would be revoked. Sure, the GPL has other vague clauses, but I just want to point out this is a clause that essentially forms an additional restriction. If instead the license simply *reminded* people that nothing gives them the right to use the trademarks or good name of the original author, then that wouldn't be an additional restriction. As for the mutual patent termination clause: I'll leave for another thread any discussion about whether this is a good idea or a bad idea. But how is it incompatible with the GPL? The provision only applies to software licensed under the AFL and similar licenses, and it doesn't affect in any way software that is not licensed with this provision. The whole point of compatibility between licenses is this: if you can combine (not mere aggregation, but linking, etc) software with license A with software license B and legally redistribute it with license C, then licenses A and B are compatible for some values of C. If either A or B is the GPL, then C *must* also be the GPL, and nothing more. But, C must be comprehensive and cover the license of the whole codebase; which means your termination clause must be represented in license C, and that prevents it from being the GPL. Amateur set theorists will quickly see that the only licenses that are compatible with the GPL are those whose terms and requirements are a subset of those of the GPL. That's always been my understanding. The MIT/X licenses are GPL-compatible because there is nothing they demand from the end-user or redistributor that the GPL doesn't demand. ***Anyone*** is free to take software licensed under the AFL and re-license it under any license, including licenses not containing the Mutual Defense provision [to use, copy, modify, merge, publish, perform, distribute and/or sell copies of the Original Work and derivative works thereof,...]. In fact, the AFL permits anyone to freely relicense their derivative work software under the GPL. But the license on the parts copied from the original work are still under the AFL, right? Which means any new license I put on it has to carry forward the same terms, at least on that original code, unless I indemnify those I give software to by meeting the terms on their behalf? When we use third-party code in Apache, we're careful that the requirements that code places are *not* more onerous than those of the Apache license as well. Surely you're not saying I can add some whitespace to the end of a .c file, and put the entire codebase under the Apache license, for example. Brian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
RE: Compatibility of the AFL with the GPL
Brian Behlendort wrote: All IMHO, and IANAL, coz I get burned every time I post here these days... Are you afraid I'll slap you 'aside the head? Relax :-) Despite these clauses being within the spirit of the GPL, they are still additional restrictions on redistribution. If the goal is just the GPL, only the GPL, nothing but the GPL, forever and ever, amen then I suppose anything that differs from it has a big hurdle to overcome. But I thought the real goal was *free software*, not simply protecting a license. So what if there are additional restrictions (although I quarrel with your use of the word restrictions)? Why is that not within the spirit of the GPL? RMS is challenging compatibility, not testing for equivalence. In the case of the trademark/names, one who creates a derivative work will always have to worry that your interpretation of endorse or promote is broader than anticipated. For example, if a derivative work proudly and loudly claimed its heritage, perhaps even named itself something similar, there would always be the possibility that you would disagree, and the right to redistribute would be revoked. Sure, the GPL has other vague clauses, but I just want to point out this is a clause that essentially forms an additional restriction. Are you suggesting different words besides endorse or promote? Under U.S. trademark law, anyone can say I've built a derivative work of Apache without using Apache's good name, or yours, to endorse or promote their software. I think the words endorse and promote are clear enough. If instead the license simply *reminded* people that nothing gives them the right to use the trademarks or good name of the original author, then that wouldn't be an additional restriction. That is precisely what it does. Note that the provision is entitled Exclusions from License Grant, and it says, in essence, here's what you don't get with this license. It doesn't say, here's the penalty for doing these things without permission. Do you want me to add the phrase pretty please to the end of the provision so that people will recognize it is a reminder rather than an order to do or not to do something? Simply put, if an AFL-licensee infringes an AFL-licensor's trademark, he will get sued for trademark infringement rather than breach of contract. The infringer won't be able to defend himself by arguing he has an implied license, because the AFL contains an express exclusion of trademarks from the license grant. All the provision does is promote clarity of the scope of license. (That's a deficiency of the GPL, by the way!) As for the mutual patent termination clause: I'll leave for another thread any discussion about whether this is a good idea or a bad idea. But how is it incompatible with the GPL? The provision only applies to software licensed under the AFL and similar licenses, and it doesn't affect in any way software that is not licensed with this provision. The whole point of compatibility between licenses is this: if you can combine (not mere aggregation, but linking, etc) software with license A with software license B and legally redistribute it with license C, then licenses A and B are compatible for some values of C. If either A or B is the GPL, then C *must* also be the GPL, and nothing more. But, C must be comprehensive and cover the license of the whole codebase; which means your termination clause must be represented in license C, and that prevents it from being the GPL. Once again, there is nothing in the AFL that prohibits anyone from combining AFL-licensed code with GPL-licensed code and licensing the entire resulting derivative work under the GPL. The Mutual Defense provision acts to prevent infringement lawsuits against the original code but not to prevent lawsuits against the GPL-licensed code. As long as the original AFL-licensor is protected, why does he care what license is used by others for their derivative works? Amateur set theorists will quickly see that the only licenses that are compatible with the GPL are those whose terms and requirements are a subset of those of the GPL. That's always been my understanding. The MIT/X licenses are GPL-compatible because there is nothing they demand from the end-user or redistributor that the GPL doesn't demand. I'm reluctant to apply amateur set theory when what is needed is clear reading of legal provisions in a license. ***Anyone*** is free to take software licensed under the AFL and re-license it under any license, including licenses not containing the Mutual Defense provision [to use, copy, modify, merge, publish, perform, distribute and/or sell copies of the Original Work and derivative works thereof,...]. In fact, the AFL permits anyone to freely relicense their derivative work software under the GPL. But the license on the parts copied from the original work are still
RE: Compatibility of the AFL with the GPL
***Anyone*** is free to take software licensed under the AFL and re-license it under any license, including licenses not containing the I just want to confirm that I have interpreted the above statement correctly. Anyone can take APL licensed software as a whole and distribute it under different licensing conditions, but the license of the individual source code files cannot be changed from APL into another license. That is, I cannot take APL licensed software and physically replace the license with the GPL. Is this correct? (if not, I would be seriously concerned about suggesting anybody to apply the APL to any software.) If I read your words correctly, yes, that's the intention. Let me describe it more precisely this way: Person A licenses copyrightable work W to Person B under the AFL. Person B must honor the terms and conditions of the AFL. The AFL permits Person B to create collective work W+X, to create derivative work W', and to distribute copies of W, W+X and W' under any open source or proprietary license not expressly incompatible with the AFL, including the GPL and Apache licenses. Because the AFL does not allow sublicensing, W (alone or as part of W+X and W') is always subject to the AFL and the license to W always comes from Person A. [Anyone can look at the source code to see that trail of ownership, because of the Attribution Notice provision in the AFL.] Person A can always enforce his license to W against anyone who uses W. And anyone who has a copy of W+X or W' has two licenses, one from Person A (for that part that was W) and one from Person B (for W+X or W'). Person A is not responsible in any respect for W+X or W'. In practice, because the AFL is so forgiving a license, Person A won't much care what Person B does with W. And the ultimate consumer will know that at least W is free and open source software regardless of what Person B does. /Larry Rosen -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
