Suggestion for contributor license #1392

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants
@vonj

vonj commented Mar 24, 2015

As a first step to be able to close this issue:
A first step to close issue 575 can be to require for contributors to license their changes under a permissive license.
Gavin can then choose to sublicense to GPL for the main client, and to LGPL or MIT license for the library.

#575

Suggestion for contributor license
As a first step to be able to close this issue:
A first step to close issue 575 can be to require for contributors to license their changes under a permissive license.
Gavin can then choose to sublicense to GPL for the main client, and to LGPL or MIT license for the library.

#575
@gavofyork

This comment has been minimized.

Show comment
Hide comment
@gavofyork

gavofyork Mar 25, 2015

Contributor

Should be Eth Dev (UK) CIC named rather than me, and would ideally be more in line with ethereum.org's Licences section, i.e. binaries/tools are GPL, rest is MIT.

Also, no need for the proprietary stuff.

Contributor

gavofyork commented Mar 25, 2015

Should be Eth Dev (UK) CIC named rather than me, and would ideally be more in line with ethereum.org's Licences section, i.e. binaries/tools are GPL, rest is MIT.

Also, no need for the proprietary stuff.

@subtly

This comment has been minimized.

Show comment
Hide comment
@subtly

subtly Mar 25, 2015

Member

Hi @vonj,

As a contributor to this project and several other open source projects I'm interested in this conversation and that we Do The Right Thing.

GLP covers the subject matter of transfer of rights and in this regard, the changes proposed are redundant; as such, this is very risky without employing legal counsel. In cases where I've seen a contributor license like this, it is not enforceable unless it's "signed". Not recommended! Example: https://cla.developers.google.com/about/google-individual?csw=1

Let's also keep in mind, we depend on 3rd party libraries which we may have been modified, included or linked. Just because we modify the readme doesn't mean that the entire codebase isn't implicitly limited to GPL anyways. For example, Qt is GPL.

There have been discussions about commercial entities not using ethereum because of GPL. This simply isn't accurate -- enterprises use GPL licensed software. See: Linux. The question is: What parts of the codebase do core developers need upstream contributions? What parts of the codebase will others want to change without contributing upstream?

Answering the first question makes the second irrelevant. What we could do is license these libraries as GLP+linking...

  • ethash
  • ethcore (excluding CommonJS)
  • devcrypto (Trie code)
  • Binaries/DevTools (ex: Mix)
  • p2p (extract network -> MIT; devp2p is GPL+linking)
  • ethereum (for v1; v2 this is "stable" and moves away from GPL)

...and the rest as MIT. This leaves the entire API (incl EVM) open for tweaking and limits copyleft licensing to kernel-like components and major developer tools.

I do think voluntary legal counsel (attorneys for GNU/EFF/CC/Wikipedia) would be able to help determine if a contributor agreement is necessary for relicensing to MIT. Until then, it maybe easier to do GLP+linking where we know there aren't upstream licenses (Qt/microhttpd/etc).

Does this approach work for how you envision using the ethereum blockchain?

Member

subtly commented Mar 25, 2015

Hi @vonj,

As a contributor to this project and several other open source projects I'm interested in this conversation and that we Do The Right Thing.

GLP covers the subject matter of transfer of rights and in this regard, the changes proposed are redundant; as such, this is very risky without employing legal counsel. In cases where I've seen a contributor license like this, it is not enforceable unless it's "signed". Not recommended! Example: https://cla.developers.google.com/about/google-individual?csw=1

Let's also keep in mind, we depend on 3rd party libraries which we may have been modified, included or linked. Just because we modify the readme doesn't mean that the entire codebase isn't implicitly limited to GPL anyways. For example, Qt is GPL.

There have been discussions about commercial entities not using ethereum because of GPL. This simply isn't accurate -- enterprises use GPL licensed software. See: Linux. The question is: What parts of the codebase do core developers need upstream contributions? What parts of the codebase will others want to change without contributing upstream?

Answering the first question makes the second irrelevant. What we could do is license these libraries as GLP+linking...

  • ethash
  • ethcore (excluding CommonJS)
  • devcrypto (Trie code)
  • Binaries/DevTools (ex: Mix)
  • p2p (extract network -> MIT; devp2p is GPL+linking)
  • ethereum (for v1; v2 this is "stable" and moves away from GPL)

...and the rest as MIT. This leaves the entire API (incl EVM) open for tweaking and limits copyleft licensing to kernel-like components and major developer tools.

I do think voluntary legal counsel (attorneys for GNU/EFF/CC/Wikipedia) would be able to help determine if a contributor agreement is necessary for relicensing to MIT. Until then, it maybe easier to do GLP+linking where we know there aren't upstream licenses (Qt/microhttpd/etc).

Does this approach work for how you envision using the ethereum blockchain?

@vonj

This comment has been minimized.

Show comment
Hide comment
@vonj

vonj Mar 26, 2015

@gavofyork
@subtly

Excellent that I have your attention, thank you. Regarding the enforceability of developer license agreement - you might be right. When it comes to transfer of right. But as things are now, cpp-ethereum accepts change-request after change-request, all implicitly licensed with the GPL. This is a problem. All "core" patches should have a more liberal license, such as X11 or MIT.

