Electronic Design
Q&A: Choosing an Open-Source License

Q&A: Choosing an Open-Source License

How do you decide which open-source license to use? Technology Editor Bill Wong talks with Protecode’s CEO Mahshad Koohgoli about the topic.

Mahsad Koohgoli, CEO, Protecode

Developers usually want to concentrate on design and coding. Issues like software licensing are often left to the legal department, but it’s important to know what software is being used and the implication its associated licensing, regardless of the source.

I recently spoke with Mahshad Koohgoli, CEO at Protecode, about open-source licensing and the issues associated with it.

Wong: Why use a particular license?

Koohgoli: A software license is a permission to use the software and sets the conditions under which the code can be used and redistributed. A license is different from copyright, as copyright indicates ownership. In many jurisdictions, copyright ownership is automatic, which means that you always own the code you write. Unless permission in the form of a license or otherwise is specifically given by the copyright holder, nobody can use the software.

Download this article in .PDF format
This file type includes high resolution graphics and schematics when applicable.

So, as a creator of open-source software, if you want the wider software community to be able to modify and benefit from your code, you must select an appropriate license that gives them permission to do so. If there is no licensing information included in your product, it will reduce the chance that your code will be studied and improved upon by the wider open-source community.

If you want to use an open-source project in a proprietary software product, you must ensure that you have the permission to do so. That means the open-source code must be licensed; otherwise you will need to track down the original creator(s) of the code and obtain their permission to use the code.

Wong: Should you use an open-source license or a proprietary, commercial license for your product?

Koohgoli: In general terms, you should choose an open-source license if you want others to be able to view, modify, use, or redistribute your code, allowing wide adoption of your project.

A proprietary license is appropriate if you do not want to make the source code for your software publicly available. Proprietary licenses allow a software creator to distribute its product under the terms of an End User License Agreement (EULA), which puts restrictions on how the product can be used.

Another method is to choose a dual-license model. With this model, you can distribute the source code of your software under an open-source license, limiting the use of your project to non-commercial applications. You can then offer a proprietary license (in exchange for fees) if anyone wishes to use your software commercially.

Wong: What are the considerations in selecting an open-source license?

Koohgoli: There are many open source licenses available, each with differing obligations, but generally open source licenses fall into two categories: permissive and copyleft.

Permissive licenses usually contain few restrictions on the reuse and distribution of the code or derivative works based on the original code. At a minimum, permissive licenses usually come with the requirement to give credit to the original authors of the code, also known as the attribution clause. The MIT License is an example of a popular permissive license. Under the MIT license, users are free to do whatever they wish with the code, as long as the original copyright and the license text are included in the file.

Copyleft licenses, on the other hand, typically come with stricter rules on reuse and redistribution of code, such as requiring the source code of any derivative works to be released to the public under the same copyleft licenses. There are varying degrees of copyleft licenses. Strong copyleft licenses, such as GPL v3, allow others to modify and use (in a cloud or Web application) or redistribute the code, but derivative works must be released under the same GPLv3 license. Weak copyleft licenses, such as LGPL, allow users to link to the code in a derivative work, but do not require the source code of the derivative work to be released under the same LGPL license.

The license category can become important when you are choosing to incorporate an open-source project into a proprietary software product. Depending on the type of product you are commercially offering, you may not want to release your source code into an open-source community, so it might be a good idea to stick with permissive or weak copyleft licenses.

Wong: What is a “composite project,” and how does it impact licensing your product?

Koohgoli: Most software developers do not write code from scratch. These days, most open-source projects are composite projects, meaning they build on and use components from other open-source projects. Composite projects contain more than one open-source package and each project could have its own individual license, creating potential licensing dilemmas for those who wish to incorporate the code into their own project. Navigating licenses of composite open-source software projects can be difficult. Depending on the individual licenses in the composite project, the choice of the license for the combined code may be limited.

Wong: What is “license compatibility” in a composite project and how do you enforce that?

Koohgoli: License compatibility means that permission rules for multiple licenses included together in a given project do not conflict with each other.  For example, a project that combines software under MIT and GPLv3 licenses cannot be distributed under the Apache license. There are tools on the market that can generate license-compatibility reports based on the open-source content found in your software portfolio.

Wong: How do you ensure license compliance?

Koohgoli: Any organization that uses open-source or other third-party code in its products should have a process in place for managing license obligations. Drafting an open-source policy that defines open-source usage rules, dictates the types of third-party licenses that are acceptable, and clarifies what to do when a policy violation occurs is a good start. Once a policy is in place, organizations should regularly examine their code to ensure that they are tracking open-source components. In small portfolios, this assessment can be done manually; however, as the lines of code increase, finding and tracking license information can be difficult.

Download this article in .PDF format
This file type includes high resolution graphics and schematics when applicable.

Various open-source scanning tools are available that can capture a policy digitally and scan code at various intervals, even in real-time, as code is being developed to search for policy violations. Software scanning tools can create a software bill of materials that lists all open-source components in your code, and report on licenses and copyright obligations, as well as other attributes such as security vulnerabilities associated with those open source.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish