Open-source licences: what the GPL, MIT and Apache require for commercial use

Operating systems, databases, web servers and programming libraries are largely released under open-source licences; anyone who develops or purchases software, or runs it as a service, uses such components in almost every product. The licences permit use free of charge, including for commercial purposes; a licence that excludes use in a business or in a particular industry is not an open-source licence under point 6 of the Open Source Definition. They attach their conditions to distribution of the software, including in modified form; the AGPLv3 and the EUPL also attach them to its operation as a service.

The licence is a permission under the Austrian Copyright Act

Computer programs are works within the meaning of the Austrian Copyright Act (Urheberrechtsgesetz, UrhG) if they are the result of their author's own intellectual creation (§ 40a Abs 1 UrhG). The author may permit others to use the work (Werknutzungsbewilligung, a non-exclusive permission) or grant an exclusive right (Werknutzungsrecht, § 24 Abs 1 UrhG). In our assessment, an open-source licence is a non-exclusive permission that the rightholder offers to anyone, subject to conditions. The conditions limit the permission: GPLv2 § 4 and GPLv3 § 8 declare any copying, modification or distribution outside the licence void and automatically terminate the user's rights. As far as we are aware, there are no published headnotes (Rechtssätze) of the Austrian Supreme Court (OGH) on open-source licences; the classification rests on the wording of the statute and of the licence texts.

The licence groups and their obligations on distribution

The common licences differ in what is owed on distribution and in whether the licensee's own code falls under the same licence.

• Permissive licences (MIT, BSD, Apache 2.0): the copyright notice and the licence text must accompany every copy. The Apache License 2.0 requires, on distribution, a copy of the licence, notices in modified files, all legal notices and the NOTICE file (§ 4). The licensee's own code may be distributed on any terms.
• Weak copyleft (LGPL, MPL 2.0): changes to the component remain under the licence; the licensee's own code used alongside the component is not covered. The MPL 2.0 operates at file level: the source code of the Covered Software must be available; a Larger Work combining it with other code may be distributed on terms of the licensee's choice (sections 1.10, 3.2 and 3.3). The LGPLv3 permits the same for a Combined Work if the licence and a notice are included and the recipient can replace the library, for instance through dynamic linking (§ 4).
• Strong copyleft (GPLv2, GPLv3): anyone who modifies the program and distributes it must license the work as a whole under the GPL (GPLv2 § 2 lit b, GPLv3 § 5 lit c). Distribution in object code requires the complete source code, either supplied with it or promised in a written offer valid for at least three years (GPLv2 § 3, GPLv3 § 6). Charging for copies is permitted (GPLv3 § 4); merely aggregating independent programs does not bring them under the GPL (GPLv2 § 2, GPLv3 § 5).
• Network copyleft (AGPLv3): anyone who modifies the program and makes it accessible to users over a network must offer those users the source code of the modified version (§ 13). Under the GPL, mere interaction with users over a network, without transfer of a copy, is not "conveying" and triggers no obligation (GPLv3 § 0).
• EUPL 1.2: the European Commission's licence requires notices, the licence text, source code and distribution under the EUPL (Art 5); distribution includes providing access to the essential functionalities of the work, in other words operating it as a service (Art 1). Works combining EUPL code with code under the GPL, AGPL, LGPL or MPL 2.0 may be distributed under that other licence (Art 5 and Appendix).

The Business Source License and the Server Side Public License make the source code available but restrict production use or operation as a service. The Llama licence makes the model and code available but restricts how and by whom they may be used. None of the three is an open-source licence, as the Business Source License says of itself and as the Open Source Initiative has stated for the SSPL and the Llama licence. Openly available AI models are frequently released under terms of this kind; we will address them in a separate article.

When the obligations arise

Internal use. Anyone who uses and modifies open-source software only within their own company has no obligations under the licence (GPLv3 § 2, GPLv2 §§ 0 and 2). A subsidiary or sister company is a separate legal person; under the wording of the GPLv3, passing software on within a group is "conveying" to "other parties" (§ 0). Passing software to a contractor, including a group company, that modifies or runs it exclusively for the client is exempt (GPLv3 § 2).

Selling a product or device. On delivery to customers, all distribution obligations must be met: licence texts, notices and, for copyleft, the source code or the written offer. For a physical product, the offer under GPLv3 § 6 lit b is valid for at least three years and for as long as spare parts or customer support are offered for that product model. For consumer devices, the Installation Information for modified versions must be provided in addition, unless nobody can install modified software on the device (§ 6).

Linking libraries. As far as we are aware, no Austrian court has decided in a published headnote whether a program that merely calls a GPL library, or is dynamically linked with it, is a work "based on the Program". The LGPLv2.1 proceeds on the basis that an executable produced by linking is a derivative of the library (§ 5). Anyone who wants to keep their own code outside the GPL uses a library under the LGPL, the MPL or a permissive licence.

