BUIP106: (withdrawn) License Bitcoin Unlimited software under GPLv3

[freetrader]

BUIP106: License Bitcoin Unlimited software under GPLv3
Submitted by freetrader
7 December 2018

Summary

In the interest of ensuring that the developmental playing field between Bitcoin Unlimited and corporations using its software remains level, re-license the Bitcoin Unlimited software under the GNU Public License version 3 (GPLv3) [1] and license new BU code exclusively under GPLv3.

Motivation

Recent events have shown that corporations are willing to use BU software to further their own aims without contributing back to Bitcoin Unlimited development.

Changing the license from MIT to GPLv3 would at least obligate companies that distribute derivatives of BU software to provide their modified source code back to the community.

To quote from [2]:

GPLv3 also provides users with explicit patent protection from the program's contributors and redistributors. With GPLv2, users rely on an implicit patent license to make sure that the company which provided them a copy won't sue them, or the people they redistribute copies to, for patent infringement.

This patent protection clauses will provide a benefit to BU users considering the recent increase in patent registrations and patent litigation threats in the Bitcoin and general blockchain space.

Implementation considerations

Original MIT license clauses need to be preserved, and GPL licensing clauses added to license existing files under GPL.

All new code contributions would be licensed under GPLv3 or later.

Notes:

1. Since the MIT license restrictions are a subset of the GPL restrictions, MIT-licensed code can be re-licensed under GPL provided the original MIT clauses and attributions remain intact.
   See [3]
   
2. As an example of a project which has re-licensed MIT code under GPL(v3), see Flowee The Hub
   See [4]

Additional information

[1] https://www.gnu.org/licenses/gpl.html
[2] https://www.gnu.org/licenses/rms-why-gplv3.html
[3] https://softwareengineering.stackexchange.com/questions/105912/can-you-change-code-distributed-under-the-mit-license-and-re-distribute-it-unde
[4] https://gitlab.com/FloweeTheHub/thehub

 

[freetrader]

I'll write a personal motivation of why I introduced this BUIP.

I don't feel like contributing to BU if my contributions will be used against Bitcoin (Cash) by corporations such as nChain.

At the very least, I want them to have to release their changes, should they make use of BU software and distribute it to other parties.

The GPL has been tested in court and should provide some protection against corporate abuse, and help ensure that the work of volunteer and paid devs on this wonderful piece of free software (best in its class as far as currently known) is not subverted to the detriment of the protocol and the users of the currency.

 

[sickpig]

I have to say that due to current situation especially the one that take into consideration patents thread a move to GPLv3 makes a lot of sense.

Since the MIT license restrictions are a subset of the GPL restrictions, MIT-licensed code can be re-licensed under GPL provided the original MIT clauses and attributions remain intact.

it would be a first, BU proposing and implementing a soft-fork... even if only at the license level

To wrap up long as that re-licensing current code base under GPLv3 is a viable solution (IANAL) I can't see why not.

 

[cypherdoc]

does this imply that bsv is currently running a derivative of BU software and is closed source?

 

[sickpig]

@cypherdoc

I don't think it implies that, but I guess @freetrader could clarify further. I think that he is more thinking to what will happen in the future.

Having said that, under the current license there's no way for BU to force any company/entity to release the source code of a derivative closed source product based on BU. This is a property of all BSD-like licenses. This is something that authors of this kind of license do on purpose. FWIW I'm ok with that.

On the other things that GPLv3 bring to the table are:

1) make it impossible to keep a derivative product closed source (same as GPLv2)
2) shields users with explicit patent protection from the program's contributors and redistributors.

Back in the days I used to push very hard for 1) but then I discovered that it is possible to have successful open source projects while using BSD-like license (e.g. PostgreSQL, Redis, etc. etc.).

Point 2) comes particularly handy in case a patent litigation. I have experienced first hand on PostgreSQL, a developer use https://en.wikipedia.org/wiki/Adaptive_replacement_cache to implement cache invalidation for an internal structure. All of a sadden IBM came out of the blue because US patent office grant them a patent over that algorithm.

To make a long story short, they had to rush out a replacement of very sensitive part of the code.

This is not something you want to happen to the software that is implementing sound money for the world.

 

[freetrader]

does this imply that bsv is currently running a derivative of BU software and is closed source?

