Call for Input: Allow Draft Patent-Encumbered Proposal

[SamWilsn]

Call for Input

Decision	Do we merge ethereum/EIPs#8919 ?
If Affirmed	Create a new optional section "Patents". Allow patent-encumbered drafts.
If Rejected	No change to policy. Patent-encumbered proposals are rejected.
Method	Rough Consensus
Deadline	October 31, 2024 🎃

Background

In ethereum/EIPs#8454, @0xNixxy disclosed that their proposal was covered by a patent. On today's EIP Office Hours, they asked if we would be willing to merge as a draft before they included a patent waiver.

Checklist

I, the opener of this Call for Input, have completed the following:

• Filled in a descriptive title.
• Filled in the "Decision" field.
• Filled in the "If Affirmed" field.
• Filled in the "If Rejected" field.
• Filled in the "Method" field.
• Filled in the "Deadline" field to be thirty days from creation.
• Added any relevant background information (or removed the section.)
• Published a notice in writing to the usual channels frequented by EIP Editors (likely Discord.)
• Commented on this Call for Input, clearly stating my opinion (or abstention.)

[SamWilsn]

I am opposed.

---

While we recommend implementers wait until review to begin playing with proposals, the truth is that historically people write code based on drafts. I am not a lawyer, but I don't want to put developers at risk of running afoul of a patent simply by implementing an EIP, draft or not. The EIPs repository should not be an IP minefield.

[shemnon]

Yikes.

I don't recall any prior policy on patents, and an argument could be made that "All EIPs must be in the public domain." (EIP-1) does not address patents in any form. The text of CC0 (which EIPs are required to be under) supports that argument as well (section 4 a). But the spirit of the requirement and the vibe of Ethereum alignment would imply that patents should not be enforcable against any of the open specs..

Since this would be new policy ground I personally feel it would be warranted to hold this in an un-merged / PR state and revoke the EIP number. Meanwhile we must create new policies to handle patents in an ethereum aligned way. Not a slam dunk, as there are multiple ways to align it. Then, we re-consider this draft with the new policies and allow the proposers to bring it under compliance and issue a new EIP number, or withdraw it.

There are a large number of things we could do, so it won't be a 2 week process. Here's an incomplete list:

• ban all patented specs
• require patents to be released to the public domain
• require them to be without license fee or royalty
• waive enforcement so long as patent use is restricted to what is required to implement the EIP
• require Apache 2.0 implementations in all relevant languages as Apache has a patent license provision
• Require the patent to be assigned to the EF or some other holding organization

Beyond that, we also may need a patent affirmation section, where authors disclose if there are patents or make the affirmation that none of it is covered by any patents.

Non-voting observer, but I am also opposed

[SamWilsn]

I don't recall any prior policy on patents

There isn't an official one. It has been discussed in the past here, here, here, and here.

Not that it comes up often, but my personal policy has been to reject.

an argument could be made that "All EIPs must be in the public domain." (EIP-1) does not address patents in any form. The text of CC0 (which EIPs are required to be under) supports that argument as well (section 4 a).

This is also my understanding. CC0 explicitly doesn't deal with patents.

But the spirit of the requirement and the vibe of Ethereum alignment would imply that patents should not be enforcable against any of the open specs..

I strongly agree. If you want to publish an EIP, it should be free to read and allow unrestricted implementation.

revoke the EIP number

Why?

• ban all patented specs

I don't think this is a reasonable approach. Companies—for better or for worse—file patents defensively, and I don't think the EIP process has enough weight to change that.

• require patents to be released to the public domain

Again, for the same reason, I don't believe this to be feasible.

• require them to be without license fee or royalty
• waive enforcement so long as patent use is restricted to what is required to implement the EIP

I believe this is the way forward, perhaps with a standard licence/grant/waiver that stakeholders have to sign.

• require Apache 2.0 implementations in all relevant languages as Apache has a patent license provision