Commissioned development. If a service provider or a freelance developer delivers code containing open-source components, the distribution obligations fall on the client as soon as it distributes the product. The contract must therefore list the components with their licences and contain an assurance that no licence conflicts with the intended use. For programs created by employees in the performance of their duties, the exclusive right of use (Werknutzungsrecht) vests in the employer unless otherwise agreed (§ 40b UrhG); for freelance developers, the contract must grant the rights.

What a breach triggers

Anyone who does not comply with the conditions uses the work without permission. Every rightholder may sue for an injunction (Unterlassung); in community projects, each joint author (Miturheber) may do so independently (§ 11 Abs 2 UrhG). The owner of a business is also liable to an injunction for infringements committed in the course of the business by its employees or by persons acting on its behalf (§ 81 Abs 1 UrhG). The rightholder may also claim removal (Beseitigung), up to the destruction of unlawfully produced copies (§ 82 UrhG), reasonable remuneration irrespective of fault (§ 86 Abs 1 UrhG) and, where there is fault, damages including lost profit or, at the injured party's option, twice the reasonable remuneration or surrender of the profit made (§ 87 Abs 1, 3 and 4 UrhG).

Under GPLv2 § 4, the licence terminates on breach; the text makes no provision for cure. A new licence can only be granted by the rightholder. The GPLv3 reinstates the rights provisionally once the breach ceases, and permanently if the rightholder does not notify the licensee of the violation within 60 days after cessation; on a rightholder's first notice, the rights are reinstated permanently if the breach is cured within 30 days of receipt (§ 8). The licences of recipients who obtained copies from the infringer remain in force; under the GPLv2, they do so only as long as those recipients comply with the licence (GPLv2 § 4, GPLv3 § 8).

Warranty and liability

All the licences mentioned exclude warranty and liability to the extent the applicable law permits (GPLv3 §§ 15 to 17, Apache §§ 7 and 8, MIT, BSD, MPL 2.0 sections 6 and 7, EUPL Art 7 and 8); the EUPL excepts wilful misconduct, damage caused to natural persons and statutory product liability (Art 8). How far these exclusions are effective under Austrian law has not been settled by published case law. Towards consumers, an exclusion of liability for personal injury and for intent and gross negligence is in any event ineffective under the Consumer Protection Act (§ 6 Abs 1 Z 9 KSchG); between businesses, an exclusion in standard terms is subject to review for gross disadvantage (gröbliche Benachteiligung) under § 879 Abs 3 of the Austrian Civil Code (ABGB).

The exclusion operates only between the open-source author and their licensee. The company that builds the software into its product is liable to its own customers under contract and statutory warranty law (Gewährleistung) as if it had written the code itself. The licences allow warranty or liability to be assumed for a fee (GPLv3 § 4, Apache § 9, MPL 2.0 section 3.5); anyone who, under Apache or the MPL, assumes it does so in their own name and must hold the authors harmless from claims.

Product liability and the Cyber Resilience Act

The Product Liability Directive (EU) 2024/2853 treats software as a product; it does not apply to free and open-source software developed or supplied outside the course of a commercial activity (Art 2 Abs 2). Anyone who integrates such software into a product in the course of a commercial activity is liable for it as for any other component (recital 15). Details are set out in our article on software product liability from December 2026.

The Cyber Resilience Act (Regulation (EU) 2024/2847) covers products with digital elements made available in the course of a commercial activity; open-source software provided free of charge without monetisation falls outside it (recital 18). Manufacturers must exercise due diligence when integrating third-party components, including open-source components (Art 13 Abs 5); a vulnerability in a component must be reported to its manufacturer or maintainer and remediated (Art 13 Abs 6). Vulnerability handling includes a machine-readable software bill of materials covering at least the top-level dependencies of the product (Annex I Part II Nr 1). The regulation applies from 11 December 2027; the reporting obligations under Art 14 for actively exploited vulnerabilities have applied since 11 September 2026 (Art 71 Abs 2).

What to set up now

• Keep an inventory: every component is recorded with version, licence and origin, including transitive dependencies; for products with digital elements, the inventory becomes the software bill of materials.
• Check the licence before distribution: before every delivery, every release and every launch of a service, it must be established which licence triggers which obligation.
• Meet the obligations: licence texts, copyright notices and NOTICE files accompany the product; for copyleft components, there is a written offer of source code valid for at least three years.
• Contracts with developers and suppliers: the contract contains the list of components, an assurance that the components were selected in compliance with their licences and the grant of rights in the developer's own code.
• Acquisitions: licence review belongs in due diligence. Under GPLv3 § 10, the acquirer of a business or of its assets receives the predecessor's licences and a right to the source code; if the seller has lost its licence through a breach, the acquirer does not receive one either (§ 8).

Our IT law practice supports you with licence reviews before a product launch, developer contracts and due diligence.

This information is general in nature and does not replace advice on an individual case.