Level 2: Secure and Appropriate Usage of Open Source Software

Initiative MenuHomeLevel 1Level 2Level 3Level 4Level 5About


This level is about the secure and responsible use of OSS. It covers in particular compliance and dependency management policies. It is about aiming for the state of the art in implementing the right processes.


Feel free to contribute for the benefit of all. Check out how to contribute.




Free and Open Source Software License Compliance: Tools for Software Composition AnalysisBy Philippe Ombredanne, nexB Inc., a nice post on understanding what open source code is included in your software and creating the so-called bill of materials before you can actually deliver it.Web page
The FOSSology ProjectAn up-to-date introduction to FOSSology and FOSS compliance by the Linux FoundationPDF
FOSS Governance CollectionAn amazing collection of governance documents put together by Vick Brasseur: bylaws, code of conducts, IPR policies etc.Web page
OpenChainThe standard behind a supply chain where open source is delivered with trusted and consistent compliance information.Web site

You must be logged in to contribute 

 Suggested content

The legal basis for Open Source

  • What is copyright
  • What is IP
  • What are patents
  • IP in the US vs. IP in Europe vs. IP
  • IP - standards - FRAND (in a nutshell)
  • Example of an Open Source "generic" license text
  • Open Source license infrigement ; what risks
  • Case studies from <company>

OSS License stewardship

  • The Free Software Foundation (FSF)
  • The Open Source Initiative (OSI)
  • The Open Source Definition (OSD) : https://opensource.org/osd
  • Others ? CERN, EU, Inria,  etc.

License categories

  • Strong Reciprocity Obligation (e.g. GPL, Affero) With this license, adaptations and derivative works must keep the term of the license as it is.  This license is commonly called “strong copyleft” and known as causing a “viral effect” that is despite the pejorative sense, not mandatorily negative depending the business objectives. This will be described later in this document.
    • copyleft : GNU GPL, Affero 
    • Why might these licenses be interesting to use ? ("true sharing", avoid "hidden" re-use, promote shared commons ...)
  • Standard Reciprocity Obligation (e.g. LGPL, MPL, EPL) The distribution terms of the license must be maintained. However, if the source code is combined with another source code to create a new work, the standard reciprocity obligation does not apply to the combined work.
    • Semi-copyleft : GNU LGPL, MPL, EPL
  • No reciprocity Obligation (e.g. BSD, MIT) These licenses are also known as permissive licenses. These licenses have no distribution terms. A proprietary software can use or integrate a software with permissive license without any obligation. Why might these licenses be interesting to use ? (more business "friendly" …)


  • What and where in the organisation Where does compliance come in the SDLC, Process description and process stakeholders, 
    • How does <company> do compliance (up front, continuous, just before delivery ...),
  • Good practices when publishing and distributing source code Source file headers, License text, REUSE.software help
  • Special cases / info LGPL on mobile devices, Android

Compliance Tools & Processes

  • Process
    • How to contribute to external projects
    • How to publish a project under a OSS licence ?
    • How to distribute a project (binaries and/or source code) ?
  • Where to get help (OSS Tooling Group, OpenChain ...) 
  • Fossology Why, Introduction, Understanding what it does and it's limitations, Example of results
    • Practical exercises Simple program/application, Complex program/application, Mobile phone application
  • Other tools SW360, Open Source Review Toolkit, Scancode Toolkit, Black Duck, Flexera FlexCode Insight, etc.

Engineering considerations

  • Dynamic linked libraries vs. static linked libraries
  • Software architecture and design, implications on licensing Front End, Back End, Mobile apps, Embeded software, Standalone Software
  • Technical interlinking between pieces of software, and the implication on licensing heritage (contamination) eg static or dynamic linking, network communications, etc.
  • Architectural implications
  • Network access
  • Designing for collaboration
  • Respects general programming guidelines imposed by the OSS projects.

Software reuse considerations

  • Languages and central component repositories
  • CI/CD tool chains and deoendency management tools
  • Challenges of software reuse Vulnerability monitoring, Compliance verification, Regression testing