#777 Licensing: Academic Free License and other licenses

msylvan Sun 11 Oct 2009

Hi,

The current license used by Fan, AFL 2.0, is commonly considered to be GPL-incompatible.

For example, Fedora considers it free but GPL-incompatible

the OSI also lists it as redundant

and, most authoritatively, from the FSF (with good explanation)

My concern is that Fan code (using Fan pods) cannot make use of GPL-licensed Java packages, which might make Fan unusable in certain scenarios.

Would it be possible to relicense (or dual-license) Fan under the following GPL-compatible licenses:

  • Apache 2.0 / Educational Community License 2.0 all the protections in AFL, minus the CDDL-esque choice-of-venue provision and minus the requirement to provide source code
  • Lesser GPL v3.0 all the protections in AFL, minus choice-of-venue. According to the FAQ, it does provide patent retaliation.

There is no provision for relicensing (apart from "upgrading" to the full GPL) but the number of licenses compatible with the AFL is rather small anyway (if the AFL term still applies, picking a more liberal license like BSD/MIT does not actually change anything, but causes confusion).

  • Full GPL v3.0

Personally I tend to go with LGPL -- it makes sure that modification to the original codebase gets shared back, but allows any libraries to be used to create proprietary applications as well.

brian Sun 11 Oct 2009

Yeah, that's a tricky subject. I understand the FSF declared the AFL incompatible with GPL. But Larry Rossen the author of the AFL and general counsel for OSI says that is compatible (for one example).

I am not particularly happy with the AFL because it isn't main stream. What I would like most to use is Apache 2.0. But Apache 2.0 is incompatible with GPL v2, and I don't think you really solve anything being GPL v3 compatabile, but not v2.

The reason I didn't choose Apache was because it has no patent termination clause. I feel pretty strongly about this clause. I've personally been involved with big, non-innovative companies using their patent portfolio to strong arm innovative startups.

I haven't studied GPL v3. If contains a patent defense clause, then I might consider a dual license.

msylvan Sun 11 Oct 2009

Hi brian,

GPLv3 or LGPLv3 have patent defense clauses -- as I linked. As for GPL compatibility, the FSF tends to be the authority followed by most Linux distributions, which is why I brought up the code-mixing problem: it would be a shame if a great app is written in Fan and then cannot be distributed for license issues.

Apache is incompatible with GPLv2, but the FSF tends to encourage projects to use the "or later" clause, meaning a large proportion of GPL/LGPL projects out there are actually Apache 2.0-compatible (Apache 2.0 + GPLv2+ ==> distributable under GPLv3+).

Unless I'm misreading things, the Apache license does have a patent defense clause, unless you want a mutually-assured counter-lawsuit provision, which from my reading of the AFL 3.0, does not exist there either (i.e. both licenses have, to my IANAL eyes, the same patent defense provisions).

If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

If you are not too concerned with requiring source availability, then Apache 2.0 sounds good (and in sync with what Google and Apache uses, so there's no hair-splitting about license required there). Otherwise, LGPLv3+ is probably the closest to what you have now. In either case, once you care about patent defense, GPLv2/LGPLv2 compatibility is out of the window anyway.

You're more than welcome to pose licensing question at our http://www.redhat.com/mailman/listinfo/fedora-legal-list[fedora-legal-list], by the way. Our license contact person, Tom Callaway, is experienced in dealing with relicensing issues, and if necessary he can get legal opinion from Red Hat's legal team.

Thanks,

-- Michel

brian Sun 11 Oct 2009

Unless I'm misreading things, the Apache license does have a patent defense clause,

The difference b/w AFL and Apache, is that AFL terminates the license if you initiate a patent lawsuit. Apache terminates patent rights, not the overall license to the code. Seeing as we have no patents on Fan, this is a huge difference. So unless you have patents to terminate, then the Apache license effectively has no patent defense. This is my major gripe with Apache 2.0. Personally I'm surprised that more open source contributors aren't more zealous in combating patent abuse.

JohnDG Sun 11 Oct 2009

My concern is that Fan code (using Fan pods) cannot make use of GPL-licensed Java packages, which might make Fan unusable in certain scenarios.

So you lose that 0.01% of the market who wants to produce GPL software.

What's the problem with that? :)

msylvan Mon 12 Oct 2009

So you lose that 0.01% of the market who wants to produce GPL software.

But if the license is redundant (very similar to Apache 2.0) and Apache is known for sure to be GPL (v3 and above) compatible, why not reduce the license clutter?

It's also more than that: see FSF's interpretation of the contract clauses in AFL and OFL, about how, if enforced, it could prevent distribution. The legal uncertainty alone, whether justified or not, probably outweighs any benefit the AFL provides over Apache, which is considered very similar to AFL anyway.

brian Mon 12 Oct 2009

But if the license is redundant

I don't personally consider them redundant because Apache doesn't provide a real patent defense. And this is something I am quite passionate about.

The legal uncertainty alone, whether justified or not, probably outweighs any benefit the AFL provides over Apache

Larry Rosen is a pretty prominent attorney in the industry, I don't think the AFL has any more risk than most open source licenses. The real issue is that very little actual case law exists for open source, so most licenses are based on theory.

From my perspective, AFL is compatible with GPL. I understand there is lots of confusion over compatibility in general, and the FSF frowns up AFL. As I said, I'm willing to consider a dual license which includes GPL v3 (but I need some time to study the license).

msylvan Wed 21 Oct 2009

I don't personally consider them redundant because Apache doesn't provide a real patent defense. And this is something I am quite passionate about.

That's understandable, but it would be great if you could point out which AFL patent provision is not present in Apache?

Larry Rosen is a pretty prominent attorney in the industry, I don't think the AFL has any more risk than most open source licenses.

I agree. The risk is not whether AFL is enforceable or not, it's in whether people agree on its GPL compatibility. Unfortunately, given that the FSF is an established organization with a track record of pronouncing on license compatibility, their claim that AFL is not compatible with GPL would have impact.

A dual-licensing would be great. Is Fan requiring copyright reassignment and/or joint copyright assignment for contributors? Otherwise, relicensing might be a problem.

brian Thu 22 Oct 2009

That's understandable, but it would be great if you could point out which AFL patent provision is not present in Apache?

AFL 3.0:

This License shall terminate automatically

Apache 2.0:

then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed

AFL terminates the entire license. Apache only terminates your license to the the patents. So if you don't have any patents, then Apache basically has no patent defense clause (which is a real shame).

Maybe we'll get lucky and the US Supreme court will overturn software patents and put an end to the whole cluster fuck, then of course we'll just us the Apache license :-)

Is Fan requiring copyright reassignment and/or joint copyright assignment for contributors?

For minor patches to core code I might require it to keep things clean. But for major submissions (like a new source file or entire new pod), then no. I think the original author should maintain copyright.

Currently, pretty much everything that matters has clean provenance with Andy and myself holding the copyright. So relicensing isn't an issue today.

Login or Signup to reply.