Back to the Insights
Print Friendly, PDF & Email

Open source software and policies

What is open source software?

Open source software, also known as Free and Open Source Software (FOSS), component usage has increased dramatically. The wide availability of FOSS eliminates the need for developers to reinvent the wheel, accelerates development and reduces costs. In fact, the availability, ease of access, and lack of financial cost of FOSS have resulted in many developers believing that it is a risk-free solution to many of their pressing development problems. However, the word free in FOSS does not mean free of legal obligations, and as with any third-party commercial software, developers need to respect the licensing and copyright terms that govern how the FOSS programs can be used and address any security vulnerabilities that may be associated with the FOSS program.

What is a FOSS license? And, why do they matter?

FOSS licensing can be a very complex legal and operational issue for organizations that use FOSS either in their development processes or in their products. Although there are many different types of FOSS licenses, they generally fall under the categories of either copyleft or permissive licenses. Copyleft licenses, such as the GNU General Public License (GPL), generally require that products containing GPL-licensed code be released under the same license. At the other end of the FOSS licensing spectrum, permissive licenses, such as the (Massachusetts Institute of Technology) MIT License, grant the user more flexibility in terms of how the FOSS program can be used. The MIT License, for example, places no restrictions on the use or distribution of a FOSS program as long as a copy of the license accompanies the copied software, while the GPL license requires the source code for the FOSS program and any modifications or other components distributed with the FOSS program be made available to others in source code form.

Engineers need and use FOSS in their day-to-day work, and this will only increase in the years ahead. It is important that any business that is involved in any product development be aware of this and put in place an open source policy that is appropriate for their organization.

What is an open source policy?

As a result, any business using FOSS programs should have an open source policy that is both comprehensive but also practical. A good open source policy is best written and defined by those who are directly affected – engineers and product development teams. Furthermore, the policy should clearly define the team that is responsible for its development, evolution, and implementation. Representatives from both the business team and the development team could be responsible for the development and evolution of the policy, while the development team should generally be responsible for its implementation and execution.

An open source policy should also acknowledge that there are different uses for FOSS programs and that there are different levels of risk associated with the different types of FOSS programs. There are four common categories of FOSS use:

  • As development tools: FOSS programs may be used as-is in object-code form without modification during the development process and as an external component not part of a proprietary product
  • Incorporated into a distributed product, without modifications
  • Incorporated into a product, with modifications
  • Incorporated into a non-distributed product
    In particular, incorporating FOSS into a product with modifications requires a detailed understanding of the applicable FOSS licenses and the terms and conditions for subsequent distribution of source code.

An open source policy should clearly define the objectives of using FOSS in the enterprise, and describe how those objectives tie into the overall business strategy. It should also define the rules that govern the internal and external use of FOSS. A policy may be quite lenient in terms of FOSS programs used internally in the development process for building and testing products, however, it will likely be much more restrictive in terms of what components can be shipped as part of a product (for example, the policy could state that no GPL-licensed software may be part of the distributed product).

How do you start to develop an open source policy?

As a start to developing an open source policy, a list of all third party software used in the development of your products should be maintained and then reviewed to ensure that you are complying with the applicable FOSS license agreements. This is a good practice for two major reasons: (i) many customers will want to have access to your list of third party software as part of the customer’s internal due diligence on any software licensed in; and (ii) it is now customary, as part of M&A due diligence on a target that is in the business of developing and selling software products, to have the code base for its products scanned by a third party such as Black Duck to ensure that the target company is in compliance with all applicable FOSS licenses. From there, an open source policy can be developed that is appropriate for the business and which will minimize the likelihood of the organization suffering the negative legal and reputational consequences of improperly using FOSS.

 

Questions? Email us at startups@dentons.com.