What is your opinion of a license that is MIT-like but with an added free patent grant? reddit / BSD ---------------------------------------------------------------------- deojfj · 2022-01-26 22:33 Some projects begun using first a permissive license like MIT or BSD, but due to some pressure from organizations they changed it to the Apache license, because the latter includes an explicit free patent grant. However, the drawback is that the Apache license is not permissive, as [copyfree.org points out](http://copyfree.org/standard/rejected): > Apache Licenses > > - Condition 3 of both the Apache License 1.0 and Apache License 1.1 violates point 3. Free Modification and Derivation of the Copyfree Standard Definition by specifying conditions (beyond licensing) that must apply to modifications. > > - Section 4, subsections 2 and 4 of the Apache License 2.0 violate point 3. Free Modification and Derivation of the Copyfree Standard Definition by specifying conditions (beyond licensing) that must apply to modifications. > > - Alternatives: COIL The site copyfree.org suggest the COIL license as an alternative. The advantage I see to using it is that it is short and the text is very similar to the MIT license, which most developers are familiar with, but with the added patent clause. [Here's the text](http://copyfree.org/content/standard/licenses/coil/license.txt): > # Copyfree Open Innovation License > > This is version 1.0 of the Copyfree Open Innovation License. > > ## Terms and Conditions > > Redistributions, modified or unmodified, in whole or in part, must retain applicable notices of copyright or other legal privilege, these conditions, and the following license terms and disclaimer. Subject to these conditions, each holder of copyright or other legal privileges, author or assembler, and contributor of this work, henceforth "licensor", hereby grants to any person who obtains a copy of this work in any form: > > 1. Permission to reproduce, modify, distribute, publish, sell, sublicense, use, and/or otherwise deal in the licensed material without restriction. > > 2. A perpetual, worldwide, non-exclusive, royalty-free, gratis, irrevocable patent license to make, have made, provide, transfer, import, use, and/or otherwise deal in the licensed material without restriction, for any and all patents held by such licensor and necessarily infringed by the form of the work upon distribution of that licensor's contribution to the work under the terms of this license. > > NO WARRANTY OF ANY KIND IS IMPLIED BY, OR SHOULD BE INFERRED FROM, THIS LICENSE OR THE ACT OF DISTRIBUTION UNDER THE TERMS OF THIS LICENSE, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS, ASSEMBLERS, OR HOLDERS OF COPYRIGHT OR OTHER LEGAL PRIVILEGE BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER IN ACTION OF CONTRACT, TORT, OR OTHERWISE ARISING FROM, OUT OF, OR IN CONNECTION WITH THE WORK OR THE USE OF OR OTHER DEALINGS IN THE WORK. I'd like to know your opinion regarding the use and promotion of this license as an alternative to the Apache license, and also if it would be compatible within BSD operating systems. Are there other licenses you would recomend instead of COIL? There is also the CC0 license that includes a patent grant, but I regard it as too long, and making a project public domain might bring legal problems in some jurisdictions, as opposed to allowing permissive use like COIL. ---------------------------------------------------------------------- VENTDEV · 2022-01-27 02:30 This is probably a bit above most of our pay grades and is something you'll want to get lawyers involved in. (There is an /r/copyright if I am not mistaken. You would probably get more legal clarity of the difference there.) If you or your work doesn't have a copyright lawyer, then you're probably perfectly fine just picking one of the many copyfree licenses and sticking with it. COIL, BSD, MIT, Zlib, whatever. If management wants Apache, give them Apache. If management is leaving it up to you, COIL reads to me, as a layman, like a perfectly fine copyfree license. ---------------------------------------------------------------------- phrasal_grenade · 2022-01-27 03:08 The Apache 2.0 license includes patent grants. You should really read this explanation of it: https://opensource.stackexchange.com/questions/1881/against-what-does- the-apache-2-0-patent-clause-protect So, when the Apache license says this: >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. One of the comments in that post explains that this means if you sue users (or anyone else) for patent infringement related to the project, you will no longer have any rights to the code yourself. I think there may be other implications as well. But it does make sense to me. Another way to look at the clause is, "If you don't uphold the conditions of this clause (i.e., if you sue anyone for violating your patents), you will lose all rights to use the project and any associated patent licenses granted to you by others." That seems fair enough, and might actually be essential to enforcing such a license. ---------------------------------------------------------------------- trasz · 2022-01-27 08:46 Please, no. Avoid license proliferation, it creates problems for everyone. ---------------------------------------------------------------------- deojfj · 2022-01-27 09:50 I also don't want license proliferation: if there are two licenses that serve the same purpose (and both are short) I'd always go for the most popular one. For example MIT over BSD. But here there is a lack of choice. There is not to my knowledge a popular permissive license with a free patent grant (excluding CC0 which is lengthy and public domain). And the main reason teams choose the Apache license (which is not copyfree/permissive) is due to the patent clause. So if introducing a new license results in more projects using a permissive license, then I think it's a net win. My desired outcome is for the Apache license to become out of favor and be replaced for whichever license is short, permissive, and with a free patent grant. ---------------------------------------------------------------------- deojfj · 2022-01-27 09:58 I agree that the patent clause of the Apache license is sensible, but there are other parts of the license that make it restrictive. What I would like is an alternative with a similar patent clause that is copyfree/permissive, in order for teams to have the option to choose the more permissive license instead. ---------------------------------------------------------------------- liveoneggs · 2022-01-27 12:48 Apache 2 is a great license ---------------------------------------------------------------------- phrasal_grenade · 2022-01-27 14:47 Please explain how the patent clause of Apache 2.0 is a problem. ---------------------------------------------------------------------- phrasal_grenade · 2022-01-27 14:48 What part of it is too restrictive to you? ---------------------------------------------------------------------- lvlint67 · 2022-01-27 17:48 Ask your lawyer but "deal in the Software unrestricted" is pretty straight forward as far as MIT goes. Getting a more specific answer is going to involve a lawyer and the phrase, "the courts are likely..." ---------------------------------------------------------------------- istarian · 2022-01-27 18:13 It’s not about your rights to the code, but about patent licenses. You can’t sue someone for their use of *your* patent (in the code *they* received) without losing any granted license to the patents of *others* inherent in the code as *you* received it. ---------------------------------------------------------------------- fallenpegasus · 2022-01-27 18:22 If you want "MIT with Patent Grant", just use Apache-2.0. There. Done. ---------------------------------------------------------------------- PunishedRaion · 2022-01-27 19:48 I think that patent grants are manifestly unnecessary for most projects. It only matters if you're implementing something that has never been covered by a patent or that you plan to patent, in the latter case, I would through my hypothetical company patent whatever it is and then offer a FOSS version of the product with as few license terms we require. Frankly, I'm aware some people would get mad at that, but the whole purpose of a patent is to prevent people from selling a design without paying you royalties. As long as people weren't commercially exploiting it without permission it wouldn't bother me, and even if they were as long as they approached us first I would find a solution that would work for us both. I am not of the belief that "commercial exploitation" is something within the primary scope of FOSS because I'm not an asshole packaging MAME or other free software and putting it in an APK with few/no mods. ---------------------------------------------------------------------- deojfj · 2022-01-28 11:01 > What part of it is too restrictive to you? Regarding Apache license 2.0, that would be [section 4, subsections 2 and 4](https://www.apache.org/licenses/LICENSE-2.0.html), which do not allow free modification and derivation (unlike BSD and MIT licenses): > (4) Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: > > (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and > > (b) You must cause any modified files to carry prominent notices stating that You changed the files; and > > (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and > > (d) 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, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. > > You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. FreeBSD points out that [the Apache license is not automatically accepted within the system](https://www.freebsd.org/internal/software- license/) (unlike BSD, MIT and ISC): > The import of new software licensed under any licenses other than the BSD license and BSD-Like Licenses (as defined below) requires the prior approval of the FreeBSD Core Team. Requests for import must include: > > A list of features or bug fixes that the new version or patches contain, along with evidence that our users need those features. PRs or references to mailing list discussions are ideal forms of evidence. > > This process should be used for all software imports, not just those that require Core Team review. The mere existence of a new version does not justify an import of software to source or ports. > > A list of FreeBSD branches that may be affected. Expansions of scope require a new request to and approval from the FreeBSD Core Team. > > The Apache License 2.0 is acceptable for use in some cases. The Core Team must approve the import of new Apache License licensed components or the change of license of existing components to the Apache License. > > This license is approved for the following components: > > - LLVM toolchain and (with LLVM Exceptions) runtime components. > > - Subversion and its dependencies [OpenBSD rejects any code with an Apache license](https://www.openbsd.org/policy.html): > The original Apache license was similar to the Berkeley license, but source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD. In particular, if you use code under the Apache 2 license, some of your rights will terminate if you claim in court that the code violates a patent. > > A license can only be considered fully permissive if it allows use by anyone for all the future without giving up any of their rights. If there are conditions that might terminate any rights in the future, or if you have to give up a right that you would otherwise have, even if exercising that right could reasonably be regarded as morally objectionable, the code is not free. > > In addition, the clause about the patent license is problematic because a patent license cannot be granted under Copyright law, but only under contract law, which drags the whole license into the domain of contract law. But while Copyright law is somewhat standardized by international agreements, contract law differs wildly among jurisdictions. So what the license means in different jurisdictions may vary and is hard to predict. As the OpenBSD team points out, a license with a patent clause is problematic. However, some projects choose the Apache license explicitly because of the patent clause, so in such cases having a permissive alternative with a patent clause would be desirable. If a project does not require a patent clause, then the MIT license would be preferrable to the COIL license. Basically, in my view: permissive + no patent clause (MIT, BSD) > permissive + patent clause (COIL?) > restrictive + patent clause (Apache). ---------------------------------------------------------------------- deojfj · 2022-01-28 11:15 > Please explain how the patent clause of Apache 2.0 is a problem. I haven't said that the patent clause of the Apache license was a problem. I have pointed out that there are *other* clauses that make the Apache license restrictive rather than permissive ([section 4, subsections 2 and 4](https://www.apache.org/licenses/LICENSE-2.0.html).) Some projects have switched from MIT to Apache, that is, from permissive to restrictive, exclusively because they wanted this patent clause. Therefore, I'd be sensible to have an alternative license that is permissive with a patent clause, so that these teams can choose that one instead. ---------------------------------------------------------------------- deojfj · 2022-01-28 11:27 I'm not questioning if the Apache license is good or bad. I'm pointing out that [it is not permissive](http://copyfree.org/standard/rejected) like the MIT or BSD licenses are. If permissive is better or worse than restrictive is subjective, and I'm not arguing that (though my personal opinion is that permissive is better.) What I'd like to discuss is which licenses are practical alternatives to Apache, in case a team wants a permissive license with a patent clause. Some projects first used the MIT license but then switched to the Apache license because they required the patent clause, so in these cases such an alternative would be useful. ---------------------------------------------------------------------- deojfj · 2022-01-28 11:32 The problem with the Apache license is that it is restrictive rather than permissive ([section 4, subsections 2 and 4](https://www.apache.org/licenses/LICENSE-2.0.html), which do not allow free modification and derivation), so it is not an equivalent to the MIT license. ---------------------------------------------------------------------- deojfj · 2022-01-28 11:36 > I think that patent grants are manifestly unnecessary for most projects. I agree; however, some teams have switched from MIT (permissive) to Apache (restrictive) because they wanted the patent clause. In such cases, a permissive alternative with a patent clause would be desirable. ---------------------------------------------------------------------- liveoneggs · 2022-01-28 13:28 The restrictions in apache 2 (the patent protections) are good in my opinion. It would be my default for any new projects. The sections you point out (if I am reading them correctly) are about *attribution*, which I also like. The requirements stated are pretty reasonable. I don't know this copyfree.org website but it appears to have issues with most licenses so I'm not sure i can take it seriously. :) ---------------------------------------------------------------------- deojfj · 2022-01-28 14:33 > The restrictions in apache 2 (the patent protections) are good in my opinion. It would be my default for any new projects. > > The sections you point out (if I am reading them correctly) are about attribution, which I also like. The requirements stated are pretty reasonable. Whether you think it is a fine license or not is immaterial. I was pointing out the lack of a permissive alternative. If a team wants a permissive license with a patent grant, which one should they choose? Not the Apache license, because it is not permissive. If you prefer a license with certain restrictions for your projects, that is your choice, and I'm not discussing that here. > I don't know this copyfree.org website but it appears to have issues with most licenses so I'm not sure i can take it seriously. What copyfree.org does is give a definition for "copyfree" or "permissive", and then check which licenses meet that criteria. The fact that it results in few licenses being permissive does not mean that they are being inconsistent; unless you can point out licenses that should be regarded as "copyfree", as per their definition. You may want the word "permissive" to be applied to the licenses you like, but it doesn't seem the best word to describe them. Another organization that [regards the Apache license as restrictive is OpenBSD](https://www.openbsd.org/policy.html): > Apache > > The original Apache license was similar to the Berkeley license, but source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD. In particular, if you use code under the Apache 2 license, some of your rights will terminate if you claim in court that the code violates a patent. > > A license can only be considered fully permissive if it allows use by anyone for all the future without giving up any of their rights. If there are conditions that might terminate any rights in the future, or if you have to give up a right that you would otherwise have, even if exercising that right could reasonably be regarded as morally objectionable, the code is not free. > > In addition, the clause about the patent license is problematic because a patent license cannot be granted under Copyright law, but only under contract law, which drags the whole license into the domain of contract law. But while Copyright law is somewhat standardized by international agreements, contract law differs wildly among jurisdictions. So what the license means in different jurisdictions may vary and is hard to predict. OpenBSD also has an issue with the patent clause (and I do too), but regardless of that, some teams want such a clause, so at least there should be the option to go with a permissive license which includes a free patent grant. ---------------------------------------------------------------------- liveoneggs · 2022-01-28 14:43 copyfree appears to consistently have issue with attribution, which is dumb. "Muh freedoms" to freely take software and not even put in a "thanks to Library X" anywhere in my derived software is some real nonsense, imho. Anyway IANAL but I don't see how you can have a patent protection clause without an attribution clause. How would you know if someone was bound by the patent protection if they didn't have to say "We use software X". You can copy-paste the patent part of the apache license into a 2-clause BSD license and hope for the best. No one is stopping you. You keep pasting these openbsd and freebsd statements like they are meaningful outside of the context of freebsd and openbsd. They are not. ---------------------------------------------------------------------- deojfj · 2022-01-28 15:20 > copyfree appears to consistently have issue with attribution, which is dumb. I don't believe you have read it properly: copyfree doesn't have any issue with mandating attribution. It regards the MIT license as copyfree, and the MIT license requires attribution: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. > You keep pasting these openbsd and freebsd statements like they are meaningful outside of the context of freebsd and openbsd. They are not. OpenBSD and FreeBSD are the most popular operating systems that only allow permissively-licensed code (with the minimum exceptions). And this is r/BSD. Of course it is relevant to cite them here. ---------------------------------------------------------------------- PunishedRaion · 2022-01-28 16:07 The primary concern of projects like OpenBSD is that the patent grants assume US contract law, which is very different from British, German, Chinese etc. We cannot fix that. So I'd say patent grants should be avoided. What holds up in a US court won't hold up elsewhere. Copyright law should be the only way it intersects. LLVM is getting worse. It quickly stopped being a better lighter GCC alternative, but even more now it's harder to build than GCC and offers diminished returns. The license nails it harder. ---------------------------------------------------------------------- phrasal_grenade · 2022-01-28 16:10 Please can you just tell me specifically what you don't like? You've mentioned it but I'm just struggling to imagine a scenario where that stuff poses a real problem. The stuff you quoted seems like a lot of attribution stuff, which is usually harmless and actually desirable to most people (who wants to get NO attribution?). Requiring attribution for stuff seems fair, up to a point (see GFDL for an example of a license with burdensome attribution requirements). I suppose if you have a bunch of Apache projects intermingling then the individual "prominent notices" may turn into hell, but I'm having trouble seeing what is the *problem* specifically. ---------------------------------------------------------------------- phrasal_grenade · 2022-01-28 16:12 I suppose it is technically restrictive, in some sense, but is it *actually* restrictive in a practical way? That's what I'm trying to find out. Is this a philosophical point or a practical one? ---------------------------------------------------------------------- deojfj · 2022-01-28 17:03 Mainly practical. I believe that a shorter, more permissive license allows for greater collaboration long term and less legal overhead in general. ---------------------------------------------------------------------- [deleted] · 2022-02-04 18:52 they are still kicking this can down the road