"Let's also keep in mind, we depend on 3rd party libraries which we may have been modified, included or linked. Just because we modify the readme doesn't mean that the entire codebase isn't implicitly limited to GPL anyways. For example, Qt is GPL."

I am interested mostly in the core parts of cpp-ethereum - what would be an Ethereum library. But anyway, QT is LGPL, not GPL, so QT does not implicitly make the entire codebase GPL.

"There have been discussions about commercial entities not using ethereum because of GPL. This simply isn't accurate -- enterprises use GPL licensed software. See: Linux."

This argument is just not complete enough - "GPL is used in one commercial context - therefore it can be used in all commercial contexts". The iOS Apple Store does not allow GPL, not even LGPL. That is one problem. Another problem is that if someone, say I, creates a proprietary, closed source program, how can I link it to cpp-ethereum (core only!) and sell it on the App Store, or anywhere else?

"The question is: What parts of the codebase do core developers need upstream contributions? What parts of the codebase will others want to change without contributing upstream?"

This is a good question. LGPL for me strikes a sweet spot in theory - it can be linked to proprietary code, but it protects changes to cpp-ethereum core and requires to it to be made public. However, LGPL is not compatible with the App Store, because of the static linking used on iOS. LGPL + static linking exception would be OK, or an MIT or X11 license.

"Answering the first question makes the second irrelevant."

As I hope I have demonstrated, the second is not irrelevant.

"What we could do is license these libraries as GLP+linking..."

LGPL + static linking exception would be fine, and X11 or MIT license would be even simpler. I am only interested in library parts, what you would need to integrate Ethereum into your own application.

If you followed me through here, I will come to my most important point:

it's fine to talk about re-licensing at some point in the future. But how do you propose to do that in practice? A lot of contributors have by now contributed code, I presume under the GPL license.

Gavin can not step in and just declare that all their code is now not GPL. @gavofyork, you can declare that your core-library code is now suddenly not GPL but instead LGPL+static linking exception, or MIT, or whatever. But you cannot declare that other peoples code is now licensed under some other license.

As we speak, this problem grows with every commit. This is called "let time make the decision". Actually it's pretty similar to the blockchain itself... ;-) The further you wait, the harder it is to go back and "undo" a decision as more and more blocks (or commits) are added. A decision was made to use GPL. At some point, it will become impossible from a practical standpoint to change license. I hope this is still possible.

vonj commented Mar 26, 2015

@gavofyork
@subtly

Excellent that I have your attention, thank you. Regarding the enforceability of developer license agreement - you might be right. When it comes to transfer of right. But as things are now, cpp-ethereum accepts change-request after change-request, all implicitly licensed with the GPL. This is a problem. All "core" patches should have a more liberal license, such as X11 or MIT.

"Let's also keep in mind, we depend on 3rd party libraries which we may have been modified, included or linked. Just because we modify the readme doesn't mean that the entire codebase isn't implicitly limited to GPL anyways. For example, Qt is GPL."

I am interested mostly in the core parts of cpp-ethereum - what would be an Ethereum library. But anyway, QT is LGPL, not GPL, so QT does not implicitly make the entire codebase GPL.

"There have been discussions about commercial entities not using ethereum because of GPL. This simply isn't accurate -- enterprises use GPL licensed software. See: Linux."

This argument is just not complete enough - "GPL is used in one commercial context - therefore it can be used in all commercial contexts". The iOS Apple Store does not allow GPL, not even LGPL. That is one problem. Another problem is that if someone, say I, creates a proprietary, closed source program, how can I link it to cpp-ethereum (core only!) and sell it on the App Store, or anywhere else?

"The question is: What parts of the codebase do core developers need upstream contributions? What parts of the codebase will others want to change without contributing upstream?"

This is a good question. LGPL for me strikes a sweet spot in theory - it can be linked to proprietary code, but it protects changes to cpp-ethereum core and requires to it to be made public. However, LGPL is not compatible with the App Store, because of the static linking used on iOS. LGPL + static linking exception would be OK, or an MIT or X11 license.

"Answering the first question makes the second irrelevant."

As I hope I have demonstrated, the second is not irrelevant.

"What we could do is license these libraries as GLP+linking..."

LGPL + static linking exception would be fine, and X11 or MIT license would be even simpler. I am only interested in library parts, what you would need to integrate Ethereum into your own application.

If you followed me through here, I will come to my most important point:

it's fine to talk about re-licensing at some point in the future. But how do you propose to do that in practice? A lot of contributors have by now contributed code, I presume under the GPL license.

Gavin can not step in and just declare that all their code is now not GPL. @gavofyork, you can declare that your core-library code is now suddenly not GPL but instead LGPL+static linking exception, or MIT, or whatever. But you cannot declare that other peoples code is now licensed under some other license.

As we speak, this problem grows with every commit. This is called "let time make the decision". Actually it's pretty similar to the blockchain itself... ;-) The further you wait, the harder it is to go back and "undo" a decision as more and more blocks (or commits) are added. A decision was made to use GPL. At some point, it will become impossible from a practical standpoint to change license. I hope this is still possible.

@chriseth chriseth closed this Jan 27, 2016

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