Author Archives: Rowan Wilson

The Wikipedia hoover

Six frogs from a paper available on PubMed

“Pick a frog, any frog” – an image automatically imported from PubMed to Wikipedia

Back in August Wikimania came to London and I heard some interesting discussion there of Wikipedia’s approach to open access materials and the tools they are developing to support that approach. This github repo contains some interesting open source projects designed mainly to automate the process of identifying cited external resources that can be copied into Wikipedia’s repositories of supporting material wikisource (for texts) and (for pictures, video and sound).

open-access-media-importer for example is a tool which searches the online repository of academic biology papers PubMed for media files licensed under the Creative Commons attribution licence and copies them into the wikimedia repository. Where the files are in media formats that are encumbered by patents, the script also attempts to convert them to the patent free ogg format framework.

In the same github repo is the OA-Signalling project presents a developing framework for flagging open access academic papers using standardised metadata, perhaps integrated in future with the systems being developed by DOAJ and CrossRef. This wikipedia project page explains further:

Some automated tools which work with open access articles are already created. They impose nothing upon anyone who does not wish to use them. For those who wish to use them, they would automate some parts of the citation process and make an odd Wikipedia-specific citation which, contrary to academic tradition, notes whether a work is free to read rather than subscription only. The tools also rip everything usable out of open access works, including the text of the article, pictures or media used, and some metadata, then places this content in multiple Wikimedia projects including Wikimedia Commons, Wikisource, and Wikidata, as well as generating the citation on Wikipedia.


During the sessions in which open access and these tools were discussed, many participants expressed strong dislike for academic publishers and their current closed practices. Clearly for many the idea that Wikipedia could become the de facto platform for academic publication was a charming idea, and more open access was seen as the best route to achieving this.

Many years ago I worked in a digital archive, and one of the problems we faced was that academics who were depositing their databases and papers wanted to be able to revise them and effectively remove the earlier, unrevised versions. Naturally this made our jobs more challenging, and to a certain extent seemed to be opposed to the preservation role of the archive. My experiences there make me wonder how the same academics would react to their papers being hoovered up by Wikipedia, potentially to become unalterable ‘source’ copies attached to articles in the world’s most used reference work. On the one hand it is a great practical application of the freedoms that this particular kind of open access provides. On the other hand, it perhaps risks scaring authors into more conservative forms of open access publication in the future. Personally I hope that academics will engage with the tools and communities that Wikipedia provides, and handle any potential friction through communication and personal engagement. And in the end, as these tools are open source, they could always build their own hoover.

What can we learn from security failures?

After posting on the Apple goto fail bug, it is regrettable to have to talk about another serious, major bug in open source software so soon. This time it is more serious still, in that it has existed for over ten years, and is relied upon by many other pieces of standardly deployed open source software. The bug is strikingly similar to Apple’s, in that it happens as a result of code which is intended to signal an error but which through a subtle programming fault in fact fails to do so. This bug was found as a result of an audit commissioned by commercial Linux provider Red Hat, and the bug was discovered and publicised by its own author. What can we learn from these two failures in security critical open source code? For a start, it might lead us to question the so-called ‘Linus’ Law‘, first recorded by Eric Raymond:

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone.

This is sometimes referred to as the ‘many eyes’ principle, and is cited by some open source proponents as a reason why open source should be more secure than closed source. This conclusion is, however, controversial, and this particular bug shows one reason why. In discussing the reasons why this bug slipped through ten years worth of review, the reviewer/author says the following:

As this code was on a critical part of the library it was touched and thus read, very rarely.

A naive view – and certainly one I’ve subscribed to in the past – is that critical code must surely get reviewed more frequently than non-critical code. In practice though, It can be the subject of a lot of assumptions, for example that it must be sound, given its importance, or that it should not be tinkered with idly and so is not worth reviewing.

So must we abandon the idea that source code availability leads to better security? As I said in the previous post, I think not. We just have to accept that source code availability in itself has no effect. It facilitates code review and improvement, if there’s a will to undertake that work. It makes it easy to share exactly what a bug was once it was found, and in turn it makes it easier for maintainers of other code bases to examine their own source for similar issues. Finally it allows anyone who finds a problem to fix it for themselves, and to share that fix. What we must not do is assume that because it is open source someone has already reviewed it, and – if this incident teaches anything at all – we must not assume that old, critical code is necessarily free of dumb errors.

GotoFail, Open Source and Edward Snowden

