The Truth About the Risks of Unlicensed Software

GitHub makes sharing code with others convenient and simple. There are thousands of repositories shared by people who have already solved problems you are facing. But most developers are under-informed about the legal aspects of both sharing and using code found online, whether at GitHub, BitBucket, or elsewhere. You could put yourself or your clients “at risk of take-downs, shake-downs, or litigation.” Ugh!

With the collaborative spirit of open-source software, squaring off with copyright and intellectual property laws can seem like a boring and unneccessary chore. But the reality is that rights can’t be assumed. You’re not protecting your client’s interests if you use “free” software that isn’t licensed, or use software that has feelings-based licensing rather than licenses that have had proper legal review.

Unlicensed Software

Software that doesn’t have an explicit license is under exclusive copyright. That means nobody else can use, copy, share, or change it, even if it’s sitting in a public repo on GitHub. The only rights granted to the public by putting code on GitHub are the rights to look at it and fork the repository to look at it in their own account. That grant comes from GitHub’s Terms of Service, and still doesn’t mean that anyone can actually do anything with the code.

If this sounds a little extreme, check out what GitHub’s own software license education site has to say about code with no license. Particularly noteworthy are their recommendations for users who want to use software that isn’t licensed:

• Ask the maintainers nicely to add a license
• Don’t use the software
• Negotiate a private license

Absent from this list are “go ahead, no worries”, and “it’s fine, it’s not much code”, and “use it, it’s obvious they meant for it to be free”.

Licensed-ish

Sometimes you’ll see in a README file something to the effect of “Use this software for whatever you like, but don’t sell it or claim that it is your own.” Sounds clear, but is legally vague. There are also some snarky licenses that are send-ups of valid licenses, trolling intellectual property law. They might make us snicker, or feel like we’re sticking it to the man, but using them is irresponsible and offers no proven liability protection.

There is a reason that software licenses use the jargon they do, and cover all sorts of nooks, crannies, and exclusions. Legal language is required to hold up in a court of law if there is ever a dispute. Most are also worded so their international application is consistent. Love it or hate it, it is what it is, and as developers it’s our responsibility to be informed enough to not put ourselves, our users, or clients at risk.

If you’re a developer sharing code, don’t use sarcastic licenses or feeling-based statements to convey your intent. They probably do not do what you think they do. If you’re choosing to use software and don’t see a proven license applied to the code, see the three recommendations above.

How to Choose a License

Thankfully, choosing a license—especially for open-source software—is not too difficult. The Choose a License project does a good job helping you decide on an open-source license for the most common situations. Be careful with copyleft-type licenses. Depending on the license, you could inadvertently cause the rest of your code to fall under the same license. For example, using GPL-licensed code in a project commonly requires that all of that project’s code be distributed under GPL.

Here are our recommendations for open-source add-ons:

• Permissive
  • MIT License
  • Apache License 2.0
• Copyleft
  • Open Software License 3.0

OSL 3.0 is a copyleft license like LGPL (note the “L”), in that any changes to the software itself must be redistributed under the same license, but does not “contaminate” other software that it is “linked” to in a project. Its advantages over LGPL are clearer wording, better definition of “derivative works”, and protection against patent litigation. It concerns itself more with the legal and business implications of open-source software, rather than having a political / ethical / philosophical aim.

Whatever your choice, make it clear. Add a LICENSE file to your repository, and include the name and link to the license in the comments of your source code, lest a file make its way somewhere without the context of your LICENSE.

And if you are implementing someone’s software, make sure it has a proper license. If it doesn’t, either politely request the maintainer to add one, negotiate a license, or move on.