Open Source Code Attribution in a Remix World

Terms of OSS licenses are generally non-monitory and include obligations around usage restrictions in certain applications, warranty disclaimers and requirements to hold OSS authors harmless, reproduction of original copyrights and, in case of copyleft licenses (e.g., Gnu General Public License or GPL family), contributing resulting source code back to the public domain. While much attention has been paid to the latter, the attribution clause in OSS licenses is the one that can be easily and unknowingly violated.

The Attribution Clause

One of the most common obligations imposed by OSS licenses is an attribution clause: the requirement that “a license redistributing the licensed code, or a modified version of the code, provides a basic copyright (or copyleft) notice acknowledging the identity of the original author(s).” At a basic level, the attribution clause makes enforceable the generally accepted moral notion that credit should be given where credit is due. In addition, the presence of an attribution clause acts as deterrent to those who would otherwise strip the code of any information identifying the original author(s) and present the code as their own, promoting code ownership and code accountability, two common concerns that arise with OSS use.

Attribution in a'Remix World

Compliance with attribution requirements have been significantly complicated by the fact that many companies are often unaware that a product that they assume proprietary rights over can contain open source code. Increased reliance on code developed by third parties and software outsourcing have resulted in a loss of control over a product's code composition. Best practices, in software distribution and the acquisition of assets that contain software, include identifying all third-party and open-source code in the software and ensuring that the asset is in compliance with the requisite license obligations. This can be achieved through the use of automated software scanning and audit technology deployed in products which identifies all third-party code and associated licensing obligations, as well as any violations of a company's licensing policies and license incompatibilities. Once a license that contains attribution requirements is identified, a product or asset can be brought into compliance.

Attribution Documents

Attribution requirements can take many forms; however, compliance is often satisfied by the creation and distribution of an attribution document. At minimum, an attribution document contains a list of all third-party software, copyright and licensing information. Many licenses, including the GNU GPL, Microsoft Public License (MPL) and the MIT license, ask that verbatim copies of all copyright, patent, trademark and attribution notices from the source code be distributed with the product; sometimes, as is the case with the GPL, in the header of the distributed file. It is important to recognize that the attribution requirement must be satisfied even if the source code is not distributed with the product.

License Distribution

Many licenses also require that a copy of the license accompany the binary or code distribution. If, for instance, the code is to be used in a manner that includes a user interface that can display the license, some licenses ask that the license be made available on the user interface. For example, a smartphone application distributed under an APL (Adaptive Public License) will require that the distributer make the license text available to the end user, and that the license be in a form that is readable on the phone screen.

Creating an Attribution Document

1. Identify all third party and OSS Packages. In order to be in compliance with your open source obligations, you must first identify all open-source and third-party content in your software portfolio. You can use manual reviews to identify the components, or speed up the discovery process using automated solutions such as an automated scanning machine or an Enterprise Analyzer, which can create a bill of materials that identifies all open source and third-party code, packages and licenses quickly and accurately.
2. Identify license obligations. Once any open-source software is identified, the licenses and obligations associated with each OSS package must be identified. Automated solutions can create a License Obligations Report (LOR) very quickly based on a particular license and use-case questions and answers.
3. Consolidate the list of copyrights and licenses into a single document. This will simplify OSS attribution and license distribution compliance. Again, automated solutions exist that can expedite the consolidation process.

Conclusion

Open-source software provides developers with the opportunity to speed up the development of high quality code while reducing development cost with the support of a diverse and talented open-source community. In order to use OSS to its fullest extent, it is essential that organizations maintain awareness of OSS license requirements and remain in compliance with their obligations. These obligations need not be barriers to development and can be easily met through either manual processes or assisted by automated tools within a structured Open Source Software Adoption Process (OSSAP) practice.

Alexandra Lyn is a legal consultant with Protecode (www.protecode.com). She received a Bachelor of Engineering from the University of Guelph in 2012. She is currently a JD candidate (2016) at the University of Ottawa, and an MBA candidate at the Telfer School of Management (2014).

The landscape of software development and distribution is changing. Traditionally a closed-off proprietary process, developers and businesses alike are quickly realizing the many advantages that flow from the adoption of a more collaborative open source approach. Open source software (OSS) refers to software whose source code is made available to the public which can be used, modified and redistributed subject to certain conditions and obligations.

The popularity and growth of OSS in technology organizations has created a demand for a new breed of inside counsel or IT lawyers. The variety of the licenses associated with OSS and diversity of the obligations demanded within these licenses has introduced a level of complexity that is new to the IP legal field. The proliferation of job openings for open source licensing experts and inside counsel is a testament to both the entrenchment of OSS within the industry and the attention that organizations are paying to the obligations around OSS Licenses.