On Friday Apple released a patch for a flaw in one of their core security libraries. The library is used both in Apple’s mobile operating system iOS, and their desktop operating system OSX. As of today, the desktop version has yet to be patched. This flaw, and its aftermath, are interesting for a number of reasons.

Firstly, it’s very serious. The bug means that insecure network connections are falsely identified as secure by the operating system. This means that the flaw has an impact across numerous programs; anything that relies on the operating system to negotiate a secure connection could potentially be affected. This makes a whole range of services like web and mail vulnerable to so-called ‘man-in-the-middle’ attacks where a disreputable network host intercepts your network traffic, and potentially thereby gains access to your personal information.

Secondly, the flaw was dumb. The code in question includes an unnecessarily duplicated ‘goto’, highlighted here:

It looks like a cut-and-paste error, as the rogue ‘goto’ is indented as though it is conditional when – unlike the one above it – it is not. There are many reasons a bug like this ought not to get through quality assurance. It results in unreachable code, which the compiler would normally warn about. It would have been obvious if the code had been run through a tool that checks coding style, another common best practice precaution. Apple have received a huge amount of criticism for both the severity and the ‘simplicity’ of this bug.

Thirdly, and this is where we take a turn into the world of free and open source software, the code in question is part of Apple’s open source release programme. That is why I can post an image of the source code up there, and why critics of Apple have been able to see exactly how dumb this bug is. So one effect of Apple making the code open source has been that – arguably – it has increased the anger and ridicule to which they have been exposed. Without the source being available, we would have a far less clear idea of how dumb a mistake this was. Alright, one might argue, open source release makes your mistakes clear, but it also lets anyone fix them. That is a good trade-off, you might say. Unfortunately, in this case, it is not that simple. Despite being open source, the security framework in question is not provided by Apple in a state which makes it easy to modify and rebuild. Third party hackers have found it easier to fix the OSX bug by patching the faulty binary – normally a much more difficult route – rather than using Apple’s open source code to compile a fixed binary.

It is often argued that one key benefit of open source is that it permits code review by anyone. In this case, though, despite being a key security implementation and being available to review for over a year, this bug was not seemingly identified via source review. For me, this once again underlines that – while universal code review is a notional benefit of open source release – in practice it is universal ability to fix bugs once they’re found that is the strongest argument for source availability strengthening security. In this case Apple facilitated the former goal but made the latter problematic, and thereby in my opinion seriously reduced the security benefit open source might have brought.

Finally, it is interesting to note that a large number of commentators have asked whether this bug might have been deliberate. In the atmosphere of caution over security brought about by Edward Snowden’s revelations, these questions naturally arise. Did Apple deliberately break their own security at the request of the authorities? Obviously we cannot know. However it is interesting to note the relation between that possibility and the idea that open source is a weapon against deliberate implantation of flaws in software.

Bruce Schneier, the security analyst brought in by The Guardian to comment on Snowden’s original documents, noted in his commentary that the use of free and open source software was a means of combating national security agencies and their nasty habit of implanting and exploiting software flaws. After all if you can study the source you can see the backdoors, right? Leaving aside the issue of compromised compiler binaries, which might poison your binaries even when the source is ‘clean’, the GotoFail incident raises another question about the efficacy of open source as a weapon against government snooping. Whether deliberate or not, this flaw has been available for review for over a year.

The internet is throbbing with the schadenfreude of programmers and others attacking Apple over their dumbness. Yet isn’t another lesson of this debacle that we cannot rely on open source release on it’s own to act as a guarantee that our security critical code is neither compromised nor just plain bad?

FRAND and policy: Obama vetoes ITC iPhone and iPad ban

Even for those of us who find smartphone patent litigation interesting, the sheer number of decisions and reversals across so many countries can be hard to track. The general impression one gains is that every major player is seeking to gain a stake in the profits of every other major player by winning patent litigation against them.You could almost be forgiven for wondering if – should they all get their way and create channels of profit-sharing connecting them all – they wouldn’t end up being a kind of de facto single entity who could then cancel their individual litigation budgets and instead put some more effort into innovation. Indeed some would argue that this kind of patent enforcement frenzy is a sign of a saturated market in which innovation has slowed and the players are forced to grow their profit not by expanding the customer base with attractive new features but by squabbling over the money already developed customers are spending.

