Introduction
Non-profit organizations often use third-party images, photos, videos, or software in their everyday operations. It is often beneficial to leverage such materials that are licensed under “open licenses” because they are free to use; however, it is important to understand the conditions and requirements of such open licenses prior to using the aforementioned materials in order to avoid potentially breaching the license. This article aims to shed some light on various open licenses and how to comply with their conditions.
The first section of this article discusses open licenses as they apply to images, photos, and videos. This section is relevant to non-profit organizations that seek to use images, photos, or videos belonging to others (e.g. reproducing a photo from a third-party website on the non-profit organization’s website).
The second section of this article discusses open licenses as they apply to computer software (“open source licenses”), and in particular, how to comply with the notice and attribution requirements of open source licenses. This section is relevant to non-profit organizations that use open source software to develop software (e.g. using open source software in the development of a mobile application or educational software to further the organization’s mission).
Images, Photos, and Videos
In the U.S. and many other countries, images, photos, videos and other creative works are protected by copyright law. While it may be technologically trivial to use someone else’s photo or video on a website or elsewhere, it is important to determine what permissions the copyright holder has given in connection with reproducing, displaying or otherwise using the work. In general, merely attributing the source of the work does not give one the right to use it. While the term “fair use” is frequently invoked, the concept of fair use is highly fact-specific and does not apply outside the U.S. Many creative works are not freely available for use at all. Others can be licensed in exchange for payment (e.g., from stock photo websites). In some instances, photos and videos may be available under open licenses, such as Creative Commons (CC) licenses, or may be dedicated to the public domain. As one example, Wikipedia utilizes many images in the public domain or under CC licenses. When using works made available under a CC license, organizations should review the license language that applies before using or reproducing such content. There are several different CC licenses which set forth different restrictions and obligations, including whether the licensed work may be used for commercial purposes, whether adaptations must be shared under the same license terms, and whether derivative works or adaptations are allowed at all, among other things. Such licenses can be found on the Creative Commons website, available here. Moreover, most works made available under CC licenses require attribution credit. The Creative Commons organization describes best practices for attribution, with an ideal attribution including the title, author, source, and license of the licensed work.
Computer Software
It can be beneficial to both non-profit organizations and for-profit organizations, including social enterprises, to leverage open source software to accomplish their missions. Open source software is freely licensed and can be used to develop proprietary software. For example, organizations can use open source software as part of a mobile application to engage a broader audience or as part of an educational software program to assist in virtual teaching and learning.
Incorporating open source software into proprietary code is part of standard practice today, and many organizations may be well-informed on which licenses to use and avoid. In particular, it is widely understood that permissive open source licenses such as BSD, MIT, and Apache can be used freely and with minimal risk. However, organizations may not be aware that even these permissive licenses come with requirements and obligations. Some organizations may end up discovering after the fact that they have been using thousands of permissive open source software components in violation of the license terms.
In this section, we aim to explore the most commonly used permissive open source licenses and provide some guidance on how to comply with the often neglected notice and attribution requirements under such licenses. While this section focuses on “permissive” licenses, many “copyleft” licenses also have similar downstream requirements that are triggered when open source software is distributed.
Although open source software is free to use, the authors and copyright holders of open source software often require users to provide certain notices and attributions in connection with their use of such software by offering it under an open source license that contains these requirements. Each license should be considered on an individual basis to determine the notice and attribution requirements. License language can be readily found online by searching for the license name. As one example, the Open Source Initiative provides some resources and license language for some open source licenses. Some licenses, such as Apache 2.0, have unique requirements when users distribute derivative works. Below are a few examples of such language for commonly used permissive open source licenses:
- BSD 1-Clause: “Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.”
- BSD 2-Clause: “1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.”
“2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.” - BSD 3-Clause: “1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.”
“2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
“3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.” - MIT: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
- Apache 1.1: “1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.”
“2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.” - Apache 2.0: “You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:
“a. You must give any other recipients of the Work or Derivative Works a copy of this License; and
“b. You must cause any modified files to carry prominent notices stating that You changed the files; and
“c. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
“d. If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.
“You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.” - ISC: “Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.”
It should be noted that notice and attribution requirements for most open source software licenses are tied to distribution of the software, which can include, for example, on-premises software installations, web-based portals and frontends, browser extensions, and mobile apps. In many instances, however, organizations use certain open source software without distributing it, such as in the case of development tools that are not incorporated into a distributed software product or backend components that are not called and downloaded on a user’s machine. In these cases, the notice and attribution requirements are not triggered.
How to Comply with Open Source Software Notice and Attribution Requirements
Distributing Notices With Products
One primary method of compliance is to distribute copies of applicable notices and attributions with distribution of the software product itself. This solution is perhaps most in line with the exact language of certain open source licenses, particularly those that were drafted before the internet became used as a common software distribution mechanism. For example, in the past, companies sometimes provided printed documentation of applicable notices and attributions along with a physical storage medium containing the software. More recently, PDFs or other electronic documents containing notices and attributions are provided along with downloaded software. Software is also commonly distributed and shared via online repositories (e.g., GitHub). In such cases, a single document may be compiled that contains all the open source license notices. Alternatively, it may be sufficient to simply pass along to downstream recipients the same notice files provided with the open source software when it was originally obtained.
Dedicated Attribution Page
Another common method of satisfying notice and attribution requirements is through a dedicated webpage, which contains a compilation of all applicable notice and attribution language required by the applicable licenses. Although this approach may not meet the exact language of certain open source license notice requirements, it is commonly accepted as meeting their spirit. For example, the dedicated web page could begin with a table of contents listing various open source components by alphabetical order and the name of the applicable open source license. Below the table of contents, the applicable notice and attribution language for each license would be provided, categorized by the open source software component.
Organizations with multiple products and/or services may elect to list notice and attribution language on multiple webpages. Alternatively, organizations may also elect to provide a main webpage that hosts PDF documents which include the applicable notices and attributions for each product. As noted earlier, this method allows organizations to distribute the applicable PDF documents with any copies of software. Many software companies with good compliance practices have their open source software and third-party notices readily accessible on their product or support websites.
Dedicated Page Inside Product
In some instances, the best way to provide notices and attributions may be to include a page within the software product or service itself. The final result would look very similar to the dedicated attribution page discussed in the above example, but the page would be displayed inside an “About” or “Open Source Licenses” link. This approach is frequently used in mobile apps and other distributed software applications. It should also be noted that, although not very common, some open source licenses require an attribution to be displayed for software that has a user interface or normally displays notices.
Text in the Source Code
Another common method of providing notice and attribution is by including the text in the source code itself. Such notices, however, are not as easily accessible by the public, and can become very difficult to keep track of when there are many different software components incorporated into the product or service. This method may also raise questions as to whether sufficient notice was provided and is not the recommended best practice approach. Most importantly, a critical flaw of this method is that if the software is distributed only in its object code form, then the notice and attribution text built into the source code will not be readable and would not comprise sufficient notice.
Conclusion
While images, photos, videos, and software governed by open licenses are generally free to use, non-profit organizations should identify and consider the applicable conditions and requirements of such licenses, for example, attribution requirements. When using permissive open source software, organizations should determine whether the software packages they are using have notice and attribution requirements and whether such requirements have been triggered. When building a plan to comply with these requirements, organizations should consider which method would be simplest to implement and update over time, whether it be including all notices and attributions in a single document, including such notices and attributions in the distribution of software itself, or some other solution.
Han Chang was a contributing author to this alert.
Disclaimer: This is a general article about changing issues. It should not be construed as legal advice because we are not considering the facts of your specific situation. The opinions provided are those of the individual authors and not the views of Goodwin.
Author(s)
Steven R. Argentieri
Chris Chuang