4 ms·
Hmm. As I understand, the primary purpose here is to have a permissive license with a patent grant. Some problems I see: 1. If you're actually have patent clai
by rbehrends 9y ago
Hmm. As I understand, the primary purpose here is to have a permissive license with a patent grant. Some problems I see:
1. If you're actually have patent claims to your name (a minority of people, while every author is ipso facto a copyright holder), you will probably want to use an expressly vetted, narrowly drafted patent grant.
2. The way the license is worded, it may ask you to do things that you can't do, e.g. if you have the rights to use a patent claim, but not to (sub)license it. (Contrast this with how the Apache license words its patent grant.)
3. It's not clear how broad the patent grant is. It's not inconceivable to read it so that once somebody uses the software, they get an unlimited right to your patent claims, even outside that specific piece of software.
4. You may be waiving your right to use software patents for defensive purposes, too.
5. There's lots of fuzziness in the wording. What are the "usage rights that the author hold on [the software]"? US patent law grants rights to exclude others from making, using, selling, or importing the patented invention; it does not grant a right to exploit the patented invention. (Unlike copyright, which creates an exclusive right for authors to use and distribute the work.)
6. How compatible is the license with other licenses with patent grants?
- jashkenas 9y agoThanks for the list of concerns, it's very much appreciated. If you care enough to open any of them up as an issue on Github, it would be great to discuss them there. But for now, in short: 1. Yes. If you actually own a patent portfolio that you value highly, you may want to use a custom, narrowly worded grant. This license might not be for you. This license is for the 50+% of open source projects currently using MIT. 2. I don't quite follow the problem you're outlining here. The Apache license tries to scope its patent license only to actions that "necessarily infringe" on the Work and the Contributions to it. I'm not sure how you mean for (sub)licensing to fit in. 3. The patent grant is intentionally simpler and broader than, say, Apache. There's no clawback provision, and in short, it gives you: "usage rights to any patents the authors may hold on the software." It doesn't give you the right to use the authors' unrelated patents. The balance here is struck to give more protection and confidence to the user of the open source, not to rigidly protect the potential software patent holder. I think that's the right way to lean. 4. This rhetoric around offensive and defensive uses of software patents is what's keeping Facebook in such hot water with GraphQL and React right now. The only way to use a software patent against someone is offensively — it's a MAD-style threat of legal action. If you want mutually assured patent annihilation, then don't use LIL to release open-source software that uses your patents. It's not a great mix. 5. In US patent law, you can sell your patent, prevent other people from making use of it, or license usage rights to it. The latter is what we're doing in this case. (https://www.legalzoom.com/articles/selling-your-patent-what-you-need-to-know https://www.legalzoom.com/articles/selling-your-patent-what-...) 6. That is a great question. And it would be good to eventually have a wiki page, detailing compatibility with various alternative popular licenses. As a permissive license (more permissive than Apache), my best guess is that it would be generally compatible — but we should look into it further.
- rbehrends 9y agoSome clarifications: 1. My larger point is that this license simply is not going to interest a lot of people because they don't have patents to begin with. Only a minority of contributors will have patent claims, and almost all of them will be commercial contributors. They will simply not be interested in such a license and not contribute to a project using it; for people who don't have patents, the additional patent grant does not make a difference, other than that they're possibly scaring away contributors who do have patents. 2. The point here is that the license may require you to grant rights that you can't grant, ergo you can't contribute work under the license. The license requires you to grant any rights that you hold, but you may not have the right to grant such a sublicense. The Apache license, in contrast, only requires you to grant a license for patent claims that you can actually license. 3. My point here is that the patent grant may be uncomfortably broad especially for commercial contributors in that they give up rights that they're not willing to give up. 4. This is quite different from the Facebook situation. It's one thing to allow others to use your patents; patent holders may be much more reluctant to unilaterally disarm defensively, too. In order to get them to accept such a broad patent grant, you have to convince them that this in their best interest, too. That you can convince people without patents to their name to use the license is irrelevant, as it does not matter whether they use a license with or without a patent grant. If I were a patent holder, why would I give up my defensive rights against third parties along with a patent grant for using the software? How would that serve my interests? 5. So, what are the usage rights if you believe that this is a well-defined legal term? Can you be more specific? How are they related to patent claims? Have you researched whether this would include sublicensing rights and whether sublicensing scenarios need to be considered separately?
- jashkenas 9y agoLet's keep digging in! 1. I feel entirely the opposite way about the appeal of an MIT-style license that includes a patent grant. It's not primarily about making the author feel comfortable — as the author probably doesn't have patents, and doesn't intend to. It's about giving the user of the software confidence. Because the user has no idea what patents the author may or may not hold. At this moment, this is playing out to dramatic effect in Facebook's open source projects — you can see an example here: https://github.com/facebook/graphql/issues/351 https://github.com/facebook/graphql/issues/351 Being able to give users of my software fuller confidence under the Lil License also makes me more interested in using it as an author. It's a virtuous cycle. 2. I'm afraid I still don't quite see the issue you're describing here. If I'm following correctly, the hypothetical case is a contributor who writes a bit of code that exercises a patent that she has a license to, but not permission to sublicense, and then wants to submit that code to an LIL-licensed project. If she's not allowed to sublicense, then she can't contribute that code. She wouldn't be able to contribute it to an Apache project either. 3. It might be. I think that its width is more suitable for most open source projects than the narrower Apache and MPL, but that's something that would make for a good discussion. I'll open a ticket. 4. Again, we're talking past each other a bit. This isn't really trying to appeal to the Facebooks of the world — it's trying to appeal to us regular folk. That I might be able to convince people without patents to use the license is not irrelevant, it's exactly the point. Those people are the target audience. From a user's point of view, the patent grant is still important — because I never know for certain when an author may or may not hold a patent on the code. 5. If I grant you usage rights to a patent, I grant you a license to make, use, sell, import and otherwise transfer implementations of the invention described in that patent. If you think we need to spell out all of those words explicitly, perhaps throwing in "have made" and "offer to sell" as well, feel free to open a ticket and we'll talk about it further.