How to use open-source code in closed-source projects

Introduction

TL;DR: We must always consider the open-source code licenses used in our closed-source projects. Open-source ≠ free. Violation of OSS licenses may lead to lawsuits, fines, and reputation losses for the company.

Open-source software is a foundation — we use a vast number of open-source libraries in our closed-source projects. We use them in our infrastructure, in our helper libraries, in our client libraries, and in our scientific code.

It’s crucial to use open-source code properly and respect the license of the open-source code used.

We could split our closed-source projects into three categories:

Shipped software

Any code shipped to the user (in binary or source) is considered shipped software.

Typically, shipped software is:

Allowed to use in shipped software

Only libraries with permissive licenses (for example MIT License, Apache 2.0 License) could be used safely in our closed-source projects that are considered to be shipped software.

It’s highly recommended to use only libraries with licenses from a approved list of permissive licenses. Libraries or code with other permissive licenses may be used, but you must check their license first and contact the OSPO team if any doubts arise.

Also, you must adequately put information about all the OSS libraries used in your project. Users should be able to find the list of all OSS libraries and code used in the project.

Not allowed to use in shipped software

Some OSS libraries have non-permissive copy-left licenses, such as GNU GPLv3. You are legally required to distribute the complete source code of your project if any library with such a non-permissive license is used in your project.

Using libraries with copy-left licenses in closed-source projects shipping software is prohibited.

Note: Any code (from blogs, books, etc.) must be treated as copyrighted and not allowed to use in closed-source projects unless an appropriate OSS license is explicitly specified or you have explicit permission from the author.

Allowed with caution to use in shipped software

Some copy-left licenses could be used in closed-source projects. For example, GNU LGPLv3. But you should be very precise in the way you use those libraries to use them strictly accordingly to the license requirements (and it may be hard or impossible in some cases).

SaaS backend

In the case of a SaaS (software-as-a-service) backend, code is only running on our servers. We are not shipping our code or binaries to the user. End-users communicate with the SaaS backend via the network.

Allowed to use in SaaS backend

It’s allowed to use OSS libraries with permissive licenses such as MIT License or Apache 2.0 License (approved list of permissive licenses), plus some OSS libraries with copy-left licenses such as GNU GPLv3.

Not allowed to use in SaaS backend

Some libraries have strictly copy-left licenses, that treat “Network use” as distribution. For example, GNU AGPLv3. You are legally required to distribute the complete source code of your SaaS project backend under the GNU AGPLv3 license if any library with the GNU AGPLv3 license is used in your project.

We must be sure that we don’t use GNU AGPLv3 or a similar license in our closed-source SaaS backend.

Note: Any code (from blogs, books, etc.) must be treated as copyrighted and not allowed to use in closed-source projects unless an appropriate OSS license is explicitly specified or you have explicit permission from the author.

Non-production software

Code used only for R&D, development or test purposes and does not shipped or communicate via the network with end-users is considered non-production software.

For example:

Allowed to use in non-production software

Both permissive and copy-left licensed libraries are allowed to use.

Non-production software may become production software in the future (shipped to the users or became a part of SaaS backend). Some libraries that were allowed in non-production software may be not allowed in production software. Always consider this possibility and check the license of the library before using it in non-production software.

Not allowed to use in non-production software

You should be always aware of all your dependencies and their licenses:

Research tools, software and libraries

In general, R&D software may be treated as non-production software.

But, in cases when R&D software is used to create new formulas for active ingredients (or any other standalone results that are treated differently from the code itself), we should pay close attention to the licenses.

Therefore, the use of any digital research tool, library or code that can potentially generate leads for new active ingredients must have a Freedom to Operate (FTO) assessment carried out by the IP department. Please contact Eddie Leslie (eddie.leslie@syngenta.com) or Bill Teoli (William.teoli@syngenta.com) if you are not already in contact with a patent attorney.

The nature of the relevant open-source license will also have an impact on the FTO position of the research tool. The relevant license and any associated restrictions conferred should be checked before any use of any research tool.

The following licenses are preferred from an IP FTO perspective:

The use of licenses not in the above list should be discussed with IP or Legal. Please note that preferred licenses do not negate the need for an FTO assessment for tools involved in active ingredient lead generation.

Appendix

Approved list of permissive licenses

Libraries with the following permissive licenses are allowed for use in closed-source projects:

You are welcome to talk to the OSPO team to add more licenses to this list.

Acceptable only for SaaS backend and non-production use

Some non-permissive licenses are allowed for use in SaaS (software-as-a-service) backend code that runs only on our servers and in non-production code.

For example:

Consider consultation with the OSPO team in such cases.