BUIP106: (withdrawn) License Bitcoin Unlimited software under GPLv3

[Griffith]

Something that i did not address in my last post was

This is true, but I think that its an additional problem with the proposal. As a more centralized coin, nChain possibly doesn't need to ever distribute the program.

this still remains true. changing the license we publish with doesnt help at all if nchain is closed source. In this scenario even if they did include our GPLv3 licensed code and distributed the source to their trusted parties, we would have no way to verify to make a licensing claim against them

 

[freetrader]

nChain possibly doesn't need to ever distribute the program.

In the end, the good that we can get from a license is no better than our ability and willingness to enforce it.

Actually, I reconsider the above. The added benefit is not from detecting whether nChain is exploiting the license, but that BU code will be used by others under GPL terms which should result in more free code.

If, in the future, nChain were to use GPL'd BU code but never distributing it, sure, we would have no way to claim. But there is sufficient case precedent for proprietary software including GPL'd bits and being forced to open their code.

As long as nChain wishes to use the GPL'd code without distributing, they are within their rights. But this means no products of theirs include it, or they are in violation and at risk of being sued. Those terms seem acceptable to me.

 

[theZerg]

The MIT license does not include the right to sublicense under new terms. It explicitly denies that power:

"The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."

 

[Griffith]

This post is going to clarify some things from my last post regarding sublicensing.

My conclusion was correct but my explanation missed the mark a bit, so id give myself a 6/10 on that last post. I will take this opportunity to use IANAL as an excuse for poor explanation the first time around.

Clarifications/Corrections
In my last post I did not make it clear that if you sublicense software with license modifications (by adding a new license or by modifying the existing license), the new full set of terms MUST be compatible with the previous existing license. In our situation, any changes we make to our repo's licensing must be compatible with the MIT license. For anyone who needs an example on what it means for licenses to be compatible you can find one here.

@theZerg is right. You can not just sublicense our MIT licensed repo under a new license that strips away rights granted by the MIT license. However, there is nothing preventing you from adding new restrictions. My use of the term sublicensing up until this point was slightly off the mark. Instead of saying

As far as i can tell there is nothing stopping us from changing the license under which our software is published because we were given the rights to sublicense with no explicitly stated resctrictions on how we may sublicense.

What i should have said was "As far as i can tell there is nothing stopping us from changing our licensing in a way that is compatible with the MIT license because we were given the rights to sublicense".

Essentially, the GPLv3 license is the MIT license with more added restrictions




New Content
You are allowed to merge code from two different licenses together as long as the licenses are compatible. GPLv3 is compatible with MIT code (reference). Since the GPLv3 license is "viral" and would only apply to newly committed code (excluding backports i would assume), it will take a while to spread throughout the entire code base. As more and more commits are added as GPLv3 licensed code it will become harder and harder to distinguish which parts of the code are MIT and which are GPLv3. We will eventually reach a point where it will become so difficult to separate the two it will become easier to just consider the entire code base GPLv3 even though this wouldnt be technically true.

IMO, for ease of use and clarity, we should either make a specific branch (or better yet a separate cloned github repo) that contains all commits and release tags and such immediately prior to the commit that adds the GPLv3 license to the source code. This makes it clear what is MIT code people can go back and reference/use and what is infected with the GPLv3 virus once we hit the point of being unable to distinguish between the two.


Edit: Although i have tried to make a strong argument to explain why we are able to switch to a GPL license, I am not currently decided if we should actually pursue this route or not.

 

[freetrader]

The MIT license does not include the right to sublicense under new terms. It explicitly denies that power:

"The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."

I see that differently. It explicitly allows you to sublicense as long as those terms you quoted are met. That's why the license explicitly affirms the right to sublicense, while keeping to those conditions:

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

So while clarifications on the scope of sublicensing rights are appropriate, it would be incorrect to say that the license does not grant you any right to sublicense under new terms.

There are Bitcoin projects which use MIT but add further restrictions. A recent example is the CashDB project by Lokad.

 

[Griffith]

@freetrader My biggest remaining issue with this BUIP is enforcement. We would have to pay to prosecute anyone who violates our new terms. With our limited resources i don't see this as a reality.

also it does add extra work for the developers to maintain distinction between gplv3 and mit code until u reach that muddled point.

 

[theZerg]

@freetrader, I think that your last comment is correct but that you are not reading the MIT license carefully enough. The key portion is:

"Permission is hereby granted, ...
including **without limitation** the rights to use, copy, modify, merge, publish, distribute..."

You are right that you can add additional clauses when you sub-license so long as those clauses do not put ANY limits on the right to use, copy, modify, merge, etc. But the GPLv3 clearly puts limits and restrictions on some of these actions.

