focus on
-
Average read time 8'

Software ownership in temporary business groupings

Published in: Intellectual Property
by Arlo Canella
Home > Software ownership in temporary business groupings

In Temporary Business Groupings, the intellectual property of software becomes a crucial issue. With the increasing complexity of collaborative projects, it is essential for companies to clearly establish the exploitation rights of the software developed together.

What is a Temporary Business Grouping and how does it work in software projects?

A Temporary Business Grouping (TBG) is a strategic collaboration between economic operators who come together temporarily to participate in public tenders and manage complex projects. Provided for by the Italian Public Contracts Code (Legislative Decree no. 36/2023), the RTI allows various companies to combine their skills and resources to tackle projects that they could not handle individually. Article 65 of the Code states that an RTI can include individual entrepreneurs, commercial companies, cooperatives, and consortia, while Article 68 specifies that the economic operators must grant a “special collective mandate with representation” to the lead company, which represents the offer on behalf of all the participating companies.

There are three main types of TBG, each with a different approach. The Horizontal TBG involves companies that perform similar activities: for example, several software houses joining forces to develop an integrated IT system, combining expertise in programming and security. In a Vertical TBG, one or more companies handle the main activities of the project, while others manage secondary tasks; consider a company that develops the core of an ERP software and others that provide integrations and support services. The Mixed TBG combines these two approaches, distributing activities according to the specializations of the participants.

In the context of software projects, an TBG can be crucial for the development of complex platforms such as ERP systems or cloud solutions, where each company contributes specific and complementary skills. The digitization of public contracts, as outlined in Articles 19-31 of the Code, makes it essential for technology companies to provide innovative solutions that meet the new efficiency and cybersecurity needs of public administration.

But why should a company consider joining an TBG? First, to increase competitive capacity: participating together allows aiming for large-scale, complex projects. An TBG also allows for sharing risks and resources, reducing the financial and organizational exposure of each individual company. It provides access to specialized skills: by combining know-how, companies can develop innovative solutions and improve the quality of the final product. Finally, there is operational flexibility, crucial in software projects where requirements can change rapidly.

However, be cautious: the rules regarding who owns the rights to jointly developed software are not always clear. Intellectual property management must be carefully planned, as “failure to define ownership and usage rights can lead to legal conflicts” between participating companies. In the next chapter, we will explore what the law says about the intellectual property of software in TBGs and the critical issues to address to protect your rights and avoid surprises.

Who owns the software in Temporary Business Groupings (TBGs)?

Within Temporary Business Grouping (TBGs), the issue of ownership of jointly developed software can become a minefield. Who holds the economic exploitation rights to the software? How are responsibilities and rights determined in a context where multiple companies contribute to the final result?

The Italian Copyright Law (Law no. 633/1941) establishes some fundamental rules. Article 12-bis provides that the economic exploitation rights of software created by an employee belong to the employer, unless otherwise agreed. For freelancers, the Jobs Act (Law no. 81/2017), in Article 4, specifies that the economic usage rights belong to the client only if the inventive activity is provided for in the contract and compensated for that purpose.

Relating TBGs, software ownership is determined not only by basic regulations but also by the contractual agreements made between the parties. Article 68 of the new Public Contracts Code (Legislative Decree no. 36/2023) suggests that the companies participating in a TBG must clarify in contracts who holds ownership of the produced results, including the software. If these provisions are not clearly defined, legal uncertainty and conflicts among the parties may arise.

A relevant example is the Bologna Court ruling (no. 96/2020), which established that, in the absence of explicit agreements, the ownership of the source code of commissioned software belongs to the client. This principle becomes crucial in TBGs, where the developed software could be seen as a collective result of the group. It is essential that TBG contracts specify who holds the rights to the software and how these rights can be used or transferred.

Another important aspect is the principle of maintaining contractual balance introduced by Article 9 of the Public Contracts Code. This principle allows for the renegotiation of contract terms in the case of extraordinary and unforeseeable events that alter the original contract balance. In the context of an TBG, such a clause could be used to adjust conditions related to the intellectual property of the software if circumstances significantly impact the project dynamics.

To protect know-how and confidential information, companies should include non-disclosure agreements (NDAs), specifying what is considered confidential and how information should be handled. Articles 15 and 16 of the new Code emphasize the importance of transparency and conflict-of-interest management, which also becomes crucial to avoid disputes over intellectual property.

