Case Study: Combining Open Source & Proprietary Software

On the face of it, a commission to draft a software license agreement would appear to be a pretty routine affair. But in practice, a lawyer needs to pay attention not only to each client’s particular requirements, but also to any new aspects and technical developments. Especially when open source software is being used, a whole series of peculiar features crops up, and the wording of the contract has to take every single one into account. And as the following example clearly shows, opting to resort to standardised agreements or amend existing ones just isn’t good enough.

The Problem

Generally, software license agreements are based on a business model along the following lines: the software manufacturer and licensor generates revenues from the license fees that are paid, with the amount depending on the number of copies of the standard software that have been sold to end consumers. For customised programmes a one-off payment is usually made, but software is sometimes also offered using the SaaS model, the idea being to receive recurring payments.

One of the lawyer’s most important tasks is therefore to prevent the client from losing control over its rights in the software, for example by granting its contractual partners excessively far-reaching licenses. The fees that are charged should reflect all the kinds of use which are assigned and enable the licensee to generate turnover.

Another approach meanwhile becoming more widespread was adopted by a client of ours, who wanted to offer a software product that consisted partly of conventional proprietary software and partly of open source software. Now the special thing about open source or free software is that anybody is allowed to copy, distribute and alter it without having to pay a license fee.

What our client had in mind was to make use of existing open source software, without having to add a license fee for it on to the price it charged external hardware manufacturers for its own product. Our client’s new proprietary software was targeted into the bargain at the rapidly growing market for the successful GNU/Linux operating system. The basic idea was to generate revenues by providing support services for end customers on the one hand, whilst on the other charging hardware manufacturers a license fee for each computer on which the software was installed.

A whole series of problems had to be considered:

The Solution

In order to make it suitable for use in international dealings, the contract for our client had to be drafted in English observing normal practice in the field of Anglo-American law. In the interests of both parties to the agreement, important matters to which particular attention had to be devoted included the choice of law and place of jurisdiction, the currency to be used, and aspects relevant to tax.

When the proprietary software components and the open source components were separated out, the question of copyright was the most important issue. To start with, we had to go into all the various open source licenses in order to ascertain whether free usage actually involved further conditions, as is the case with the GNU General Public License (GPL) – for instance, the “copyleft” principle requires that on renewed distribution, any modifications of a GPL programme that is used likewise have to be offered under the terms of the GPL. So if our client was to distribute its product on a secure legal basis and in compliance with the license already in place, we had to find out whether components of the programme he had developed could be distributed under a separate proprietary license, if so to what extent, and which components counted as open source software and had to be provided for free.

It turned out that for some of the software components the position was perfectly clear, whilst for others an element of uncertainty remained due to the ambiguity of the open source license. For this reason, our client’s further developments and modifications of the existing components were re-licensed in compliance with the GPL. Similar investigations then had to be made for the programme libraries that were used as well.

Last but not least, we had to decide whether and to what extent our client’s own developments – i.e. the ones not covered by the GPL – should be provided under a free or under a proprietary license. Aspects that we had to consider and discuss with our client included sales, the technology used, and how to address the market.

The risk of unwittingly infringing software patents, particularly abroad, poses a huge problem for anyone engaging in this kind of business. We arranged for a patent attorney to investigate whether the software did in actual fact use a patented technology of which we were specifically aware, but in all other respects, with no rational alternative to a patent search presenting itself, an indemnity clause had to be negotiated and agreed with the contractual partner.

Apart from provisions on copyright, more general contractual issues also had to be resolved, including the scope of liability and warranty, product liability, non-disclosure, legislation on T&C, and integrating agreements on support services. In each case, all the implications of combining proprietary components with open source software again had to be taken into account.

Thanks to the final contract we drew up, our client is now able to offer his software on a sound legal basis.