A Quick Guide to Open Source Licensing from The ITAM Review

Best practice

A quick guide to Open Source licensing

23 February 2018

6 minute read

Rich Gibbons

What is Open Source?

Open Source - A Quick Guide

Open Source just means free, yes?

No.

Simply being free does not mean a piece of software is Open Source.

The Open Source Initiative have an Open Source Definition, which is:

Free redistribution
Source Code included
Derived Works allowed
Integrity of the author’s source code
No discrimination against persons or groups
No discrimination against fields of endeavour
Distribution of license
License must not restrict other software
License must be technology neutral

Why does Open Source need licenses?

Putting some software out into the public domain, uncopyrighted and free, may seem like the very definition of Open Source. Anyone can download it, use it, modify it, improve it etc.

However, there’s nothing to stop a 3^rd party taking that free software, making a few changes and selling it as their proprietary software. Users who acquire the software via this channel won’t have the freedom of use that the initial author intended – and that is quite often the antithesis of Open Source software.

Open Source License types

Copyleft

The concept of Copyleft can be attributed to Richard Stallman who, in his “GNU Manifesto” wrote:

“Everyone will be permitted to modify and redistribute GNU, but no distributor will be allowed to restrict its further redistribution”

However, the origins of the term copyleft (in this regard) can be attributed to his friend and fellow programmer, Don Hopkins.

How it works

Anyone creating a derived version of software covered with a “copyleft” license must make their new version available under the same license too.

In its strongest form, a copyleft license places this condition on all the other code that is compiled alongside the open source code, to make the final product. This means if a company used copyleft open source software alongside their proprietary code, they would have to make it all available for free, to comply with the licensing terms.

Examples of Copyleft

A high-profile example of a copyleft license is the GNU General Public License (GPL).

However, there are different flavours of Copyleft – some less restrictive than others. For example, the GNU Lesser General Public License (LGPL) uses a compromise form of copyleft, which means it can be used within proprietary software.

Interestingly, because Copyleft is based on Copyright, any Copyleft license must include a Copyright symbol to be fully correct and compliant.

Permissive

This is often seen as the opposite of Copyleft, as it places minimal requirements on how the software is redistributed.

How it works

The Open Source Initiative describes a Permissive license as:

“…a non-copyleft open source license — one that guarantees the freedoms to use, modify, and redistribute, but that permits proprietary derivative works.”

Examples of Permissive

MIT License, BSD License and Apache License are all well known examples of permissive Open Source licenses.

Open Source doesn’t need SAM…or does it?

If your company develops software, the Copyleft license is a big reason you must pay attention to what Open Source components are being used.

Say one of your developers find a great piece of software online, which would fit perfectly into the project they’re working on. It’s freely available online and will save weeks of time so they incorporate it and your new program is ready for sale.

However, it transpires the software they downloaded was Copyleft protected. If it’s the strictest form of Copyleft, you may not be allowed to charge your customers for your newly created product.

Assuming you don’t want to give it away for free, the product will need to return to development and have the offending Open Source elements replaced, with either Open Source software sourced under an appropriate license model or components developed by the in-house team.

At the very least this will cause delays, exceeded budgets and missed deadlines. At worst, a public product recall and lawsuits.

Why did the developer do it? It could be:

They didn’t realise Open Source HAD license terms
They didn’t understand the terms
They didn’t care

They all show the need for oversight from the ITAM team. Just as you don’t allow people to do what they feel like with licensing from vendors such as Microsoft and Oracle – the same should be true for Open Source software.

To show that Open Source license terms can require the same level of understanding and translation as proprietary terms, consider this passage from Opensource.org:

“LGPL is not “weak” in the same way MPL is, for example. Code from an LGPL project itself is fully reciprocally licensed at a project level. Any code borrowed from it for other uses as well as any alternative uses of the project itself are expected to be fully licensed under the same LGPL. Within the project itself, LGPL is “strong copyleft” just like GPL code, but the resulting executable does not necessarily have “strong copyleft” requirements – it’s effectively non-reciprocal in many uses.”

It’s easy to see how confusion could occur here!

What’s next?

It’s probably safe to say that most organisations haven’t had controls in place around Open Source use up to now, and that leads to a couple of questions.

Do you know what Open Source components are in use within your products and systems?
Do you know how to find out?
Do you have policies in place to ensure Open Source compliance?

There are other questions to consider too:

Do other parts of your business recognise this as an issue?
Can you identify all the relevant areas of your business?
Do you have communication channels with the appropriate people/teams?

Another concern around Open Source is its prevalence within 3^rd party software solutions, the difficulty in detecting this and the holes this can leave in an organisation’s security defences. That however, is another article for another day!

A quick guide to Open Source licensing