#98: Open Source - Licences

Continuing the conversation on Open Source, in this episode I look at common licences.

There are a variety of licences in Open Source - covering legal use and commitments you must abide by. Like any legal contract, its important that you understand what you're committing too.

Or listen at:

Published: Thu, 19 Aug 2021 14:07:40 GMT

Links

Transcript

Hello and welcome back to the Better ROI from Software Development podcast.

In this episode, I want to continue the conversation on Open Source. In the last two episodes, I've given you an introduction. And in the last episode, I gave you an idea of the motivation as to why individuals and organisations would even create Open Source and why it even exists.

In this episode, I want to take a deeper look into licencing.

Before I start this episode, I should really be clear, I am not a lawyer. This is not legal advice. I will talk you through what I believe to be how the licences work and the top licences out there for Open Source. However, you should definitely take your own review on any licences that you adopt.

So an open source licence will cover things like permissions, conditions and limitations. And the things that you need to think about considering is is it licenced for commercial use? Does it allow modification? Does your project need to contribute or provide attribution on any modifications? Can it be redistributed, if so, under what conditions? And what are the liabilities and warranty associated with that licence and that software?

I will be clear, though, while I talk about some of the common licences in place, there's nothing to stop someone creating their own licence. As such, whenever you're using a piece of open source software, you need to look and understand what that licence is. Is it one of the more commonly known, in which case you can understand that fairly simply, or is it a bespoke licence. If it's a bespoke one then I'd certainly make sure that you spend the time reviewing it before allowing it to be used within your software or your systems.

Let's start talking about what the top licences in use. Let's look at the White Source Software Open Source licences in 2021 Trends and Prediction article - I'll provide a link in the shownotes.

Before I talk about what the report shows, I probably should just mention that White Source Software produce an ability to provide governances over the use of source code within your software practise. It provides a system for being able to produce governances over which licences are acceptable so that you've got an ability to police some of this. So if any of this feels like you need work or help, it's probably worth looking at that software. They're not the only ones out there, and I'm certainly not being paid to endorse them, but as I am definitely taking stuff from their article, it only makes sense to provide what they do.

As such, it means they're in a good position to produce data and produce an analysis on what is currently happening in the commercial market.

So from their report, they attribute a top three as being the Apache 2.0 licence, the MIT licence and the GPL V2 and V3 licences.

The Apache 2.0 and the MIT licence are considered to be quite permissive licences.

They allow you to do quite a lot with the source code. They don't really require you to do much in terms of any additional obligations, passed maybe providing attribution.

The ChooseALicense.com website provides this description of the Apache Licence 2.0:

"A permissive license whose main conditions require preservation of copyright and license notices. Contributors provide an express grant of patent rights. Licensed works, modifications, and larger works may be distributed under different terms and without source code."

Whereas ChooseALicense.com describes the MIT licence as:. 

"A short and simple permissive license with conditions only requiring preservation of copyright and license notices. Licensed works, modifications, and larger works may be distributed under different terms and without source code."

The Apache Licence 2.0 and the MIT licence seem very similar and in truth they are. The main difference is under the Apache Licence 2.0, the contributors who provided software into that product are expressly providing a grant of patent rights.

Generally speaking, if you've got software that you're using that's under an Apache Licence 2.0 or MIT licence, you can generally be fairly confident that's good software to use and you won't have a problem with it. Again, I will caveat that with I am not a lawyer and you do need to take your own review on these things.

The GPL V2/ V3 however, part of the GPL family, provides much more conditions and are seen as much less permissive. A description of the V3 licence from, for example, from the ChooseALicense.com website is:. 

"Permissions of this strong copyleft license are conditioned on making available complete source code of licensed works and modifications, which include larger works using a licensed work, under the same license. Copyright and license notices must be preserved. Contributors provide an express grant of patent rights.".

The thing with the GPL licence is it is expecting you to contribute back any modifications. So, yes, you can use the licence, but if you make any changes, they're expecting you to contribute that back to the community.

Now, you may not see that as being a bad thing, that's maybe just seen as being able to give back to add back to the community, but you have to understand what is right for you and your organisation.

And there are other licences that have much stronger licence conditions. In theory, there's nothing stopping any number of conditions being in a licence, which is why I said definitely make sure you review them - and especially ones that are custom that could potentially be any number of revisions in them, including whether or not you're even allowed to use the software at all in a commercial setting. Whether you're able to use it in certain territories or countries. Whether or not you have to actually provide copyright notices and attribution to the original author in your software or any derivative works.

Now, what happens if there is no licence at all, if you're using the software, which has no licence?

Before we talk about no licence, there is different between no licence and unlicensed. ChooseALicense.com actually defines unlicensed as:

"A license with no conditions whatsoever which dedicates works to the public domain. Unlicensed works, modifications, and larger works may be distributed under different terms and without source code."

Now, as much as this is termed unlicenced, this is a licence, it's just a type of licence. And it will expressly say if the software that you're using is under that licence.

Where there is no licence, that's slightly different, that's where there is software, but there is no express definition of which licence the work is under - it isn't telling you. It doesn't tell you. It doesn't give you an idea what it is. At which point I would be quite cautious of that software because you don't know what rights you have.

You also don't know if the owner, the individual providing the software, actually had rights to it in the first place. Do they have the copyright to make that software available? Do they have the rights to distribute?

While I do know people will see software with no licence be attributed to it as being open season. I personally don't. I see that as potentially dangerous territory and something that needs to be checked before it's used. Potentially reaching out to that author and actually making sure they have the rights firstly to distribute the software and then under what licence - and the rights you have to then potentially to use it going forwards.

In this episode, I wanted to talk about the Open Source licencing. With Open Source being so prevalent and the use of Open Source being pretty much everywhere, licencing is becoming so much more of an important factor in how we govern and run our businesses and our software development.

There really can be legal and financial implications of getting this wrong. There can be real business affecting outcomes if we use a licence in the wrong way. If we break any one of those licencing conditions or we break copyright - it's like everything else, there are potential legal ramifications on that, which obviously then would lead to financial ramifications.

You have to think about whether or not that software is providing enough benefit to accept that licence and any risks that may be associated with it.

As I've said in the last couple of episodes, Open Source is exceptionally valuable and it is beneficial to you as an organisation. You certainly will be using open source. It would be almost impossible now to be able to compete in software development to produce good software systems without using some level of Open Source somewhere.

But you do as an organisation need to use and provide some sort of governance around it to make sure that you're doing it in a safe way.

There is, of course like everything, a growing ecosystem around this because it's so important. Software providers like White Source Software provide tools to be able to provide some of that governance checks - to be able to look at some of the software you're using, some of those dependencies you're taking on Open Source product and be able to report back on which licences are in use, allowing you to be able to report on any licences that are not appropriate to your definition. You may be happy to use anything that is Apache Licence 2.0, but not happy to use anything that's GPL V3. And as such, those tools can highlight when a software developer may accidentally add that to a software application - so that you're alerted, so the software team are alerted and they've got an opportunity to resolve it before it becomes embedded within your systems where you're maybe six months, 12 months, 24 months into a lifespan of a product and it's relying heavily on something that you as an organisation cannot be comfortable with because of the licence terms.

So certainly worth looking at that as a potential way of helping to provide that level of governance.

Thank you for taking the time to listen to this episode. I look forward to speaking to you again next week.