So while it can be depressing to monitor, sometimes the smartphone litigation gangfight can throw up interesting policy decisions. This happened on Saturday, when President Obama decided to veto a ban imposed by the International Trade Commission (ITC, but not the Thunderbirds one). The ITC offers, among other things, a quick method to banning the distribution of products that you feel are infringing on your patents. Well, I say quick… it still takes a year or so, but that’s lightning fast compared to many patent litigations conducted in court. So the ITC can act quickly, but on the down side (a) they can’t award damages, only prevent sales and (b) even if you win, the President can still decide that, for ‘policy reasons’ the ban should not happen. This last risk is not generally considered to be huge however; indeed no President since Reagan has vetoed an ITC decision. So Samsung probably felt that when the ITC granted their request to prevent the sale of certain models of Apple’s iPhone 4 and certain iPads (models 1 and 2) they had a good chance of it happening. (Having said that, it is ironic that the last time a veto did happen, back in 1987, it was in Samsung’s favour, and covered the distribution of their 16 and 32 KB RAM chips).

Samsung’s patent covers technology necessary for implementing the CDMA standard, which is used for making data connections to certain US mobile providers. As what is called a ‘Standards-essential Patent’ (SEP), the patent in question has to be licensed to competitors, and on what are known as FRAND (Fair, Reasonable and Non-discriminatory) terms. We have blogged about the interaction between FRAND and free and open source software before, and we discuss the issues in our briefing note ‘Open Standards and Open Source‘. When the owner of a SEP uses it to try to ban a competitor’s product, therefore, there will be some serious discussion of whether the owner has – as they must – already offered a licence to that competitor under fair and reasonable terms. What does fair and reasonable mean, in dollars? Unfortunately no-one knows. It’s one of those ‘litigate and see’ things. In this case, we know that Apple and Samsung have negotiated and failed to reach agreement. As Fortune magazine notes, while the details of this negotiation are largely private, a dissenting view attached to the ITC decision gives a small insight into that process, and implies that Samsung were perhaps attempting to close a so-called ‘tying’ deal. This works a lot like a satellite or cable TV package: the things you actually want are only available with a load of extras that you don’t necessarily want. Here Samsung may have been trying to force Apple to license additional patents in exchange for a workable deal on the CDMA essential patent.

This Presidential veto is interesting for a number of reasons. Its rarity makes it news, but also gives us an indication that the issues it addresses are considered very important to US trade policy. It would be possible to view this as self-interested and protectionist – after all Apple must be one of the US’ largest tax payers. However in practice Apple would just have to settle if the Presidential veto had not been applied, and it is not as though they could not afford to do so. So it seems more likely that the policy imperative here was more associated with the dispelling of doubt around whether FRAND is really a workable model. By vetoing the ITC ban, the President sends a clear message that trying to expand the boundaries of ‘fairness’ to include things that are really quite ‘unfair’ and indeed having endless arguments about what constitutes ‘fair’ is damaging to a healthy IT market.

From the point of view of the free and open source community though, it is also an interesting decision. As our briefing note linked above points out, implementing even open standards in FOSS can be non-trivial. When the UK Cabinet Office decided to define open standards as those available on a royalty free basis (partly to encourage FOSS software provision to government), there was some grumbling among standards definition bodies (indeed I was present at an event in Brussels on FRAND just after the policy was announced, and when it was mentioned in the room it clearly irked more than a few attendees). However the veto shows that the current system of agreeing to be ‘fair’ then immediately disagreeing about what ‘fair’ means is terminally broken. In this context the Cabinet Office’s decision to provide something a bit more defined than just ‘fair’ seems well justified, whether it was decided upon with FOSS in mind or not.

Icon Envy

Github, popular code sharing and collaboration site, has recently become much more attentive to the subject of unlicensed code. Obviously, like any user content driven site, Github had extensive terms and conditions that governed what Github itself could do with code that you uploaded. However, unlike Sourceforge or Google Code, it lacked a robust framework for allowing users to state what licence covered their code for the purposes of other users. Frequently it would not be clear which licence if any covered this kind of use of the projects on Github.

We have discussed the option of providing no licence with your code on this blog recently (Unlicensed code: is it ever OK?, Unlicensed code: movement or madness?). It’s superficially tempting, both as a reasoned reaction to the complexity of IPR management and as dodge to avoid it. However OSS Watch advises its customers to deal with the issue, and indeed over the years it has become an easier and easier argument to make in the academic world at least, where IP management and exploitation is emphasised more with each passing budget.

