Components and GNU Licensing

From Open Transactions
Jump to: navigation, search

Open-Transactions is available under the MPLv2 license. The main components of Open-Transactions are the core library, the client API, the 'opentxs' command-line tool, the opentxs-notary server, and the Moneychanger GUI desktop application.

RELAXATION IN LICENSING: In 2015, the Open-Transactions licensing relaxed from AGPLv3 to MPLv2. What was our rationale for the change?

First, MPLv2 is much more business-friendly than GPL. For example, you can use MPL'd code files inside proprietary software projects. And importantly, you can also use MPL'd code to build apps for the Apple App Store and the Google Play Store. (This is important for making OT available on mobile devices.)

Importantly, MPLv2 is still a copyleft license, similar to GPL. The license terms mandate that improvements made to the OT source code itself must be released back to the open-source community under the MPLv2 license. This ensures that the open-source community will continue to benefit from any improvements made to OT by commercial entities.

The MPLv2 license is fully-compatible with GPLv3, as well as with BSD/MIT licenses and proprietary licenses. This means OT can be utilized in any software project, including any commercial project, without fear of legal repercussions.

The OT code base has many different contributors, and so the open-source community will never have to worry about a single copyright-holder trying to regain control over how it is used.

Free Software Movement.

Copyleft licenses create a protective legal buffer zone so that a long-term community can build around the software, safely contributing to it in a consortia-like arrangement, to the benefit of all, even amongst a large group of business competitors (see Linux, for example.) Copyleft licenses create an incentive for separate entities to plow money into development of the software, without any fear that their competitors will simply copy the code without reciprocating.

David Wheeler explains why a copyleft license like GPL can benefit a software project, on his blog:

GPL, BSD, and NetBSD - why the GPL rocketed Linux to success

Charles M. Hannum (one of the 4 originators of NetBSD) has posted a sad article about serious problems in the NetBSD project, saying "the NetBSD Project has stagnated to the point of irrelevance." You can see the article or an LWN article about it.

There are still active FreeBSD and OpenBSD communities, and there's much positive to say about FreeBSD and OpenBSD. I use them occasionally, and I always welcome a chance to talk to their developers - they're sharp folks. Perhaps NetBSD will partly revive. But systems based on the Linux kernel ("Linux") absolutely stomp the *BSDs (FreeBSD, OpenBSD, and NetBSD) in market share. And Linux-based systems will continue to stomp on the *BSDs into the foreseeable future.

I think there is one primary reason Linux-based systems completely dominate the *BSDs' market share - Linux uses the protective GPL license, and the *BSDs use the permissive ("BSD-style") licenses. The BSD license has been a lot of trouble for all the *BSDs, even though they keep protesting that it's good for them. But look what happens. Every few years, for many years, someone has said, "Let's start a company based on this BSD code!" BSD/OS in particular comes to mind, but Sun (SunOS) and others have done the same. They pull the *BSD code in, and some of the best BSD developers, and write a proprietary derivative. But as a proprietary vendor, their fork becomes expensive to self-maintain, and eventually the company founders or loses interest in that codebase (BSD/OS is gone; Sun switched to Solaris). All that company work is then lost forever, and good developers were sucked away during that period. Repeat, repeat, repeat. That's enough by itself to explain why the BSDs don't maintain the pace of Linux kernel development. But wait - it gets worse.

In contrast, the GPL has enforced a consortia-like arrangement on any major commercial companies that want to use it. Red Hat, Novell, IBM, and many others are all contributing as a result, and they feel safe in doing so because the others are legally required to do the same. Just look at the domain names on the Linux kernel mailing list - big companies, actively paying for people to contribute. In July 2004, Andrew Morton addressed a forum held by U.S. Senators, and reported that most Linux kernel code was generated by corporate programmers (37,000 of the last 38,000 changes were contributed by those paid by companies to do so; see my report on OSS/FS numbers for more information). BSD license advocates claim that the BSD is more "business friendly", but if you look at actual practice, that argument doesn't wash. The GPL has created a "safe" zone of cooperation among companies, without anyone having to sign complicated legal documents. A company can't feel safe contributing code to the BSDs, because its competitors might simply copy the code without reciprocating. There's much more corporate cooperation in the GPL'ed kernel code than with the BSD'd kernel code. Which means that in practice, it's actually been the GPL that's most "business-friendly".

So while the BSDs have lost energy every time a company gets involved, the GPL'ed programs gain every time a company gets involved. And that explains it all.

That's not the only issue, of course. Linus Torvalds makes mistakes, but in general he's a good leader; leadership issues are clearly an issue for some of the BSDs. And Linux's ability early on to support dual-boot computers turned out to be critical years ago. Some people worried about the legal threats that the BSDs were under early on, though I don't think it had that strong an effect. But the early Linux kernel had a number of problems (nonstandard threads, its early network stack was terrible, etc.), which makes it harder to argue that it was "better" at first. And the Linux kernel came AFTER the *BSDs - the BSDs had a head start, and a lot of really smart people. Yet the Linux kernel, and operating systems based on it, jumped quickly past all of them. I believe that's in large part because Linux didn't suffer the endless draining of people and effort caused by the BSD license.

Clearly, some really excellent projects can work well on BSD-style licenses; witness Apache, for example. It would be a mistake to think that BSD licenses are "bad" licenses, or that the GPL is always the "best" license. But others, like Linux, gcc, etc., have done better with copylefting / "protective" licenses. And some projects, like Wine, have switched to a protective (copylefting) license to stem the tide of loss from the project. Again, it's not as simple as "BSD license bad" - I don't think we fully understand exactly when each license's effects truly have the most effect. But clearly the license matters; this as close to an experiment in competing licenses as you're likely to get.

Obviously, a license choice should depend on your goals. But let's look more carefully at that statement, maybe we can see what type of license tends to be better for different purposes.

If your goal is to get an idea or approach widely used to the largest possible extent, a permissive license like the BSD (or MIT) license has much to offer. Anyone can quickly snap up the code and use it. Much of the TCP/IP code (at least for tools) in Windows was originally from BSD, I believe; there are even some copyright statements still in it. BSD code is widely used, and even when it isn't used (the Linux kernel developers wrote their own TCP/IP code) it is certainly studied. But don't expect the public BSD-licensed code to be maintained by those with a commercial interest in it. I haven't noticed a large number of Microsoft developers being paid to improve any of the *BSDs, even though they share the same code ancestries in some cases.

If your goal is to have a useful program that stays useful long-term, then a protective ("copylefting") license like the LGPL or GPL licenses has much to offer. Protective licenses force the cooperation that is good for everyone in the long term, if a long-term useful project is the goal. For example, I've noticed that GPL projects are far less likely to fork than BSD-licensed projects; the GPL completely eliminates any financial advantage to forking. The power of the GPL license is so strong that even if you choose to not use a copylefting license, it is critically important that an open source software project use a GPL-compatible license.

Yes, companies could voluntarily cooperate without a license forcing them to. The *BSDs try to depend on this. But it today's cutthroat market, that's more like the "Prisoner's Dilemma". In the dilemma, it's better to cooperate; but since the other guy might choose to not cooperate, and exploit your naivete, you may choose to not cooperate. A way out of this dilemma is to create a situation where you must cooperate, and the GPL does that.

Again, I don't think license selection is all that simple when developing a free-libre/open source software (FLOSS) program. Obviously the Apache web server does well with its BSD-ish license. But packages like Linux, gcc, Samba, and so on all show that the GPL does work. And more interestingly, they show that a lot of competing companies can cooperate, when the license requires them to.