Topic: Why MIT license for Bitcoin Core Over other Permissive License Alternatives (Read 175 times)

That's true, but brokenness never comes in an absolute form, it's always in some degree.  Better, more comprehensive terms would allow overcoming a greater degree of brokenness.

In any case, the MIT terms I think are generally pretty good. In hindsight I can see ways they could be improved, but even though they failed to get us a summary dismissal (which means they failed their primary purpose) very happy to have them over having nothing at all.

Right.  The vulnerability of concern there is that there is a risk some contributors could maliciously submit patent encumbered submissions without disclosing it then litigate against users.  They'd be countered on the basis of that their actions were misconduct ('cause they induced the infringement) and that the MIT license is an implied patent grant ('cause it gives you permission to USE etc, which you can't do without access to whatever patents there are),  but it would be easier to get a vexatious lawsuit dismissed if the contributors all had to agree to make their work available under an explicit patent grant (in addition to the MIT license).

The normal review process is inadequate because in the US patentees have a year after publication to file a patent and then there is some additional time for the patent application to be made public (and good luck finding it), so it's literally impossible for review alone to close the risk of that kind of attack. (Though I've previously advocated that consensus change proposals be substantially available for at least a year before activation to that it's at least theoretically possible to do a clearance search, if impractical).

Unfortunately even a parallel license with an explicit grant isn't sufficient, since a truly malicious party could make the infringing submissions through some anonymous sockpuppet account... but it at least might help in the case of a confused/misaligned employer or a situation where someone decides to go evil after the fact.

Creative commons specifically recommends against their licenses including CC0 for software.  One reason is that it lacks a disclaimer of liability.

The MIT expat license has what appears to be a strong disclaimer of liability.  Without it, anyone writing the software would be open to defending ruinously expensive lawsuits from users who didn't like how it worked. ... then again, Bitcoin has the MIT license and it failed to provide adequate protection.  ::shrugs::


Years back I'd tried suggesting the project require contributors to adopt apache 2.0 in parallel or a parallel patent grant, but by then much of the people around bitcoin had turned virulently toxic and the endurance of maintainers were already so thin that there didn't appear to be an appetite for it. 

::sigh::  "He who foresees calamities, suffers them twice..."

One thing I know about the MIT license is its simplicity. Simply put.
 Perhaps, Bitcoin core aims to communicate to its vast users that it is still simple to use or navigate and it doesn't need them(users) to also be bothered about new developments that may be of no meaningful concern as long as their coins are safe and transactions are secured.
MIT also has a good reputation. I don't think it really matters if it is Apache 2.0 license or Simplified BSD license. What matters is it works as it should!

It's also kind of a trick question. The answer, IMO is mostly because it was there in the beginning and it still works now. I don't think there has been a lot of discussion about changing it. I have seen some discussions crop up now and then, but nobody really seems to care enough to put forth any kind of effort to change it.

So the simple answer, getting rid of anything that has to do with non restrictive use, more restrictive use, less restrictive use, is purely inertia. It is there and it works, so it stays the way it is.

From the department of...If it ain't broke, don't fix it....

-Dave

Anybody can change anything about the code and do whatever they want, there is just "filters" they have to go through to get them merged into the reference implementation and of course there is a community they have to convince to accept those changes.

CC0 was released in 2009 which is after Bitcoin's release while MIT license existed ever since 1980's.
https://en.wikipedia.org/wiki/Creative_Commons_license#Zero_/_public_domain

MIT license is more common in software, while licenses such as the CC0 tend to be more in creative works. In addition, the MIT license requires a copyright notice in each of its future redistributions and therefore better for the programmer, especially if developing the code for free or being paid indirectly as it happens with some Bitcoin core developers.


You have to distinguish between Bitcoin, which is a protocol, and Bitcoin core, which is a full node program.

I agree with you that MIT license is very permissive for decentralized project like Bitcoin, but I'm very curious to know that why Bitcoin core wasn't launched in public domain? Let's suppose if the core was launched in public domain then wouldn't that be more decentralized because in that case no-one, not even the developers could have any control over it, and anyone could easily modify and add new features to it without any permission.

I'm asking this just out of curiosity and truly I don't have much knowledge related to that stuff. I know something about the licenses like they provide permissions to anyone who wants to contribute to the code, or the developers who want to add some good features into the code, and in that case isn't public domain more permissive?

I think the Creative Commons Zero license would be even more permissive and easy to use than the MIT one, and that license doesn't require the attribution to the original creator. If the reason was permissiveness then both public domain, and CC0 license would provide more freedom.

While both Apache and Simplified BSD also don't have much limitation/resrutction, MIT License is shorter and IMO easiest to understand.


This page is very poor reference to know which license is more popular/widely used. https://github.blog/2015-03-09-open-source-license-usage-on-github-com/ is far better reference, even though it's 8 years outdated.

If you have an open source project and intend to attract more people to work with you and contribute to its development.

MIT license is the best choice because it:

• Less restrictive for copyleft
• It allows companies that build on top of your project to choose whether or not to continue with the project being open source.
• New developers can add more to the project without the need to take permission from the first developer.
• It protects against problems if you find a bug because new projects are not restricted to following specific libraries or specific parts of the program without changing them.

It is suitable for projects in which the community wants to develop more than the desire of the first developer/s.

MIT license is a very simple license that basically has no restrictions which makes it perfect for a decentralized project such as Bitcoin that doesn't want any obstacles in front of its development, improvement and adoption.
This way you can create proprietary software on top of MIT licensed Bitcoin without restrictions but if it were something else like GPL they would have to do everything from scratch.

Here is what Satoshi said:

I was looking around the bitcoincore.org website¹ when I noticed this text towards the end of the web page: It caught my attention because I understand what open source means, but I wanted to know why it was released under the MIT License. Why not other open source alternative licenses like the Apache License 2.0, Simplified BSD License, which are also popular choices?²,³Was this a suggestion from Satoshi?

---

1 https://bitcoincore.org/en/download/
2 https://www.saashub.com/mit-license-alternatives
3 https://fossa.com/blog/open-source-licenses-101-mit-license/