Software Licenses
© 23 Jul 2014 Luther Tychonievich
Licensed under Creative Commons: CC BY-NC-ND 3.0
other posts

Reflections from a decade of reading EULAs.



I am not a lawyer, and nothing in this post is (or should be treated as) legal advice or advice of any kind. Any and/or every assertion in this post may be a complete fabrication or falsehood; such fabrications need no additional identification beyond this notice, and the sole liability for mistaking a false statement for truth (or a true statement for falsehood) lies with the individual, company, or entity making the assumption of truth (or falsehood). This post makes no claim to provide accurate information; to correctly report on, analyze, or characterize anything; or to provide any form of entertainment or other service to anyone. This post is provided “‍as is‍” and any express or implied warranties including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the author or authors or distributor or distributors of this post be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, libel; procurement of substitute information, goods, or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the existence or use of this post, even if advised of the possibility of such damage. Any similarity to identification with the location, name, terms, or history of any person, product, license, or entity is coincidental and unintentional except where such similarity is made unambiguously explicit in the post itself. Views and opinion expressed in this post are the sole creative work of the author and shall not be taken to represent the author’s actual views; the views of any organization or entity with which the author is affiliated or that provides, has provided, or will yet provide support (material or otherwise) to the author; or the views of any entity citing, hosting, or providing access to this post. To treat this post, including but not limited to this disclaimer and all subsequent portions of the post, as anything other than a meaningless sequence of characters is neither justified by the post itself nor by any theory of meaning or intent whatever.

If Licenses are Copyrightable…

I read license agreements. It started out as a general sense that, if I am to be bound by them I ought to know what they contain. Over the years it has become more of a habit, almost a passtime. I’ve read licenses for software I’ve never used and never intended to use.

I know very little about intellectual property law, but I assume that licenses are not copyrightable because most of the licenses I read appear to be mostly verbatim segments of other licenses I’ve read with a few novel bits pasted in here and there. Law appears to have a lot in common with programming: there’s a small set of standard statements that make up the bulk of everything.

Based on this observation, this post quotes several snippets of licenses without attribution.

Automatic Agreement

Many licenses include a passage like this one from Python:

By copying, installing or otherwise using Python, Licensee agrees to be bound by the terms and conditions of this License Agreement.

There’s no room for negotiation. Use the product and the license becomes binding.

Automatic agreement is more troubling for me in paid software. The usual sequence is:

  1. You provide money to gain access to the software.

  2. You void your ability to return the software by opening its packaging.

  3. The software informs you of its licensing terms.

While it is sometimes possible to discover the license prior to purchasing, it is rarely straightforward.

No warranty or liability

Most licenses that I read have the same two paragraphs (usually in all caps) stating that the software is provided “‍as is‍”, declaiming “‍merchantability or fitness for a particular purpose‍”, and asserting the creator/distributor of the software has no liability for any losses related to the software whatever. In other words, “‍don’t sue me.‍”

At one level I find these passages troubling, since software is generally designed with the goal of being fit for a particular purpose; but since I find the accepted grounds for civil suits in my country to be far in excess of what seems reasonable or appropriate, I am in favor of software doing what it can to avoid them.

Purchased software often replaces these “‍no liability‍” clauses with “‍limited liability‍” clauses, typically limiting liability to the amount of money you gave to the company providing the software within some narrow time window before the incident causing you loss.

Public Domain

Some projects waive all rights to the software completely. David Megginson, the author of the Simple API for XML, put it this way:

I hereby abandon any property rights to SAX 2.0 (the Simple API for XML), and release all of the SAX 2.0 source code, compiled code, and documentation contained in this distribution into the Public Domain.

SQLite is a bit more formal:

The author or authors of this code dedicate any and all copyright interest in this code to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this code under copyright law.

Either way, I find it interesting that large, popular systems are built and maintained by people who intentionally give away everything they do. A lot of the world of software is very generous indeed.

Open Source Restrictions

Most of the software I use is open source. Open source licenses generally grant wide-sweeping powers to users, including the right to create derivative works without fee or royalty. However, they also usually include a few constraints. These often include the following:

Keep the license

Most open-source licenses include a requirement that the original license be distributed with any derivative works and continue to apply, unmodified, to those derivatives. Because of this, I have hundreds of copies of licenses on my hard drive, each significant system often coming with a half a dozen distinct licenses.

This also means there is a whole world of “‍-compatible‍” licenses: if my software derives from two different licenses, is the combination of those two licenses even possible? GPL and BSD compatibility are the ones I see discussed the most often, and where the strangest legal issues tend to arrise. For example, Python’s license comes with this footnote:

According to Richard Stallman, 1.6.1 is not GPL-compatible, because its license has a choice of law clause. According to CNRI, however, Stallman’s lawyer has told CNRI’s lawyer that 1.6.1 is "not incompatible" with the GPL.

Some licenses, such as the BSD license, contain almost nothing except a disclaimation of warranty and a “‍keep the license‍” clause.

Provide the source

Some open-source licenses (notably the GPL) require that derivative works are also open-source and provide their source code to anyone who wishes it without fee or royalty.

Protection of Trademark

Many open-source licenses include the rule that the name of the software is owned by some particular entity and that derivative works may not call themselves by the original name.

Non Commercial