The argument against leaving your licensing unclear is fairly obvious: many of the benefits of open source release arise from collaboration, and if your collaborators value clarity in IP then they need to know the terms under which they can collaborate with you. Full clarity is perhaps only achievable when you have the trinity of a licence, a contributor agreement and a governance model, but of these the licence is the most crucial (and indeed some would say the licence should be taken to serve as all three).

So is we accept that a licence is necessary for clarity, how do we make sure we are clear on which licence to choose? It’s ironic that – for something that is supposed to improve clarity – most licences are so opaque linguistically. Like cryptic crosswords, they have implied techniques for parsing their language that are non-obvious. One answer is to do what Github has done (and indeed what OSS Watch did for their community some years ago) and produce a kind of taxonomy of licence features. Licences are complex and individual, but they contain sections that can be broadly grouped in terms of what they try to achieve. This is true both for licences in general, and even more so for the small sub-category of free and open source licences.

What you end up with, if you attempt this task, is something like the feature comparison lists you often get to aid understanding of software functionality; essentially a table with features on one axis, products on another, and ticks in between indicating which products have which features. The feature list Github has extracted varies slightly from the OSS Watch one, but that is only natural; this is a subjective exercise. The question we faced, and which faces users of Github’s tool now, is what to do when you have landed upon the ‘product’ that seems to suit your needs as a code author. At OSS Watch we use our licence tool as a first stage during a consultation, with subsequent discussion and support to choose a licence which genuinely suits a customer. We do our best to make sure the code owners actually read and understand the licence they pick; after all this is their property and the licence is a statement of their intentions for it. Personally I feel uneasy at the idea that any approximation of a licence, such as these tools inevitably provide, is going to be taken as the licence itself. Still, maybe an approximate idea is better than no idea at all?

I think in some ways the free and open source software community has been suffering icon-envy ever since the Creative Commons project launched. In the case of CC, the features, their iconic representation and their encoding in legal and natural language were born of a unitary effort. Free and open source licences have no such single source, and although the Open Source Initiative provides accreditation that certain licences exhibit certain features, we are far from having a simple, single, agreed taxonomy of their features. Github’s project may help provide us with one, but like OSS Watch’s tool, it’s not a complete substitute for actually reading your licence.

Basic Freedoms Marketing

I attended the Think GCloud event in London last week, which was extremely interesting and informative. In the exhibition area the words ‘open source’ were everywhere on the pop-up display stands and freebies. Clearly the sector has taken the government’s indication that it wishes to seriously consider open source solutions very seriously. Leafing through the event pamphlet while trying to recover my composure (don’t try running up the escalator at Angel on a hot day, it’s longer than you think) I noticed that although the stands were richly laced with the words ‘open source’, the descriptions of the seminars seemed to avoid them. Most notably Red Hat (tag line: “The World’s Open Source Leader”) did not mention them, instead choosing a slightly odd circumlocution:

Unlocking the Cloud

Cloud services have made Business question the relevance of IT. Innovation based on Open Standards and basic freedoms have allowed rapid take up of new technology, but without the IT control or forward thinking Departments are used to providing. Architectural oversight and a clear set of requirements, allows departments to prepare for cloud services, not just based on today’s offering but also with a view to future opportunities. The session will concentrate on Unlocking the Cloud, so Departments can take advantage of Cloud technologies but avoiding lock-in, both now and in the future.

“Open Standards and basic freedoms”? Which basic freedoms are we talking about here?  Open Standards and freedom of religion? Open Standards and the right to life? It seems to me that we are probably talking about software freedom here, but for some reason we dare not speak its name.

Now I have no idea what the author of that blurb had in mind when they chose that formulation, and I am certainly not saying that Red Hat are in some way generally avoiding those words; just look at their web site. It has made me speculate though, about how we use the idea of free and open source software as a marketing tool when it is rapidly becoming the norm. Do we need to highlight it any more, or can we expect our audience to either not care or know already? For some reason Red Hat decided here to lay off their usual emphasis on the subject. Is that related to their perception of this particular audience perhaps? Or is it an understanding that when talking about cloud services, people tend not to care about the underlying freedom of the platform?

Whatever the truth, I have decided to pay more careful attention to how the freedom of free and open source software is referred to in marketing from now on. Please send me your examples!

Digital Exhaustion

