Consider switching back to MIT license

[cburgdorf]

What is wrong?

I believe the only reason why we migrated away from the MIT license was because the parser incorporated code from a project (nom) that isn't MIT licensed. With the parser being rewritten we could consider switching back.

How can it be fixed

Discuss & change.

[sbillig]

The de facto standard in rustland is to dual license under Apache 2 and MIT, Apache preferred for patent troll protections, the latter for GPLv2 compatibility. Seems like we should do the same, unless there's a compelling reason not to.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.
Why?
The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache

• Relicense under dual MIT/Apache-2.0 sfackler/rust-postgres-macros#19

[cburgdorf]

Alright, seems to be in line with what @davesque wrote here. Happy to stick to Apache 2 then.

[g-r-a-n-t]

Reopening this to discuss GPL3.

[cburgdorf]

Reopening this to discuss GPL3.

Meh..that would be like the opposite of MIT haha. Do you think we are currently in breach of the Solidity license? I guess we are because solc-rust is GPLv3.

If that's the case then I suggest we raise the issue internally in the EF and find ways to mitigate it. My naive thinking would be that Solidity could grant us exceptional rights or basically just say "we won't go against you" but what I don't know is if that would prevent an angry external observer (someone totally unrelated to the Solidity team) to still turn the license issue against us.

But I assume the EF legal team can help us figure that out.

[sbillig]

@g-r-a-n-t and I discussed this a bit on discord. Everything that depends on yultsur/solc-rust/solc (directly or transitively) has to be licensed GPL3.

I suggest we split the yul/solc codegen stuff out into a separate crate, and add a driver crate that pulls everything together (the current compile() function, basically), which the fe executable will call. fe main, driver, and codegen have to be gpl3, the rest doesn't depend on gpl stuff at all, and can thus be apache2/mit. Personally, I'd be fine with all of the code being gpl3, but if there's a desire to keep some of it liberally licensed, then this is probably as good as we can do (unless we replace the yul/solc stuff).

fe -> driver -+-> parser
              +-> analyzer
              +-> compiler (lowering, ...?)
              +-> codegen --> yultsur/solc-rust/solc

We can't use solidity under a different license unless every contributor agrees to relicense their contributions. The Fe project can't claim that code is usable under the terms of apache2/mit if it's actually bound by the terms of gpl3.

[cburgdorf]

@sbillig cool, that makes sense! I like it 👍

[g-r-a-n-t]

There are only three contributors to our fork of yultsur. We might be able to get everyone to sign off on a switch to apache 2 and then structure things like so:

fe -> driver -+-> parser (Apache 2)
              +-> analyzer (Apache 2)
              +-> compiler (lowering, yul codegen) --> yultsur (Apache 2)
              +-> bytecode gen --> solc-rust/solc (GPL 3)