An Introduction to Modern Open Source Licence Patent Clauses

I bet that title sent shivers of pure pleasure up and down your spine, didn’t it? :-) This post explains why all modern open source licences have patent clauses, what they do (and don’t do), and why you should use and recommend licences which contain them. This question is relevant to discussions of licence choice.

I am not a lawyer, although I do sometimes play one in real life. If in doubt, consult the real deal.

This analysis will focus on the 3 most popular modern licences with patent clauses – the Apache License 2.0 (“APL”), the Mozilla Public License 2.0 (“MPL”), and the GNU General Public License 3.0 (“GPL”).

What Do They Do?

The APL (section 3) and the MPL (section 2.1, 1.11, 1.2, 1.3) say that if you make a contribution to the code, you have to grant all users a licence to any patent you hold which is infringed by your contribution, or by the whole thing as a result of adding your contribution. In the case of the GPL (Section 11, para 2), you have to grant a licence to any patent you hold which is infringed by any part of the modified work, at the time you contributed to it, whether you wrote or changed that part or not. So the GPL’s grant is wider in scope than the other two.

The above affects contributors. There are also clauses which relate to users. In the case of the MPL (section 5.2) and the GPL (section 10, para 3), you lose your right to use the software at all if you launch a patent suit against someone else regarding that software. In the case of the APL (section 3), you lose any patent licences you might have got to the code (which may be none), but you don’t lose your copyright rights.

What Don’t They Do?

In the case of the APL and MPL, they don’t make a contributor grant a licence to patents which the code already implemented before they came along, or which someone else made the code implement while they were contributing. In all cases, if the code is changed in the future by someone else to implement a patent, the licences don’t make the contributor grant a licence to that patent. (I.e. if BigCorp has a patent on the Bar algorithm, and they contribute some non-Bar-related code to project Foo, you can’t get a free license to the Bar patent by changing Foo to implement it.) And they don’t protect you at all from the patents of people who are neither contributors nor users, including patent trolls.

Why Are They Good?

  • They provide some protection to stop one member of the community suing another one. This particularly applies to the MPL and GPL, which rescind all rights (including copyright rights) to the code when a suit is filed, thereby giving the small, patentless guy some power when this happens.
  • Relatedly, they make big companies much more comfortable about collaborating on a codebase together. Without a patent licence, the first big company you recruit to work on your code will scare off any additional ones, because they are concerned about the first company’s patents.
  • If your code is widely-enough used, it provides some protection from third parties who would not want to lose their rights to use it.

Patent clauses do not solve the software patent problem. But they do mitigate it and, in the presence of the problem, they do help build collaborating communities. That is why all modern open source licences have a patent clause, and why you should only use and promote licences which have them, and encourage others to do the same.

