-
Notifications
You must be signed in to change notification settings - Fork 0
Components
Open Transactions is quickly turning into a family of components:
NAME: Xml-OTC……….— A file format…………….LICENSE: GNU Free Documentation License ? Unlicense? RFC?
NAME: Xml-OTX……….— A messaging protocol…LICENSE: GNU Free Documentation License ? Unlicense? RFC?
NAME: OTTP……………— A URI format……………LICENSE: GNU Free Documentation License ? Unlicense? RFC?
NAME: OTLib…………..— A class library…………..LICENSE: LAGPLv3
NAME: OT-API………….— A Client API…………….LICENSE: LAGPLv3
NAME: OT-Server……..— A Server Application……LICENSE: AGPLv3
NAME: testwallet……..— A command-line client….LICENSE: LAGPLv3
NAME: Moneychanger…..— A Java Client App……….LICENSE: GPLv3
— Xml-OTX, which describes the internal OTMessage format (a russian-doll metaphor of nested, signed contracts) and Xml-OTC, which describes the basic file format it is based on, will be fully illuminated in as-yet-unwritten RFCs (I guess.)
— OTLib is the core foundation library of OT’s C++ classes, and comprises the bulk of the code. (Though it doesn’t include any transport code, server code, or client code.) Classes such as OTToken, OTMint, OTCheque, OTMessage, OTIdentifier, etc can be found here.
— The OT-API implements the client side of the Xml-OTX protocol. The OT API is the high-level interface that most developers will actually use. OT also includes interfaces for Java, Ruby, Python, Php5, Perl5, LISP, C, C++, etc.
— The OTTP URI Format (incomplete) Would enable Open Transactions links to be added to HTML and other hyperlinked media. (Open Transactions requires client-side processing and storage, for verifying receipts, withdrawing cash, signing cheques, etc.) The use of OTTP URIs would allow web developers to link to OT resources, which could then be processed on the client side with the user’s approval (and via the user’s GUI.)
— The OT Server (transaction.exe) is a software implementation of the server side of the Xml-OTX protocol.
— The testwallet is a command-line test program — a software implementation of the client side of the Xml-OTX protocol.
— The TestGUI is now called Moneychanger and it’s a client GUI that operates via the OT-API (in Java).
Licenses
GPLv3: You are required to open-source your code if it links to this OT code, but only if you are distributing binaries of your own code. If you are instead running your code on your website only (so-called “software as a service”), and you are not distributing binaries, then you do not have to open-source your own code in order to link to this OT code.
LGPLv3: Whether you are distributing binaries, or “software as a service,” either way, you may use this library without having to open-source your code. However, if you are distributing binaries, and if you make any improvements to the OT library itself, then you must make those improvements available (your own application code may remain private, but improvements to OT must be shared.)
AGPLv3: Whether you are distributing binaries, or even if you are only using this OT code in your website — so-called “software as a service” — either way, your own code that links to OT must be open-source as well. (Otherwise contact the developer for an alternate license.)
LAGPLv3: Whether you are distributing binaries that link to the OT-API, or whether you are using the OT-API in your website — so-called “software as a service” — either way, your own code may remain private, but any improvements to the OT library or API code itself must be made available open-source.
Just as the LGPL is written as a set of additional permissions on top of the GPL, so in like manner, the LAGPL is written as a set of additional permissions on top of AGPL. The LAGPL license starts with the AGPL (closing the software-as-a-service loophole) and then it grants the additional LGPL permissions, so that developers can use the OT-API even in their proprietary code.
RECENT RELAXATION IN LICENSING:
Open-Transactions recently relaxed the OTLib and OT-API licensing from AGPL to LAGPL.
Links:
Free Software Movement.
The GNU license creates a protective legal buffer zone so that a long-term community can build around the software, safely contributing to it, to the benefit of all, even amongst a large group of business competitors (see Linux, for example.) The license creates 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.
My rationale for this below, from David Wheeler’s blog: http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd
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.