Dear developers, do you have a license to build with that (open) software?
This is a guest post for the Computer Weekly Developer Network written by Ilkka Turunen in his role as global director of solution architecture at Sonatype.
Turunen describes himself as a software engineer with a knack for rapid web development and cloud computing, he has technical experience on multiple levels of the XaaS cake.
Sonatype’s open source governance platform (Nexus) is designed to help software developers accelerate innovation and improve application security.
Turunen writes as follows…
Open source has changed the way we build software forever. Gone are the days of the lone pizza-eating team developing carefully crafted software. Today, on average, 85% of the binary footprint of a typical modern application is composed of open source components. It helps cut corners, take care of routines and also not put developers at risk of reinventing something critical, such as encryption or authentication.
In today’s world, there is (typically always) a library for that and it’s ready for your developers to use – for free.
However, ‘free software’ and open source components are not the same thing.
Just like every other piece of software, open source is not free, it is open to use given certain obligations. Fail to make this distinction and your business risks violating copyright law. You might even sign your corporate card to a bottomless round at the bar if you encounter the author of your open source component under the ‘Beerware’ License.
Why should developers care?
Why are licenses important? Can’t I just download the component and move on with my life? I’ve got builds to break and apologies to give!
Even if you get that licensing is important, it’s not exactly a professional endeavour for most of us, unless you dream of a career as a corporate intellectual property lawyer.
Still, a basic understanding of licensing, its obligations and its benefits, is crucial to all of us – it’s vital to protecting the livelihood of the open source community and the hundreds of thousands of developers that have come to produce it. Proper licensing helps developers of popular open source gain the visibility they deserve and help protect against that code being appropriated by some other organisation.
Just like an artist or musician, source-code authors still own their work and it’s protected by copyright. The software ‘license to use’, provides you and others the right to use that software given some obligations you or your organisation needs to fill. No license, no right. Licenses lay down a contract between the original creator and their end users on the way in which a component can be used or distributed by others.
Too often, people assume that OSS licenses allow you to use the code freely, at your own risk, with acknowledgment of the author(s). While true sometimes, many licenses are more complex than that.
On the producing side, new maintainers don’t necessarily give proper consideration to the license they select with the program they’re publishing. It’s easy to click next on that GitHub template readme page, defaulting to one that the author already knows.
What open source licenses exist?
The open source licenses we observe fall into four broad categories:
- Permissive
- Copyleft
- Strong Copyleft
- Non-standard.
Some common examples of permissive licenses are: BSD (Berkeley Software Distribution). MIT License and Apache 2. These licenses generally allow you to use, modify and redistribute the code. The obligation is only to retain the original author’s copyright notices.
A stronger category of licenses is Copyleft. These include the famous GNU Public License (GPL), Mozilla Public License (MPL) and Eclipse public license (EPL) and CDDL. These licenses do come with some baggage, most often containing obligations such as attribution requirements or releasing any changes with the code.
A stricter type of Copyleft license are the so-called ‘strong copyleft’ licenses, like Affero GPL and newer versions of the GPL license. These licenses typically contain obligations such as mandatory sharing of all code that it has been compiled with and public distribution of source code.
The final noteworthy category is non-standard license. These include such classics as Beerware or the JSON license, which simply states “The software shall be used for good, not evil”, which might be a tricky obligation for a corporation to comply with. What is the legal definition of good or evil after all?
Consider components
You must consider the license of every component you use, including all of their dependencies.
What makes this a challenge is the amount of open source typically used; the average application has over 100 discrete components. Some licenses are also not compatible with each other. Licensing authorities such as the Free Software Foundation publish compatibility lists that define what license can coexist in the same piece of software – making the task of selecting the right components more important.
Even if one single component exists that you’re not complying with, no matter how many levels deep, is included in your application, then the entire application may need to comply under those requirements. This has been a lesson learnt by many vendors, such as Symantec.
I recommend every business ask themselves five questions when evaluating licensing:
- What is “distribution” and how does it relate to my organisation?
- How do open source licenses affect patent rights in the software?
- What is the “copyright notice” requirement and how do we comply?
- Do we have “derivative work” and, related, does incorporating GPL code into my proprietary code cause the proprietary code to be licensed under GPL?
The last and most important question is: Do you have an open source policy to guide you on use of “good” licenses or “bad” licenses to avoid? Do you have a list of all the open source you are currently packaging in your products? And if so, do you follow these guidelines? The answer is most likely no. While 57% of developers admit to having a policy, few say that they actually adhere to it.
A good open source licensing compliance effort results in an obligations report – a list of all open source components used, with their respective obligations (often copyright associations) fulfilled. A good example of this can be found in your favourite browsers, typically under the help menus.
How licenses help the community
Open source components, more than anything, are about community. At its core, licensing ensures the ability to come together and work with your peers to create in a way that is fair.
There often is a symbiotic relationship between the open source community and the enterprises that use open source software. Having a good understanding of what works best for a given project can help maintainers get adequately compensated for their work, and not fall in the working-for-free trap. Enterprises on the other hand have become much more willing to contribute back to open source, helping us all stand on each others shoulders. By being one community with fair, transparent rules and adhering to them we get to see further than anyone before.
Turunen: Consider the license of every component used, including all of their dependencies.