Page tree
Skip to end of metadata
Go to start of metadata

The goal of this page is to summarize the approach OPEN-O 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 OPEN-O charter and summarized in these two main sections 14 (a) and 14 (d):

14 (a)

14(a).''Members agree that all new inbound code contributions to Open-O 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 licenses expressly granted in the Apache License, Version 2.0 with respect to such contribution.''


And there is 14 (d) regarding the Board exception:

14 (d)

14(d).''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 Open-O’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@Open-O.org to obtain exception approval.''


The use of Creative Commons Attribution 4.0 International License is required for all documentation by theOPEN-O charter and summarized in these two main sections 14 (c):

14 (c)

All documentation will be contributed to and made available by OPEN-O 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 OPEN-O Software Configuration Management (Gerrit) independently of the origin (either OPEN-O 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 OPEN-O 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 OPEN-O Community may be facing.

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

As OPEN-O 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 OPEN-O code and included in OPEN-O software distribution is permitted.
  2. OPEN-O 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 OPEN-O distribution (including supply of source code when required).
  4. Usage of third-party binaries that are linked/referenced statically or dynamically within OPEN-O 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 OPEN-O 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 OPEN-O. This is similar to how OPNFV operates. In that case, licensing would be governed by the other community. Modifications within OPEN-O 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 OPEN-O distribution

This is for internal usage only and MUST not be in the OPEN-O 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


OPEN-O 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

.java
.js

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

.txt
.png
.gif
.jpg
.tiff
.svg
.pdf
.docs
.odf
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 License.txt 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 License.txt 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 License.txt is applicable for both types of artifacts (source code and documentation). The License.txt contains the appropriate wording for both Apache Version 2 and Creative Commons Attribution 4.0 International.