When I was a poor student I was extremely grateful that the local bookshop had both a new and a second hand section. Text books were and are expensive, and I would always check the used section for a usable if dog-eared copy of whatever text I was seeking. At the end of each term I would lug a stack of books up to the second hand department and recover some beer money.

These days students will probably acquire at least some of their textbooks in digital form, to be read on tablets or ereaders. Often these copies will be cheaper than their physical equivalents, but as things stand right now, they lack the end-of-term-beer-money-cash-in value that their heavier cousins still enjoy. Why is this?

It might make more sense to ask why we can resell the physical copies. After all, books are copyright works, and one of the exclusive rights a copyright owner enjoys is the right of distribution. Why can I distribute a book to which I don’t own the copyright when I sell it second hand? It’s because of what is called ‘exhaustion’. Exhaustion means that – for any given copy of a copyright or patented item –  the copyright or patent owner’s rights run out  when it is sold for the first time. This leaves the first buyer free to resell that copy of the item without the rights holder complaining that the sale infringes their rights. Why does the law explicitly allow this? It’s chiefly because the reverse situation – in which the rights holder controls every subsequent sale – is generally considered to give them too much power to fix prices therefore distort the market in ways that are societally undesirable.

So if resale of copyright and patented items is societally beneficial, shouldn’t it be possible to resell digital copies in the same way we can resell physical copies? As things stand I can resell my paperbacks but not my ebooks, my CDs but not my mp3s, my games on DVD but not the apps on my phone. The technologies that prevent users from illegally duplicating digital copies (and which are illegal to disable) also prevent this kind of resale. Only the controller of the necessary encryption keys can permit the transfer required for resale. This issue has become more pressing recently for a number of separate reasons.

Firstly, large scale digital retailers Apple and Amazon have both obtained patents for systems of resale for digital items. These systems are interesting in that they both seem to presuppose that the rights holder can enforce their rights after first sale (in Amazon’s case by effectively destroying the item after a certain number of resales, and in Apple’s case by enforcing a cut of the resale price being handed over to the rights holder).

Secondly, the announcements of the next generation of home consoles (Xbox One and PS4) have both led to speculation that the second hand games market will be restrained by the new technologies built into the new systems. It has been clear for years that games creators and console manufacturers resent the second hand games market. Second hand sales – it is argued – reduce the market for new copies and new games. None of the second hand price goes to the console or game manufacturers. However, when the game disc is all that is required to play the game, there is little they can do to restrain that disc changing hands after first sale. In the case at least of the Xbox One, it seems clear that some kind of controlled resale of games will be implemented, although the details are yet to be fully announced. This would – it seems likely – involve unique identifiers being assigned to each copy of a game (whether on disc or downloaded), and registration of these identifiers with a user account being a technological necessity for a user to play. Thus resale would necessarily involve the console manufacturer’s consent (to transfer the game ID from one account to another), whether it was legally required or not, and at that point of transfer it seems likely that some kind of levy may end up being charged.

This would all be rather disheartening if it were not for the third development, which was last year’s European Court of Justice decision in the case of Usedsoft v Oracle. This case concerned whether a company (Usedsoft) could resell licences to Oracle software that it had bought from legitimate Oracle licensees. The question being considered was, in essence, whether a combination of transfer of a copy and transfer of a licence to use the copy amounted to a ‘first sale’ that could trigger rights exhaustion. Oracle argued that it couldn’t, and that what they were doing was selling perpetual licences that could not be transferred from one user to another. Usedsoft argued that in effect Oracle were selling copies of the software and so could not control resale. The ECJ agreed with Usedsoft, and ruled that when you provide a perpetual licence and a copy of the licensed software you are selling a copy, and lose rights over that particular copy.

The fallout from this decision has yet to fully play out. Law firm Linklaters advises its software developing readers to consider stopping selling perpetual licences altogether, instead moving to a rental or service provision model. It’s hard to see this working well for consumer products however. Would customers accept annual renewals to keep their books, games and music? Probably not, unless the initial prices were a lot lower, and that is not an attractive prospect for creators and distributors.

So how does this affect free and open source software? In the worst case, one could potentially argue that the responsibilities associated with various FOSS licences, such as attribution, copyleft and source provision only apply to the first acquirer of the software and that – as a result of exhaustion – responsibilities associated with that copy no longer apply once it passes from a first acquirer to later downstream users. As the FOSS model relies on all copies requiring the same compliance with the licence, this could construably be an ugly problem. Whether this problem actually is a problem depends to a large extent on what we consider to be a ‘sale’. The Usedsoft judgement has this to say on the subject:

