Open-Source Licenses in Your Product: A Polish Legal and Transaction Checklist

Open-Source Licenses in Your Product: A Polish Legal and Transaction Checklist

Your code may be your company’s most valuable asset. But do you know what components it contains—and the terms on which you may use them? The worst time to discover a copyleft-licensed library at the heart of your product is when an investor opens a data room or an enterprise customer sends an intellectual property questionnaire.

Open-source licenses are not merely a technical detail. They can require attribution, access to source code or compliance with patent provisions. A breach may jeopardize your right to use a component, lead to copyright claims, or delay a funding round or major customer contract.

This article explains the risks for technology companies operating in Poland and the steps you can take to manage them without stopping product development.

Terms you need to know

Computer programs receive copyright protection under Poland’s Act of February 4, 1994 on Copyright and Related Rights and Directive 2009/24/EC. An open-source license does not waive copyright. It permits the exercise of rights that would otherwise be exclusive, subject to the license’s conditions.

Why open source becomes a transaction risk

In 2024, 96% of organizations increased or maintained their use of open-source software, while 53% of respondents identified cost reduction as their main reason for choosing it. The practical question is therefore less likely to be whether your product contains open source than whether you know the terms governing its use.

Many technology companies do not maintain a component inventory. Without one, they cannot reliably assess their exposure or demonstrate compliance. The gap often becomes visible at one of three points:

1. A funding round or exit: An investor asks for component and license lists and evidence of the company’s chain of title.
2. An enterprise sale: A prospective customer requests IP and license-compliance representations and warranties.
3. A change in distribution: Moving between SaaS and an on-premises offering can change which license obligations apply.

Missing documentation can mean delay, a lower valuation or a lost contract.

License families and their practical implications

Not all open-source licenses create the same obligations. This overview is a starting point; how a particular component is integrated and distributed still matters.

Permissive licenses such as MIT, BSD and Apache 2.0 allow components to be included in proprietary commercial software. You must still provide the required notices and attribution. Apache 2.0 is not interchangeable with MIT: it contains an express patent-license provision and requires changes to source code to be identified.

Copyleft licenses such as GPL and AGPL operate differently. As the approved Polish analysis explains, using GPL entails licensing without a royalty and giving users free access to the complete source code when the relevant obligation is triggered. Breach may cause a conditional or permanent loss of permission to use the component, creating exposure to claims for use without a legal basis.

GPL does not prohibit commercial activity. A business may charge for implementation or maintenance services. The need to make source code available and license it without charge does, however, call for deliberate decisions about product architecture and distribution.

SaaS is not a blanket exception: check for AGPL

A common assumption is: “We do not distribute a binary, so copyleft does not concern our SaaS product.” There is a basis for part of that view, but it is not a safe general rule.

Under most licenses in the GPL family, merely providing functionality over a network does not trigger the source-code obligation. That obligation arises when the program is “conveyed.” This reflects the commonly accepted interpretation and the Free Software Foundation’s position.

GNU Affero GPL (AGPL) is the important exception. It was designed to address network use: where users interact with the covered program over a network, its terms require source code to be made available to them.

Directive 2009/24/EC does not itself require a SaaS provider to publish source code. Any such obligation here comes from the applicable license. AGPL is less common than GPL, but a component under AGPL at the center of a product can materially change the company’s position.

Check:

1. Whether any dependencies carry an AGPL license.
2. How those components interact with your own code, including linking, forks and modifications.
3. Whether adding an on-premises version—or otherwise changing distribution—would trigger obligations that did not arise in the SaaS model.

What investors examine in technology due diligence

Due diligence commonly follows a term sheet and precedes transaction documentation. It covers matters such as IP, liabilities and taxes; see this Polish Agency for Enterprise Development guide to selling a startup. For a technology company, the technical review concentrates on its code.

Documents an investor may expect

An investor may ask whether the company has rights from every employee and contractor; whether GPL or AGPL components are present and how they are integrated; whether contractor agreements document the required fields of exploitation; whether there have been security incidents or IP claims; and whether customer contracts include change-of-control clauses.

“Fields of exploitation” is a Polish copyright-law concept: the agreement must expressly identify the categories of use for which economic rights are transferred. The Patent Office of the Republic of Poland’s 2024 startup guide likewise emphasizes establishing who holds each IP right, whether founders, employees or contractors created the relevant work, and what agreements govern it.

Licensing gaps or an incomplete contractor chain of title can affect a share purchase agreement (SPA) or other transaction terms. Possible responses include:

• IP and license-compliance representations and warranties that the company may struggle to give;
• Escrow or a purchase-price holdback where identified risks remain unresolved; and
• An earn-out tied to measurable technology milestones instead of payment of the full price at closing.

For a founder, these mechanisms can mean less money upfront and greater uncertainty.

Polish copyright: securing rights from B2B contractors

Article 74(3) of the Polish Copyright Act provides for an employer’s statutory acquisition of rights in a computer program—but only within an employment relationship. It does not automatically give a company rights in code created under a B2B contractor arrangement.

For contractor-written code, the company needs a written agreement transferring economic copyrights. Article 53 requires written form for the transfer to be valid. Under Article 41(2), the agreement must expressly specify the fields of exploitation; a general reference to “all rights” without identifying them is insufficient.

For computer programs, the relevant fields under Article 74(4) are:

1. Reproducing the program.
2. Modifying it, including translation, adaptation and changes to its arrangement.
3. Distributing it, including lending and rental.

An invoice or repository access is not a substitute for a written transfer. For due diligence, the chain must also account for every individual who created the code, including any subcontractors engaged by your contractor.

