Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIPs should preemptively add a CLA #5662

Closed
kdenhartog opened this issue Sep 15, 2022 · 11 comments
Closed

EIPs should preemptively add a CLA #5662

kdenhartog opened this issue Sep 15, 2022 · 11 comments
Labels
e-consensus Waiting on editor consensus enhancement

Comments

@kdenhartog
Copy link
Contributor

Proposed Change

I've seen these types of issues arise when trying to build out technical specifications in the DID and VC space. Generally speaking, most people here seem to be operating in good faith, but there's always some point where IPR is brought up because companies have to appease their lawyers as they grow.

I'd suggest that this repo adopt some sort of basic IPR rules preemptively to avoid the mess that arises in the case that patents and royalties come into play.

They're a few different methods on how to approach this which will directly affect the ability of contributors to assist in the process of developing an EIP and the governance necessary to maintain and enforce the rules. This is the unfortunate reality of how these things go. Here's some places to look at and consider modeling after:

  1. IETF IPR as defined by RFC8179
  2. W3C approach to IPR which is outlined here in their patent policy document. Note this typically requires that legal agreements need to be signed by members/participants/orgs etc
  3. OASIS IPR - I don't have a link to this one, but I know this one sparked some controversy in the past because they allowed for royalties from my understanding (it's before my time).
  4. GSM IPR - again don't have links to this here, but I've heard that there's some sort of IPR rules that lead to setting specific royalty amounts per patent or relevance of patent. Let's not go this way, but I'm highlighting it to further define the landscape of IPR.

In any case, I think it's useful for us to start this topic now so that we've got something sorted before people start getting dragged into court or depositions to settle patent cases based on EIPs. My personal preference would be go the IETF or W3C route. I'm curious where others fall on this.

@erkinalp
Copy link

Royalties per implementation cannot work in this case as there are many implementations distributed as-is and royalty-free.

@Pandapip1
Copy link
Member

Pandapip1 commented Sep 16, 2022

All EIP reference implementations, test cases, and specifications must be CC0. There was a discussion about having a CLA (contributor license agreement, which can also waive patent rights), which I am in favor of, but it was eventually abandoned.

@Pandapip1 Pandapip1 changed the title EIPs should adopt some form of intellectual property rights (IPR) rules preemptively EIPs should preemptively add a CLA Sep 16, 2022
@Pandapip1 Pandapip1 added the e-consensus Waiting on editor consensus label Sep 19, 2022
@Pandapip1
Copy link
Member

I've tentatively re-created this CLA: https://gist.github.com/Pandapip1/c0a80fc2dcade3da8e48747d8691afb2

CC @SamWilsn @gcolvin @axic @lightclient - Any objections?

@kdenhartog
Copy link
Contributor Author

Royalties per implementation cannot work in this case as there are many implementations distributed as-is and royalty-free.

That doesn't preclude someone from doing this in the future. E.g. defining a standard ERC like ERC-721, patenting it, and then charging royalties to anyone who deploys the contract or a similar contract.

After talking with people on our team, the main concern here is likely to be patenting and royalties. While we don't expect that the CLA here is going to perfectly solve any sort of legal dispute here (really it's just going to kick the can down the road is what I've been told) having some sort of baseline agreement to protect our wallet and other EIP related specs that we implement to not come back and lead to royalties we need.

At the very least requiring contributors to declare patent conflicts like they do in IETF would be useful here so that we can properly assess the risks of implementing would be a bare minimum. Requiring the contributions to also grant royalty free licensing and all the other stuff would be nice, but there's plenty of loopholes that can be taken here. E.g. an employee could contribute something they're developing on behalf of their employer and not have the authority to share that IP or agree to make it RF. These cases, aren't things I think that we can settle via this agreement outright, but are things that we can at least be calling out.

More than anything this should be used as a deterrent for low hanging malicious behavior. The rest is going to have to be settled in court just like it would have to be if there wasn't one at all. At least with a CLA though there's a leg to stand on for implementers if they start getting patent trolled.

@xinbenlv
Copy link
Contributor

xinbenlv commented Sep 20, 2022

@kdenhartog thanks for the comment.
We've previously discuss this and didn't converge into a consensus. We effectively only enforce a CC0 declaration in EIPs but no others.

@xinbenlv
Copy link
Contributor

I've tentatively re-created this CLA: https://gist.github.com/Pandapip1/c0a80fc2dcade3da8e48747d8691afb2

CC @SamWilsn @gcolvin @axic @lightclient - Any objections?

@Pandapip1 , per previously discussion, I personally object to having a CLA in EIPs repo.

@kdenhartog
Copy link
Contributor Author

Do you have a thread on that discussion so I can read up on it? At least for context on how the decision was arrived at. I suspect this isn't likely going to change at this point, but having an understanding would be helpful.

@Pandapip1
Copy link
Member

There's #1840, and there was some discussion on the cat herders discord. I'll find it later.

@xinbenlv
Copy link
Contributor

xinbenlv commented Sep 21, 2022

My personal stance is weakly lean against having a official CLA, but in favor of allowing, but not mandanting authors to include a patent waiver.

Here are rationale:

  1. EIP Authors propose a Ethereum "Improvement Proposal", with intention to have this proposal adopted by other client implementors. It's to the benefit of an Author to make it as easy as possible for EIP to be adopted. It's unhelpful for them if their are sincere proposing a EIP to be adopted.
  2. Regardless of whether EIP Authors explicitly grant patent, client implementers still might stumble upon (infringes) a patent of someone else if patent is not being aware or owned by EIP Author. Client implementers have to make their own research and judgement on how they will implement the EIPs.
  3. As a venue for preserving a repository of proposals, it's to the EIP Repository's best interest to make it as easy as possible for authors of different industry background and context to contribute.

With these argument, I'd humbly suggest we

  1. Not having a CLA at least for now
  2. Provide an optional waiver of patent for convenience but don't make waiving patent a requirement for an EIP.

The consensus of the call today is to keep this issue open for now.

@SamWilsn
Copy link
Contributor

@gcolvin brought up the point that CC0 explicitly doesn't grant patents and that is the behaviour he'd like to see. If an author holds a patent and wants to licence it, it's perfectly valid. EIPs are purely standards. Regardless of whether EIP authors grant patents, implementers are still responsible for not infringing patents, so an author granting patents doesn't fix anything.


I disagree with that entirely. Standards in the EIP repository should be free to implement and share, and legally unencumbered. If an author comes back after a year and starts suing people for implementing their algorithm, I would say we've failed.

@kdenhartog
Copy link
Contributor Author

After talking with our team more on this, I don't think the effort to achieve consensus on this will be worth it. I'm going to go ahead and close this and we can all hope no issue comes of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
e-consensus Waiting on editor consensus enhancement
Projects
None yet
Development

No branches or pull requests

5 participants