Header with GNU/GPL license text

[terencechain]

Opening this issue to discuss the necessity of putting a license notice in our header. The license notice makes the header of the file cluttered, and we should have a sweeping license in the root of the project. Let's evaluate our options to avoid possible legal complications for the future

[rauljordan]

I would recommend we hold off on this. We have a license in the top-level README at the bottom of the file.

[prestonvanloon]

If we do decide to do this, there are many tools to easily add the preamble.

[rauljordan]

It makes the most sense that we will be sticking to the go-ethereum license for our sharding implementation. Closing this issue unless anyone has important concerns at the moment.

[prestonvanloon]

That isn't the question. The question is: do we need to add the license preamble to our new files?

[prestonvanloon]

Raul will confirm with go-ethereum team

[rauljordan]

Confirmed by Peter from the geth team. We will use LGPL for lib code and GPL for binaries. Closing.

[prestonvanloon]

We shouldn't close this until it is resolved.
Your comment confirms that we need preambles before merging upstream so we'll need it eventually.

[rauljordan]

We will no longer be a fork of geth. Closing.

[prestonvanloon]

This isn't a geth dependency but a licensing question. If we are going to use GNU/GPL then we may need this preamble

[prestonvanloon]

I think that we'll choose a more permissive license and the preamble may not be necessary. Not sure how to reach a definitive answer though.

[shazow]

Can anyone provide clarity about why the project didn't adopt a more permissive license?

Seems to be the right thing to do, especially in the spirit of the philosophy of subtraction.

[prestonvanloon]

@shazow Sure, happy to explain. We want to ensure this software remains open and free to use. Take the linux kernel as an example. Imagine if they didn't choose GPL and some company decided to make and withhold improvements to the open source software. This hypothetical company may try to profit from this in some way, perhaps by selling closed source software based on the Linux kernel that everyone should benefit from for free.

I'm glad you linked to the Ethereum foundation as the go-ethereum project was an inspiration for choosing the license we did. I would argue that this license is better for the community. If you want to fork this project, modify it, and use the modified code privately then you may do so with the permissions granted with GPLv3. However, you may not distributed modified closed source software with this license.

If there is a compelling reason that someone wishes to distribute copies of this software (for free or for charge) without ensuring the same open source freedoms to their recipients then we can revisit this or consider explicit permission for said entity.

[shazow]

Thanks for the quick followup!

Some context: I've been maintaining popular open source projects since 2008, with over 60M downloads/mo. I'm very familiar with the mechanics of GPL and the effects it has on open source efforts, but my experience does not match this. Are you open to being convinced otherwise? Would it be better to take this conversation to another medium?

Quick summary:

• There were many discussions and desire to change go-ethereum's license to a more permissive license, but it's increasingly difficult to do after there is a non-trivial number of contributors and copyright holders.
• Linux kernel is a bad example because everything links against it dynamically to bypass GPL. Projects like Google Fuchsia were started specifically because of the licensing issue. Many more permissive kernels also exist and are successful, like BSD and popular derivatives (macOS, iOS).
• Many companies and marketplaces outright disallow use of GPL due to logistical complexities with meeting the terms (e.g. GPL dependencies violate the iOS App Store terms of service).
• Even in the cryptocurrency space, GPL is not the norm. The original Bitcoin codebase itself was released under MIT. Many other projects use permissive licenses too, work your way down the top marketcap list and try to find a reference codebase that does not use a permissive license: Bitcoin, Ripple/Stellar, BCH/LTC/ZEC/other derivatives, EOS, Cosmos/Tendermint, Monero. Ethereum is the exception.
• Even in the Ethereum cryptocurrency space, GPL is not the norm. Many other implementations use more permissive licenses: Trinity, Artemis, Lighthouse, etc.

I don't feel that the argument that Ethereum is successful because some of the implementations are GPL is compelling, given that Ethereum largely exists because of Bitcoin which is MIT.

My more immediate concern: I'm working with Infura and we've built a lot of private infrastructure that is statically linked in Go. Part of my role is open sourcing pieces of this, but right now it's a big monolith with many thousands of engineering hours behind it and converting the entire thing to GPL is not an option while the option to redistribute is important. Managing micro-dependencies as dynamically linked libraries is also more inconvenience than it's worth. In effect, we're duplicating effort of doing clean-room rewrites of bits and pieces of go-ethereum just to avoid touching GPL. This is an unfortunate circumstance, and I'm hoping we can avoid this with future projects like prysm.

Worth noting that I've been personally involved in several "duplication of effort" rewrites just to avoid touching GPL in my career. A lot of the rewrites end up being released as MIT anyway, for others to avoid duplicating the duplication, but I wish we didn't have to do this in the first place.

Finally, regarding the subtraction principle, the premise of being protective from others trying to profit from our work reads very strongly as "Unhappy when others create value" and against "Matter less." It reads as an attempt to recapture opportunities into the origin codebase, to pull changes back in-house. Clearly this is a subjective sub-topic that we're only starting to explore.

[prestonvanloon]

THanks for the feedback @shazow. I won't argue with you that MIT and other more permissive license allow more freedoms with regards to distributing closed source projects when using projects with modification.

Finally, regarding the subtraction principle, the premise of being protective from others trying to profit from our work reads very strongly as "Unhappy when others create value" and against "Matter less."

I can appreciate your perspective about this. To be clear, our intention is not to prevent anyone from using the project for profit. The GPL license allows anyone to freely use the project as they see fit without publishing the modified closed source code as long as they aren't redistributing the software. This satisfies the majority of use cases that I can imagine. The iOS use case is an interesting exception.

We are not lawyers and licensing reaches outside of our knowledge domain. I won't say we can't be convinced that GPL is harmful for Prysm, Ethereum, and the community. For this reason, we have a CLA in place, since the beginning, which should allow us to change license at a later date (I'm not a lawyer so this might not be correct).