Split projects, re-licence libraries as more permissive

[vonj]

https://github.com/ethereum/cpp-ethereum/issues/3

"license is and always has been GPL"

Yet, you Gavin said:

"Kord's point is taken and the licence will be changed to something more liberal in due course", back in January. When is due course?

But now the issue is closed. If you actively want to hinder the adoption of this code, keep the GPL license. Many companies will not take the risk of building their solutions on GPL code, or likely can't even find a business case for it all. If you want to protect the direction of the code, then at least use LGPL. (Though MIT is clearly the simplest license to understand.)

For us GPL is a no go - we would have to use the Go or Python or Java implementation, even though C++ would fit much better.

I understand your point that: "It's worth remembering that this codebase is a proof-of-concept prototype, created mainly to test the whitepaper's premise and verify as reasonable the architecture it asserts."

However, realistically, probably no one is going to implement a clean room implementation from scratch in C++. If strict clean room principles are employed, the team doing it can't even look at your C++ code, unless they want to use GPL too.

I woke up in the wee hours - couldn't go back to sleep until writing this rant, because it has bugged me since January and now I decided to look back to see if the issue had been resolved.

[gavofyork]

"When is due course?"

After the PoC release series. Specifically alpha or beta.

At present, I expect we will move the core to LGPL.

On Mon, Dec 8, 2014 at 1:40 AM, vonj notifications@github.com wrote:

"license is and always has been GPL"

Yet, you Gavin said:

"Kord's point is taken and the licence will be changed to something more liberal in due course", back in January. When is due course?

But now the issue is closed. If you actively want to hinder the adoption of this code, keep the GPL license. Many companies will not take the risk of building their solutions on GPL code, or likely can't even find a business case for it all. If you want to protect the direction of the code, then at least use LGPL. (Though MIT is clearly the simplest license to understand.)

For us GPL is a no go - we would have to use the Go or Python or Java implementation, even though C++ would fit much better.

I understand your point that: "It's worth remembering that this codebase is a proof-of-concept prototype, created mainly to test the whitepaper's premise and verify as reasonable the architecture it asserts."

However, realistically, probably no one is going to implement a clean room implementation from scratch in C++. If strict clean room principles are employed, the team doing it can't even look at your C++ code, unless they want to use GPL too.

I woke up in the wee hours - couldn't go back to sleep until writing this rant, because it has bugged me since January and now I decided to look back to see if the issue had been resolved.

— Reply to this email directly or view it on GitHub https://github.com/ethereum/cpp-ethereum/issues/575.

Gav Wood

[vonj]

Thanks and excellent news. LGPL is acceptable for us, even though it makes it difficult to make iOS applications because it disallows static linking.

[gavofyork]

If this is a significant problem, I'd be willing to consider LGPL + static linking exception.

[vonj]

That would solve every issue for me, anyway. (iOS + LGPL is a problem. Example argument: http://multinc.com/2009/08/24/compatibility-between-the-iphone-app-store-and-the-lgpl/ )

Also, please consider that the contributors so far, also have to be OK with changing the license.

debris chriseth CJentzsch subtly programmerTim caktux LefterisJP chfast giact danielhams josephyzhou CodeShark msimovic

and so on.

I can only assume this list of contributors will only increase over time. Right now, it is manageable to change license, but this can quickly become impractical.

[rheaplex]

"If you actively want to hinder the adoption of this code, keep the GPL license."

That's a bogus argument. The GPL reassures all users of Ethereum that they will always be free to use the software as they wish. That is only going to discourage those actors who seek to fragment and exploit the potential adoption base of Ethereum.

"MIT is clearly the simplest license to understand."

It's simple, yes, but your case is meant to be based on risk. Apache 2 is clearer and more robust than MIT. Since LGPL + static linking leaves very little of the LGPL intact, either MIT or Apache 2 is preferable if permissive licensing is desired.

[vonj]

On 15/12/14 23:55, Rob Myers wrote:

"If you actively want to hinder the adoption of this code, keep the GPL license."

That's a bogus argument. The GPL reassures all users of Ethereum that they will always be free to use the software as they wish. A bogus argument, really?

I can say that I will not release GPL code in an iOS product. So it will hinder me. Or you can argue that I

a) ... I am a lier. I complain about problems releasing GPL code on iOS because I enjoy it.

b) It will hinder me, but I am so strange and unusual that I don't really count. I am a nobody.

c) That true freedom is to choose to not use Ethereum on iOS.

That is only going to discourage those actors who seek to fragment and exploit the potential adoption base of Ethereum.

For many types of programs I would actually agree with you. But I thought the point of Ethereum was the block chain and the network built around it, not a particular implementation of a client?

I can only infer that you suspect me of somehow wanting to "exploit" and "fragment" the adoption base of Ethereum. I am not sure in what way I would do that. Honestly, please elaborate. I don't get it. What are you afraid of?

Drawing a comparison to the world wide web, it sounds to me like you would prefer a world where there is ONE web server, (such as Apache) and ONE web browser, such as Firefox. No deviation encouraged.

or is it not reasons a, b, or c, but reason "d"?

d) You don't say it, but you hate that I could make a commercial, closed source program and even charge money for it. You think that closed source programs are immoral and that all code should be GPL. This is a valid position and I respect that position, and you are not alone, not the least Richard Stallman and the Free Software Foundation agrees with you, if this is what you think.

"MIT is clearly the simplest license to understand."

It's simple, yes, but your case is meant to be based on risk. Apache 2 is clearer and more robust than MIT. Since LGPL + static linking leaves very little of the LGPL intact, either MIT or Apache 2 is preferable if permissive licensing is desired.

I'll let the reader decide if MIT or Apache is clearer, it is possibly a matter of taste. I cannot agree however, that LGPL + static linking leaves very little of the LGPL intact.

LGPL + static linking exception would still be a copyleft license. Any changes to the LGPL code must still be distributed openly.

[vonj]

I saw a github project which had an interesting Contributor License Agreement:

https://github.com/flarum/core

Something like this would be very appropriate here as well.

[vonj]

Any news on this?

[vonj]

Just for completeness, can we have a comment on why it was closed?

[bobsummerwill]

Hey @vonj, I believe this was just a duplicate issue.

The project flipped from GPL to MIT several months back.

[chriseth]

@vonj this issue was scheduled for poc-9 and the last substantial comment was over a year ago. Licensing is explained here https://github.com/ethereum/wiki/wiki/Licensing and we have other issues to track the changes that still need to be done.

[vonj]

Thank you so much! @chriseth @bobsummerwill

[bobsummerwill]

Hey @vonj,

Further to this ...

• https://bobsummerwill.com/2016/07/12/c-re-licensing-plan/
• https://bobsummerwill.com/2016/07/12/ethereum-everywhere/

It seems that the earlier attempted switch to MIT was never completed. I'm driving on an Apache 2.0 relicensing now, so that this long-running saga can finally be put to bed!