Review whether you have written agreements with each contractor; whether they specify the Article 74(4) fields; whether the transfer is linked to acceptance of an identifiable deliverable, such as a commit or acceptance report; and whether any subcontractors’ rights are documented.

AI coding assistants and code provenance

Tools such as GitHub Copilot may generate snippets identical or substantially similar to open-source-licensed code. If a snippet enters a production repository, the company may face three separate issues: compliance with a component’s license terms, a claim involving economic copyrights, and difficulty establishing the code’s provenance in due diligence.

Articles 1(1) and 74(1) of the Polish Copyright Act address protection of a program that is the author’s own intellectual creation. The fact that AI generated code does not, by itself, resolve whether the output has the required creative character or who holds rights to use it. The approved source identifies no Polish court ruling or public-authority position resolving that issue.

At minimum:

1. Review generated code before committing it.
2. Scan for similarities to public repositories.
3. Record component sources and licenses.
4. Do not put the company’s confidential code into prompts without a legal basis.

EU regulatory and customer requirements for an SBOM

The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, introduces a requirement to maintain a component inventory, or SBOM, for products with digital elements.

A manufacturer incorporating an open-source component into a product with digital elements is responsible as the manufacturer of the final product and should maintain an up-to-date SBOM. The CRA does not prescribe one mandatory format. CycloneDX and SPDX already appear in public procurement requirements, including this e-Health Centre procurement description.

Article 21(2)(d) and (e) of the NIS2 Directive (2022/2555) addresses supply-chain security and vulnerability management for essential and important entities. NIS2 does not expressly mandate an SBOM, but one may be a proportionate way to support those obligations.

Customer contracts can move faster than legislation. If an enterprise customer requires an SBOM in 2026, you must address that contractual requirement regardless of the later date for the CRA’s full manufacturer obligations.

A practical checklist for CTOs and founders

Open-source compliance can be organized as a continuing project rather than an emergency that interrupts the roadmap.

Priority actions

1. Generate an SBOM for every repository and build. Software composition analysis (SCA) tools can identify dependencies automatically. Identifying a component is not, however, the same as legally assessing its use.
2. Sort licenses into policy categories and record their obligations. The source’s proposed starting categories are permitted (MIT, BSD), conditionally permitted (Apache 2.0, LGPL, MPL), and not permitted in the commercial product without architectural changes (GPL, AGPL). Treat these as internal review rules, not a claim that GPL or AGPL legally prohibits commercial software.
3. Examine where your code meets copyleft components. Review linking, forks and modifications; identify any component that needs replacement or an architectural change.
4. Adopt a short open-source policy. Say who approves libraries, how approvals are recorded, what the default restrictions are and how exceptions are granted. Write it for developers to use.

Ongoing controls

5. Add license checks to CI/CD. Automated scanning and blocking of components outside your policy is not specifically required by law, but can make the policy workable.
6. Prepare a reusable diligence package. Include the component inventory, NOTICE file and attributions, open-source policy and exception register.
7. Train developers with concrete examples. Cover SaaS and copyleft, copying code from Stack Overflow, and reviewing AI-generated code.
8. Review customer contracts. Check whether you can satisfy existing IP representations, warranties and indemnity commitments.
9. Revisit the inventory and exceptions regularly, for example quarterly. Dependencies can change every sprint.

How we can help

Project agreements can set rules for recording, reviewing and approving open-source components. They can also allocate responsibility for replacement solutions and costs arising from third-party claims connected with license breaches.

We assist technology companies with:

The aim is to resolve issues before a transaction, not restrict developers unnecessarily. We recommend code changes where the review identifies a real risk.

Bring your licenses under control before an investor asks

Open source is not inherently a problem. The problem is being unable to identify the components in your product or explain the terms on which you use them. An advance review is a planned project; remediation during a transaction may bring a lower valuation, escrow and unplanned engineering work.

If you are preparing for funding, selling to enterprise customers or assessing your position in Poland, contact us. We can audit components, help establish a licensing policy and prepare the documentation an investor or customer expects.

Frequently asked questions

Where do we start if we have dozens of repositories and no dependency inventory?

Generate an SBOM for each repository and build, using SCA tools to assemble the initial list. Classify the identified licenses under your policy, then assess where integration or distribution creates a real risk. Some issues may call for code changes; others may require completing notices or documentation.

Does copyleft matter for a SaaS product?

Yes, but the license matters. Under most GPL-family licenses, network access alone does not constitute conveying the program and generally does not trigger the source-code obligation. AGPL addresses network interaction. Check whether AGPL components are present and how they are integrated.

What does an investor want to see?

A documented chain of title, an SBOM with licenses, informed decisions about integrated copyleft components, written B2B contractor agreements specifying fields of exploitation, and evidence of an open-source management process. Gaps do not automatically end a transaction, but may lead to escrow, a holdback or an earn-out.

Can an SCA tool replace legal review?

No. It can identify components and their reported licenses. Whether the way you link, modify or integrate a component triggers a particular license obligation requires analysis of the license and the product architecture.

Do we automatically own code written by B2B contractors in Poland?

No. The employer rule in Article 74(3) concerns employment. For B2B work, check for a valid written transfer of economic copyrights that specifies the fields of exploitation—and trace rights through any subcontractors.

Do AI coding assistants add licensing risk?

They can. A generated snippet may resemble licensed code, and its origin may be difficult to show later. Review it before committing, check for similarity, record relevant sources and licenses, and keep confidential company code out of prompts unless there is a legal basis for using it there.