Split projects, re-licence libraries as more permissive #575

Closed
vonj opened this Issue Dec 8, 2014 · 13 comments

Comments

Projects
None yet
5 participants
@vonj

vonj commented Dec 8, 2014

#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

This comment has been minimized.

Show comment
Hide comment
@gavofyork

gavofyork Dec 8, 2014

Contributor

"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
#575.

Gav Wood

Contributor

gavofyork commented Dec 8, 2014

"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
#575.

Gav Wood

@vonj

This comment has been minimized.

Show comment
Hide comment
@vonj

vonj Dec 8, 2014

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

vonj commented Dec 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@gavofyork

gavofyork Dec 8, 2014

Contributor

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

Contributor

gavofyork commented Dec 8, 2014

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

@vonj

This comment has been minimized.

Show comment
Hide comment
@vonj

vonj Dec 8, 2014

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.

vonj commented Dec 8, 2014

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.

@gavofyork gavofyork added this to the alpha milestone Dec 15, 2014

@gavofyork gavofyork self-assigned this Dec 15, 2014

@gavofyork gavofyork changed the title from License still the same to Split projects, re-licence libraries as more permissive Dec 15, 2014

@robmyers

This comment has been minimized.

Show comment
Hide comment
@robmyers

robmyers Dec 15, 2014

"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.

"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

This comment has been minimized.

Show comment
Hide comment
@vonj

vonj Dec 21, 2014

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 commented Dec 21, 2014

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

This comment has been minimized.

Show comment
Hide comment
@vonj

vonj Feb 10, 2015

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 commented Feb 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@vonj

vonj Jun 25, 2015

Any news on this?

vonj commented Jun 25, 2015

Any news on this?

@chriseth chriseth closed this Mar 8, 2016

@vonj

This comment has been minimized.

Show comment
Hide comment
@vonj

vonj Mar 9, 2016

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

vonj commented Mar 9, 2016

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

@bobsummerwill

This comment has been minimized.

Show comment
Hide comment
@bobsummerwill

bobsummerwill Mar 9, 2016

Contributor

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

The project flipped from GPL to MIT several months back.

Contributor

bobsummerwill commented Mar 9, 2016

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

The project flipped from GPL to MIT several months back.

@chriseth

This comment has been minimized.

Show comment
Hide comment
@chriseth

chriseth Mar 10, 2016

Contributor

@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.

Contributor

chriseth commented Mar 10, 2016

@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

This comment has been minimized.

Show comment
Hide comment

vonj commented Mar 10, 2016

Thank you so much! @chriseth @bobsummerwill

@bobsummerwill

This comment has been minimized.

Show comment
Hide comment
@bobsummerwill

bobsummerwill Aug 6, 2016

Contributor

Hey @vonj,

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!

Contributor

bobsummerwill commented Aug 6, 2016

Hey @vonj,

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment