In an earlier post Mark Johnson responded to recent commentary about unlicensed code on Github. Mark criticised the idea put forward by some pundits that developers not licensing their software project was some kind of movement. Instead Mark sees it as emerging from a lack of education (or, quite possibly, sheer laziness). He also reiterated the point that a lack of licensing clarity discourages community and harms reuse and sustainability of software. Experienced developers won’t touch unlicensed code because they have no legal right to use it.
However, I decided to follow up by seeing if I could start from the other end of the argument and identify some good – or at least acceptable – cases for where you might legitimately make your source code available intentionally without applying a license.
Here’s what I’ve come up with.
Deferring the licensing decision
Licenses interact with your choice of business model. For example, some licenses are more useful than others when pursuing a dual-licensing strategy; some make more sense for software that provides online services; and each license provides some degree of advantage over others for particular cases (if there wasn’t, there wouldn’t be so many of them!)
However, for some projects its hard to identify early on what the business case is going to be, or even if there is likely to be any point developing one.
Your software experiment may turn into a liberally-licensed library, a copyleft and commercial dual-licensed application, or a service offered under something like the CPAL or AGPL, but maybe its too early to tell. Should you keep it under wraps while you work out where its going, or share it now and risk selecting the wrong license?
Releasing your code with no license while you are still deciding on an appropriate model is one possible option. The downside of this is that no-one will really be able to reuse your code until you do apply a license, and it is also likely to deter potential collaborators.
So even here I’d still recommend choosing a license and revisiting the choice later as the project matures: as the owner of the intellectual property for your software you always have the option of changing your mind, and your license, later on.
Changing licenses for software can be controversial and difficult, but at least you have more chance of developing a user community and partner network to have this argument with by making the initial code available under a recognised license.
Note that its also much easier to change from a more restrictive license to a more permissive one than the other way around.
Software as evidence
There is a type of project where releasing code but not licensing it (effectively sharing code with all rights reserved) may make sense. This is where you have no interest in anyone else actually reusing your code, or building on it, or contributing to it!
Why on earth would you want to do that? Well, when the purpose of releasing the code is not to create viable software, but instead to provide transparency and reproducibility.
For example, if you have written software as part of an experiment, and you need reviewers to be able to replicate or inspect your work. In this case, there is no real expectation that anyone will take your code and reuse it for something else, or integrate it into any kind of distribution.
So maybe then you can just distribute the code, but not as open source or free software?
One reason why that may not be a great idea is that no-one else being able to make use of the code is just your perspective; from another perspective, maybe your code has a value you don’t realise? As Scott Hanselman points out, you can think of this kind of these projects as a “Garage Sale” where one developer’s junk is another’s treasure.
You may also be concerned that, by distributing your code under an open source license you may be raising expectations of what the code is for, or inviting a critique of your software development skills; this is a theme that Neil Chue Hong picks up on in a post over on the SSI blog. (Neil even points to a special license, the CRAPL, aimed at this sort of case.)
Even for very specialised academic code aimed at a single objective for a single paper in a specialist journal, the case can be made for releasing the code as Free or Open Source software.
(For another good discussion of this topic, see Randall LeVeque’s post Top ten reasons to not share your code (and why you should anyway)
The Contractual Obligation Software Project
Sometimes you get to work on a project as part of some sort of funded initiative, which, while not stipulating sharing your code as open source, does expect you to at least make the code “available” in some fashion.
So, like an artist locked into a record contract, when the funding runs out you may be tempted to just make a code dump somewhere in order to meet your obligations, and in a fit of spite not even bother put a license on it either.
However, the “garage sale” metaphor works well here, too. Maybe the project or initiative didn’t exactly set the world on fire, but maybe some of the code written in the process could still be salvaged for something.
Gists and examples
You often find code snippets in blog posts or as solutions to questions on StackOverflow. This is very rarely explicitly licensed, but the assumption is that its usually OK to copy and paste without worrying too much about licensing. If you’re conscientious, you can always pop in a comment with a link to where you found it.
However, there are also grey areas, such as Gists, which are a bit more than a few lines of code, but not quite project in their own right.
Even with a small snippet of code, its not always clear whether or not copyright protection applies. For example, a lengthy example of how a standard Java library should be used would probably not be protected as it doesn’t involve much creativity. However, a two-line program that offers a novel solution to a problem could well be considered protected under copyright.
So, in some cases you may be justified in not bothering with a license for a snippet or Gist, but to avoid all uncertainty its still better to put in a license header, or at least make it clear you’re willing to license the code for anyone who wants it that thinks its necessary.
Creating Fear, Uncertainty and Doubt
OK, I wouldn’t say this is a great reason, but it could be a reason.
Maybe you really do want to make people uncertain about whether they can use your code because … well, because thats the way you roll.
Maybe you’re happy to license your code, but only with people who ask you nicely first, and you don’t want them to be able to distribute their code as free or open source software for some reason.
Or maybe you are looking to bait the uncautious into copying your software so you can threaten them with lawyers and shake them down for money, because you are actually a Copyright Troll.
Not necessarily wise, but not necessarily evil either
From this brief excursion I would conclude that distributing unlicensed code is never a great idea, and rarely even a good one, but I can see there are circumstances where you might consider doing it. In each case, though, there is usually a better option worth taking.