Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Split projects, re-licence libraries as more permissive #575
"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:
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.
"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 firstname.lastname@example.org wrote:
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.
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.
"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.
On 15/12/14 23:55, Rob Myers wrote:
I can say that I will not release GPL code in an iOS product.
a) ... I am a lier. I complain about problems releasing GPL code on iOS
b) It will hinder me, but I am so strange and unusual that I don't
c) That true freedom is to choose to not use Ethereum on iOS.
For many types of programs I would actually agree with you. But I
I can only infer that you suspect me of somehow wanting to "exploit" and
Drawing a comparison to the world wide web, it sounds to me like you
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
I'll let the reader decide if MIT or Apache is clearer, it is possibly a
LGPL + static linking exception would still be a copyleft license. Any
Further to this ...
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!