Likely not sufficient. Imagine the case where the authors write all the reference implementations, but the patent is held by a third party troll.

• Require the patent to be assigned to the EF or some other holding organization

Interesting, but again, I don't think the EIP process has the weight to force this behaviour.

we also may need a patent affirmation section, where authors disclose if there are patents or make the affirmation that none of it is covered by any patents.

Agreed.

[shemnon]

revoke the EIP number

Why?

If we are concerned about people implementing drafts, I think there is a similar risk to implementing unmerged PRs. Then they could publish code that says "implements EIP-7693". If we don't assign a number when there are a priori issues such as copyright, patent, author designations, or the existence of a specification then implementors cannot point to the EIP by reference number and it is more obvious that existential issues are at play other than the viability of the concept.

Withdrawing the number proir to the draft being published would signal that the issue is serious.

waive enforcement so long as patent use is restricted to what is required to implement the EIP

I believe this is the way forward, perhaps with a standard licence/grant/waiver that stakeholders have to sign.

The patent grants in the GPL 3.0 (section 11) or Apache 2.0 license (section 3) could be a guide (a grant plus protections) but that's a lot to put into each EIP. Perhaps grant by reference like the CC0 license is handled. But however it lands the advice of lawyers should be involved (IANAL).

[SamWilsn]

revoke the EIP number

Why?

If we are concerned about people implementing drafts, I think there is a similar risk to implementing unmerged PRs.

I disagree. It's notably harder to find a pull request by EIP number than it is to navigate to eips.ethereum.org or browsing the master branch of the repository. There's also the clear implication that because the pull request hasn't been merged, nothing is official.

One day my goal is to get to a system where the EIP number is only assigned during the merge commit, but that's a little off-topic for this discussion.

Withdrawing the number proir to the draft being published would signal that the issue is serious.

Withdrawing the number would amount to closing the PR. The number is burned now.

[SamWilsn]

Oh, and https://contributoragreements.org/ has some good legalese about patents.

[shemnon]

Withdrawing the number proir to the draft being published would signal that the issue is serious.

Withdrawing the number would amount to closing the PR. The number is burned now.

My intent would be to use the same PR, and then if there is a new policy and they conform to it to re-issue a new number when it's clear. But I would say your opinion on this is stronger than mine.

[shemnon]

Oh, and https://contributoragreements.org/ has some good legalese about patents.

I don't like the bias towards FSF licenses. I'm on the OSI side of the argument on what real freedom in licensing means. That could be customized in the text, however.

What I'm liking less than that is that it appears to need a quasi-formal signature. I was hoping to something that could be slip-streamed into the commit or affirmed like the CC0 license is affirmed, in-line in the text. The click-through to me implies each author would need to counter-sign or click-through. May be a necessary step, and possibly could be done CLA style where it is blanket to all the contributions.

[abcoathup]

I am opposed. (I don't have a vote)
Patent-encumbered proposals should be rejected.

[g11tech]

opposed

I think CC0 license is good enough, any search for patent infringement complicates the process in the least.

[SamWilsn]

@g11tech to be clear, ethereum/EIPs#8454 has a patent disclosure in it, without a patent license. That proposal's author is who prompted this CFI.

[g11tech]

@g11tech to be clear, ethereum/EIPs#8454 has a patent disclosure in it, without a patent license. That proposal's author is who prompted this CFI.

understood, still would vote no, all rights need to be waived to contribute to the repo is my opinion

[xinbenlv]

I oppose too.

There are a few reasons.

1. adding Patent grant is a restriction, making it hard (sometimes infeasble) for certain authors to continue to contribute to this repo
2. sometimes an EIP/ERC author doesn't own all the patents or aren't patent owners at all, even if they grant patent, it's not useful enough.

[SamWilsn]

The consensus seems to be to not merge.

[0xNixxy]

The consensus seems to be to not merge.

Thank you @SamWilsn for your help.