Most commercial contracts are between named parties and have clear monetary commitments. In software licensing there is either a specific signed agreement (such as Microsoft’s Enterprise Agreement) or, for consumers, an end user licensing agreement (EULA) accepted via an ‘I Accept’ tick box.

• Open source licensing is more of a struggle to understand:
• The identity of the licensor may be unclear;
• There is no obvious acceptance process similar to execution of a document;
• No royalties are generally paid; and
• Their terms, often imposing extensive obligations on the licensee eg to license back their own developments, seem never to be enforced.

Any scrutiny of commercial source code will however habitually uncover the extensive use of open source code.  Open source specialists, Black Duck, recently assessed 1,000 commercial applications uncovering use of open source in 96% of cases.  Under the GPL family of licenses, 75% of applications contained components, but only 45% of those applications complied with GPL obligations. Software for retail and financial services were most exposed.

Commercial licenses of software which have embedded open-source will therefore often not conform to the licensing obligations under the original open source license – in many cases eg GNU, there is a contractual commitment to license onwards for free and to license back your derivative software back to the community. Clearly then that downstream commercial license could be challenged (question: by whom?).

There are few cases on open source – perhaps because of lack of clarity regarding the ‘licensor’ but also because of widespread usage which is seemingly never checked or controlled.

A recent US case (April 25, 2017) confirms again that such licenses, although exceptional in commercial terms, are indeed enforceable and that their terms cannot be wholly disregarded.

In Artifex Software Inc v Hancom, Inc, an interim judgment confirmed that there can be both breach of contract and copyright infringement claims where an open source license is breached.

Here, Artifex had created and made available its Ghostscript software – a program for interpreting Adobe pdf files.  This was available free to end-users but onward commercial distribution, or embedding into other products, required a fee.

Hancom incorporated Ghostscript into its ‘Hangul’ product an alternative to MS Word.

The US District Court confirmed that, even where a GNU General Public License (here the Affero version) were in place, financial payments (damages) can still be obtained if use goes outside its limited terms.

The case noted the leading US judgment in Jacobsen v KAM Industries where the Federal Court said that ‘There are substantial benefits, including economic benefits, to the creation and distribution of copyrighted works under public licenses that range far beyond traditional license royalties’.

Key to both cases is a differentiation between conditions which set out the scope of a license and ‘covenants’ which are effectively promises to carry out particular acts. Where there are limiting conditions then use beyond the delineated scope will be an infringement of copyright. For any US use that can trigger ‘statutory damages’ – very high fixed penalties per infringement not correlated to any license fee tariff.

In Germany, Gpl-violations.org has been very active in bringing claims against Skype amongst others, seeking court orders that their source code must be made available to the public.

In the UK, FSF Europe (the Free Software Foundation) pursued BT over its Home Hub, a network device that utilises the Linux kernel. FSF Europe maintained that BT necessarily needed to make available the firmwaresource code because the BT software had included its Linux kernel under a GPL v2 license.

Scrutiny of use of open source in commercial software is increasingly part of M & A due diligence and can now be expected. But what of licensees of commercial software that are being pursued for under-licensing. It is arguable that, if that commercial software has incorrectly-licensed open source, then the vendor has a liability to you and/or their grant (and thereby their recoverable license fees) are invalid.

Speculative perhaps – but these are issues which could be raised by astute licensees.

It is clear that, although open source has wide acceptance across industries, the related legal ramifications – for developers, software vendors and licensees – are still being overlooked.

Lesson # 1 (for software publishers):  Carry out forensic tests on your commercial software to identify the use of open source and the applicable license terms; consider your jeopardy for license fees if usage goes beyond the limited open source license.

Lesson # 2 (for users of commercial software): Consider whether any embedded use of open source code within the vendor’s commercial software either (a) breaches their indemnities to you or (b) renders void their license grant. Raising either issue may, in certain circumstances, be useful strategies in dealing with a demanding software vendor.

Robin Fry

© 2017