OSS Attribution Obligations

The Free Dictionary defines attribution as “The act of attributing, especially the act of establishing a particular person as the creator of a work of art.” This definition can also be applied to software.

Open source attribution obligations, as specified in the most common licenses, are usually very simply stated, and subject to a great deal of interpretation. Here are a few examples:

• Apache 1.1 License: “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.”

• MIT License: “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.”

• GPL 2.0: “1. You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.”

• MPL 1.1: “3.6. Distribution of Executable Versions. You may distribute Covered Code in Executable form only if the requirements of Section 3.1-3.5 have been met for that Covered Code, and if You include a notice stating that the Source Code version of the Covered Code is available under the terms of this License, including a description of how and where You have fulfilled the obligations of Section 3.2. The notice must be conspicuously included in any notice in an Executable version, related documentation or collateral in which You describe recipients’ rights relating to the Covered Code.”

• Apache 2.0: “(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.”

In addition to the obvious requirement to document your usage of an open source package, there are a couple of concepts referenced in these licenses that benefit from a bit of exploration:

• Two of the licenses use the expression “conspicuously included”.
• The very common Apache 2.0 license uses the expression “if and wherever such third-party notices normally appear”

These concepts require interpretation: What is actually legally required? What is the best way to meet the attribution obligations? To answer these questions, we should first think about the purposes (goals, objectives) of software attribution.

Why Attribution?

Open source software is not sold; it is free. So what is the motivation to create and release software under an open source license?

The complete motivation spectrum is beyond the scope of this essay, but it is clear that open source developers want credit for their work, perhaps stated as: “I created this software and I want everyone who benefits from it to know that.”

Thus the spirit of an attribution obligation suggests the following guidelines:

• Make sure the attribution notices are easy to find.
• Make sure the attribution notices are easy to understand.
• Make sure that the developers of the open source packages are acknowledged.

How are software suppliers providing attribution? Are they meeting the minimum legal obligations, or do they respond to the spirit of software attribution? An informal survey reveals a variety of formats, with varying results.

Attribution Examples Worthy of Special Interest

Two major software providers, Mozilla and Google, provide some excellent examples of very different approaches to software attribution.

Mozilla Firefox

In Mozilla Firefox, you can click on “About Firefox” and then click the Licensing information link, which takes you to an about:license page. The information is organized by license name, and each license name is a link that takes you to the corresponding details, including the pathname of the component subject to that license as used in Firefox, the copyright statement, and the texts of the licenses and notices. A glance at this page should convince any software developer that there is some value to a good copyright statement in order to be acknowledged beyond the mere name of a package. Regarding the license names, Mozilla provides the official license name from the license text when available, or it constructs a license name from the project name followed by license.

Google Chrome

In Google Chrome, you can click on “About Google Chrome” and then click the “open source software” link, which takes you to a chrome://credits/ page, which is a very clean and efficient display organized by the open source projects used in Chrome. Each project entry provides quick links to the project home page and the project license. The links to the project home pages provide a very nice thank-you to the project contributors. Of particular interest, Google makes no attempt to name the licenses, and simply presents the copyright and license text. You only see the license name if it is part of the license text.

Android

On an Android-based device, you can typically go to “Settings > About phone > Legal information > Open source licenses”. Note that Android organizes attribution by Deployed components, in contrast to Mozilla Firefox and Google Chrome which base the contents of the attribution documentation on their respective Development codebases. Android presents a list of deployed component links, and each link takes you to a detail page with a clear presentation of the copyright and license information. This is an excellent model for attribution on a small dev.

Typical Attribution Examples

The following software projects generally illustrate the spirit of software attribution.

In the Amazon Music desktop application, you can click on “About Amazon Music”. You get a nicely formatted information window, and you can click on the Legal Notices link to get to a page in your default browser with a couple of clearly identified link choices, one of which takes you to the attribution notices. The presentation is easy to read, organized by component (or project), but without TOC or links. Typical of Amazon, you have the chance to say if the page was helpful (Yes/No choice) at the bottom, and a place to enter comments.

In TextWrangler from Bare Bones Software, you can click on “About TextWrangler” to get a small, but very easy to read, window with control over the scrolling text. It provides basic information with some links, and third-party components are identified by project.

In Logic Pro X from Apple, you can click on “About Logic Pro X”, and then “Acknowledgments”, to get a pdf file that opens in your default pdf reader. The information is clearly presented by project, with some contact information, but without TOC or links.

Disappointing Attribution Examples

The following software projects arguably comply with basic software attribution obligations, but would benefit from some improvements to promote the spirit of software attribution.

Adobe Reader XI

The attribution notices for Adobe Reader XI are difficult to find. Click “About Reader”, then click the Legal Notices button, and then you see a list of proprietary copyrights, and at the bottom you see: “Third Party notices, terms and conditions pertaining to third party software can be found at https://www.adobe.com/go/thirdparty and are incorporated by reference herein.” The URL is not a live link. Copy and paste it to a browser. The page you get requires you to find your particular Adobe product, and eventually you will find “Adobe Acrobat XI Pro, Adobe Acrobat XI Standard and/or Adobe Reader XI”, which takes you to a pdf page which is not at all user-friendly: no obvious organization, no TOC, and no links. This is a surprising disappointment from a company that specializes in information presentation.

Apple iTunes

In iTunes from Apple, you can click on “About iTunes” to get a small window with a small pane of automatically scrolling small-sized text in a light-gray hard-to-read color with no control over the scrolling speed; the acknowledgments zip by somewhat like the credits at the end of a movie. One wonders if the contributing third-party projects consider this adequate attribution, which is certainly not in the spirit of software attribution.

VLC

In VLC, you can click on “About VLC media player…” to get a floating window. If you click on the “Credits” link, you get a poorly formatted, automatically scrolling list of projects accompanied by license short names. The extensive list is almost impossible to read, and would definitely benefit from some simple software improvements to the presentation.

Attribution Technical Resources

You can construct your attribution notices manually, especially if your software project is relatively small and uncomplicated, but a manual process does not scale up very well. There are a number of resources that can help you.

• SPDX: “The Software Package Data Exchange® (SPDX®) specification is a standard format for communicating the components, licenses and copyrights associated with a software package.” The scope of SPDX, a Linux Foundation project, goes considerably beyond basic software attribution, but the associated tools and SPDX License List can be quite helpful to a project building a comprehensive attribution process. A recently published tutorial provides an excellent introduction.

• AboutCode: “The AboutCode tool and ABOUT files provide a simple way to document the origin and license and other important or interesting information about third-party software components that you use in your project.” This open source project, sponsored by nexB Inc., is a simple approach to software attribution suitable to development teams with limited resources.