Reference implementations aren't linted prior checkin or when marked as final. Different EIP's reference implementations aren't consistent with each other

[TimDaub]

• e.g. https://github.com/ethereum/EIPs/blob/master/assets/eip-4907/contracts/ERC4907.sol has pretty wild formatting inconsistencies in itself
• e.g. has // SPDX-License-Identifier: MIT albeit it needing to have CC0-1.0 or not? https://github.com/ethereum/EIPs/blob/master/assets/eip-4400/contracts/ERC721Consumable.sol
• the two have inconsistencies with regards to their formatting e.g. but they're both marked as "final"

[Pandapip1]

I definitely agree that some linting would be good. However, right now, EIP authors are free to use whatever formatting they please.

For the second point, you are absolutely correct. I'm pretty sure was the one who merged that PR finalizing that EIP, but since these EIPs tend to be quite large when the reference implementations are in the assets folder, these often slip through the cracks, especially when they are not modified in the PR. I might actually submit a feature request on the EIP bot repo to block anything with an MIT SPDX identifier.

EDIT: Normal changes may be occasionally made to final EIPs, for reasons such as formatting, typos, or incorrect licenses. In fact, I just submitted a few PRs to fix all of the non-cc0 licenses.

[Pandapip1]

Here are my prefered linters. These are just my opinions:

• https://github.com/standard/semistandard with prettier for JavaScript
• https://github.com/prettier-solidity/prettier-plugin-solidity for Solidity
• I can probably get semistandard to work for TypeScript (I've done it before with eslint instead of prettier, although it was a pain)

[SamWilsn]

As far as I am aware, there is no rule that assets must be CC0, only the EIP itself. Personally, I think we should permit any licenses that allow for mostly unencumbered redistribution (so Apache, MIT, Unlicense, BSL, etc.)

[Pandapip1]

Personally, I think we should permit any licenses that allow for mostly unencumbered redistribution (so Apache, MIT, Unlicense, BSL, etc.)

I disagree. If I were developing, say, something like openzeppelin contracts, I would probably end up using an interface provided in the specification section, if there is such an interface, in my library. If this weren't always CC0, I would have to worry about a lot of different licenses, and honestly, having to keep a copy of the MIT license for every specification interface or reference implementation is just bloat if one can simply look up the ERC and see the authors.

There's also the problem of what is defined as "mostly unencumbered," which can be circumvented by requiring that all assets be licensed under CC0-1.0. So unless there's a particularly important reason why other licenses should be allowed, I would prefer if CC0 was required, to remove the hassle of checking and abiding by various licenses, and to avoid ambiguity.

[SamWilsn]

Ah, yes, sorry. Any portion of the eip-X.md file MUST be CC0, including code blocks. I'd suspect that most EIPs directly include their interfaces in that file.

There's also the problem of what is defined as "mostly unencumbered,"

I actually think this is the easiest part. This is the list of licenses I would propose off the top of my head: Apache-2.0, BSD-3-Clause, BSD-2-Clause, MIT, CC0-1.0, CC-BY-1.0, CC-BY-2.0, CC-BY-2.5, CC-BY-3.0, CC-BY-4.0, ISC, Unlicense, and whatever the IETF RFC license is called. Adding any other licenses would be a change to EIP-1, and would be open for debate.

reason why other licenses should be allowed

Reference implementations are... more complex than interfaces. I guess my arguments for allowing less permissive licenses are basically:

• Often the implementation is started as part of a product before beginning the EIP process, and therefore had a default license set. Changing that license might require getting written permission from several contributors, and that whole process might be skipped.
• Getting some sample code you can crib from is pretty dang useful. Why make it harder than necessary for EIP authors to get that code in?
• We should be able to rebuild all of Ethereum after the world ends with only this repository. Unnecessarily limiting what can be included here makes that goal harder to achieve.
• Some assets aren't code, like the semver document I recently included, or the RFCs you want to include in https://github.com/ethereum/EIPs/issues/5223, and also aren't public domain. I believe we should be able to include those documents (or similar ones in the future.)

[Pandapip1]

Okay, I would like to revise my opinion: Asset files should be CC0 unless there is a good reason for them not to be (borrowing code from another project, etc...)

[LanceSnow]

Thanks for the reminder, we will finish the modification as soon as possible: MIT > CC0

[Pandapip1]

Thanks for the reminder, we will finish the modification as soon as possible: MIT > CC0

Actually, CC0 should be preferred over MIT

[MicahZoltu]

I'm pretty strongly in favor of requiring CC0. While I can appreciate the points made above by @SamWilsn, they don't outweigh the points made by @Pandapip1 for me personally. Getting into the licensing game is a huge can of worms that we can avoid by just saying everything must be CC0.

Pragmatically, I suspect that the vast majority of EIP authors who have pre-existing code they want to include likely can/will just change MIT to CC0 and be done with it. For the few cases where someone can't do that for some reason, one should be able to implement from scratch via the specification. If the author is unable to write a reference implementation from the specification that is an indicator that the specification is too complicated.

Also, requiring CC0 helps keep the reference implementations pretty slim, as people can't just copy/paste huge swaths of OpenZeppelin libraries into the assets directory (which I generally don't think is what people should be doing).

[Pandapip1]

I would not require CC0. I would state that files in the assets folder should be CC0, and that they must be CC0 unless an EIP editor provides an exception.

[poojaranjan]

@TimDaub As suggested in the EIPIP meeting, split the issue to collect comments separately and we can bring it on the next EIPIP to continue discussing

1. Licensing issue
2. Linting code

[poojaranjan]

Based on above suggestion form the EIPIP meeting, closing this issue.