There’s a useful guide at GitHub for choosing an open source license. The guide presents a developer with three distinct options:
These capture three common, primary concerns that show up once one has made the decision to be open with one’s source code. Simple, permissive licenses include MIT’s (which GitHub links to) and the BSD license (which GitHub doesn’t note). Open licenses that address patents include Apache 2.0 (GitHubbed) and OSL 3.0 (not GitHubbed) and GPL 3.0 (GitHubbed in the next category). If one wants to ensure that improvements, if made public, are shared on common terms, then the GPL 3.0 is a good choice (though there are drawbacks as well).
For each category, the Chooser provides an illustrative license with a summary. Here’s the start of the Apache 2.0 description:
Again, nice layout, clear text, informed design. Alongside this information runs a side bar that explains how to use the license. Below is the full text of the license. This is really helpful stuff–well executed by knowledgeable people.
If the first three options don’t work, in good Marx brothers fashion, they’ve got more:
Following the links leads to additional discussions of licensing strategies, including using Creative Commons licenses for documentation. GitHub’s license chooser provides a way for developers to quickly incorporate a license into their project. GitHub provides documentation and scripts to install a license with minimal technical work. There’s another benefit of this approach–while developers have choice among any license they want, including the most happy WTFPL–the selection of choices provided with support by GitHub helps to decrease the random variation among licenses. If the MIT and BSD licenses pretty much do the same job, simplify the choice set by picking one and letting it stand for the category.
If you want to see a much broader range of open source licenses, then the Open Source Initiative is a good place to start. OSI has created a definition of “open source” and describes licenses relative to that definition. The OSI definition requires non-discrimination for users and use–thus, one cannot using the OSI definition of “open” source have different terms for commercial uses or for large organizations than for nonprofit or private or small organization use. That’s a nit, but for folks who have bought into the definition, non-discrimination is a big issue.
There are reasons to curate code rather than release it happily to the winds. We ran into semantics issues in making source code available but restricting certain modified distributions–we wanted to establish the code base in a new standard and didn’t want early users gutting the standard and reverting the code to the old standard (it would be like replacing H.265 coding with FLASH-ugh!). So we called source access with limitations “source available.” Most every modification that didn’t mess with standards implementation we approved immediately. But the discrimination was enough to send some open source organizations into a deep tizzy, then funk, then hatred, and then efforts to destroy our distribution with a competing, “open” version. Actually, it was a “free” version, which we should discuss next.
Another good discussion of open source licenses is provided by the Free Software Foundation, the authors of the GNU General Public License–GPL–and its versions and variants. For the FSF, “free” means “free as in speech” not “free as in beer.” The idea is, code is expression and people should be free to adopt that expression, use it as they please. The FSF guide to licenses discusses which licenses are “free” and which are not. Merely being “open” does not meet the requirements of “free.” Richard Stallman’s statement of why software should be “free” is still an excellent starting point to understand the thinking behind free software.
Free licenses do not have to be without charge–that is, not with a price of “free”–but once someone has purchased the code and license, they are free (as in speech) to redistribute it at no charge (and with source). Thus, a price point gets maintained only by the grace of the user community (and differences in warranty offers)–people pay because they want to pay, not because they are forced to. This concept is utterly alien to most IP attorneys and the university administrators they advise. It’s not a difficult concept, really. We pay all the time without having to–we tip, we donate, we volunteer, we waive off the costs, we go to potlucks and BYOBs. We also are willing to help with free software (and with open source software; and with software with source available that is open in a general way but not in an OSI or Free way).
The issue comes up–why even have a license with software? The answer starts back with changes in copyright law–specifically the 1976 Copyright Act that allowed publication without notice or registration without immediate loss of copyright, the 1980 decision that software could be protected by copyright (as a “literary” work), and the 1988 ratification by the U.S. of the Berne Convention on copyright, making copyright protection automatic as a “right of authorship” rather than a statutory grant following obedience to formal rules (such as placing a notice or registration with the government).
Put these changes together and source code that once could circulate in the public domain simply by being made available without copyright notice or registration became owned by someone–the problem was finding out just who, and what they expected. A work can circulate now without a notice, without registration and still enjoy copyright protection. A copyright owner might have some work to do to be able to enforce a copyright or obtain statutory damages for infringement (such as registering the copyright), but a user is exposed to claims unless there’s a dedication to the public domain or a license. (There are all sorts of other problems with copyright law and software–is a computer’s copying code from storage to RAM allowable without permission? Are source code and object code really the same “work”? When html text is rendered on a user’s screen, is the copying from a network server to local memory a permitted act? is the resulting text a public display? a transmission? a distribution? Angels, meet your pins; all tempests, report to the teapot staging area.)
Quite apart from the details of formalities, there are good reasons to consider a license–not necessary in “legalese” but rather to make clear your intentions as owner of a property right that others have access to. There’s a good discussion of the rationale for adding a license to open source software at Coding Horror. If there’s no statement of use, then it’s unclear what an owner’s intent is. It is like coming upon a piece of land that’s not posted–there must be an owner, but it’s not at all clear if the owner is friendly or hostile, sneaky or candid. If a piece of code has been abandoned, then there are defenses if someone later asserts infringement–laches (delay) for instance.
Code that is not maintained by an active owner becomes “abandonware” or “orphaned.” The uncertainties of such code mean that one has to avoid them, use them with some risk of being caught up in a surprise claim, or clean-room the development (isolate someone to inspect the code and write a specification; pass the specification to someone isolated from the original code to write new code–infringement requires access + substantial similarity, so remove the access part and rebuild a functional equivalent). All of which is a bother. For university “technology transfer,” it’s even worse, because poorly designated code simply means it is less likely to be used. All that work to create something to avoid, a totem of an evil, angry god who is not your friend.
Software developers at universities face multiple problems in dealing with their university licensing operation. One issue involves ownership. Why is software produced by a computer science faculty member not scholarship? (It is scholarship, often!) Another issue is choice of license. The FSF has advice for programmers: refuse to finish a code if the university won’t allow you to release it “free.” And it’s worth keeping in mind that university attorneys, when they hear “license” think “document” rather than promise not to enforce. A license can be as simple as “As far as I’m concerned, you can do what you like with my software.”
A document recording this promise, with a capable attorney being paid by the hour, can run to scores of pages of legal banter, all supported by form book language recording every end-run, ever cleverness, every blow that every laid anyone down. Multiple pages can be devoted to liability (user assumes all risk, disclaimer of endless list of liabilities, user indemnifies for damages, user will defend against claims, user carries insurance that names university as co-insured, user will provide documentation of insurance, insurance limits specified, notice of any change in insurance… you get the point–now do this for every frickin’ detail in the proposed arrangement, from definition of parties to usage (headings aren’t part of the agreement, plurals and singulars mean the same thing unless they expressly don’t, capitalized words have meanings given in the document unless context indicates otherwise, and on and on).
Not only does such a license require careful (and expensive) legal review–often university drafters get things awfully wrong–but also the challenge (and expense, and delay) to negotiate changes (even to fix gross errors or insults) is formidable. I’ve seen attorneys from public universities argue for weeks over governing law: “We can’t use Texas law because we are the state of California.” “Well, y’all better git on yer horses, because we here being the state of Texas will never accept California law.” Or something like that, minus the dialect. Sigh. Use Hawaii law and venue, and test the venue for dispute resolution once a year. Usually, after about two months, attorneys will decide to drop the venue clause, or turn it into an even more complicated tangle–California law for stuff happening in California, Texas law for stuff happening in Texas, but before any litigation, three pages of dispute resolution not using escalation, mediation, arbitration….
It’s then not just a matter of including a license as a statement of owner’s intentions, but also one of making the license immediately understandable–clear, direct, to the point, without a creating a mess of ill-chosen words, clever minefields, and useless detail. In this, the open source community has done a great job (other than perhaps the GPL 3.0 license, which becomes a convoluted mess trying to navigate its own ideology). The open source setting is not the only place where statement of intention matters–stating clear intentions is a general “must do” for all university IP.