Combined with Griffith's prosecution cost observation, this BUIP creates problems for us (BU doesn't respect prior author's copyright), without giving us any tangible benefit.

 

[freetrader]

@theZerg, I think the "without limitation" is a point which Griffith and myself seem to have interpreted differently than you did, namely meaning that there shall be no limitation on how a recipient may exercise these rights, including that of sublicensing, so long as they do not remove from the rights already granted by the MIT license.

As certainly IANAL, clarification of this seems prudent and likely necessary before proceeding with a vote on this BUIP.
It seems to me that as already-MIT-licensed code would remain available under the MIT license, the users would effectively not lose any rights to such code.

New code, which would be released under GPL, would not be affected by any potential limitations of rights incurred from MIT -> GPL. So essentially this BUIP is somewhat badly titled as it does not do that aspect justice.

At the same time, as Griffith points out, the resulting intermix of MIT'd and GPL'd code will result in a somewhat muddled, evolving state, especially if MIT'd and GPL'd source files are not kept separate.
No doubt policing this would cost some additional developer effort - that much is recognized, the question to be weighed IMO is whether it would be worth the effort. That is a hard thing to estimate.

Certainly, the benefits of using a new open source license may not be immediately tangible.
However I do see some potential tangible benefits - unrelated to prosecution of rights in case of non-compliance - as I've tried to point out in the Motivation and some subsequent comments.
These benefits would result already in the case of compliance, and would include

• increased patent protections
• obtaining voluntary return code contributions from corporate use, which may have otherwise have been forfeited due to proprietary squirelling-away of modifications (the assumption here is that corporates are usually inclined to avoid compliance risks)
  
• attracting more FOSS developers to use BU through the increased guarantees of others contributing back their modifications
• a possible effect of keeping a market area open for OSS effect in cases where the compliance risk decision of a corporate prevents it from using the software to fill a market gap

It is perhaps worth mentioning that according to the Software Freedom Law Centre (SFLC) assessed that disputes are "regularly settled in an amicable and cooperative fashion" before reaching litigation.

[1] https://downloads.softwarefreedom.org/2015/conference/CLE_Packet.pdf
[doublepost=1547497450][/doublepost]@solex : I think the implication of the "without limitation" clause of MIT on the sublicensing using GPL is sufficiently nebulous to hold off on including this BUIP in the upcoming (January 2018) vote.

 

[solex]

@freetrader
Certainly. It can be easily included in a subsequent voting round.

 

[Tom Zander]

You might be interested in the fact that I did seek advice about this matter, although I had not published this anywhere as this was purely by email.

Dear Tom,

Thank you for reaching out to us with your request! Please note that the
FSFE is a non-profit organisation that has no capacity, nor is allowed
to give legal advice. For a more detailed assessment of your situation,
please refer to a legal professional in your jurisdiction.

We, nevertheless, would try to give you some general guidance regarding
your request that we hope you find useful.

On 01.05.2017 11:53, Tom Zander wrote:
> As I am afraid of patents being an issue in Bitcoin, I want to switch to
> a more appropriate license. My eyes are on GPLv3+

While GPL v.3+ is an adequate option, you might also consider Apache 2.0
which is a closer licence to MIT but with a patent clause.

> Some questions;
>
> * Is it legal to just relicense existing MIT code to GPLv3+ in a new
> release? (without copyright-owner permission)

Yes, assuming that you will make some changes to the existing code, and
do not remove the existing copyright notices.

One possible practical way to re-licence to, for example GPL v3, is to
place the GPL license text alongside the MIT license into the SCM and
explain the situation in some README file: X is based on Y,
which is released under MIT license. All changes made by X are done
under the GPLv3+ and X as whole is therefore GPLv3+.

It would be also beneficial to make the new license clear in the first
commit message.

> * In practically all files the copyright license is made towards a non-
> existing legal entity ("Bitcoin Core", which is not defined or owned AFAIK).
> In case the first question is negative, can the fact that people gave
> copyright to a non-existing entity help with a relicensing effort?

The copyright assignment to an unincorporated associations (without
formally formed legal entity) varies from jurisdiction to jurisdiction.
In some states, such unincorporated associations are not able to hold
assets, hence the copyright assignment might be void. Another problem
with unincorporated associations is the ability to enforce their rights
in court, which depending on jurisdiction might be very limited.

There are several existing organisations that are able to act as an
umbrella organisation for their Free Software projects and help with
administrative and fiscal burden, including the issues in question.

However, as the answer to the first question is positive, in your case
you do not need permission to incorporate MIT code into a GPL project.

