Yesterday Martin Hawksey of JISC CETIS published an interesting blog post on the ugly problem of openly-licensed content wrapped in closed file formats. In that post Martin writes:

PSD is a proprietary file format developed and owned by Adobe and used in Photoshop. You can actually open and edit PSD files in open source tools like GIMP (I’m not sure how legally Gimp can do this…

…and goes on to  note that he has asked OSS Watch to comment. I wrote back a quick email pointing to some issues at the levels of copyright, patent rights and trademarks, but with the headline summary: ‘it can be awkward on all levels’. In this post I propose to detail some of the issues that I as a non-lawyer can see with open source software authors implementing import and export of proprietary file formats.

Starting with copyright, the software whose functionality you are reproducing is very likely protected by copyright. It is also possible that the file format itself is a protected work. In the case of the program, we have a good reason for saying that we are not infringing its copyright by reproducing its file import/export functionality. The European Court of Justice’s ruling on some questions raised by the SAS v WPL case tells us that:

 ”neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program for the purposes of Article 1(2) of Directive 91/250.” (para 39)

There is also a limited copyright exception at EU level covering acts undertaken

 to obtain the necessary information to achieve the interoperability of an independently created program with other programs. (point 15)

under the Directive on the legal protection of computer programs (2009/24/EC). However this would not cover the distribution of a program that would otherwise be infringing, just the copying etc of the original program required to hack it about and get the information.  The directive also notes that:

 An objective of this exception is to make it possible to connect all components of a computer system, including those of different manufacturers, so that they can work together. Such an exception to the author’s exclusive rights may not be used in a way which prejudices the legitimate interests of the rightholder or which conflicts with a normal exploitation of the program.

…which quite conceivably makes it unusable if your reverse engineering is aimed at producing a competing product, as opposed to just doing some systems integration plumbing. So in fact the reverse engineering exception is very narrow and likely does not cover the kind of work we are discussing here.

While the SAS v WPL ruling probably protects us from being accused of infringing the original program’s copyright, it does (rather worryingly) also note:

45. The Court also points out that the finding made in paragraph 39 of the present judgment cannot affect the possibility that the SAS language and the format of SAS Institute’s data files might be protected, as works, by copyright under Directive 2001/29 if they are their author’s own intellectual creation (see Bezpečnostní softwarová asociace, paragraphs 44 to 46).

So if the file format itself is a separate protected work, we might be infringing its copyright by writing and distributing code that creates similar works. How could this be? Well let’s take an exaggerated example. If I wrote a program whose data file format required that chunks of data be separated by the lines of an original sonnet I had written, then any compatible file would have to contain a copy of my sonnet, as would the code that creates the file. In real life of course things tend to be different: file formats are largely defined by structure, not content, and I can’t write sonnets. We have some reason to believe that structure in computer-based works is not in itself copyrightable; the decision in Oracle v Google, while not directly applicable here, and made by a US court, points in that direction. Overall though, because we can conceive of a file format which is a protected work under copyright, we have to acknowledge that – despite encouraging developments in the courts – we might still have a problem at the level of copyright.

Patents are easier to consider, in that they are definitely a problem. Any code which implements a patented process will require a licence. We have solid examples of successful enforcement of patents against software engineers writing import export functionality. I’m sure every internet veteran remembers the GIF Wars associated with Unisys’ successful enforcement of their patent on LZW compression (pdf link) which was integral to the GIF image format. More recently Microsoft was successfully brought into compliance with i4i’s patent on methods for XML processing that were present in versions of Microsoft Office from v2003 onward.  The latter example is interesting because the patent was not actually integral to the file format, but dealt with the particular way Microsoft had chosen to create and manipulate Office files in their software. Open Office did not use the same method, and was therefore able to generate files with the same content without requiring a licence from i4i. It is also interesting, and troubling, because it highlights the fact that at the level of patents, it is not just the authors of the original program you have to worry about.

Finally there is the issue of brands and trademarks. Some file formats have associated brands. Pantone Inc’s Hexachrome technology, for example, is protected both as a patented technology and as a registered trademark. Even if the patent were found to be invalid, someone writing software that imported or exported Hexachrome data would need a licence from Pantone Inc to describe their software as Hexachrome-compatible.

So for all these reasons I think my statement that  ’it can be awkward on all levels’ is regrettably justified. The file format IP issue we have discussed here  is closely adjacent to the perennial question of what makes a standard ‘open’. As the Cabinet Office discovered this year, it’s a question with many answers, depending on which interest group you ask. Anyone interested in these issues might want to attend the European Commission’s workshop on open source and FRAND (the ‘fair reasonable and non-discriminatory terms’ under which patents associated with recognised standards are often required to be licensed) next month.

Linux behemoth Red Hat is currently being sued over alleged patent infringement by Twin Peaks Software, vendors of the closed source ‘Mirror File System’ technology. It seems that the suit has been triggered by Red Hat’s acquisition of Gluster - an open source  file system project – last year. Twin Peaks hold a patent (US7418439) which covers the technology in their product and, they argue, technology embodied in Gluster. Now that someone with a bit of cash owns and is distributing Gluster, it is not surprising that Twin Peaks has decided it is time to enforce their patent rights.

So far so normal; Red Hat is sued for patent infringement all the time, and continues its progress seemingly regardless. Red Hat being sued has ceased to be headline news. In this case though, they made a novel and interesting response. It seems that Twin Peaks’ product may contain GPL-licensed code written by Red Hat, or so Red Hat are counter-claiming.

46. Red Hat, through its employee-developers, has made significant contributions to the tools in the util-linux package, and to its “mount” program in particular, in the form of improvements implemented in the source code.

…

53. Twin Peaks’ proprietary replication software products, namely, “TPS Replication Plus” and “TPS My Mirror,” include, inter alia, a program called “mount.mfs.” This program is essential to make Twin Peaks’ “replication solution” software usable.

54. On information and belief, rather than develop its own source code to create its proprietary software replication products, Twin Peaks copied substantial portions of open source code into those products, including source code originally authored by Red Hat. Among the code Twin Peaks improperly copied was that embodied in the “mount” program released in util-linux version 2.12a, which Twin Peaks copied into the source code for its own “mount.mfs” tool. Twin Peaks’ verbatim and near-verbatim copying of open source and Red Hat source code into its “mount.mfs” tool is pervasive and extensive.

…

8. Granting a permanent injunction preventing Twin Peaks Software Inc. from copying, modifying, distributing, or making any other infringing use of Red Hat’s software;

9. Ordering Twin Peaks to pay Red Hat’s damages for Twin Peaks’ infringement of Red Hat’s copyright in its software;

10. Ordering Twin Peaks to pay Red Hat’s damages for Twin Peaks’ violation of the GPL;

11. Ordering Twin Peaks to account for and disgorge to Red Hat all profits derived from its unlawful acts; and

12. Awarding any other such relief as is just and proper.

Red Hat want money for this alleged infringement, and although it’s not in line with FOSS community norms, it’s also not that surprising here. The counter claim is intended to mitigate any losses Red Hat may suffer if the patent infringement case against it is successful. Getting Twin Peaks to stop distributing their product or come into compliance with the GPL might be a comforting moral victory, but it butters few parsnips.

In this context it was interesting to see one of the chief architects of the standard, measured community response to GPL violation, Eben Moglen, signalling in his law firm’s blog that this was a special case and might need especially serious treatment:

First, if Red Hat is correct, they take our software without playing by our rules, and then they attack the community using their doubtful patent.

Such betrayal of the community while making use of its software is a particularly severe offense. If Twin Peaks is in fact ripping off the community while also suing one of our leading commercial redistributors, serious consequences should follow.

Red Hat has been a significant supporter of SFLC since I founded it. But in this as in all similar situations, SFLC’s primary concern is protection of the rights and interests of our clients, non-profit makers and distributors of FOSS. SFLC will now begin an investigation of Twin Peaks’ products, to ascertain whether any of our clients’ rights are being infringed through the violation of FOSS licenses. We hope that other organizations around the world, including GPL-violations.org and the Software Freedom Conservancy will do likewise. Community defense is the crucial guarantor of a level playing field for businesses, as it is the heart of protecting freedom for developers. We need to know the truth about Twin Peaks’ practices, and we must take whatever steps are appropriate when the truth is known.

The latter part of that final paragraph immediately brought this famous moment from B-movie history to my mind (warning: very mild horror).

This Wednesday Twin Peaks responded (pdf link) to Red Hat’s counter claim, and in doing so stayed true to their mysterious TV namesake. It seems that to them little is certain. Red Hat, in its counterclaim, waxed discursive over the operation of the GPL and the nature of free and open source software. In responding to these sections, Twin Peaks almost universally says that it has insufficient information to assess whether the claims are true or not. In paragraph 42 of Red Hat’s counter claim we find this:

42. Furthermore, Section 4 of the GPLv2 states:

You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.

Twin Peaks respond, confusingly:

42. Twin Peaks admits that Section 4 of Exhibit A to Red Hat’s Counterclaims states:
You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.
Twin Peaks lacks sufficient information to admit or deny the remaining allegations in Paragraph 42 of the Counterclaims, and therefore denies them.

What remaining allegations? All they can be objecting to is the assertion that Red Hat’s pasting-in of the GPL v2 as Exhibit A is in fact the GPL v2, something that they are surely able to check using their reading skills. They do seem doubtful though:

37. Twin Peaks admits that Exhibit A to Red Hat’s Counterclaims appears to be a copy of version 2 of the GNU General Public License (the “GPLv2”).

(my italics). This approach has the disadvantage of (perhaps unintentionally) signalling to the wider FOSS community that the fairly uncontroversial statements Red Hat makes about FOSS and the operation of the GPL in these sections (for example: “The benefits of the FOSS development model are widely recognized”) are things Twin Peaks intends to deny in court. What may well be a canny legal tactic of keeping one’s arguments hidden at this early stage runs the risk of making Twin Peaks seem, to the FOSS community at large, like an attacker intent on undermining its values. With luminaries like Eben Moglen calling for the community to unite in investigating them, Twin Peaks might do well to think about community relations as much as legal manoeuvring.

With the release of Microsoft’s Windows 8 operating system approaching (October 26th) I thought I would take a look at the current version of the agreement that developers must sign to get their applications into the Windows Store. There has been some controversy over the Windows Store, with some games company representatives pouring scorn on the potential benefits that the Microsoft-managed distribution channel is said to provide. Clearly Microsoft have seen what Apple has succeeded in doing with their iOS App Store and subsequent Mac App Store (essentially gaining increased control over their developer ecosystems) and decided that they would like some of the same, please.

When the developer agreement was published in December last year Microsoft got some positive coverage from the IT press for what seemed to be a deliberate attempt to include open source software in the range of code that could be distributed via the Windows Store. In fact, as many noted at the time, although Microsoft’s definition of what ‘FOSS’ is includes GPL licensed software (‘”FOSS” means any software licensed under an Open Source Initiative Approved License…’) in practice the fact that the Windows Store agreement imposed restrictions not present in the GPL would make use of third party material under that licence in the Windows Store impossible.

The agreement makes it clear that Microsoft is not an intermediary in the grant of rights from the developer to the end user, but that they do have certain requirements for what that grant of rights should look like. In fact they provide a default agreement between developer and customer which will automatically used if the developer fails to write their own (Exhibit A at the end of the agreement, referred to as the Standard Application License Terms). If the developer does want to write their own, Microsoft has some opinions on what it should look like. These requirements are given in section g:

g. License to Customer for Windows Store apps. You, not Microsoft, will license the right to install and use each app to customers. You may provide a license agreement to the customer for your app. That license agreement or other terms that govern a customer’s use of your app (including any privacy policy), or a link to them, must be delivered to Microsoft for publication via the product description materials you provide to Microsoft. If you do not provide such materials, then the Standard Application License Terms, attached as Exhibit A, will apply between you and customers of your app. If you provide your own license agreement, your license must, at a minimum, (a) permit the customer to download and run the app on up to five Windows 8 enabled devices that are associated with that customer’s Microsoft account, without payment of any additional fees to you (from either Microsoft or customer), (b) include “disclaimer of warranty” and “limitation on and exclusion of remedies and damages” sections that are at least as protective as Exhibit A and (c) disclaim any support services from Microsoft and the customer’s device manufacturer and network operator (if applicable). Your license terms must also not conflict with the Standard Application License Terms, in any way, except if you include FOSS, your license terms may conflict with the limitations set forth in Section 3 of those Terms, but only to the extent required by the FOSS that you use. “FOSS” means any software licensed under an Open Source Initiative Approved License.

So for a developer wanting to include third party code, they must determine if the open source licence they have to the code they want to include is compatible with these requirements. (a) and (b) seem relatively unproblematic. (c) could be a problem, depending on how explicitly Microsoft require such a disclaimer to be. If Microsoft need to be explicitly named that could be an issue, as they tend not to be in open source licences . Then we read that, as well as those requirements, our open source licence must also not conflict with any part of the default agreement with the exception of section 3, which it is entitled to overrule. So, at the risk of belabouring the point, we now need to check all the responsibilities we inherit as a result of our inbound FOSS licence against those present in the Microsoft Standard Application License Terms (excluding section 3) to see if this combination of responsibilities results in any conflicts. If it does, we can’t use the FOSS in question. We have to assume, I think, that section 7 of the Standard Application License Terms has to be excluded too, as its requirement that the Standard Application License Terms be the entire agreement between the developer and the customer is necessarily conflicting with any additional/alternative agreements, FOSS or not.

So what’s a developer to do (if they want to use someone else’s FOSS in their project)? Well, in practice, the developer agreement lets us know what we have to do in order to submit our code. After that Microsoft will determine whether our variant customer agreement (including the FOSS terms of the code we reused) meets with their approval or not. Once the Windows Store has been operating for a while we will be able to see practical examples of software containing third party FOSS which have been approved, and start making a de facto list of FOSS licences that Microsoft feel are not in conflict with their model. Of course, it is still possible that the third party FOSS authors themselves might object that distribution via the Windows Store is not in accordance with their understanding of the licence they chose, but that is another issue. What would have been a genuinely useful gesture on Microsoft’s part, however, one that would have made their seeming openness towards FOSS much more useful to the community, would be a pre-delivered list of OSI approved licences that meet the rather difficult-to-assess criteria that we see in the current version of the developer’s agreement. Without it, the developers that Microsoft is so keen to woo to their platform will have to waste valuable coding time doing something that Microsoft’s legal department would be much better placed to accomplish.