Rules for implementing FOSS in a project

Owned by Gildas Lanilis Gmail
Last updated: Apr 11, 2018 by Eric Debeau
7 min read

The goal of this page is to summarize the approach ONAP community is taking in regards to Free and Open Source Software.

The Rules

The use of Apache 2 License is required for all new inbound code contributions by the ONAP charter and summarized in these two main sections 13 (b-c) and 13 (e):

13 (b-c)

13(b - c)."Inbound Contributions. Members agree that all new inbound code contributions to the Project shall be made under the Apache License, Version 2.0 (available at http://www.apache.org/licenses/LICENSE-2.0). All contributions shall be accompanied by a Developer Certificate of Origin sign-off (http://developercertificate.org) that is submitted through a Governing Board and LF-approved contribution process. Such contribution process will include steps to also bind non-Member contributors and, if not self-employed, their employer, to the Apache License, Version 2.0 and to the licenses expressly granted in the file with respect to such contribution. c. Outbound License. All outbound code will be made available under the Apache License, Version 2.0."


And there is 13 (e) regarding the Board exception:

13 (e)

13(e).''Exceptions. If an alternative inbound or outbound license is required for compliance with the license for a leveraged open source project or is otherwise required to achieve the Project’s mission, the Governing Board may approve the use of an alternative license for specific inbound or outbound contributions on an exception basis. Any exceptions must be approved by a two-thirds vote of the entire Governing Board and the LF and must be limited in scope to what is required for such purpose. Please email legal@onap.org to obtain exception approval.''


The use of Creative Commons Attribution 4.0 International License is required for all documentation by the ONAP charter and summarized in these two main sections 13 (d):

13 (d)

