Software projects: how to manage open source libraries and third-party APIs

Which open source licenses are safer for a commercial project?

Generally, the open source licenses that are easiest to manage in a commercial project are permissive licenses, such as MIT, BSD, and Apache. They allow the software to be used, modified, and distributed even within proprietary products, provided that the conditions set out in the license are complied with.

This does not mean that they are always “safe” in an absolute sense. It means that, compared with other licenses, they tend to impose fewer constraints on the final product.

MIT and BSD licenses, for example, are often considered more suitable for commercial projects because they mainly require copyright notices and the license text to be retained. They usually do not require the company to disclose the source code of its own software or to distribute the product under the same license as the library used.

The Apache license is also generally compatible with commercial projects, but it requires a slightly more careful review. In addition to attribution obligations, it contains specific provisions on patents and modifications to the code. For many companies it remains a manageable license, but it should be read carefully when the software has significant technological value or is developed to be sold, licensed, or assessed in due diligence.

The position is different for LGPL, GPL, and AGPL licenses. They are not licenses that are “prohibited” for a commercial project, but they may have a stronger impact on the way the software is integrated, distributed, or offered to customers.

• The LGPL may be compatible with a proprietary product, especially when the library remains separate from the main software. However, attention must be paid to the technical way in which the library is linked to the rest of the program.
• The GPL requires a more rigorous assessment. If a GPL library is integrated into software intended for distribution, obligations may also arise in relation to the code of the final product. For this reason, before using it in a commercial project, it is necessary to understand whether the software will be distributed to customers, incorporated into a proprietary product, or used only internally.
• The AGPL deserves an even more specific review in SaaS models. Unlike other licenses, it may give rise to obligations even when the software is not delivered to the customer, but is used to provide an online service. For a company developing digital platforms, web applications, or cloud services, this point may directly affect the business model.

In practice, an initial operational choice may be the following: if the project is commercial and proprietary, MIT, BSD, and Apache licenses are usually the easiest to manage. LGPL, GPL, and AGPL licenses should not be ruled out automatically, but they require a technical and legal review before integration.

The decision, therefore, should not be based only on the name of the license, but on a few concrete questions: will the software be used only internally or distributed to customers? Will the library be modified? Will it be integrated into proprietary code? Will the product be offered in SaaS mode? Could the software be subject to investment, sale, or due diligence?

These questions allow the company to make a more controlled choice. A library under a permissive license may be a straightforward choice for a commercial product. A copyleft library may be usable, but only if its obligations are compatible with the project. The issue, therefore, is not avoiding open source: it is choosing licenses that are consistent with the way in which the software will be commercially exploited.

And this review becomes even more delicate when the project does not incorporate a library, but connects to external services through third-party APIs.

What are the legal issues in the use of third-party APIs?

Using a third-party API means connecting one’s software to an external service. For example: a payment system, a map, an artificial intelligence service, management software, a CRM, or a messaging platform.

Therefore, before integrating an API, the company must know under which conditions it may use it.

The first thing to check is the provider’s terms of service. These usually establish what may be done, what is prohibited, which usage limits apply, and when the service may be suspended or modified.

In practice, the company should verify at least the following aspects.

1. Not all APIs may be used for any purpose. Some prohibit certain commercial uses, integration into competing products, scraping, or the use of data to train artificial intelligence systems.
2. Many APIs provide for call limits, traffic thresholds, paid plans, or costs that increase based on use. An API that is sustainable during testing may become expensive as the product grows.
3. If personal data, customer data, or company information passes through the API, it is necessary to understand who processes it, where it is stored, for what purposes, and with which responsibilities.
4. An API may be modified, limited, or suspended by the provider. If that API is essential for the product’s operation, the company must assess what happens if the service changes or is no longer available.
5. APIs must also comply with copyright law. However, the Court of Justice of the European Union, in SAS Institute Inc. v World Programming Ltd. (C-406/10), clarified that the functionality of a computer program, the programming language, and the format of data files used to exploit its functions do not, in themselves, constitute a form of expression protected by copyright. This principle is therefore also useful when considering APIs: connecting to another party’s technical functionality does not, in itself, amount to reproducing protected code.

The position changes if the company copies source code, object code, technical examples, manuals, documentation, or other materials made available by the provider. In that case, it is not merely using an interface or a function: it may enter the scope of the right holder’s exclusive rights. The same judgment in fact emphasizes that technical documentation may be protected by copyright, just like the software itself.

For this reason, the use of third-party APIs should be treated as a relationship with an external provider. It is not enough to verify that the integration works: it is necessary to understand which conditions govern access, which limits exist, and what consequences a change to the service may have.

In summary, an API may be used in a software project if its terms are compatible with the product the company intends to build. The review must be carried out before integration, because a technical dependency can quickly also become a contractual dependency.

After choosing libraries and APIs, one final step remains: documenting what has been integrated and establishing who is responsible if an external component creates problems.

When is an SBOM needed to manage libraries, APIs, and third-party components?

After choosing open source libraries and third-party APIs, one step is often overlooked: documenting what has been integrated into the software project.

It is not enough to know that a library “may be used” or that an API “works”. The company must be able to reconstruct which components have been used, in which version, under which license or term of service, and for which function of the product.

This documentation is often called a Software Bill of Materials, or SBOM. In simple terms, it is the list of software components: an organized list of libraries, frameworks, modules, packages, APIs, and other external components present in the project.

The SBOM serves to answer very concrete questions: what is inside the software? Who developed it? Which license governs it? Are there obligations to comply with? Can the component be used in a commercial or SaaS product?

If the company develops software internally, the SBOM should be built during the project, not reconstructed at the end. Each time a new library is added or a component is updated, the documentation should be updated together with the code. In this way, the legal review does not become a late-stage check, but part of ordinary development management.

If, instead, the company entrusts development to a software house, a freelance developer, or an external provider, the logic changes: the SBOM must be contractually required. The client should require a list of the components used, their respective versions, the applicable licenses, and any limits on use, distribution, or modification.

This point is particularly important for SMEs. Often the company does not have an internal technical department capable of checking every library used by the provider. For this reason, the development contract should provide for at least three obligations: delivery of the SBOM, a warranty that the components are compatible with the project’s objectives, and liability of the provider in the event of unauthorized or undeclared use.

The SBOM is also useful when the software is to be sold, licensed, presented to an investor, or assessed in due diligence. In these cases, a product without documentation on external components may lose value, because the party purchasing or financing it cannot understand whether the code can truly be exploited without unexpected constraints.

In practice, the SBOM is not only useful to developers. It is useful to the company in order to maintain control over its digital asset. Without a map of the components, it becomes difficult to manage updates, vulnerabilities, license obligations, dependencies on external providers, and contractual responsibilities.

For this reason, in software projects, the rule should be simple: those who develop internally document; those who commission development require documentation. Open source libraries and third-party APIs can be useful tools and perfectly compatible with a commercial project, but only if the company knows what it is using and can prove it.

In this way, the project remains manageable even when it grows, changes provider, enters a commercial negotiation, or is subject to legal review. The difference does not lie in avoiding external components, but in not leaving them invisible inside the software.