No, it does not imply that "BSV is currently running" closed source derivative of BU. It's certainly possible, but not a given.

According to https://cashnodes.bitcoinunlimited.info/nodes, there are currently 21 BUcash:1.5.0.2(SV; ...) nodes and 2 BUcash:1.5.0.1(SV; ...) nodes.

 

[solex]

@freetrader I am adding this BUIP to the index, and welcome @theZerg's feedback.

 

[torusJKL]

I like the GPL and we have to thank it for many great and widly used software.
But the implications of switching from MIT to the GPLv3 need to be thouroughly analyzed.

I don't feel like contributing to BU if my contributions will be used against Bitcoin (Cash) by corporations such as nChain.

I find the above reason highly disturbing and it might blind us from seeing the long term implications out of current fear and hate against one Company/Person.
It looks to me more like an alergic reaction than a health response from the imune system.

Releasing code under MIT does not give the other side something to use against the creator.
At most it would give it an adavantage when used in its closed source project by getting free labour from BU.
Unfortunately the GPL does not forbid this behaviour, as this would be a form of restricting freedom, but only asks the other party to release the code should he release binaries with modifications.
If he keeps the modified code to himself, which we can assume will happen more often in the future, than BU will not see any code flowing back.

This patent protection clauses will provide a benefit to BU users considering the recent increase in patent registrations and patent litigation threats in the Bitcoin and general blockchain space.

From what I understand this would only protect BU if the company holding the patent would release its code under GPLv3 and BU uses the released code or part of it.
This means that said company would need to use BU GPLv3 code in the first place, build upon and release it.


Another point to be awaer of with the GPL is that it forces linked code also to be released under the GPL.
This could be a reason for many not to use BU code in the first place and could weaken BU as a base for accepted enhancement by the whole ecosystem.
A license like the LGPL might help in this regard.

 

[freetrader]

LGPL is certainly an alternative, the same suggestion was made by dagurval on the BU slack on the day I opened this BUIP.

I find the above reason highly disturbing and it might blind us from seeing the long term implications out of current fear and hate against one Company/Person.

Perhaps. As I wrote "I feel" - it's my own personal feeling as someone who has contributed to BU in the past.

Releasing code under MIT does not give the other side something to use against the creator.

Disagree with you here - my personal feeling is that in fact it would, now that they have split off into their own currency.

Take for example, the Compact Blocks interoperability work that I've started working on.
They could use that directly to achieve bigger block size capacities on the BSV network, which even if there was no real world application, they would rub in the public's noses as BSV somehow being better than BCH, even if that was objectively untrue.

Now you are right - as long as they don't distribute the binaries publicly, they could include such modifications in closed source code for software that they run on their back end. They would of course deny using BU or its changes, and it might be hard to prove otherwise as long as they are careful enough. But sooner or later we would catch them out.

Releasing such new code under GPL would make it impossible for them to just grab work that gives BU and BCH and advantage and use it in their *public client* unless they really kept the changes freely available.

From what I understand this would only protect BU if the company holding the patent would release its code under GPLv3 and BU uses the released code or part of it.
This means that said company would need to use BU GPLv3 code in the first place, build upon and release it.

Probably. Meaning I agree, but my understanding is also not that of a patent lawyer.

I do however think there is value for BU in the defensive patent retaliation clauses in the GPLv3 license, as discussed by Moglen and Stallman here:

https://fsfe.org/campaigns/gplv3/patents-and-gplv3.en.html

At this point I do not really intend to change this BUIP from GPLv3 to LGPLv3. If someone sees sufficient value in LGPL, I think they should open a separate BUIP to propose that.

 

[theZerg]

IANAL but I do not think that you can relicense code just because one is a subset of another, unless doing so is explicitly allowed by the original license. But that is not the case here anyway. The MIT license explicitly provides certain permissions that GPL takes away.

I do not see Flowee the hub as a good precedent in this matter, but may be wrong. If it did so based on a reasoned legal opinion then by all means link to that.

A positive vote on this BUIP does not allow us to break the law so we'd have to solicit a legal opinion.

Instead, consider changing your BUIP to allow GPLv3 licensed code to be submitted to BU as separate files. This would achieve your goal I think, not for bug fixes, but for larger work -- we'd just make sure that any medium or large feature is in its own files, which is good practice anyway. Of course, it would be the actual contributor's decision to GPLv3 or MIT license the code.