According to a commonly accepted definition, a ‘sale’ is an agreement by which a person, in return for payment, transfers to another person his rights of ownership in an item of tangible or intangible property belonging to him.

Using this definition it would seem fairly clear that the usual method of acquiring FOSS does not fit the pattern for a ‘sale’, due to the absence of a payment in exchange for rights of ownership over a copy. However it should be noted that Oracle tried to argue that they were handing out the copies for free but the licences for money, and that therefore it was not sale of an item, and that was rejected by the ECJ. As I am not a lawyer I can’t really give an informed opinion on how closely the judgement might bear on the FOSS model. I have certainly heard a number of people who are lawyers express very similar reluctance to give an opinion.

What seems clear is that older notions associated with physical items, first sale and exhaustion are hard to apply in the digital world, where the idea of a discrete ‘item’ is problematic. To play devil’s advocate, we can probably assume that the idea of exhaustion of rights was first conceived when it seemed obvious that a new copy would have certain advantages over a resold copy in the market, in terms of absence of physical wear and tear. Is exhaustion as fair a principle in the digital world, where the resold item is identical to the original? We can also see that the very idea of a discrete copy of a digital item is something innately tied to copy protection and digital signing technologies. If we cannot identify a particular ‘item’ we cannot know if it has been resold. While as consumers we may want a healthy second hand market in digital items, in practice such a market may well require the embracing of the kind of copy protection technologies that – up to now – consumer groups have tended to decry. What we can say is that, as technology and law continue to develop, the issue of rights in digital copies will need a clearer resolution than we have now.

Trademarks and FOSS

On April 19th the United States Patent and Trademark Office finally rejected an application for the trademark ‘Open Source Hardware’. The grounds for the rejection were that the term was ‘merely descriptive’. Trademarks are intended to identify a specific source of goods or services, protecting that source from confusion in the minds of consumers with other sources. Naturally then, if you try to obtain a trademark which is just a description of a type of product or service, it is proper that you should be refused; it would not be distinctive and it would distort the market by allowing one source to control the generic term. If I market a car for a hamster, I should not be able to get a trademark for the name ‘hamster car’, as that would improperly restrain competitors from bringing their own hamster cars to market. So should we be pleased that the application was rejected? After all there is no trademark ‘open source software’ (although the Open Source Initiative do hold one for their own name and logo which acts as a kind of accreditation mark for their approved licences and projects that use them). In this case it’s a little confusing, because the applicants do not seem to have been actually looking to use the mark to describe what is usually understood by the phrase ‘open source hardware’ at all. In fact they were looking to protect their offering comprising:

Computer services, namely, providing an interactive web site featuring technology that allows users to consolidate and manage social networks, accounts, and connections to existing and emerging application programming interfaces (APIs)

Reading the decision it seems that the services relate to providing and managing services for children on a variety of devices, and that the trademark is supposed to imply the ‘general freedom’ of open source software but applied to one’s hardware devices in a surprising new way:

In support of registration, applicant maintains in Section 1 of its brief that the mark is not merely descriptive because OPEN SOURCE was used initially with the Open Source Software Movement; that applicant’s use of “open source” would associate that term with the provision of software and that “this causes a jarring effect that is overcome by the user’s imagination to the play on words.”… Additionally, applicant argues that joining HARDWARE next to OPEN SOURCE causes consumers to think of “physical artifacts of technology designed and offered in the same manner as free and open source software,” citing to the definition of “open source hardware.”

So, I would argue, this is really not an application to use the term ‘open source hardware’ on what is normally understood to be open source hardware, so it’s not merely descriptive. This is more like the the Irish company that holds the trademark ‘open source’ for use on dairy products. Indeed, the decision does have a strong dissenting opinion which argues that the trademark ought to be allowed as non-descriptive but then properly obstructed by complaints from the actual ‘open source hardware’ community before its final grant.

What this shows, I think, is a couple of things. Firstly, that bodies like the USPTO have trouble understanding phrases like ‘open source’ where they relate to technology. Secondly, that terms that the community relies on to describe their interests and enthusiasms are not necessarily immune from proprietary seizure. While the decision here seems to contain an error that worked to deny the trademark, it’s possible to imagine a similar error that would allow a troublesome trademark to be granted.

