I've seen it a number of times. Some great code has been shared on GitHub—it's exactly what I need to complete that client’s project. And… oh drat… the developer hasn't licensed their code.
For a long time as the SilverStripe Community Manager, I would manually raise pull requests on SilverStripe modules to correct this FOSS (Free and Open Source Software) faux pas (lucky that we now have the ever vigilant Helpful Robot on the scene to automate this process).
You may think to yourself, "I'll just go ahead and reuse this". In today's digital sharing culture, who would blame you for thinking this is OK? We flick photos and videos around at the speed of snapchat every day. What's the big deal?
That is, when you express your ideas in a tangible form—be it a funny cat photo or an incredibly useful SilverStripe module—copyright automatically kicks in. It grants you, the creator, a bundle of property rights and freedoms (to use, copy, change, sell or distribute your work). If someone else reuses your code, changing it or distributing it to others, in the word of law, they are breaching your copyright. Unintentionally, of course— as often, this is not what you, the creator really wanted.
"I just posted my funny cat photo. Someone used it on their blog and now a SWAT team has turned up"
Ok, so probably not that bad.
Through the shift in online culture to "share first, care later", a whole generation of sharers are unwittingly breaking the law. Unjust as this is, it's the state we find ourselves in on the web today.
This is not a post about the state of copyright. It's about acknowledging your property rights magically come into existence (like unicorns) through your hard work and there is a simple way to extend those rights for others to enjoy the same freedoms you have as the creator. Just putting your code online is not open sourcing in the full sense of the concept.
If your intention is for others reuse your work, licensing is the way forward. It's not as hard as you think. In fact, it's often as simple as doing your homework and then a copy-paste job once you understand some basics. Through licensing, authors express clearly to the world what they'd like to see happen with their work.
There are lots of different open source licences out there. At the time of writing the Open Source Initiative lists over 70 different Free and Open Source Software (FOSS) Licences.
How do you know which to choose for your open source project? Forget about the licences for a minute and think about what you want to happen after you release your code.
- Do you want others that use and change your code to open source licence their code too—if they decide to share it?
- Are you ok with your code being used by a software vendor that rolls it into a closed source, proprietary product?
- Do you not care and want others to do whatever the heck they want with your code?
- Are you trying to build a community around your application?
These are all questions that should run through your mind.
It's difficult to cover to full array (developer pun intended) of the nuance of every licence, so let's look at 2 common types of licences that should see you through most situations.
I've just spent the last couple of months learning about these on a secondment to the New Zealand Government at the Open Data Programme to help put together open source software guidance for publicly funded software. Check out the work in progress if you're interested.
On to the licenses.
Permissive licenses (BSD/MIT)
This one should be familiar to the SilverStripers out there since SilverStripe CMS uses the Berkeley Software Distribution licence (BSD). Another similar licence is the Massachusetts Institute of Technology (MIT) licence. Essentially, these two are equivalent and have come from two different academic institutions.
These licences grant reusers the broad freedoms to use your code without any obligations, other than to attribute you as the original developer (by retaining the copyright notice in the LICENCE files when someone forks and alters your code).
Permissive licences are simple and easy to understand. It's often used when developers simply don't mind what happens to their code after releasing it. If you are the re-user of the code, there is no obligation to further open source your altered versions if you distribute the code (however, you might make the choice to share it under a permissive or any other licence as long as you keep the original attribution notice).
On the other hand, someone can build closed source software out of your code and sell it rather than share it further. If you're ok with this (or really don't care), then a permissive licence is still a good choice and an open source one is better than none. However, if you object to this aspect of permissive licences, then a copyleft licence might be more your style.
See the full licences for Berkeley Software Distribution licence (BSD) and Massachusetts Institute of Technology (MIT)
Copyleft/share-alike licence (GPL)
The General Public Licence (GPL) released by the Free Software Foundation is useful, should you want to ensure future alterations to your shared code are also made free and open for others to re-use. This is the essence of "share-alike"—I shared my code, so should you; and together we'll have twice the code to play with.
There is a common misconception that the use of the GPL:
a) forces people to release their code; and
b) cannot be used for commercial purposes.
Both are simply untrue!
When you reuse GPL code you only need to provide access to the source code if you distribute the software. When working for a client and delivering them a project using GPL code, this doesn't count as distribution, the "share-alike" doesn't apply. For example, a website that was delivered in a GPL licensed CMS and served up via a web server doesn't count as distribution.
Another thing to note about GPL is the way it overrides other licences when used in mixed licence projects. For example, say, you created a SilverStripe module, licensed this as BSD (permissive licence) and shared on GitHub (you distributed it) and then added a library of code that is GPL. What happens? Well, the module in its entirety now needs to be released as GPL too. And so on. Again, this isn't a bad thing.
What GPL protects from mostly is your code becoming part of someone else's proprietary software without them sharing back. Important or not, commercial and proprietary are mutually exclusive.
There are also a few alternative GPL-like licences that cover different use cases and developer intentions too (though I'm not covering those here in this post; leave me a comment if you'd like to see them discussed in a future post).
You might be interested to check out:
LGPL: really good for libraries of code you want to be share-alike if someone modifies and used in proprietary too
AGPL: useful when the software transmits over a network, for example, a web application via a server or embedded hardware applications.
So there you have it, a reason to care about licensing your work as open source and some useful licences to use. You could also check out the handy licence picker at choosealicence.com.
Make sure the next time you release that SilverStripe module (or any other code for that matter), include a LICENCE file in your repository with the licence that gives your code the freedoms it deserves.
Disclaimer: Please be aware, I am not a lawyer and while I've given some useful things to think about above, it's not legal advice… if in doubt talk to a copyright legal expert, they're nice people.
Post your comment
No one has commented on this page yet.
RSS feed for comments on this page | RSS feed for all comments