But what happens if companies do not provide clear agreements? The lack of a precise contractual framework can lead to disputes that risk undermining the entire project and the relationships between the companies. This is why it is crucial to foresee essential contractual clauses. In the next chapter, we will explore what these clauses are and how they can prevent conflicts and protect the interests of all parties involved.

Essential contractual clauses to protect software developed in TBGs

When multiple companies collaborate on software development within a TBG, the protection of intellectual property requires clear and detailed contractual clauses. These clauses help to avoid misunderstandings and future conflicts, ensuring that all parties have a precise understanding of their rights and obligations.

Non-Disclosure Agreements (NDAs) are essential for protecting the know-how and confidential information shared between companies. An effective NDA must define what is considered confidential, who can access such information, and the necessary security measures to protect it. It should also establish the consequences in the event of a breach. Protecting confidentiality is one of the foundations for successful collaboration in a TBG.

Clauses regarding the economic exploitation rights of the software are another key element. They must specify who has the right to use, modify, distribute, or sell the developed software. The lack of clarity on these aspects can lead to conflicts. For instance, a clause could stipulate that the software is jointly owned by the participating companies, but that none may transfer it to third parties without the consent of all involved parties.

An additional safeguard is the software escrow clause. This clause requires the deposit of the source code with an independent third party. In the event of the developer’s bankruptcy or other specific circumstances, the client can access the source code to continue development or maintenance of the software. Escrow thus becomes a crucial guarantee to protect investments and ensure project continuity.

It is essential to include a clause that defines liability for any infringement of third-party rights. Who is responsible if the developed software violates third-party intellectual property rights? Setting liability limits and establishing a transparent management process for such situations can prevent unwanted surprises. The companies may decide to take out specific insurance or directly assume responsibility.

The key to preventing conflicts is to put everything in writing and establish from the outset who does what and how unforeseen situations will be handled. In the next chapter, we will see how the management of software ownership once the project is completed, and the distribution of economic benefits, can influence the sustainability and future collaboration between the participating companies.

Management of Software Ownership Post-Project and Distribution of Economic Benefits

The conclusion of a project developed within a TBG does not mean that the issues surrounding software ownership are resolved. On the contrary, it is at this stage that critical aspects of the future management of the software and the distribution of economic benefits emerge.

One of the key points to define in TBG contracts is who retains the rights to use the software after the project ends. Participating companies may be authorized to use the software for internal purposes, but what happens if one of them wants to sell it or license it to third parties? It is crucial that the contract establishes clear conditions regarding these possibilities, specifying required authorizations, limitations, and potential compensation for the other participants.

Another sensitive aspect is the distribution of profits arising from licensing or selling the software. Distribution is often proportional to each company’s contribution to the software’s development, but it is essential to precisely define the criteria for evaluating contributions and how these translate into profit percentages. Clear definitions help avoid misunderstandings and disputes between the parties.

Maintenance and software updates are equally important. Even after the main project is completed, the software may require modifications and improvements. The contract must specify who is responsible for these tasks and for how long. In many cases, one of the participating companies, typically the lead company, is designated to provide technical support and updates, ensuring that the software continues to function correctly and remains competitive.

Operational continuity clauses can be vital to ensuring that the developed software remains functional and updated, regardless of the status of the participating companies. These clauses may include the obligation to deposit the source code with a third-party entity or to transfer development and maintenance licenses to other companies in case one of the participants leaves the project or ceases operations.

Adopting a clear and shared strategy for managing software ownership after the project is essential to maintaining good relationships between the companies and ensuring that the value generated by the project is distributed fairly. Careful planning not only prevents conflicts but also facilitates future collaborations.

© Canella Camaiora Sta. All rights reserved.
Publication date: 9 September 2024

Textual reproduction of the article is permitted, even for commercial purposes, within the limit of 15% of its entirety, provided that the source is clearly indicated. In the case of online reproduction, a link to the original article must be included. Unauthorised reproduction or paraphrasing without indication of source will be prosecuted.
Avv. Arlo Cannela

Avvocato Arlo Canella

Managing Partner of the Canella Camaiora Law Firm, member of the Milan Bar Association, passionate about Branding, Communication and Design.
Read the bio
error: Content is protected !!