Hope you find our answers helpful!
​

So, to repeat what the lawyer from FSFE explained in practical terms;
You can effectively relicense. Imagine I take your MIT file and I rename it to fie.MIT,
then I start a new file with copyrightable content which is GPLv3 licensed. Additionally I copy the MIT code from you into this new file. Because GPL combined with MIT results in GPL licensed code, the new file stays GPL.
Naturally you don't have to go through these steps in git, its just something to understand the point.

I don't see problems for BU to do this, but please realize that this is not legal advice.

 

[TierNolan]

Most of the discussion seems to be on the mechanics of actually making this change. The pros and cons of the decision should also be considered.

If you make a project GPL, then you prevent companies with closed source software from incorporating your work into their projects. Even the risk of having to open source unrelated software might deter them. This is the direct intention of the BUIP (including a reference to a specific company), but is this actually desirable?

BU is low level infrastructure for the Bitcoin Cash network. Excluding certain types of use cases is not a great idea in that situation. Some use cases work best with open source code and some work better with closed source. Projects should be allowed to pick what works for them.

You would, essentially, be saying to anyone who might want to have a full node as part of their closed source software that they should use some other implementation of the basic Bitcoin Cash protocol.

This would make it much harder for BU to displace BitcoinABC as the primary client used by miners. It is crucial for the health of the Bitcoin Cash network that there are multiple viable clients available for miners to chose from.

Another thing to consider is that it is easy to apply GPL to an MIT project but it is hard to remove GPL from a project and revert to MIT. Once you decide to switch back from GPL to MIT, you will have to find every commit since the branch point and get permission from every author.

If you are lucky and there aren't many different authors, they might all agree to switch things back, but all it takes is one author to refuse.

If that happens, you have to find and remove all of their code. Since a small number of authors do much of the commits, it isn't as hard as it might initially seem, but it is still a big hassle. There is also legal risk if you miss any code. If you do, then the project is still a (submarine?) GPL project.

 

[freetrader]

This would make it much harder for BU to displace BitcoinABC as the primary client used by miners.

Absolutely not. You seem to misunderstand how the GPL works.

Miners could use BU, even in modified form, as long as they do not distribute it as a product without also distributing their modifications.

Fact is, miners might make modifications to Bitcoin clients to gain competitive advantage.

Fact is also, they keep these under wraps. Ever seen some being distributed in closed source (binary) form? I haven't. Feel free to point me at them. No other miners would trust to run them, it would be too expensive to ensure that such binaries they are free of malicious code.

Hence, miners might be using GPL'd code right now, and you would not know, since the license would not mandate them to share their modifications with us.

Some use cases work best with open source code and some work better with closed source. Projects should be allowed to pick what works for them.

Users can still pick whatever works best for them. This would not change by adopting a free software license.

Right now, very few miners are using BU. This doesn't seem to have anything to do with it being open or closed, since it is MIT licensed so they could all use it in some closed source form if they wished.

I'm not arguing that putting the source code under a free software license will make more miners run it. But it will make sure that competing chain miners (BSV and others) will not be able to legally distribute modified versions of BU without making the source code freely available to the world, i.e. to use BU to the competitive disadvantage of Bitcoin Cash users.

Right now they have already taken Bitcoin ABC code and stuck it under a license that is not open according to OSI defintion.

 

[solex]

@freetrader
Do you consider this proposal ready for vote?

 

[freetrader]

@solex : After the discussions, I don't sense sufficient support for this proposal in the BU community.
I'm considering withdrawing it entirely, except if some BU members really want it to be voted on.

From a "readiness" POV, I think it *could* go ahead.

 

[freetrader]

After calling to gauge membership support of this BUIP in the previous comment, on the BU slack and via a Memo post, I received no further feedback from the membership.

As it stands, I don't want to waste people's time on voting for something for which there is apparently little support, so I'm formally withdrawing this BUIP.

If future events should make the membership reconsider the current license, this proposal can serve as a basis for further discussion and considerations.

CC @solex

 

[solex]

@freetrader
Marking as withdrawn.

 

[TierNolan]

Absolutely not. You seem to misunderstand how the GPL works.

Miners could use BU, even in modified form, as long as they do not distribute it as a product without also distributing their modifications.

They would also have to release the source for the entire project that it was incorporated into. If you want to distribute software that has any GPL code, you must make available the source for the entire project.

LGPL allows "libraries" to be incorporated into other projects without requiring the entire project to be distributed. Changes to the library itself must be made public though.

Your main point is valid though. If they don't want to distribute the resulting software and just use it internally, they would not be under any obligation to distribute.