What if anything is wrong with the Apache License 2.0?

Question

I occasionally see claims that the Apache license makes it difficult to incorporate your code into other projects. See for example:

That's awfully disconcerting news, considering the difficulties involved in AL2 management in derived works

But what exactly are the difficulties?

I am looking at selecting an appropriate license for an open source project. For why this matters consider the community wiki answer to the question What should every developer know about legal matters?.

The best contenders so far seem to be:

• Apache License v2.0 (https://www.apache.org/licenses/LICENSE-2.0)

• Tesla COIL License (Copyfree Open Innovation License (http://copyfree.org/content/standard/licenses/coil/license.txt)

I selected these as:

• they include clauses to protect against threats of patent infringment
• copyleft is not appropriate here as it would restrict incorporation in commercial software (saying that the LGPL could possibly work)

Useful references.

There are some differences however:

• Copyfree Open Innovation License compatibility
• https://www.wikivs.com/wiki/Apache_License_vs_COIL
• http://copyfree.org/standard/rejected

In particular both of the latter mention (concerning the Apache license):

• A book-keeping clause (Section 4, Subsection 2)
• A project organization clause (Section 4, Subsection 4)

If you look at the actual text of the license though (e.g. http://copyfree.org/content/standard/rejected/apache2/license.txt) it is not clear which clauses this actually refers to. What constitutes a section or subsection?

Which part is the "project organisation clause"?

The question What should I note when I want to change Apache License 2.0 code? almost but not quite answers it.

It seems to me that the book-keeping clause is item 7:

If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices […]

This provides explicit protection of attribution. Why would this be a bad thing?

This site (via this question) provides some common sense guidelines which when followed ought to make it less of a bad thing.

The main differences are:

• COIL is copyfree and effectively places the software in the public domain (as far as possible) while the Apache license retains each contributor's copyright and grants a permissive license to use etc.

• COIL can be used beyond just software.

• The Apache license includes a clause for automatic attribution of patches under the same license. This sounds like a useful property lessoning the need to get contributers to provide an explicit waiver.

copyfree.org claims that the Apache license 2.0 is not copyfree.

The FSF does not list COIL as GPL Compatible (i.e. you can include the code in new software under the GPL) but I believe that any copyfree license must be (please comment if you can argue otherwise). It does list Apache License 2.0 as compatible as does the Apache foundation (http://www.apache.org/licenses/GPL-compatibility.html).

On the other hand what do you lose by going with a "public domain" license rather than a permissive open source one (i.e. waiving your copyright)?

In case specifics will help answer the question suppose your project is a file format or a protocol.

You wish to foster wide adoption and provide reference implementations in popular languages. In the unlikely event the format or protocol is really popular (e.g. JSON, HTTP) you want to allow your project to be used as a basis for standardisation by W3, IETF, ISO or whoever.

Does it make a difference if the project is started or maintained by a company or an individual? i.e. is it easier to get a company to sign stuff over under a permissive license than a copyfree one?

Muddying the waters further (the whole area is a minefield) the W3 license almost sounds tailor made for this scenario. It is also rejected by copyfree.org due to a book-keeping clause.

Update I think I have given too much weight to the COIL license. Although it looks professional to the untrained eye, I can find no evidence of it being drafted by a lawyer rather than whoever wrote it, or that it is used widely. There are no such details on it website and no contact details whatsoever. So it looks as if the alternative choices are MIT (with no patent clause) or MPL (weak copyleft).

Answer 1

http://copyfree.org/standard/ currently contains a section titled “Copyfree Standard Compliance” which highlights typical problems. In particular it describes “Bookkeeping Clause” and “Project Organization Clause”, quoting the corresponding sections of AL2 as examples, and discussing at length why these requirements do not agree with the goals of copyfree licensing. I'll try to summarize that here.

A book-keeping clause (Section 4, Subsection 2)

You must cause any modified files to carry prominent notices stating that You changed the files

This means you can't modify the sources any way you like, you have to follow certain rules.

A project organization clause (Section 4, Subsection 4)

If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, […]

I have no clue why you would consider this item 7, but perhaps you got some strange formatting of the license somehow. Anyway, this could lead to conflicts in situations where there are multiple such files, or files with this name used for some other purpose.

I'll not go into the large number of other questions you asked at the end of your post, since most of them would be independent questions in their own right. Let's keep this focused here.

Answer 2

Any "non-standard" license runs the risk of walling your work off from the wider world. Take a look at David Wheeler's "Make Your Open Source Software GPL-Compatible. Or Else."