Would you sign a license for software that read:
“By placing an order via this Web site on the first day of the fourth month of the year 2010 Anno Domini, you agree to grant Us a non transferable option to claim, for now and for ever more, your immortal soul. Should We wish to exercise this option, you agree to surrender your immortal soul, and any claim you may have on it, within 5 (five) working days of receiving written notification from gamestation.co.uk or one of its duly authorised minions.”?
And that then went on to say? “We reserve the right to serve such notice in 6 (six) foot high letters of fire, however we can accept no liability for any loss or damage caused by such an act. If you a) do not believe you have an immortal soul, b) have already given it to another party, or c) do not wish to grant Us such a license, please click the link below to nullify this sub-clause and proceed with your transaction.”
In fact, 7,500 shoppers did accept the agreement, according to UK retailer GameStation, and “only a few” ticked the nullify box (and received a £5 (roughly $8) voucher).
Now, this was just a license to download a computer game or two, so perhaps there may be some justification for not reading the license in full. But how about the last software you loaded onto your computer. Did you read the End User License Agreement (EULA) in detail, or did you just tick the box? You know, of course, that you probably haven’t actually bought the software, don’t you? All you have done is to agree with the supplier that you are licensed to use the software, usually on a specific machine and subject to whole pile of caveats.
When it comes to the software you use for developing systems or for incorporating in the systems, you are very much more careful, though, aren’t you?
Often this care extends to not using products licensed under the GPL (GNU General Public License). For those opposed to GPL, it is a document on a par with the soul clause in the GameStation license: it is evil and designed to bring down the entire structure of the software business as we know it. For many of its supporters, it is a huge step forward, opening up new opportunities and designed to bring down the entire structure of the software business as we know it.
The GPL is linked to the whole concept of “Free” software. This is a recurrent topic, and the word “Free” is one that is open to misinterpretation. The best definition I have found is to look at the French language, which has “gratis” for “something without cost or charge,” and “libre,” which means “without constraints.” The word is linked to “Liberty.” In mangled French, the idea of Free Software would be “Software Libre.”
I owe the idea behind the use of French to differentiate between the two meanings to Robert Dewar, CEO of Adacore. Adacore has an interesting approach, as the company offers both “commercial” and “free” versions of their development tools, and it also uses the GPL.
I recently heard Robert talking, enthusiastically as he does, at the SPARK User Group. (SPARK is a version of Ada (sort-of) that is formally designed and intended for use in ultra-high-integrity applications. It was developed by Praxis, a company based in the English town of Bath and now part of the Anglo-French Altran Praxis.) At the conference, Robert laid into what he called the myths surrounding the GPL and also laid into those he blamed for creating some of the myths. The session was fascinating, so I caught up with him later and followed up on some of the points. The following discussion is largely based on his comments, but any errors, omissions, or misstatements of Robert’s views, etc., are my responsibility. Nothing in the article should be taken as accepting responsibility for what you, the reader, understands, or any inferences you may draw from reading the article. (Licensing language can be infectious.)
Both an EULA and the GPL are licenses, placing restrictions on what you can and can’t do with software. Whether there has been money changing hands or not, this is different from most other commercial transactions. When you buy, say, an oscilloscope, you own it and can do what you like with it. The relationship with the vendor is limited to the warranty (and to certain elements of consumer law), and the warranty can be void if you do something stupid. (Particularly if the manual says don’t so such and such, and you do.) You can also expect that the oscilloscope will work according to specification. (I had just got to this point when I remembered that most ‘scopes are now software driven and you should have the same expectations of the software in the ‘scope as you have of any other software.) The law in most countries is fairly well established on vendor and purchaser liability.
Software is different. The law on software is still fluid, to the point that in some jurisdictions people prefer to settle cases out of court, as they have no idea which way a court judgement will swing.
But to return to the GPL. Robert’s basic premise is that a GPL is not some weird hippie-dippie nonsense but a very sensible license to cover certain circumstances. However, for lawyers accustomed to the standard lawyer-speak of contracts and licenses, the preamble to the GPL can come as a shock, with its talk of copyleft and freedom. When they manage to get past the preamble, then the terms of the GPL (now in version 3) is very lawyer-like, and they can begin to understand the benefits.
In Robert’s view, the GPL is much less restrictive than the equivalent license from, say, Microsoft. Yet companies who happily accept the Microsoft license balk at GPL. One reason for this is that Microsoft itself has been a leader in attacking Open Source Software and the GPL. The Halloween documents, leaked from Redmond, make it very clear that Linux and open source software is seen by Microsoft as a serious competitor that has to be fought by any means available. (And as we know, Microsoft is a mean street fighter.)
In theory, one great use for GPL is software development tools. You use the tool, and you can even modify it for your own needs, but the output from the tool can be covered by a normal commercial license, and you don’t have to reveal any source code. This might work, for example, with source code analysis tools and, at first glance, with compilers. However, the compiler model falls down in the real world, since the compiled code will almost certainly include elements from a library. And the library may itself have restrictions. In fact, within the open source community this is an area of debate. The library for GCC, the GNU Compiler Collection, is covered by an exception to the GPL, and it appears that not everyone is in agreement as to what this means.
There is a general belief that if you make changes to source code you have acquired under GPL, then you have to make these changes public. Robert dismisses that. If all you do is use the changed source in-house, then that is fine. No one is forcing you to disclose anything to anyone. If, however, you choose to distribute the modified code then, under the terms of the GPL, you have to include your new source code.
If the software you are acquiring is never going to be redistributed, or if it is only to be used to create products that you are only ever going to use in-house, then free software under the GPL may be exactly what you need. This obviously includes teaching, research, hobby development, or even evaluating the viability of a commercial development.
If, however, you plan to redistribute the software, think carefully before you do – is this central to your role as a company? Then look very carefully at the GPL. It may be appropriate or it may not.
And if your in-house use is safety- or mission-critical, or if you plan to sell software and products on a commercial basis, then do you want more than the software? You probably need warranties in all senses of the word from your supplier, and you will probably need support from the supplier. For these the supplier is going to want to be paid, and this changes the relationship.
So the message is – choose the right license, be it commercial or GPL, for the task in hand.