In connection with trademarks and FOSS I was interested to see the establishment of, a wiki-based site which

 …proposes language one might use for trademark guidelines for FLOSS software projects.

It already contains a very useful page listing pre-existent FOSS project trademark policies. I would encourage readers to read the draft version of the guidelines and comment.

Openly developing data models

I was interested to see the following announcement flow through my mailbox thanks to Google Alerts:

The Financial Services Industry is full of duplicated and repetitive tasks performed within each of the financial firms with little or no standardization in what is being done. One of the most affected functions is data management with the lack of standard data to describe the entities that participate in one or the other way in financial markets, and instruments created, traded and held in custody by entities. Entity data, instrument data, corporate actions and events data, pricing and evaluation data and position and transaction data is required to generate trading signals, calculate risk, execute trades, complete clearance and settlement, and perform asset servicing in the normal course of business. Many of the business problems occur because there is no standard list of terms and definitions to describe the required information as well as relationships between different terms. Additionally, there is no standard scheme that acceptably categorizes the various asset classes in which business is transacted and classification of entities in different business segments.

φmod is an open source project to create and continually enhance and maintain data model for financial services industry. Objective is to have a well-defined and documented model that can be of immediate practical use to industry practitioners. Anyone can download and use it and anyone can contribute to the project through proposed edits of and contributions to the content of the model.


Now I have very little notion of the operations of the financial services industry, but I recognise the general shape of this problem only too well, after many years working in HE IT. I suspect it’s a common problem everywhere: lack of standardisation of data, awkward interoperability issues, little motivation to solve the big problems of data exchange that sit between organisations. I’ve seen it at one remove in other areas of the public sector such as Health and the Police Services, and in the legal services industry too. So despite my lack of financial services experience (and indeed finances in general) I will watch this project with interest. They have posted their data model on github and have a simple governance model for collaborators. I hope they can succeed in showing that they can attract collaboration from competing suppliers and industry players. We should be undertaking more of this kind of low-overhead data-silo-breaking within the public sector. Initiatives like the Cabinet Office’s Open Standards Hub are useful in themselves, but could be greatly enhanced by collaborative activity to enhance and build standards that make the most of the data for which we all pay.

Open Standards and Open Source, continued

I have just got back from this event organised by the European Commission and the European Patent Office to discuss the implications of implementing open standards in open source. Now of course this is an issue that has been very active in the UK recently, and about which we have blogged, due to the present government’s desire to use open standards as a way of increasing efficiency in government IT procurement. The idea, briefly, is that specifying IT systems in smaller, interoperable chunks that implement open standards should make government IT easier to manage and maintain and more able to be supplied by a wider range of bidders, including authors and integrators of free and open source software. As discussed in the blog linked above, there is an issue with implementing royalty-bearing standards in GPL-licensed software, and as a lot of the free and open source software out there is GPL-licensed, government risks locking this software out if they don’t specify standards that are royalty free.

Well, after a long consultation process, the Cabinet Office has decided that it will indeed make it a principle that government IT should implement interoperability standards that are royalty free:

1. We place the needs of our users at the heart of our standards choices
2. Our selected open standards will enable suppliers to compete on a level playing field
3. Our standards choices support flexibility and change
4. We adopt open standards that support sustainable cost
5. Our decisions on standards selection are well informed
6. We select open standards using fair and transparent processes
7. We are fair and transparent in the specification and implementation of open standards



Rights – rights essential to implementation of the standard, and for interfacing with other implementations which have adopted that same standard, are licensed on a royalty free basis that is compatible with both open source and proprietary licensed

solutions. These rights should be irrevocable unless there is a breach of licence conditions.

This is a bold step, and has been welcomed throughout the free and open source software community. It is also likely to peeve advocates of royalty-bearing FRAND standards (if this terminology is confusing you I would suggest reading the previous blog post linked above). At the event in Brussels, which was held under the Chatham House Rule, it was clear to me that the UK decision had come as a surprise to many attendees. One attendee asked why it was necessary to make allowances for a single licence, while another wondered why the licensing practices of the majority of standards defining bodies were somehow not acceptable. Other attendees welcomed the decision and pointed out that although in general royalty-bearing FRAND was a common phenomenon, in the area that the policy specifically addressed – software interoperability – it was far more rare, and that this perhaps reflected the differing business models and motivations that tended to operate in the software and ICT spaces. OSS Watch will be publishing a briefing note on FRAND and open source, so watch this space if this this is an area that interests you.