Many open-source licenses include a requirement that the licensed software and any derivatives may not be sold or otherwise redistributed for fee or profit. Some are more draconian than others on this point; for example, ParaType’s Free Font License states “‍You may bundle the font with commercial software, but you may not sell the fonts by themselves,‍” while Roadgeek’s fonts come with a license forbids the use of the fonts for any “‍offline, commercial purpose.‍”

Not all open-source licenses contain any version of a non-commercial clause. The MIT license, for example, explicitly grants the licensee “‍the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software.‍”

Changes Visible

Many open source licenses contain the requirement that derivative works notify the user in some fashion of what was changed in the derivative. The most extreme version of this requirement that I recall noticing was The LaTeX Project Public License, which requires each modification to one particular component “‍clearly and unambiguously identifies itself as a modified version of this component to the user when used interactively‍”—that is, even when running the program the change must be identified, not only when looking at the source, license, or packaging.

I used to think that this kind of identification was a bit extreme, but a few years ago the ffmpeg project split into two versions and the differences were poorly identified to the casual user, causing no little confusion. There is reason to make changes visible.

There are other, stranger licenses out there too. One license attached to source code I downloaded once requires that derivatives be distributed only in compiled form only, not as source files. Python’s license includes a page on the history of the software. Several licenses specify particular file names that must be used for license-related information. One actively-developed tool I use has, in its license, the clause “‍The Software was not designed to operate after December 31, 1999‍”; I assume that clause was a lot more common in the late 1990s during the Y2K scare (though I could be wrong; I was not a big reader of licenses back then).

Closed-Source EULAs

Reviewing my current set of software tools of choice, I only use closed-source software as a means of interaction with other users of closed-source software, with the exception of a few web-hosted tools and a few games.

Closed-source licenses Close-source licenses are often called End-User Licensing Agreements, or EULA (Pronounced “‍You luh‍”). are generally more interesting reading than open source, sometimes in a frightening way. Here are a few of the common and not-so-common clauses I find in them.

Don’t look at me

Almost all closed-source license forbid “‍reverse engineering, decompilation, or disassembly.‍” Some go into much more detail: “‍Licensee may not reverse engineer, decompile, disassemble, modify, translate, make any attempt to discover the source code of the Software, or create derivative works from the Software.‍” In other words, you can use the software but you are not allowed to look at it.

As far as I understand the laws (which is not far), these clauses only operate if you actually accept the EULA and use the product. I am not aware of prohibitions against reverse-engineering a program you have never used.

One back-up copy

Several licenses grant the user the right to “‍make one back-up copy of the Software solely for archival purposes.‍” Considering that simply loading the software from disk to memory means making four or five copies in the cache hierarchy and that many file systems duplicate and/or copy files without notice, I find this particular clause a bit odd.

I assume that these clauses were added as the result of some particular law or court case that stated that a back-up copy was legal. I can’t readily imagine why they would be so prevalent otherwise.

Your content

Many licenses describe User-Generated Content and disclaim all responsibilities regarding it. Some of these also give the software “‍the right to refuse to post, edit, or deliver‍” your content or any part thereof for any reason without explanation. I suppose those clauses could result in arbitrary censorship, perhaps removing all occurrences of the names of competitor companies; I have not yet been made aware of such censorship in practice.

Waive rights of dispute

Most EULAs include some kind of waiver of the user’s rights to raise disputes in court, either by waiving the rights to dispute at all or by agreeing to a specific class of out-of-court settlements.

Tell provider about you

Many EULAs include explicit permission for the provider of the software to collect various kinds of information about you and how you use the software. For example, one of the web browsers I use states that it may send the providing company loosely-specified “‍information‍” on installation, each time I start the browser, and “‍periodically‍” while running; it also sends them all text I type on any web page, everything I ever put in the web address specification field, and geolocalizing and web routing information.

Many licenses include privacy language stating that some information flow may be disabled and the uses the collecting entity plans for the data sent; I generally find these privacy clauses less generous to me than I would personally prefer.

Clauses I have not seen

There are ideas I have assumed would be desired by licensing entities but have not noticed in any existing licenses.

I have never yet noticed a EULA that claims anyone who looks at the software’s bytes as a licensee. While the bytes are protected by copyright, I am not aware of prohibitions on disassembling, decompiling, or reverse engineering copyrighted material Such a prohibition, if extant, could probably be stretched to make a case against book reports and plot summaries as examples of reverse-engineered fiction. without explicit license agreements making those prohibitions. Probably this is just a hole in my knowledge of intellectual property law. Even if there is no such prohibition, reverse engineering others’ work is something I discourage and I am opposed to it on principle; but I am surprised I have not seen it in a license agreement so far.

I also keep waiting to see “‍everything you create with this software is solely owned by the software provider’s company.‍” I do see “‍everything gets sent to us‍” but not “‍and we own it thereafter.‍” I seem to notice fads in commercial licenses; for a few years they will move closer to “‍we own you‍” and then there will be a few years of “‍we protect your privacy‍”. Right now we seem to be in one of the privacy protection phases.

I am surprised I have not yet found a license agreement that contains a Gödel-style incompleteness paradox, that contains (or is itself) a quine, or that is infinitely self referential. I’ve seen EULAs that contain clauses granting the provider of the software the immortal soul of the licensee or ownership of the licensee’s firstborn child, so I know these aren’t missing because licenses are always taken seriously. I know that a non-trivial subset of software designers became intrigued by these self-referential oddities when they were introduced to them in their computational theory courses. Still, for whatever reason, I’ve never seen them make it into a license.

Looking for comments…

Loading user comment form…