Drivers of OSS adoption include:

• Reduced development costs;
• Reduced time to market;
• Avoidance of proprietary lock in; and
• Availability of external support through the OSS community.

It is important to understand that the original developer(s) of the source code automatically possess an all rights reserved copyright to that piece of code. Placing the code in the open source domain does not extinguish this copyright. Rather, the author(s) of the code have the ability to grant certain rights and impose certain obligations to prospective users through the use of a license. An OSS license is a contract between the original developer (the licensor) and those who wish to use the code (the licensees). Failing to comply with license obligations may result in the infringing entity being forced to pay damages or being forced to bring their asset into compliance.

Terms of OSS licenses are generally non-monitory and include obligations around usage restrictions in certain applications, warranty disclaimers and requirements to hold OSS authors harmless, reproduction of original copyrights and, in case of copyleft licenses (e.g., Gnu General Public License or GPL family), contributing resulting source code back to the public domain. While much attention has been paid to the latter, the attribution clause in OSS licenses is the one that can be easily and unknowingly violated.

The Attribution Clause

One of the most common obligations imposed by OSS licenses is an attribution clause: the requirement that “a license redistributing the licensed code, or a modified version of the code, provides a basic copyright (or copyleft) notice acknowledging the identity of the original author(s).” At a basic level, the attribution clause makes enforceable the generally accepted moral notion that credit should be given where credit is due. In addition, the presence of an attribution clause acts as deterrent to those who would otherwise strip the code of any information identifying the original author(s) and present the code as their own, promoting code ownership and code accountability, two common concerns that arise with OSS use.

Attribution in a'Remix World

Compliance with attribution requirements have been significantly complicated by the fact that many companies are often unaware that a product that they assume proprietary rights over can contain open source code. Increased reliance on code developed by third parties and software outsourcing have resulted in a loss of control over a product's code composition. Best practices, in software distribution and the acquisition of assets that contain software, include identifying all third-party and open-source code in the software and ensuring that the asset is in compliance with the requisite license obligations. This can be achieved through the use of automated software scanning and audit technology deployed in products which identifies all third-party code and associated licensing obligations, as well as any violations of a company's licensing policies and license incompatibilities. Once a license that contains attribution requirements is identified, a product or asset can be brought into compliance.

Attribution Documents

Attribution requirements can take many forms; however, compliance is often satisfied by the creation and distribution of an attribution document. At minimum, an attribution document contains a list of all third-party software, copyright and licensing information. Many licenses, including the GNU GPL, Microsoft Public License (MPL) and the MIT license, ask that verbatim copies of all copyright, patent, trademark and attribution notices from the source code be distributed with the product; sometimes, as is the case with the GPL, in the header of the distributed file. It is important to recognize that the attribution requirement must be satisfied even if the source code is not distributed with the product.

License Distribution

Many licenses also require that a copy of the license accompany the binary or code distribution. If, for instance, the code is to be used in a manner that includes a user interface that can display the license, some licenses ask that the license be made available on the user interface. For example, a smartphone application distributed under an APL (Adaptive Public License) will require that the distributer make the license text available to the end user, and that the license be in a form that is readable on the phone screen.

Creating an Attribution Document

1. Identify all third party and OSS Packages. In order to be in compliance with your open source obligations, you must first identify all open-source and third-party content in your software portfolio. You can use manual reviews to identify the components, or speed up the discovery process using automated solutions such as an automated scanning machine or an Enterprise Analyzer, which can create a bill of materials that identifies all open source and third-party code, packages and licenses quickly and accurately.
2. Identify license obligations. Once any open-source software is identified, the licenses and obligations associated with each OSS package must be identified. Automated solutions can create a License Obligations Report (LOR) very quickly based on a particular license and use-case questions and answers.
3. Consolidate the list of copyrights and licenses into a single document. This will simplify OSS attribution and license distribution compliance. Again, automated solutions exist that can expedite the consolidation process.

Conclusion

Open-source software provides developers with the opportunity to speed up the development of high quality code while reducing development cost with the support of a diverse and talented open-source community. In order to use OSS to its fullest extent, it is essential that organizations maintain awareness of OSS license requirements and remain in compliance with their obligations. These obligations need not be barriers to development and can be easily met through either manual processes or assisted by automated tools within a structured Open Source Software Adoption Process (OSSAP) practice.

Alexandra Lyn is a legal consultant with Protecode (www.protecode.com). She received a Bachelor of Engineering from the University of Guelph in 2012. She is currently a JD candidate (2016) at the University of Ottawa, and an MBA candidate at the Telfer School of Management (2014).