The present text does not engage nor represent the views of the Apache Software Foundation. It is the mere opinion of the author and the author alone. Moreover, the opinions expressed herein seem to be shared by a small, but growing minority. I recognize the hard work that went into preparing the new license and I should like to thank its contributors for their valuable work.

The Apache Software Foundation (ASF) is currently debating the merits of adopting the next version (2.0) of its license. The current Apache license is tagged as version 1.1. Version 1.1 lacks any provisions regarding patents whereas the proposed 2.0 license reads:

   4. Contributor Grant of Rights. Subject to the terms and conditions
      of this License, each Contributor hereby grants to You:

      a) a non-exclusive, worldwide, royalty-free copyright license to
         reproduce, prepare derivative works of, publicly display,
         publicly perform, distribute, and sublicense the Contribution
         of such Contributor and such derivative works in source code
         and object code form; and,

      b) a non-exclusive, worldwide, royalty-free patent license under
         Licensed Patents to make, use, sell, offer to sell, import, and
         otherwise transfer the Contribution of such Contributor in
         source code and object code form. This patent license shall
         apply to the combination of the Contribution and the Work to
         which such Contribution was submitted if, at the time the
         Contribution is submitted by the Contributor, such addition of
         the Contribution causes such combination to be covered by the
         Licensed Patents. The patent license shall not apply to any
         other combinations which include the Contribution. No hardware
         per se is licensed hereunder.
    

The patent related provisions are identical to those that exist in other open source licenses, for example section 2.b of the IBM Public License or section 2.b of Common Public License. Some other open source licenses contain similar provisions, for example section 2.1.b and 2.1.d of the Mozilla Public License 1.1 and sections 2.1.b. and 2.1.d of the Nokia Open Source License.

Given that the above are open source licenses certified by the Open Source Initiative, the reader might be induced to let down her guard. According to Eric Steven Raymond in his Licensing HOWTO the following constraints apply to to a license in order to qualify as open source. I quote:

The Open Source Initiative is the result of a great deal of thought
about what makes software "open source" or (in older terminology)
"free software". Its constraints on licensing require that:

An unlimited right to copy be granted.
    
An unlimited right to use be granted.
    
An unlimited right to modify for personal use be granted.
 

Note the 3rd condition. The third condition does not require the license to grant rights for public forks. One of the mantras of the ASF is "if you don't like it, you can always fork." No one needs permission of the ASF to fork the code. However, the forked code must change its name and cannot claim to be endorsed by the ASF. Thus, you can fork any Apache code you fancy, provided that you change its name and stop marketing it under the Apache banner.

With the proposed 2.0 license however, any fork of the code may be attacked based on patent infringement because of the "The patent license shall not apply to any other combinations which include the Contribution." provision. It is important to note that this statement does not explicitly prohibit other combinations. It just says that there is no patent grant for "other combinations". Legal language does not use fancy words just to fill up empty space. Every sentence has its purpose and no, the purpose is not to write long documents to confuse the hacker. One conservative interpretation of this statement is that other combinations are expressly forbidden and require a separate patent license. This is the interpretation that seems most plausible which I retain for the rest of my argumentation.

Many people argue that the proposed license provides more protection than the existing Apache license, at least more protection to the ASF and its users. This absolute statement must be qualified because it simply cannot be taken for granted.

Section 4b) grants an explicit patent license to use licensed patents to the original work as intended by the contributor. However, it also states that this patent license "shall not apply to any other combinations which include the Contribution." This means that a third party may not safely fork the code even if it scrupulously adheres to the terms of the Apache license. A Contributor can attack the third-party for patent infringement.

Note that the third-party can be the ASF itself. It is quite common for Apache developers to scavenge parts of Apache licensed code and use it in some other Apache licensed code. This is the principle behind jakarta-commons. You think this is bad? Wait, it can get worse! Assume you subscribe to a mailing list of project P. A contributor, say C, makes a contribution to project P by submitting a patch and explaining the idea behind the patch. You happen to think that the idea is cool and incorporate it in some other ASF project. Now, the contributor C can sue the ASF, you or your users because you incorporated an idea that she submitted in the mailing list of project P but not your project.

You might ask whether this could have happened with version 1.1 of the license. It could but with the 1.1 license the argument of contributor C is weaker. The defendant can argue that by contributing to the project under the terms of Apache license 1.1, contributor C made an implicit patent license grant to use the patented ideas expressed in the code. With version 2.0 of the license, there is now an explicit grant to use the patented idea in its contributed form, however, there is also an explicit prohibition to use the patented idea in modified forms.

To the best of my knowledge, there is no precedent for a contributor to an open source project attacking users or the institution responsible for the project for patent infringement. This does not mean that open source projects have not been attacked in the past or will not be attacked in the future. It means that a contributor cannot willfully participate in an open source project and later decide to play sleazeball by attacking the other participants.

With the proposed 2.0 license, due to the explicit restrictions on allowed combinations, the offensive position of the contributor is substantially improved. The improved offensive posture can entice it to play dirty.

Should the patent license extend to commercial redistributions?

I think it should extend.

I recognize that extending the patent license to commercial resitributions would allow "competition" to leverage patented ideas belonging to the contributor. However, the competition can leverage patented ideas only if they follow the terms of the Apache license. They must still obey the rules of the game.

Redistributions, including commercial redistributions, should be granted a patent license. There are many reasons for this. First, it allows commercial entities to feel safe when extending or building on top of code licensed under the Apache license. Otherwise, who can guarantee that the planned extension does not fall outside the scope of the allowed combination? Second, Apache developers familiar with Apache licensed code may occasionally rip off code and use it in totally unrelated areas, usually in a commercial context. Such combinations will not be explicitly allowed with the currently proposed 2.0 license.

