Linux Foundation license scan identifies a number of problems which need to be resolved before any releasing.  This wiki page describes the best practices for resolving these identified issues.

Binary files

We cannot have binary files in Gerrit.o-ran-sc.org repo.  If the scan report identifies any binary files, they need to be removed.  Artifacts built from source codes are hosted in their corresponding repos, not in Gerrit.  

Use restriction statement

If a file is identified to have use restriction, the inclusion and use by O-RAN SC must comply within the restriction.  Otherwise such a file must be removed.

Copy left licenses

In general, we cannot have files under "copy left" licenses such as GPL in our Gerrit repos.  

Files identified by scan to be under a copy left license shall be removed or replaced by alternatives under open source friendly licenses, or developed by O-RAN SC.  If the use of such "copyleft-ed" files is not avoidable, the PTL needs to request for ToC approval for exception.  In such request the PTL shall describe how such files are used and why the use of such files does not compromise the integrity of the O-RAN SC licenses.  

Weak copy left

In general, we cannot have files under "weak copy left" licenses such as LGPL in our repos.  

Files identified by scan to be under a copy left license shall be removed or replaced by alternatives under open source friendly licenses, or developed by O-RAN SC.  If the use of such "weak copyleft-ed" files is not avoidable, the PTL needs to request for ToC approval for exception.   In such request the PTL shall describe how such files are used and why the use of such files does not compromise the integrity of the O-RAN SC licenses.  

License statement incorrect

Problems identified under this category must be fixed by correcting the incorrect statements or inconsistency.

Attribution

This category includes the uses of files under open source friendly licenses that are not within the O-RAN SC license family, such as MIT, BSD, etc.  

For all files original to the O-RAN SC, we must use one of our licenses, i.e. Apache 2, Creative Commons 4, or O-RAN Software v1. 

For files under these non O-RAN SC licenses that are originated from external sources, the use need to be reported to and approved by the ToC.  If possible, such files should be placed under a directory clearly indicating its external originality, such as "external", "thirdparty", "vendor", etc. 

The PTL will need to describe the use of these files to the ToC for approval, including how they are used in the project, their original location, and where they are placed under the O-RAN SC repo.  The license uses under this category are tracked here:  License Attribution Records

No license

Code files need to contain license claim at the beginning.  This is to protect files from being copied and used individually.  The standard text for O-RAN SC licenses can be found here: Licensing Text.

False positives

If an identified issue is believed to be incorrect, an exception must be filed to the ToC to clarify the use and why owner believes that the report is incorrect.

Files/file types that should be excluded from having license claim header

.gitattributes
.gitignore
.gitmodules
.gitreview
.readthedocs.yaml
INFO.yaml
favicon.ico
*.png
*.gif
*.jpg
*.json


  • No labels

5 Comments

  1. I see quite a few false positives in the report. I would like to request that the scan process be enhanced to avoid the following files by name, and I suspect this list will grow:


    .gitattributes
    .gitignore
    .gitmodules
    .gitreview
    .readthedocs.yaml
    INFO.yaml
    favicon.ico
    *.png
    *.gif
    *.jpg
    *.json
  2. user-d3360

    Thanks Chris.  I added subsections under the false positive section to track ToC decision for these.  

  3. Can we also include these files in false positive list:

    *.jks

    *.p12

    *.keyfile

    1. d k

      Speaking just for myself, I'm uncomfortable having files containing keying material in the repository at all, let alone whitelisting them in checks.  Is there an absolute reason we have keys in the repo?

  4. d k

    Bit more to add to the exception list: we use empty files named "placeholder_for_files" in the robot tree to allow us to have otherwise-empty directories in the git repo.   the scanner's flagging these as missing a license but properly noting they're empty.  can we except empty files rather than having files consisting of nothing but a license agreement?