Given that an open, transparent, distributed p2p network is a central element of Bitcoin project it seems unusual that it is licensed under the MIT license which allows proprietary closed source derivitives.

MIT licence is less restrictive than for example copyleft, giving you freedom to do more with it. It allows people to make the choice of whether they want to give their source code away or not, which can draw more people in to work on the project than if they wouldn't have that option.
– ThePiachuNov 4 '11 at 21:15

2 Answers
2

If the only library is closed source, then there's a project to make
an open source one.

If the only library is GPL, then there's a project to make a non-GPL
one.

If the best library is MIT, Boost, new-BSD or public domain, then we
can stop re-writing it.

I don't question that GPL is a good license for operating systems,
especially since non-GPL code is allowed to interface with the OS.
For smaller projects, I think the fear of a closed-source takeover is
overdone.

Using a more restrictive license would have slowed adoption. The biggest obstacle to Bitcoin is lack of adoption. Anything that would restrict the set of things people can do with Bitcoins or make it more expensive or more difficult to use them in particular ways increases the chances that Bitcoins never get significant penetration.

Some Bitcoin uses involve proprietary, closed source derivatives. How would it help Bitcoins to discourage those uses?

But the actual historical reason is even more important. If the Bitcoin client had been licensed under the GPL, anyone who wanted a proprietary client would have to recreate it. That would create a whole host of real problems that would harm the usefulness of the Bitcoin system.

For example, say the developers want to add a new type of script. Right now, they can add support for that script in the official client and everyone will have it in a few months. But if there were proprietary versions, they may never be able to cost justify adding the new scripts, and this could cause adoption of the new scripts to fail. If a new currency supported those scripts and forks meant Bitcoin didn't, that could make Bitcoins fail.

Or say there was a bug in the client that caused it to accept blocks that are subtly invalid. If the network had a significant number of clients separate developed, they might reject those blocks while the official client accepts them. If fewer than 50% of the network runs the official clients or miners tend to run the proprietary clients, this could result in a serious network fork that would be very painful to resolve.

Another problem would be if different clients wind up using different attack resistance methods. If one client passes a message another client considers abusive, attackers could exploit this to isolate nodes from the rest of the network. Having all clients use the same logic for validating messages avoids this attack method. (If X punishes nodes for it, X also won't pass it to other nodes. So if other nodes follow the same logic as X, X will never get punished. But if X passes a message Y punishes for, sending that message to X will result in X not punishing you, but X getting punished by Y.)

Revisiting this two years later there are as of yet no proprietary clients being distributed. There is a lot of proprietary work done in the Bitcoin "ecosystem" but these are specific internal implementations which would have been compliant with a GPL style license anyways. Sadly what has restricted alternative development isn't licensing but the fact that there is no independent library. The QT (reference) client is a library, full node implementation, and a specific wallet all rolled into one codebase with the major functions horribly interdependent. Maybe someday this can be refactored.
– DeathAndTaxesAug 1 '13 at 18:06