On final nit: the GPLv3 technically cannot be compiled with MIT licensed code since GPL is "viral". This issue is normally handled by adding an exemption clause to the GPLv3 licensed code to allow it to be compiled with more permissive FOSS code. Please research this and propose an exemption clause.

 

[freetrader]

Instead, consider changing your BUIP to allow GPLv3 licensed code to be submitted to BU as separate files.

The intent of this BUIP is to license the entire codebase under GPLv3, same as Flowee has done.
So after consideration, changing it to cover only new files under GPLv3 would foresake the main objective, which is to prevent others from modifying and distributing derived versions of BU in closed form, thus denying their changes to upstream BU.

As you pointed out, GPL can be called 'viral', but I think you are wrong about compilation not being permitted - it is when the resulting program is distributed that the GPL applies.

I will have a look at exemption clauses - for out of own interest, as I said I think it would defeat the main goal of this BUIP.

To my understanding, files that have previously been under MIT license and not modified under GPL license can still be distributed under MIT license, even if they are simultaneously licensed under GPLv3 as well.

 

[Griffith]

if im interpreting this correctly... MIT lets you sublicense code making it possible to relicense and distribute the original MIT code under a new license with more restrictions such as GPLV3. Google results seem to agree with my interpretation, although almost all of them are prefaced with IANAL.

Theres a 50/50 im wrong on this next part but...
I also recall reading somewhere that if you are the copyright owner, which BU org would be if we change to GPLV3 (i think), then we can freely change the licensing as we see fit which means it would be changeable again in the future if for whatever reason GPLv3 doesnt work out.

 

[torusJKL]

I don't think that the contributors to the BU code have waived their copyright to BU at the time of the pull request. (I could be wrong on this)
As such BU would need to get the consent of said contributors to change the code to a different license.
MIT is a subset of the GPL and as such it would most possibly to be legal to relicense the code without the consent of past contributors.

As the copyright holder (who is the copyright holder of the BU code?) you can change the license as often as you wish.
But you can't revoke code that was published under a different license in the past.
Everyone holding a copy of the old code with the old license is free to continue to use it under the license it was released at the time.

 

[solex]

@freetrader, Shall I will add this to the list for the next vote?
Note, I added the 3 header lines.

 

[Axel Gembe]

Recent events have shown that corporations are willing to use BU software to further their own aims without contributing back to Bitcoin Unlimited development.

Wouldn't AGPL be a better choice for this? The AGPL is like the GPL, but it also requires sharing the code when you run a derivative work on a network. From Wikipedia:

Both versions of the Affero GPL were designed to close a perceived application service provider (ASP) loophole in the ordinary GPL, where, by using but not distributing the software, the copyleft provisions are not triggered. Each version differs from the version of the GNU GPL on which it is based in having an added provision addressing use of software over a computer network. This provision requires that the full source code be made available to any network user of the AGPL-licensed work, typically a web application.

https://en.wikipedia.org/wiki/Affero_General_Public_License

 

[freetrader]

@freetrader, Shall I will add this to the list for the next vote?
Note, I added the 3 header lines.

Yes, thanks @solex .

@Axel Gembe : I don't think AGPL is needed as this would force people who just change their own client but run it on the network to disseminate their (maybe experimental) code changes.

IMO this would be unnecessarily onerous, and the GPL would sufficient because everyone would be entitled to a copy of changes if the modified program were actually distributed.

So I'm not going to change this BUIP to use AGPL, but if someone else wants to propose a similar BUIP but with AGPL instead of GPL, feel free.

 

[Griffith]

I don't think that the contributors to the BU code have waived their copyright to BU at the time of the pull request. (I could be wrong on this)
As such BU would need to get the consent of said contributors to change the code to a different license.
MIT is a subset of the GPL and as such it would most possibly to be legal to relicense the code without the consent of past contributors.

As the copyright holder (who is the copyright holder of the BU code?) you can change the license as often as you wish.
But you can't revoke code that was published under a different license in the past.
Everyone holding a copy of the old code with the old license is free to continue to use it under the license it was released at the time.

