Comment by rbehrends | Hacker News Reader

Comment by rbehrends | Hacker News Reader

Parent Full thread

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?

Thanks 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-...)

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.

Some 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?

Let'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

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.

1. This wouldn't have changed anything about the GraphQL situation. Unlike with copyrights, getting a patent is expensive. Companies don't do that for fun and they don't give their just acquired patent claims away for free. They may grant a limited license (narrowly scoped to include only the specific software or excluding use for defensive purposes), but there's no point in first paying for a patent and then giving it away for free.

2. Correct, she's barred from contributing, and if she accidentally does so, anyway, she may get into further trouble, because she's violating one license or the other. And no, Apache does not have the problem, because that patent grant is specifically limited to patent claims that contributors have the right to license. Same goes for the OSI BSD+Patent license (not to be confused with Facebook's BSD+Patents license, which has a similar name, but a totally different purpose).

4. And a license will not protect you from that, because unlike with copyright, innocent infringement does not preclude liability. See the folks that are building React variants to avoid the Facebook license: they risk infringing upon patent claims, anyway (as long as they use similar algorithms), and won't have a patent grant to protect them. They can grant any patent-related rights they want, and it'll result in zilch protection. Granting rights only matters if you can actually grant the rights. Without being the actual patent holder, you cannot indemnify anyone.

5. "Opening tickets" is fruitless, because you still end up with a crayon license. What you should do is consult actual lawyers specialized in the field and let them draft a license to your specification.

[1] https://opensource.org/licenses/BSDplusPatent

Reply on news.ycombinator.com