OpenZeppelin/openzeppelin-labs

Define zos license

Opened this issue · 4 comments

facuspagnuolo commented

MIT

IMO it is the less restrictive license. It gives the rights to anyone to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the software. It just requires that the given license is included in all the copies of the code.

In addition, it clarifies the code does not provide warranty of any kind, and denotes that the authors are not responsible for any problem the code may cause.

GPL 3.0

This license is more extensive and descriptive. It gives the rights to anyone to use, copy and modify the software. However, it does not allow sublicensing. i.e. the main difference would be that you can modify the code without including said license if you don't distribute it. It also clearly explains that there is no warranty for the software.

Apache 2.0

Has a pretty similar philosophy to the MIT. It gives the rights to anyone to reproduce, copy, modify, publish, distribute, sublicense, and distribute and/or sell copies of the software. It states the code does not provide warranty of any kind too

Some differences with the MIT license are that:

  • it requires any modified file to carry a note stating those changes.
  • it does not grant permission to use the trademarks or product names of the Licensor.
  • it provides an express grant of patent rights from contributors to users.

References

@ElOpio would you mind sharing your thoughts/ideas?

frangio commented

Thanks for the summary!

There is a typo here which makes the sentence a bit difficult to understand:

you can modified the code without including said license

The distinction between GPL and LGPL is also relevant.

come-maiz commented

From what I've seen so far, most solidity projects use MIT (expat license is a better name). But I think that's because most of the solidity code out there are libraries that have to be mixed with other code to be useful. We are just starting to see complex platforms like Zeppelin OS, with services that can be consumed by stand-alone projects. IMO, the expat license is not good enough for this.

The FSF recommends to use Apache 2 instead of expat, because of the patents provision, which is something very important for us to take into account. I'm ok with Apache 2.

Now about GPL, take a look at the aragon case. They chose GPL. Somebody copied a part of the code and released it under MIT: https://twitter.com/izqui9/status/977858436988891136
If we choose MIT/expat/Apache2, we can't copy GPL code. If we choose GPL, we force everybody who copies our code to release under GPL and then we can copy the improvements.

And as @frangio mentions, the GPL/LGPL distinction is very interesting here. We could license the core as GPL, and the libraries as LGPL. Or everything LGPL. But, I'm not so sure how to apply the terms static and dynamic linking, loadable modules and system libraries to blockchain contracts.
See here: https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License#Differences_from_the_GPL
here: https://www.gnu.org/licenses/why-not-lgpl.html
here: http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html
and here: https://www.gnu.org/licenses/gpl-faq.en.html#SystemLibraryException

If we choose MIT/expat/Apache2, we put little restrictions to derivatives so those terms are not so important.

I personally prefer GPL always, because to me, every piece of code released that way helps the revolution. This is a harder fight, it's more complex to enforce, we will lose potential contributors that don't like or can't release their code under GPL, and we will need to solve in a very clear way the concepts of static, dynamic, loadable and system. It could be very beneficial later on the game, but we need to discuss if it will help or complicate our immediate goals.

If we add a nice CLA like the one from FSFE, the specific license we choose is less of a concern, because we will be able to relicense as long as the new license is free too.

But two things. First, I'm very new to this community. There are some communities out there that are averse to GPL and CLAs. We can invite the OpenZeppelin community to voice their opinions here.
Second, I'm not a lawyer. I recommend to involve our legal advisors early. They can tell us how to best protect our project depending on the license we choose.

maeste commented

First of all, based on experience in open source, I would strongly recommend involving your lawyer/legal advisory on this. In a nutshell LGPL is the most business-friendly one, largely used by companies working w/ open source products/library integrated in a commercial product. If you don't have completely clear your business model (or if you would at least stay open to different business model) You should select the license easier adapting to different business model (read LGPL).
Just my 2C

  • 👍1
maraoz commented

Thanks everyone for their comments and the info you shared.

We've decided to move forward with MIT License for the MVP release (https://github.com/zeppelinos/labs/milestone/1), given:

The plan is to review this discussion for the next release (v0.2), and to involve a lawer, as @maeste suggested.

  • 👍1