15 thoughts on “An Introduction to Modern Open Source Licence Patent Clauses

  1. I’m having a hard time parsing the sentence ” they don’t make a contributor license patents the code is changed in the future to implement”, are there a fe words missing?

  2. No; but I will clarify it :-) It means:

    [Open source licences with patent clauses] don’t force a contributor to give a licence to patents which the code does not implement at the time their contribution is changes, but which the code is made (by someone else) to implement at some point in the future.

    The issue may be that license in the original sentence is a verb, not a noun.

  3. Unfortunately, it’s my understanding that none of your suggested licenses are compatible with the “2/3-clause BSD” license family or the (L)GPL version 2.0 (in the sense that code under the suggested licenses cannot be incorporated into a larger work which is under either of those licenses without changing the license of the larger work to match). If compatibility with those licenses is still a priority (which IME is far more frequent than not) are there any alternative ways to defend against the concerns that have led to the inclusion of patent clauses in the newer licenses?

  4. Code under the MPL 2.0 can be incorporated into a larger LGPL 2.1 or GPL 2 work, using the provisions and process specifically written into that licence.

    Code under either the MPL 2.0 or the Apache License 2.0 can be incorporated into a BSDed work without changing the license of the BSDed bits. (Obviously, the MPL/Apache bits stay MPL/Apache.)

    Does that answer your question?


  5. Is it possible to have patent clauses protection while still being MIT/ BSD licensed?

    As i understand Servo still has yet to decide on its license and patent clauses is the main issues.

    And to be honest MPL is pretty much being used by Mozilla only, so i wouldn’t really classify it as “popular”

  6. No, that misses the point; allow me to rephrase. Some projects — in fact, the overwhelming majority of projects IME — will not incorporate contributions unless they can relicense them under the same terms as the rest of the codebase. They do not want to incorporate code which is formally under another license, even if that license permits that type of aggregation. As such, if I write a code module which I distribute standalone but which is designed to be incorporated into a larger work, I need to choose license terms that are maximally permissive of downstream relicensing. If I’m okay with allowing proprietary reuse, the optimal choices are some form of 2-clause BSD, or the FSF’s “all-permissive” license. If I want to restrict reuse to copyleft projects, the only sane option is LGPL 2.1 with “or later” clause (because of the unenthusiastic uptake of GPL 3, and the toothlessness of the MPL).

    Neither of those options makes any kind of statement about patents, and I don’t think they could without interfering with the goal of allowing downstream relicensing under whatever terms are congenial. So I’m asking you if anyone has thought about an alternative — that is, non-license-terms-based — means of achieving the same end (protection from third-party patent lawsuits).

  7. Some projects — in fact, the overwhelming majority of projects IME — will not incorporate contributions unless they can relicense them under the same terms as the rest of the codebase.

    That’s surprising to me, because it’s not my experience at all. Linux contains much BSD code and they don’t add GPL headers to it. Mozilla contains much MIT/BSD code and we don’t add MPL headers to it. LibreOffice _is_ adding MPL headers to the Apache code taken from OpenOffice but I don’t think it’s doing so for code taken from other sources.

    Can you give me some examples (and links to policy URLs) of projects with this policy?

    I don’t know of any licence with a patent clause which allows you to relicense under another licence without a patent clause.

    Also, I’m not sure what sort of patent protection you are trying to achieve in the scheme you are attempting to construct. Remember, patent clauses don’t protect you from random 3rd parties – only 3rd party users (in some cases) and other contributors. In your scheme, would the other contributors be contributing under a licence with a patent clause, or not? If not, you have no protection from their patents. If they do, you have some protection. That is true whether or not someone else subsequently takes the code and relicenses it under a licence with no patent clause.

  8. The licence you choose is what people agree to when making contributions. If they don’t agree to a patent licence as part of that, then you have no protection from their patents.

    It’s possible to add a patent licence to the MIT and BSD licences; that’s what Google did for the VP8 code. But then, it’s no longer the same licence.

    MPL is also used by LibreOffice and other projects, and is listed by the OSI as being “popular, widely used or having a strong community“. But really, you should not pick your license by looking at what everyone else is doing (that kind of thing leads to continued use of BSD and MIT, which are IMO not robust enough for today’s world) but by whether it meets your licensing goals (which may include certain sorts of compatibility – that’s why Rust is Apache 2/MIT rather than Apache 2, to gain GPL 2.0 compatibility).

  9. That’s surprising to me, because it’s not my experience at all.…Can you give me some examples (and links to policy URLs) of projects with this policy?

    Have a look at the Boost project’s licensing requirements and rationale: and (note the statement near the bottom of the latter page that “Boost’s lawyers were well aware of patent provisions in licenses like the GPL and CPL, and would have included such provisions in the Boost license if they were believed to be legally useful.”) It doesn’t explicitly say they wouldn’t accept a contribution under the Apache 2.0 license, but the general attitude is “we want all the code to be under this license”, and I expect that if you offered them something under Apache 2.0 or any other license more restrictive than their variant of 2-clause BSD, you would be asked to relicense it or the contribution would be rejected.

    My experience has been that this is the attitude taken by all projects using a variant of the 2- or 3-clause BSD license. The policy may not be written down where you can point at it, but it is a rigid policy nonetheless: no code under a more restrictive license need apply. Similarly, projects still using (L)GPL 2 (with or without “or later”) will ask you to relicense under those terms if you show up with GPLv3 code. Your Linux and Moz examples are off the mark because they are both cases of code under more permissive licenses being aggregated into a larger work under a less permissive license.

    I’m not sure what sort of patent protection you are trying to achieve in the scheme you are attempting to construct.

    I’m most concerned with protection against patent lawsuits by other contributors.

  10. This is just my personal opinion, but I don’t see that a file-level copyleft provides any meaningful protection against closed-source reuse, so I don’t think the MPL provides any real benefit relative to BSD-style licensing, and I think Mozilla should switch to the GPL.

  11. One notable side effect these clauses have is to make your license incompatible with a lot of other licenses. (This, however, is probably only really important if your license doesn’t already contain other clauses that also do that, e.g., a share-alike clause, a non-commercial clause, etc.)

  12. The Boost team’s page says: “if you don’t want to use the Boost licence, talk to us”. Which is sort of what Mozilla says too. The problem they had to deal with was a load of proliferating licenses which had to each be evaluated by corporate counsel. Using a popular existing license like Apache wouldn’t exacerbate the problem they are trying to deal with.

    The reason the Boost team haven’t included a patent clause is that they think that the license they have written already implicitly grants patent rights. Some lawyers do think this about MIT/BSD (based on the fact that they give the right to ‘use’, and in order to use it, you have to be able to use any patents), but this has never been tested in court and others think that having an explicit patent licence is an excellent idea. Mozilla agrees.

    I wouldn’t expect a permissively-licensed project to take code under the MPL, LGPL or GPL, but I would hope they would at least consider taking code under the Apache License 2.0, which is not “more restrictive” in a copyleft sense.

    As for protecting people while still using the BSD and MIT licence, see above for a legal theory you could try using. Let us know how you get on :-)

  13. The purpose of the file-level copyleft is not to provide watertight protection against closed-source reuse. See Netscape :-) The purpose, to my mind, is to set up a community expectation of sharing, and to associate some penalty (in the form of having to contort your source code base, with associated maintenance headaches) with not sharing.

    I think it’s highly unlikely that Mozilla will switch to the GPL.

  14. Not necessarily; Apache is not all that incompatible with anything else. Even if you want it in a BSDed project, you only have a problem if you want to mix code from Apache and BSD files; and even then, you can make the whole file (only) Apache.


  15. The MPL may set up a community expectation of sharing, but does it do that any more effectively than a BSD-style license? Certainly the dozens (if not hundreds) of BSD-licensed projects out there suggest that one can get by on a community norm of contribution, without needing any formal copyleft at all.

    I don’t seriously expect Mozilla to switch, but I want to point out that a copyleft with teeth (i.e. the GPL) would have real, concrete benefits for the project: for instance, it would eliminate closed-source extensions with all their associated compatibility and reliability headaches.

Leave a Reply

Your email address will not be published. Required fields are marked *