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):

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

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):

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).

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.

/*
 * 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.
 */

# 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.

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.

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.

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.