The essence of the Apache license 1.1 is "do what ever you want with the code and the ideas contained therein as long as you respect ASF's minimal branding restrictions." The 2.0 license says "do what you want with the code but not the ideas contained therein." This constitutes a severe limitation restricting the ideas and by implication the code.

Explicitly granting a patent license to open source software is a step forward, but remains insufficient. Apache license should allow commercial extensions of the code.

How can commercial entities protect their intellectual property and still participate within the ASF framework?

By donating their intellectual property to the ASF participant agree to play according to certain rules set forth by the foundation. Those rules allow anyone to extend, modity and redistribte the code as long as they adhere to the terms of the Apache license. In particular, one is not allowed to freely ride on the reputation of the Apache brand. One cannot remove the ASF copyright.

Commericial entities may protect their intellectual property by exercising good judgement prior to making contributions. Contributions with attached strings may ease the workload of the contributor, but in turn they materially increase the burden on other participants.

Conclusion

Given that the proposed license shifts the onus of due diligence from the contributor to other parties wishing to leverage the code, the proposed license constitutes a significant regression of the BSD spirit as compared to version 1.1 of the Apache license. I urge the Apache members to postpone the approval of the proposed license until the last two sentences of section 4b are removed.

Followup Comments

Comments by William A. Rowe, Jr.

Let's consider a hypothetical case. A contributor of RSA in 1999 commits a patch to Apache 2.0 mod_ssl to perform MD5 authentication, a patent they hold at the time. [The example is stretching time and details, but heck, it's an imaginary case.]

The employer, aware of the contribution, lets it stand. The employee and employer know of the patent and the contribution. Pretend we [the ASF] don't.

Under the proposed Roy-License, if someone takes mod_ssl, and reduces it to a very lightweight Apache-SSL style module and a super-light build of the Apache framework, they explicitly violate the license to the patent contribution. If someone extends Apache, adding lots of 'nifty features', again they explicitly violate it.

Under Ceki's proposal, we fall back into the 'fuzzy' relm. However, there is no explicit license violation in that example above.

Now, pretend that someone crafts a new SNMP/POP3 transport, borrowing heavily from the Apache code, or even running as a 2.0 filter. The program is no longer doing the same thing (once, it served web pages, now it's processing email.)

Taking Ceki's proposal, it's very difficult to envision that any 'web server' usage of the patent, using the Apache code, will be interpreted by a court as a violation of the patent. But the new Mail server modified not only the code but the purpose of the program. Here, the court is far more likely to tip to the side of the patent holder.

"addition of the Contribution causes such combination to be covered by the Licensed Patents." What does that implicitly tell the court? That the combination of web server+MD5 is granted license to the patent. That the combination of something else+MD5 is not.

Of course the example is 'patently' absurd (all pun intended.) It's simply trying to illustrate that a reasonable court will err for the developer using our code containing such patented ideas with Ceki's proposal than for the original license. However, Ceki's proposal does not altogether strip the patent holder of all rights, but simply leaves the interpretation of . "causes such combination to be covered by the Licensed Patents" to be determined by the courts if it ever comes to that. Rather than define combination and adding the restrictive original language, we are all better off with his proposal.

Comments by Brian Behlendorf on the 10th of November

I'm a bit confused - I thought the current proposed language in roy-license said the "patent continues even if the code is modified", but only for code that is modified within the ASF's control. That last restriction is what Ceki's worried about, as am I.

The language in 4b says nothing about the ASF! The license explicitly applies to the original combination. It does not apply to forks or even to code scavenging *within* the ASF.

Ah, you're right. For example, IBM commits patent-encumbered code to create Combination A1, then then someone else makes a change creating A2 - IBM's patent license applies to A1 not A2, until another IBM employee makes a commit creating A3, since now A3 is covered by the Licensed Patents. But by this logic, only one company's patents can apply to any particular Combination at once! Because of the commit that created A2 was from Sun, and the code was encumbered by a Sun patent, then the patent license from Sun applies to A2, but there's no IBM patent license that applies to A2! And Sun's patent license doesn't apply to A3!

I'm trying to reconcile this with the claim "Once the patent is licensed, the license to that patent continues even if the code is modified." I just don't understand how Drew gets that from 4b of roy-license, when it's clear that the patent grant applies only to "the Contribution and the Work to which such Contribution was submitted", and "The patent license shall not apply to any other combinations which include the Contribution."

Oh, I see Ceki got all this in his document.

I've already given up on the idea that the patent license would apply to commercial redistributions.

Can you please explain why?

In the interests of making progress, I'll buy the claim that such a giveaway would be to ask too much of commercial contributors. I don't like that personally and would still like to make it clear to people that it allows for patent-covered code that can bite commercial redistributors. I'd like to also draw peoples' attention to the furor that erupted when the W3C even demanded "fair and non-discriminatory" licensing of any patents their standards required, and had to back down to demanding "royalty-free". We should expect some flack for taking such a pro-patent position. But the more important thing for me is that we have a list of patents that we *know* are covered by our code.

Note that if we did have language that required the patent license grant to apply to commercial redistribution, I care much much less about knowing what patents may apply.

but as a compromise, could the language be modified so that the patent license would apply to any redistribution under, say, an OSI-approved open source license? That would allow for open-source forks, at least.

I have modified http://apache.org/~ceki/newlicense.html to reflect on this point. Please see the text under the heading "Should the patent license extend to commercial redistributions?"

Great, thanks for coalescing this all in one place. I have to say, not only should those two sentences in 4b be released, but an explicit grant to any derivative work should be allowed, is my preferred position. The more I think about this the more damage I see in being too conservative.