The use of open-source software (OSS) in the development of commercial software offers numerous advantages but also entails legal risks.
Open source licences such as the GNU General Public License (GPL) or the Mozilla Public License can, due to ‘copyleft’ effects, mean that software may only be passed on under certain conditions that do not allow licence conditions that deviate from them. Inappropriate integration of OSS into proprietary software can infect the entire software and restrict commercial use.
Leupold Legal supports software providers in the legally secure integration of open source components into their own software and in avoiding licence violations and liability risks.
Developing software regularly requires significant investments. This makes the legal protection of software all the more important, and every software provider should be aware of the conditions and legal consequences. Leupold Legal
Software providers and their customers are increasingly turning to software as a service (SaaS), but some companies still prefer on-premises models. Software End User License Agreements (EULA) must be flexible and individually tailored to this.
Leupold Legal creates customized software licence terms that achieve this and also ensures GDPR compliance and protection of trade secrets when processing data in the cloud.
The introduction of software in a company is complex and involves significant risks – almost 70% of all IT projects fail either completely or in part due to missing or unclear contractual provisions and inadequate project management. Delays, cost explosions and insufficient software functionality are particularly problematic. Clear contractual provisions help to achieve project goals and minimise project risks.
Leupold Legal supports you with
To ensure business continuity, software maintenance contracts with service level agreements (SLAs) that meet your system availability requirements are indispensable. Leupold Legal drafts and negotiates customized SLAs that also cover the interaction with existing IT system landscapes and ensure the operational readiness of high availability (HA) systems.
In the European Union, copyright protection applies to the expression in any form of a computer program including drafts and their preparatory design material. Ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected. Since the functionality of a computer program is not a form of expression so competitors are principally free to create software with similar functions as long as they don´t use the source or object code in the process.
The natural person who has created the program is principally the rightholder who has the exclusive right to make reproductions of the computer program by any means and in any form as well as the right to translate, adapt, arrange or otherwise modify the program the right to distribute the original or copies of it and to communicate it to the public e.g. by making it available to download on the internet.
The decompilation of a computer programs is permissible under certain conditions without prior consent of the rightholder if it is indispensable to obtain the information necessary to achieve the interoperability of an independently created computer program with the program that shall be decompiled. However, the information obtained by the decompilation may not be used for the development, production or marketing of a computer program which is substantially similar in its expression without the consent of the rightholder.
The answer to this question depends on the licensing terms of the open source software (OSS). While it has become common practice to use OSS code in commercial software, it is often ignored that OSS licenses can “infect” proprietary software code if the OSS license provides that it shall apply to such code as well. This can have the undesirable consequence that any licensing terms deviating from the OSS license do not apply and a computer program that contains OSS code cannot be marketed as intended. For this reason, the use of OSS in commercial software products should always be subject to prior consideration and clarification of the legal effects this may have.
Developing or adapting software according to agile principles such as SCRUM or other recognized agile frameworks can have significant advantages and increase the likelihood of a successful project completion in less time than is needed for applying traditional waterfall methodologies which require the up-front definition of all software requirements.
However, it is not rare that the lack of clear software requirements is used as an excuse for the application of agile principles. Customers are often unaware that they must be familiar with agile principles and willing to invest significantly more of their time in agile projects, not less. Agile “by name only” and the failure to clearly limit the project scope can result in “feature creep”, i.e. the continuous extension of the software by new functions and the lack of software documentation. Moreover, agile software development or adaptation is often offered as a mere “service” without an obligation of the supplier to achieve a specific project success or remedy software defects. It is therefore of particular importance to manage the risks associated with agile software development and adaptation in a project agreement that accounts for these risks.
The scope of rights granted in bespoke software or software adaptations does not always receive the level of consideration it deserves. Clear licensing terms that account for the intended use are of vital importance for software users as well as suppliers. As a rule, rights of use that are not expressly granted remain with the rights holder unless the mutually agreed purpose of the contract concluded does not suggest otherwise and too restrictive licensing terms can lead to an overuse that results in copyright infringements and additional costs. Software licensing terms must therefore be crafted in a way that accommodates the interests of both parties and avoids ambiguities with the resulting legal uncertainties.
A service level agreement is usually part of a software maintenance agreement and provides for specific deadlines which must be kept by the service provider to respond to the communication of software defects by their customers and to cure such defects. Service level agreements are crucial for ensuring business continuity because statutory law does not provide specific provisions on the scope of software maintenance.
Without a proper software maintenance agreement, software bugs that can seriously affect the execution of essential business processes are either not cured in a timely manner and/or left to troubleshooting on demand depending on the current capacity of the service provider. While there can be a mutual oral understanding on some kind of software “support”, the true meaning of such terms is often at best dubious. This is not only detrimental to software users who may not be able to enforce adequate software maintenance and are facing high costs but also to service providers who can be exposed to rising and indefinite maintenance demands by their customers.
Additionally, the GDPR mandates transparency about automated decision-making processes, including providing meaningful information about the logic involved.
The legal nature of SLA depends on what is agreed. Some SLA only provide certain response times for examining whether a malfunction communicated by the customer is indeed due to a software defect and to start working at it in which case the SLA may be viewed as a contract for services. However, if the SLA also provides for measurable deadlines (e.g. in hours or minutes) to cure such defects, the service provider must not only work on a defect but achieve a certain work result, ie. the elimination of the defect. This makes a significant difference because it gives the customer an enforceable claim to have defects cured. Most Software maintenance agreements consist of obligations to perform a mix of services with or without an obligation to achieve certain work results. If this is the case, it is all the more important, to clearly distinguish between the two and ensure that the maintenance agreement provides clear governance for both.