i would assume the BU code is copyright held by BU as an org making a BUIP the only valid way to change its license. Yes you are correct that people using past versions would still have the code under that older license, however newer releases would be able to be completely published under the new license. so yes, you could fork the repo at an old commit and get it under MIT license.

 

[theZerg]

@Griffith You are correct as far as you go, which is code paid for by Bitcoin Unlimited. But we would have to get the permission of every contributor prior to Bitcoin Unlimited forking the code.
[doublepost=1546639004,1546638035][/doublepost]

As you pointed out, GPL can be called 'viral', but I think you are wrong about compilation not being permitted - it is when the resulting program is distributed that the GPL applies.

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.

To my understanding, files that have previously been under MIT license and not modified under GPL license can still be distributed under MIT license, even if they are simultaneously licensed under GPLv3 as well.

Having worked for a many years for a company that dual-licensed GPL and proprietary my understanding is as follows. If we owned copyright to the code, we could change our license to simultaneously distribute under GPL and MIT. But since we do not own copyright to portions of the code, we cannot change the license (for those portions we do not own copyright) to GPL. However we CAN change the portions we have copyright to to a GPL-like license (GPL with a clause that explicitly allows binary compilation and distribution alongside MIT licensed code).

The legality of Bitcoin code is extremely muddled due to people putting nonexistent entities like "the Core developers" in the copyright line. And additionally, note that most BU work is technically independently submitted, not paid for by BU. So any legal argument would first have to determine whether github change records are grounds for copyright, and if not then who is "the core developers". But this is exactly what the original copyright holders wanted I think -- they both gave it away for free and placed tremendous legal ambiguity (i.e. expense) into any subsequent attempt to remove those freedoms.

 

[Griffith]

("We" and "our" refer to BU in my post since BU is the entity publishing all BU code releases. if my assumption about this is wrong please let me know)

@theZerg Afaics we don't need all contributors agreement to change the license because we were given the rights to sublicense. Let me try to explain...

Definitions:
MIT license rights: "the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell"

A sublicense:

As a general matter, a sublicence amounts to a grant by a licensee of certain licensed rights to a third party, the sublicensee. That is, the licensee in effect transfers or licenses some or all of his or her rights to the sublicensee, which means that the sublicence has similar incidents to the primary licence, including the right to exercise independently certain rights enjoyed by the licensee pursuant to its licence. It has been said, in fact, that “a sublicence is simply another name for the indirect granting of a licence”
[reference, more about this reference at the bottom of this post]
​

My Logic:
When we forked the "core" repository, we got the code from "core" under the MIT license. This means that we were granted all the rights listed in said license including the rights to sublicense.

Since that fork, we have been adding our own changes and are publishing our new version where BU is the publisher. When we publish our software, we are using our right to sublicense to publish our software with another MIT license ensuring that the agreement between BU and the 3rd parties using BU software is those outlined in the MIT license.

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. I agree that we would have an issue with trying to change the license under which we received the code, but we aren't trying to do that. We are talking about changing the license we are publishing our software with via our rights to sublicense which only applies between us and the 3rd party using our software.

I would like to note that sublicensing under a different license is not possible in GPLv3 because it explicitly states in the GPLv3 license that "Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License.". This is another reason why i think that by leaving MIT sublicensing in broad terms, one is able to change the license under which their publication is licensed via their right to sublicense.


Feedback
i would like to hear some thoughts/feedback on how i came to my conclusions about our situation. so if you disagree please let me know where


EDIT:
Note about the reference. The reference link is to a case summary in canada's supreme court. The case subject matter isnt super important but for those of you interested, it is about a company granting a license that specifically prohibited sublicensing to another company and the company receiving the license is accused of sublicensing it again which breaches original licensing agreements.
The full quote is actually from a law book by Leslie W. Melville, Forms and Agreements on Intellectual Property and International Licensing, vol. 1 (3rd ed. rev. 1997 (loose-leaf)), at §3.18. It is just used as evidence/a reference point in this court case. To address the question of validity, a quick google search showed me that the book is available in a good number of law school libraries in the US and Canada to which i thought "good enough for me".

 

[freetrader]

Short and sweet - I agree with @Griffith, the code is licensed under MIT with explicit permission to sublicense, as long as we still comply with the MIT licensing clauses of the existing code.

I agree that we would have an issue with trying to change the license under which we received the code, but we aren't trying to do that.

Exactly.