Open Source Software and Licensing¶
With tech giants like Google, Microsoft, Amazon, Apple and IBM all using Open Source Software (OSS) across many different platforms and services, it seems par for the course that any size company looking to either keep pace or leapfrog past their competitors should strongly consider leveraging the OSS community. No matter what industry.
You may be planning for such a project and along the way, there will be a need to consider what types of software and what types of licensing that your project will depend on. You probably have some thoughts in mind such as:
- Do I need to adopt open source or proprietary software? Or a little bit of both?
- How does licensing typically work in these different scenarios?
- Do open source Software licenses allow for unrestricted commercial redistribution and use?
In this article, we provide an introduction to OSS including details about licensing, to give you an idea on how to get started.
What is Open Source Software?¶
Open Source Software (OSS) was born in the late 1990s. Industry leaders met to reflect on the success of Netscape's decision to provide the source code for their popular Netscape Communicator Internet Suite. The group identified that the term 'free' was too ambiguous, and that a different terminology or phrase needed to be chosen. The term 'open source' was coined. The act of open sourcing code, as seen with Netscape, paved the way for software users and developers to collaborate among a much larger community than before.
There are many benefits to using OSS. A survey by GitHub and the broader open source community helped identify what is most important to OSS users. Most notable were Stability and Security. These traits were identified due to such a large community of developers, engineers and hackers who have visibility on, and can provide valuable feedback to any OSS project. On the other side, the school of thought is that proprietary (closed) software has limited code review and/or visibility, in turn being more susceptible to bugs or exploits. Also code reuse is something to consider as a tremendous advantage in using open source projects.
In terms of the impact that OSS has had across many different industries: “...These days, many programs are 20 percent original code on top of 80 percent previously open-sourced code”, zdnet.com.
Practically speaking, OSS is a decentralized model to develop software in which the copyright holders of such software, allow the code to be reviewed, changed and redistributed for any purpose, i.e: commercially, under open source or free licenses. Not to be confused with Shared Source, where the source code is simply allowed to be viewed (and in some cases modified).
In contrast, proprietary software that is licensed is typically provided closed source, as a compiled or binary format. In some cases, it can be provided open source to the customer, with the stipulation that any modification to that code becomes the intellectual property of the licensor. These details are typically governed by an end user license agreement (EULA), in which the license allows the individual or company adopting such software to be used (but not owned) as a part of their final product. If you intend to modify proprietary source code, and include that code in your product, be sure to review in detail the EULA for the particular software.
See also Copyleft (aka Restrictive) and Non-Copyleft (aka Permissive) below, for further important details about types of open source licenses.
For a more exhaustive definition of OSS, see: The Open Source Definition on opensource.org.
Below is a list of examples with companies, software of note and whether the software is open source or proprietary:
| Company / Author | Software | Open Source or Proprietary |
|---|---|---|
| Apple | iTunes | Proprietary |
| Microsoft | Windows | Proprietary |
| Adobe | PhotoShop | Proprietary |
| Microsoft | Skype | Proprietary |
| Mozilla | Firefox | Open Source |
| Android | Open Source (mostly) | |
| Chromium | Open Source | |
| Kubernetes | Open Source | |
| Canonical | Ubuntu Linux | Open Source |
| Yocto project | Yocto Linux | Open Source |
| Linus Torvalds | Linux Kernel | Open Source |
| Apple | MacOS | Proprietary |
So you're probably wondering about licenses. What types of licenses are there?¶
There are two main types of software license categories: Copyleft (aka Restrictive) and Non-Copyleft (aka Permissive).
Copyleft (aka Restrictive)¶
The term “Copyleft” is derived from the more familiar term “Copyright”. Copyleft software licenses require that people who distribute the original code or make derivative works must make the source code or the re-distributed copy, available under the same license terms as the original. Topics like Patent use and Copyright are also allowed under certain conditions.
Here is a list of common permissions, conditions and limitations of these license types:
| Permissions | Conditions | Limitations |
|---|---|---|
| Commercial Use | Disclose source | Liability |
| Distribution | License and copyright notice | Warranty |
| Modification | Same license | |
| Patent use | State changes | |
| Private use |
Note: not all Copyleft licenses have the same permissions, conditions and limitations. Be sure to review.
Examples of Copyleft licenses:
- GNU GPL v2 and v3
- GNU LGPL
- Mozilla Public License
- Eclipse Public License 1.0
Examples of software that use Copyleft:
- Linux Kernel
- Bash
- GIMP
- Ansible
- Quake (id software)
Non-Copyleft (aka Permissive)¶
Non-Copyleft software licenses allow for the distribution of copies and modified versions as long as attribution is given back to the author, and that the author is not liable in any way. The original type of license optionally, does not need to be followed. Some Non-Copyleft licenses also allow for things like Patent use (Apache Software License 2.0), while others do not (MIT License).
Here is a list of common permissions, conditions and limitations of these license types:
| Permissions | Conditions | Limitations |
|---|---|---|
| Commercial Use | Disclose source | Liability |
| Distribution | License and copyright notice | Warranty |
| Modification | ||
| Patent use | ||
| Private use |
Note: not all Non-Copyleft licenses have the same permissions, conditions and limitations. Be sure to review.
Examples of Non-Copyleft (permissive) licenses:
- Apache Software License 2.0
- BSD Licenses
- MIT License
- Internet Software Consortium (ISC)
- X11 LIcense
- Free Public License
- The Don’t Ask Me About It License
- Eclipse Public License 2.0
Examples of software that are licensed as Non-Copyleft:
- Powershell
- Tensorflow
- ASP.NET
- .NET Framework
- Android (mostly, see: https://source.android.com/setup/start/licenses)
- SimCity
- Atlassian (Bitbucket, JIRA, etc)
To learn more, see the Choose A License website. Here you will find for each license a breakdown of what is required or what is allowed.
Another useful resource about license types is: TLDRLegal.com
GitHub also has some useful resources here:
A Practical Example - Operating Systems¶
Consider the Yocto Embedded Linux Operating System. Depending on what your Operating System requirements are in terms of things like: kernel, drivers, modules, libraries and packages, there could be hundreds of open source and/or proprietary software included in the final build. You may want to understand what the impact of each license means for your project. Fortunately with Yocto (and also Android OS), a manifest file is generated when the OS image is built which contains a list of all software and their respective licenses therein.
- In the case of Yocto, you can find the manifest file here:
${DEPLOY_DIR}/licenses/image_name-datestamp - In the case of Android, you can find the manifest file here:
/out/target/product/$(PRODUCT_DEVICE)/system/etc/NOTICE.html.gz
Limit specific license types from your Yocto builds¶
Yocto facilities through a configuration parameter, the option to avoid specific license types. As an example, to avoid GPLv3 and MIT, you can add the following to your conf/local.conf:
INCOMPATIBLE_LICENSE = “GPL-3.0 MIT”
Or, maybe you want to avoid all software components that have commercial or special license requirements within a given recipe. As an example, the poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly includes the following:
LICENSE_FLAGS = "commercial"
See: https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#enabling-commercially-licensed-recipes for more detailed examples of statements to help limit these potentially unwanted license types in your Yocto embedded linux project.
Stats¶
Below are some statistics made by our friends over at GitHub to get a better idea of which licenses are leading the pack in Open Source Software:
In terms of popularity
| Rank | License | % of projects |
|---|---|---|
| 1 | MIT | 44.69% |
| 2 | Other | 15.68% |
| 3 | GPLv2 | 12.96% |
| 4 | Apache | 11.19% |
| 5 | GPLv3 | 8.88% |
| 6 | BSD 3-clause | 4.53% |
| 7 | Unlicensed | 1.87% |
| 8 | BSD 2-clause | 1.70% |
| 9 | LGPLv3 | 1.30% |
| 10 | AGPLv3 | 1.05% |
How license usage changed over time
Source: https://blog.github.com/2015-03-09-open-source-license-usage-on-github-com/
Other Helpful Tools¶
Licensed¶
Licensed was open-sourced by GitHub in February, 2018. It is a Ruby gem to cache and verify the licenses of dependencies and check their status. The Licensed program then uses the Licensee program to identify dependencies and their licenses, including their license text. Licensed can do this via a continuous integration (CI) job.
To learn more about Licensed, see: https://githubengineering.com/improving-your-oss-dependency-workflow-with-licensed/
ScanCode¶
ScanCode scans code and detects licenses, copyrights, package manifests & dependencies and more … to discover and inventory open source and third-party packages used in your code.
FOSSA¶
FOSSA provides Software as a Service (SaaS) for dependency tracking, license compliance and attribution notices on autopilot.
Recommendations¶
If you’re thinking about incorporating Open Source Software in your project, you have some decisions to make in terms of software and licensing.
Whether you decide to redistribute software without touching any code, the very nature of Open Source Software allows for this. If your project intends to modify and redistribute code commercially, you should also be able to re-use this code, permitting you follow the license guidelines. We highly recommend reviewing each license to be sure that they can be incorporated with your project, comfortably.
One useful way to think about what direction to take, is to look at it in terms of freedoms. What types of freedom are you looking for in your project?
-
Do you want to have optionality in the future where you can take what you build as a derivative work and make it proprietary (Non-copyleft / permissive type licenses)?
-
Do you want to provide your derivative works back to the community, possibly because the Open Source recognition is a part of your brand or strategy (Copyleft / restrictive type licenses)?
Choose wisely, which style of freedom is best for you or your company.
Enjoy the Art of Coding®
References¶
https://opensource.org/faq#commercial
https://en.wikipedia.org/wiki/Open-source_model
https://en.wikipedia.org/wiki/Open-source_license
https://en.wikipedia.org/wiki/Shared_source
https://choosealicense.com/
https://en.wikipedia.org/wiki/Proprietary_software
https://blog.github.com/2015-03-09-open-source-license-usage-on-github-com/