All documentation will be contributed to and made available by the Project under the Creative Commons Attribution 4.0 International License (available at http://creativecommons.org/licenses/by/4.0/).

Interpretation of the rules

All inbound source code contributions and documentation must be licensed under Apache 2 License or Creative Commons Attribution 4.0 International License. Inbound represents all source code that goes into ONAP Software Configuration Management (Gerrit) independently of the origin (either ONAP community member or code from third-party source). In the case you would like to bring in third-party source code, that is not under Apache 2, we need to ask for a Governing Board exception.

In addition to source code contributions, we may need to incorporate third-party unmodified binaries. It is permissible to use such third-party unmodified binaries without Governing Board approval (even if it is not licensed under Apache 2). In those cases, please notify the Release Manager so we can document the licensing and the reasoning in the tables below.

Linux Foundation operates the scan on ONAP source code and is using Fossology to look at disclosure of License.

To be more specific, the sections below illustrate a couple of different situations ONAP Community may be facing.

Copy/paste third-party source code directly into our code files and compile it into ONAP binaries

As ONAP is recompiling the code, the third-party source code must be Apache Version 2 (or an exception must approved by Governing Board).
All snippets reuse must also be documented with an adjacent comment in the code:

  1. Original Source of Snippet

    1. URL location of the source code files or web article

    2. The name of the publication and it's publisher

  2. The original copyright statement

Standalone elements (unmodified third party elements)

  1. Usage of third-party unmodified executable binaries that are not linked/referenced statically or dynamically within ONAP code and included in ONAP software distribution is permitted.

  2. ONAP should track use of such unmodified executable binaries (hence the table down below for each project).

  3. License compliance requirements for such elements must be observed with each ONAP distribution (including supply of source code when required).

  4. Usage of third-party binaries that are linked/referenced statically or dynamically within ONAP are subject to Apache 2 license requirement or Governing Board approval (for non Apache 2 License).

Note

  1. binaries that are not linked/referenced means they execute in separate contexts, in separate processes, or on distinct physical or virtual processors.

  2. binaries are not limited in type of code, but should also include images, sounds, fonts and other non-text file types and file types that do not actually result in code execution.

Modify and compile third-party source code into binaries, reference these binaries from our code and include them in ONAP software distribution

It is assumed that such binaries are produced by a different upstream community. It would be best to make any modifications within the scope of that other community, and only do an integration within ONAP. This is similar to how OPNFV operates. In that case, licensing would be governed by the other community. Modifications within ONAP would cause a fork, and would make it more difficult to maintain over time.

Importing third-party source code that claims to be licensed under Apache Version 2 AND that third-party source code also embeds some other third-party source code under a different type of licensing

Team needs to understand the dependencies and will need to ask permission to Governing Board. This becomes same as point 1 above.

Using third-party binaries during test activities or test phase of build, not included in ONAP distribution

This is for internal usage only and MUST not be in the ONAP repository. Team should understand and comply with the requirement of the license.

Apache Version 2 and Creative Commons Attribution 4.0 International license

Apache Version 2 License

The text below (in the box labelled License Header) must be copied AS IS, replacing <yyyy> with 2017 and replacing <copyright holder> with your own identifying information. 
For the <yyyy> field, the first year the work is published the <yyyy> field has only 1 year (i.e. 2017). 
If the work is subject to modification, then the <yyyy> field is followed by the year of modification.

  1. If the date are adjacent year, they can be condensed to a start year then a dash (-) then the last year of the range (i.e. 2016-2017).

  2. If the date are not adjacent year, they can be condensed to a start year then a comma (,) then the year of the modification (i.e. 2016, 2018).

As indicated in Apache License 2 Appendix, Don't include the angle brackets!

The text should be enclosed in the appropriate comment syntax for the file format.



License Header Java
/* * Copyright <yyyy> <copyright holder> * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */
License Header Python
# Copyright <yyyy> <copyright holder> # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License.


Multiple contributors

As indicated in Apache Version 2, Section 4.b, in case multiple companies are contributing, you must make it clear the file has been changed.
The easiest way is to simply add your company copyright after the original ones. 
In case multiple companies are contributing, add each and every contributing companies.
In case an individual who does not claim to be part of a company, add the individual's email address.
You must not remove existing copyright claim.

Original License Text

Copyright <yyyy> <copyright holder>
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License

Modification license text (add as many as necessary)

Modifications Copyright <yyyy> <copyright holder>

Creative Commons Attribution 4.0 International License

The text below must be copied AS IS, replacing <yyyy> with 2016 and replacing <copyright holder> with your own identifying information.

In case multiple companies are contributing, add each and every contributing companies.

In case an individual who does not claim to be part of a company, add your email address.

Creative Commons Attribution 4.0 International License

Copyright <yyyy> <copyright holder>
This file is licensed under the CREATIVE COMMONS ATTRIBUTION 4.0 INTERNATIONAL LICENSE
Full license text at https://creativecommons.org/licenses/by/4.0/legalcode


ONAP License breakdown per file extension

The purpose of the table below is to help breaking down which type of license is applicable based on the file type extension.

Apache Version 2

for source code

Creative Commons Attribution 4.0 International

for documentation

Apache Version 2

for source code

Creative Commons Attribution 4.0 International

for documentation

.java
.js

.ts
.py
.sh
.bat
.sql
.xml
.html
.css
.json
.yaml
.properties
.cfg
.conf
.config
.c
.c++
.cc
.php
.pl
.lua

.rst
.txt
.png
.gif
.jpg
.tiff
.svg
.pdf
.docs
.odf

.md

.plantuml

.adoc
README

Applying license to artifacts that can't be edited

In the case where artifacts can't be edited to include the license header then the Rules for implementing FOSS in a project file must be placed at the root directory for which the license is applicable. 
The license in a directory by default applies to all directories beneath it. If a sub directory contains a different license file, the same rules applies to that directory and its subdirectories.

Concretely while importing third-party binaries into Gerrit or distributing some third-party binaries, do not mix all the code in a single directory but rather create a directory specifically for each. Then, when applicable, in each relevant directory copy the Rules for implementing FOSS in a project file. 
This approach is applicable for both third-party binaries in Gerrit and while distributing-installing the artifacts.
This approach is not limited in type of code, but should also include images, sounds, fonts and other non-text file types and file types that do not actually result in code execution.

Note

The same Rules for implementing FOSS in a project is applicable for both types of artifacts (source code and documentation). The Rules for implementing FOSS in a project contains the appropriate wording for both Apache Version 2 and Creative Commons Attribution 4.0 International.