Apache says ASL2.0 is GPL-compatible 384
Steve Loughran writes "The ASF board have put up on the Apache Web site, a page
rebutting claims that the new ASL2.0 license is incompatible with the GPL, claims made by on an
FSF page and covered in
Slashdot last week.The key points are (1) The interpretation of the GPL license is not just the opinions of individuals in the FSF, it is designed to be rigorously defendable in a court of law.
(2) Rather than look at opinions about compatibility, people should look at the
ASF2.0 and GPL licenses to see if they really are compatible.
(3) If you look at the two licenses, they really are compatible.
This means there is nothing to stop you linking your [L]GPL apps against apache libraries, shipping them with apache applications, and the like." Of course, this is still up to debate.
1.0 and 1.1 Incompatible As Well... (Score:5, Interesting)
It also says that versions 1.0 and 1.1 of the ASF License are incompatible... why are we only hearing about this with version 2.0?
Re:GPL... (Score:4, Interesting)
How about looking at it in terms of economic motivation? For certain types of people (arguably, most people), the GPL provides incentive to create free software where otherwise one wouldn't have bothered. Without the GPL, some of them might begrudgingly release code under a public domain-ish license, but most these people would either be coding proprietary software or not at all.
Which world would you rather have? A world with the GPL as a licensing option, or a world without it? The first world has more free software available, software that respects the rights of the user instead of trying to control the user through EULAs and insidious distribution terms. Regardless of the moaning of anti-GPL types like yourself I'll take the first world where I have more choice as a user and as a creative producer. Begrudging others of their choices when it comes at no cost to you is simply ridiculous. Nobody is going to be sympathetic to your whining because you can't have others' work on YOUR terms.
Shutup (Score:2, Interesting)
Looting the OSS infrastructure? (Score:1, Interesting)
Are we re-playing the unix fragmentation of the late 80's?
Non-Western versions of licenses? (Score:3, Interesting)
Most of the software licenses (BSD, GPL, etc) debated here have their basic origins in copyright and ideas about intellectual property that are distinctly American/European in origin.
Is there any such thing or is anyone aware of software licensing schemes that are more organically based on non-Western ideas of intellectual property or copyright concepts?
The western bias of these licenses makes sense in that they're primarily issued and used in western countries, and hence, need to be oriented towards western IP and copyright models.
But as software development and usage grows in places like China and India, will we see PPL (People's Public License) or IPL (Indian Public License) with terms or concepts different than GPL/BSD, etc?
This is actually an important discussion (Score:3, Interesting)
The fact that Apache has been moving towards a GPL-compatible license and away from the more open earlier licenses shows that there is a desire to benefit from some of the protection that the GPL offers.
(As a free software author, I've made the same move from liberal BSD-style licenses to the GPL in the last years, swayed in part by Stallman's argument that anything less than the GPL helps commercial competitors more than open source developers.)
The compatibility of these two licenses is essential if we're to see Apache smoothly integrated into wider GPL'd frameworks.
The FSF appears quite flexible in considering changes to the GPL for future versions, and I suspect the Apache Group are important enough to push through what they need.
It's an important discussion and one I'll be following.
Re:Its actually 100% relevant (Score:5, Interesting)
Have you, erm, looked at the Apache Software Foundation project list [apache.org] lately?
This isn't just about a license for the Apache HTTP server. In fact, it isn't even just about ASF projects either, since it offers independent developers a new choice of license to easily release their code under.
Conditions on Copyright vs Patent (Score:4, Interesting)
So the disagreement is over whether clause 6 of the GPL:
applies to the patent grant. Does "rights granted herein" refer to the rights in clause 6 ("...copy, distribute, or modify...") or to all rights mentioned in the license?
Re:You know what ? (Score:4, Interesting)
Argument (1) is bogus because other people can release software under the ASL. For example Bob & Mimi can release their (individually patented) package under the ASL, and you have a grant under the ASL to USE and redistribute.
Argument (2) is bogus because when you sue Bob for violating your software patent, you can no longer USE Mimi's portion of the software without violating her patent.
GPL Clause 7 only talks about REDISTRIBUTION. So if this had been GPL software, you would no longer distribute because you'd be distributing what you claim to be your patented technology, but you could still USE it.
A Tale of Apache and it's use of GPL software (Score:4, Interesting)
I've been arguing parts of this issue since late last week, when I was contacted by members of Apache Cocoon [apache.org] in regard to their use of my software, Jisp [coyotegulch.com].
A few months back, I began migrating all of my "free" software from the libpng/zlib license to the GPL. Let's not get into the reasons why I made the change; the change is made, and I'm pleased with it.
The Cocoon people discovered my license change, and opened a dialog. In their view, my use of GPL would force them to remove Jisp from Cocoon. They requested that I either change my license or add Jisp to the Apache collective. Beyond a few miscommunications, the discussion was pleasant and educational.
My software remains under the GPL (or a commercial license, for those so inclined). I did not want to join Apache, as I have already committed myself to FOSS (Free and Open Source Software) projects that are more closely aligned with my business and personal interests. I did not want to "give" Jisp to Apache, either, given that I have several paying customers who might be uncomfortable with such a move --and my personal interest in keep Jisp a small, one-man project.
In the end, Cocoon may not even need Jisp , rendering this an intellectual debate as opposed to a practical one.
Most of Cocoon's members were quite polite; a few were quite pushy and arrogant, although some of that may be due to the crossing of language barriers. In the end, I think we've reached a point of mutual respect. People can disagree on these issues, and remain friends.
Licensing issues are rapidly approaching the contentiousness of fundamentalist religion; people are Balkanizing the FOSS world over the finer points of dogma, rather than building a common framework in which we can all thrive.
Re:GPL... (Score:1, Interesting)
He said the GPL provides ECONOMIC motivation to write software. I said (and still maintain) that it does NOT. In an attempted rebuttal, you then, say people are going to write software "no matter what you do." Not much of a rebuttal, is it? Especially when followed by how the GPL "allows them to release
Then, you attempt to prove the GPL incentivizes software development by pointing to "one hell of a lot of code" in Linux that needs explaining. That code is DWARFED by the amount of proprietary code in existence. MS has at least $1,000 in profit for every single one of those lines (I am assuming then that there are roughly 55MLOC in "Linux" for some value of "Linux" -- a choice of terminology sure to incense the FSF zealots).
Oh, yeah, I founded a multi-million dollar closed source software company, in which I provide regular paychecks (full health care, dental plan, 401K, etc.) for dozens of programmers. There is no real generalizable GPL-based software business model. Our revenues are bigger than Mandrake's... RedHat does not an industry make.
Re:Non-Western versions of licenses? (Score:2, Interesting)
(Who was the guy at Duke that wrote about the need for property rights in a stable society? 2 points for finding it without Google)
Re:License "foo" is crap! (Score:3, Interesting)
For the incompatible licenses, you see some big names there. OpenSSL, BSD, Apache, xinetd, Mozilla, LaTeX, Sun, PHP, and Apple. I know some pretty hardcore FSF zealots, and they use OpenSSL, Apache, and Mozilla, just to name a few. Clearly these products and their group/company backings are not so evil as to prevent their use. Some of the people I know even contribute to these projects, so clearly the license is not so evil as to tarnish their code. The incompatible licenses aer still "free software" according to that page. So what's the problem?
But that's a rhetorical question, so I'll address another glaring problem with the page. Look at all the compatible licenses. Again, a lot of big names: VIm, Perl, Python, Berkley DB, zlib, W3C, X11, and of course BSD. Why do all these licenses need to exist if they're compatible with the GPL? Again, I don't expect an answer.
But the fact that there exist a large number of compatible and incompatible licenses indicates that the state of the licensing world is broken. And there's an opportunity for the FSF to take a leadership role here. Call a license summit. For the compatible licenses, get some folks from each project together, and say "what is it that you find objectionable about the GPL, and how can we fix it? Can we create another license that is not the GPL, but is acceptable to all of you? Ditto for the incompatible ones. Many of those are from big companies that have an interest in Free Software and Open Source (IBM, Apple, Sun, Netscape). They probably each have their own license because their lawyers wanted to cover their asses. Get all the lawyers together, and say "Look, it's stupid to have all these licenses. Can we come up with a license that allows your software to be free, but won't scare your CEOs and shareholders?". That, of course, may be harder, since lawyers cost money. But the FSF should at least be able to get the attention of influential people within each company.
Unless the state of licensing is fixed soon, software will be strangled by it. Being more restrictive (c.f. debian-free, debian-nonfree, debian-illegal (tongue in cheek, get over it)) and claiming that everyone should use the GPL or LGPL is the wrong answer. If this is handled correctly, we'd ideally end up with something like 4 licenses: GPL, LGPL, "Open Source", "Free Software" (those last two would be licenses that cover GPL-compatible and GPL-incompatible licenses , respcetively). But as long as I'm dreaming, I'd like a pony.
Re:Its actually 100% irrelevant (Score:5, Interesting)
The problem is when you want to take some code that is already licensed under the GPL and combine it with ASL2.0 licensed code. All of a sudden you have a tool that compiles and works well, but can't be legally distributed.
The fact of the matter is that the FSF controls the copyrights to a big fat pile of source code, and if they say that derivatives of their GPLed source can't be combined with ASL2.0 source and legally distributed, then folks are going to listen to the FSF.
Since the FSF has a long history of not changind their stance on what is GPL-compatible there is an equally long history of projects changing their licenses to get the FSF blessing. Being cut off from using the millions of lines of FSF GPLed code is simply too big a deal. The Python license is a good example, as is the old QPL license (that QT used to use).
pot...kettle...black (Score:2, Interesting)
You mean like when people withold permission to use their free software with other free software because of dogmatic adherence to their One True License?
To put it bluntly, you are part of the problem. Either stop preaching or start dual-licensing your code.
Re:Its actually 100% irrelevant (Score:2, Interesting)
Trying 199.232.41.10...
Connected to www.gnu.org.
Escape character is '^]'.
GET HTTP/1.1 http://www.gnu.org
HTTP/1.1 400 Bad Request
Date: Tue, 24 Feb 2004 19:29:02 GMT
Server: Apache/1.3.26 (Unix) Debian GNU/Linux mod_python/2.7.8 Python/2.1.3
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>400 Bad Request</TITLE>
</HEAD><BODY>
<H1>Bad Request</H1>
Your browser sent a request that this server could not understand.<P>
The request line contained invalid characters following the protocol string.<P>
<P>
<HR>
<ADDRESS>Apache/1.3.26 Server at www.gnu.org Port 80</ADDRESS>
</BODY></HTML>
Connection closed by foreign host.
seems like license incompatibility doesn't really stop GNU from using software.
Re:Its actually 100% irrelevant (Score:3, Interesting)
But what happens if a third party makes some change to Apache and releases it under the Apache licence? You would also need that third party's written statement to distribute the whole under the GPL. Whereas if the Apache licence were more obviously and transparently GPL-compatible, such that it didn't need these disclaimers, there would be no problem combining APSL-licensed code from different sources as part of a GPL'd program.
The annoying thing is that the fix is really simple. All the Apache people need do is dual-license the code under both their own licence and the GPL, as happens with Perl. If they really believe that the APSL allows GPL'd distribution anyway, they should have no problem doing this, however it helps the rest of the world who don't find the APSL's wording quite so obvious.
(Third parties would still have the option of distributing a modified version under APSL only, but at least it would be obvious and simple what you need to do to allow GPL distribution of your changes.)
Re:vice-versa (Score:4, Interesting)
GPL (duh)
LGPL (duh)
Guile's
GNU ADA compiler runtimes'
X11 (not to be confused with the XFree 4.4 licence)
Expat (aka "MIT")
Standard ML of New Jersey
public domain
Cryptix General
current BSD
Zlib
iMatix Standard Function Library
W3C
Sleepycat/Berkeley DB
current OpenLDAP
current (and early) Python
Perl (when not Artistic 1.0)
Artistic 2.0
Zope 2.0
Intel Open Source
Netscape Javascript
eCos 2.0
Eiffel 2.0
current Vim
Code released under the GPL may be included in projects with thse liceances:
GPL
Re:GPL... (Score:2, Interesting)
IANAL (I am not a lawyer)
I DID read the XFree 4.4 License
I DID read the GPL
I DID read the ASL2.0
I am not disagreeing with Oct..30th
I am not fully agreeing either
Even XFree 4.4 license is not a "problem" per-say. They have some requirements that you tell people that they are using XFree in your documentation. That's it. That's the incompatability. So, that means that any piece of software that uses XFree should say so.
Because XFree doesn't inherantly use GPL software, they have the right to choose this license, freely.
Because of this many people will have to re-write some of their code if they want to compile it against NEW XFree libraries in binary form. (Still nothing needs to be changed for a source distribution model). So what's the big deal?
Yeah, if you are running an entire distribution, that would be a lot to change - once. Hell, it's really something that should have already been in there. Just as Internet Explorer - to THIS DAY - prominantly displays the fact that they use some of the code from NCSA Mosaic. So, you write something that links directly against XFree libraries to get what you need done? Say so!
From what I've read on /. and elsewhere, it seems. Many distributions are simply choosing not to use it YET because of the release-time restraints on labelling XFree use NOW. Some may find it easier to go with a different X platform. Some will not, but the labeling only serves to give each distribution pause to say, if we're going to change, now would be a good time to consider it.
Labelling is only decent, and it may help everyone understand the dependancies that programs have to each-other. Really, if all programs required this (in an "About Page" or "man page" form), then Linux would be a much easier place for me to live.
I am a primary Linux user and from my perspective, dependancy labelling would help out with dependancy hell.
technical nit: relicensing vs. sublicensing. (Score:4, Interesting)
Re:Why not add a compatibility clause (Score:4, Interesting)
Then, to comply with the GPL, they must license the Apache package as a whole under the GPL. You're correct, the Apache folks claim that the Apache License allows that.
Umm, no. See above. To fulfill the conditions of the GPL, the distribution as a whole has to be under the GPL, so there's nothing Jim could complain about. The only one who could potentially sue here is John (who wrote the Apache-licensed code), if he doesn't consider the terms of the Apache License for his code fulfilled by the distribution under the GPL.
So there is a risk only if the GPL does not fulfill all of the Apache License's requirements. This is what is meant by the term "GPL compatibility": that a license contains only requirements that are also fulfilled by the GPL, so it is possible to distribute that code under the GPL.
The ASF says that this is the case, so if their reading of the licenses is correct, there is no risk.
But I'm not sure the ASF's statement is correct. The Apache License 2.0 contains a patent termination clause that might also affect the use of the program. The GPL clause, on the other hand, only talks about distribution. I am not a lawyer, so I don't think I'm qualified to judge whether or not the license is GPL compatible. But I won't be convinced by the ASF's statement before I have heard some reply from someone at the FSF who is qualified and thinks different.
If its compatable? (Score:0, Interesting)