Licences for Assets / Reference Implementations in EIPs

Currently there is no consistent policy for licenses allowed in the EIPs repository (aside from the EIP itself.) This is especially relevant for reference implementations.

Policy Options

There are three camps:

Please be aware that I am biased, so if I misrepresented your views below, call me out on it.

All assets must be CC0-1.0

This view is held by @Pandapip1.

Simple, clearly unambiguous. Most permissive for implementers. Most restrictive for authors.

Allow non-copyleft open source assets

This is my view.

Assets may be any license that doesn’t impose significant restrictions on implementations. So this would allow MIT, Apache-2.0, and likely some others. It would, however, deny GPL-3.0 and BUSL-1.1.

More ambiguous (we’d need to maintain a list of approved licenses), but balances author vs. implementer interests.

Unrestricted Reference Implemenations

This view is held by @xinbenlv and @gcolvin.

Allow any license we can legally distribute, and allow linking to reference implementations we cannot distribute.

Also extremely unambiguous, provides authors the most flexibility, but doesn’t preserve our immutability/availability goals and can potentially create copyright traps.

Related Reading

3 Likes

Thank you for summarizing it, @SamWilsn !

My stance is generally: “we should make it easy for ERC authors to share reference implementations for educational purpose”.

On that basis, for the question I am happy with either of the following:

  1. Allow check-in a broad range of Open Source Licenses for RefImp code into asset folder
  2. Allow link to external reference implementations.

Disallowing both will make it super hard to share reference implementation and undermine the open standardization effort.

How broad is broad? Would you permit a license that allows viewing the reference implementation, but disallowed any derivative work?

If so, what is the point of such a reference implementation?

While CC0 is optimal for the EIP, I feel it’s too restrictive for reference implementations.

I’d consider especially CC0 4.a stating “No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document.”

IMHO (not a lawyer obviously) “No […] patent rights held by Affirmer are […] licensed” implies that I cannot be 100% sure when I use a reference implementation licensed under CC0, whether I will applicable to license fees under certain circumstances.

This was the prime reason why we decided to use MIT license (also used throughout OpenZeppelin) for the Reference Implementation in our ERC-6956. We wanted people to be able to freely use it, without having any second thoughts. Especially since for our edge-case there is a broad application range with physical products and smartphones involved etc. and as soon as things get beyond digital-only, you enter a patent landscape that’s hard to comprehend.

We discussed this at some length in

Thanks, although I believe I have another angle, which has not been discussed so far.

As responded in much more detail to your comment in PR 6956, we have a situation, where we do own patents that have at least similarities to the EIP and I want to be very clear that the EIP and reference implementation can be used freely and unrestricted by anyone. Yet, I do no want to grant a free, unlimited and world-wide license on any of our patents, as they cover much more than just what’s in the EIP and reference impl.

For the EIP I think CC0 still works, but I would argue that if we were to enforce CC0 for reference implementations and not allow any amendments, I would in my case not have the legal framework to ensure people it is safe to use our reference implementation here. That’s why the reference implementation must allow MIT, BSD or similar imo.

I don’t think the EIPs repository has the authority to stop you from additionally granting patent licenses :rofl: If you wanted to dual license under CC0-1.0 and/or MIT, of course that’d be fine. I think @Pandapip1 just wants one of the options to be CC0-1.0 (though I may be misrepresenting his position.)

Well, that’s clear but I think I didn’t express myself clear enough :wink: .

I meant; I have a patent US1234, which is partly similar to the EIP. But the EIPs content is e.g. just one aspect, not the complete content of the patent. So I need to find a legal way, to license EIP + Reference Impl freely and unrestricted. But at the same time, it is not possible for me to say “With this EIP I grant you a license for US1234” - because the US1234 has other aspects beyond the EIP, which I do not need or want to waive.

Dual licensing works imo! I just thought the goal was to have CC0 mandated as in the verbatim Waiver in the EIP. That would’ve been an issue - but seems all is fine then. Thanks for the clarification

Right, that makes sense.

Yep, that’s perfectly understandable. The requirements, today, of the EIPs repository are roughly:

  • Text of the EIP itself, including any inline code, MUST be available under CC0-1.0.
  • Files under the ../assets/eip-xxxx/ directory SHOULD be CC0-1.0, but MAY be a non-copyleft OSI approved license.