This division between idea and expression is slightly more complicated in the world of computer programs, however. Clearly the lines of code in a program’s source files are analagous to the words on a page in a novel, but what is a program’s ‘plot’? Is it the broad task that the program is written to achieve? How about the arrangement of code elements – say the way that the task is conceptualised as subroutines or objects? At what level of abstraction does a program pass from being an expression into an idea?

This question is an important one for anyone who is publishing code. While it’s easy to see that pasting someone else’s source code into your own program is likely to need the original author’s permission, it’s less clear whether borrowing someone else’s object model, data model or API definition is an infringing act. These questions have been being discussed both in the US and Europe recently as a result of a couple of high profile court cases.

In the US, Oracle and Google have been fighting over a range of intellectual property issues – both patent and copyright-related – for almost two years now. One key issue that remains unresolved at the time of writing is whether certain non-literal elements of the Java programming language are protected by copyright. This argument centres around what are essentially helpful code snippets that are provided to Java programmers by the creators of the language. These are arranged into named sets, with established conventions for calling them up and making use of them (APIs). The question at issue here is whether the naming of these sets and the conventions for making use of them is ownable.

In Europe, in a case covering similar though not identical ground, the European Court of Justice has ruled on an argument between SAS and WPL over the issue of whether a programming language and the structure of data files are ownable. The former question is closely adjacent to the Google-Oracle APIs issue: is a conceptual arrangement of useful items copyrightable? In this case the ECJ ruled that it is not, and drew heavily on the analogy with literature and natural language; books in English are ownable, but you can’t own English. On the issue of data files, on the other hand, the ECJ held that the structure of a data file is ownable as copyright as a part of the expression of a computer program. So here we have a real example of a concept which is not a literal expression but is still not sufficiently abstract to be an unprotected idea.  (In the event this finding did not help the ‘owners’ of the data file format, as the act of infringement they were complaining about was legitimised by an exception in EU and UK law that permits certain acts in respect of computer programs if they are done for the purposes of facilitating interoperability.)

These issues may seem annoyingly abstract and  inconsequential, but in fact they have deep significance for all software authors and consumers. While software is treated as a literary work in copyright law, its tendency to be more formally structured and complex than literature means that the division between idea and expression in it will tend to be hard to find. This in turn means that there is often a real lack of clarity on what aspects of a computer program can be legitimately reused by other software authors. This exposes the authors to risk, and means that we as consumers can find ourselves relying on software that infringes others rights and may be subject to unexpected licence fees or removal from the market. While not specifically an open source issue, it affects open source just as much as closed source. So the recent ECJ judgement and the forthcoming decision on API copyrightability in the Google-Oracle case are of real benefit to the IT community. Whatever the specifics of the decisions, their clarity will be useful.

The answer is that it doesn’t, really. In situations where implementing a standard would necessarily infringe on someone’s patent, the standards creation bodies will usually try to get the patent’s owner to agree some terms which will guarantee them a return for their investment but which will still allow everyone in the market to actually use the standard in their products. These kinds of terms are often referred to as RAND or FRAND – standing for (fair), reasonable and non-discriminatory.

FRAND is a slippery term. There’s no single definition, which makes determining what is and is not FRAND hard. Most people agree that the general principle behind FRAND is that the fees or other requirements for use of the patents in question are not ridiculously high and are the same for anyone who wishes to implement the standard, whether your best friend or fiercest competitor.

That sounds like a good idea to most people, and for more traditional hardware and closed source implementations of standards it arguably is. There can be problems, however, when software under a free or open source software wishes to implement a standard available under FRAND terms. For example, the GNU GPL family of licences all contain conditions that say – in essence – that if a distributor of the software is forced to pay for the use of a patent in the software, they must either cease distribution or obtain a licence for everyone (the schoolroom chewing gum scenario). These conditions are designed to deter patent owners from pursuing distributors of GPL software, but they mean that payable FRAND standards and GPL software do not play well together.

Even where the licence is not GPL, there can be problems with the interaction between FRAND and FOSS. One way in which patent owners make their patents available for use in a standard is by issuing a ‘non-assert’ promise. These are unilateral undertakings to not assert their patent rights, and in this context they are usually conditional on the patent being used in an implementation of the standard (not unreasonably). However in the context of open development, this can be something of a nightmare. You may write a piece of code that implements the standard and release it under a FOSS licence, confident that you are protected from patent litigation by the non-assert. An unwary downstream developer looks at your code – specifically the bit that implements the patent – and thinks: “that’s a nice bit of code – I’ll use that for my next project…” Of course, unless by some happy accident their next project is also implementing the standard then their use of the same code will not be protected by the non-assert, creating a potentially very dangerous problem.

The question of the compatibility of FRAND terms with FOSS software has become a vexed one recently due to the UK Government’s Cabinet Office seeking to create a policy around the use of open standards in government IT. The idea here is to reduce the currently crippling costs of government IT systems by opening the procurement process up to more competition. One of the perceived problems with the current situation is that there are only a few providers of solutions who can cope with the government’s massive requirements, and that the monolithic solutions they provide are often very hard to substitute once they are in place. The solution, or part of it anyway, is to break up the requirements into smaller deliverables that could be provided by more and smaller companies. How do you get these smaller solutions to work together? Use standards, preferable ‘open’ ones. That ought to create a level playing field for all sizes of providers, and alongside that make it easier to pitch FOSS solutions – with their problems with more restrictive standards and tendency to be supported by SMEs – to government.

Initially the Cabinet Office just stated that they would mandate open standards in future government procurements. Unfortunately this ran into problem of definition. Just as with FRAND – no-one has a single, snappy definition of what and open standard actually is. It’s easy to assume – with Justice Potter Stewart – that we will know one when we see one, but in practice there are polarised views in this area. The Cabinet Office’s initial definition was not to everyone’s liking. To resolve this potential confusion, not to say conflict, the Cabinet Office launched a consultation exercise to help pin down exactly what an open standard is, according to the largest possible group of respondents. The deadline for this has since been extended after it emerged that a perception of bias might have been introduced by the conduct of the process.

Some evidence of the ructions that lead to the consultation exercise can be seem in the documents columnist Glynn Moody obtained through a Freedom of Information request. I will not attempt to summarise this weighty sheaf, but I would recommend glancing through them if you want to see how lobbying of the government over IT matters looks in its naked state. At issue is the idea that – as in the Cabinet Office’s initial definition – open standards should be entirely royalty free. Now obviously ‘at no cost’ is about as low a barrier to entry as one can get, at least in monetary terms, so it’s easy to see why the Cabinet Office adopted this definition from its original home at the W3C. For one thing, it would get around the GPL-compatibility issue mentioned above, and if used instead of a non-assert, also the ‘mode of use’ problem I have cited. However it would also exclude some existing technical standards (although not many – most are already royalty free), and clearly some players are not going to be happy with that…

OSS Watch is interested in the outcome of this process because – as a non-advocacy group – we are keen that all potential solutions are able to be assessed on their merits alone. We would strongly recommend that everyone responds to the UK government consultation exercise, in order that a truly communal definition of open standards can be achieved.

In 2003, early in OSS Watch’s history, Sebastian Rahtz and Stuart Yeates drafted a policy on open source software for our funders the JISC, beginning it during a long train journey to an event. JISC had been receiving questions from the community about its attitude to open source, which was becoming a something of a hot topic. I had joined OSS Watch at its inception, having worked in other externally funded projects here in Oxford before that. One thing that had become clear quickly was that intellectual property rights were often an afterthought among projects, and that particularly where project work involved collaboration between institutions, failing to sort out those rights early could result in hair-tearing complications by project end. Where the problem was not solved, project outputs could remain undistributed, and the public money invested in them locked away.  Of course JISC was even more aware of this than any individual institution. Thus the open source policy served the dual purposes of spelling out the benefits of open licensing of resources and introducing the idea that intellectual property rights needed to be dealt with early in a project’s lifecycle.

The policy introduced a presumption that software developed with JISC resources would be open source. While this might seem like a value judgement about openness, the fact that projects could make an argument against openness where they felt it would be detrimental was another key component. In practice projects could take either approach, but what they could not do was ignore the issue. The openness presumption provided a default exploitation model that would allow maximum reusability of the publicly funded resources.   If the project’s host institution felt that a different llicensing model would suit the work better, then that option was open to them. All they needed to do was to justify it.

So one use of openness for publicly funded works is – I would argue – to stimulate creative thinking about exploitation. If the default assumption is that the intellectual property will be ‘in the cupboard’ and ready for exploitation when we get around to it, it is all too easy to postpone the decision. Operational complications can then mean it is forgotten altogether. If we begin with a default policy of openness, we know that this cannot happen, and the option to draft variant exploitation models means that we do not limit anyone’s creative thinking.

JISC were ahead of the curve in identifying the root problem here and implementing the policy to deal with it. As we have worked with other public funders over the years it has been extremely useful to point to the policy and the thinking behind it.

There are many free and open source software licences, and while they all broadly attempt to facilitate the same things, they also have some differences. Some of the major differences can be grouped together into categories, and this talk acts as an introduction to these categories. Having attended this session, you should be able to understand which decisions you should take in order to select a licence for your code.

Delegates will take away an understanding of:

• the main categories of open source licences available
• the implications of choosing one for the future of your software

Also, advance notice that the week after, on Wednesday March 14th, OSS Watch’s Sander Van Der Waal will be asking: “How healthy is your open source community?“

To be viable, academic projects using open source software need to ensure that people continue to engage with their project beyond initial funding. Similarly, academic institutions and businesses seeking to adopt open source solutions developed as part of academic projects need to be sure they can do so without exposing themselves to unmanageable risk. By using the Software Sustainability Maturity Model, both businesses and academic users and developers can identify any weak points in their development and governance processes, and address them as appropriate. This session will provide the participants with the skills to assess the non-technical aspects of open source software development.

Having attended this session, you will be able to answer the question: “Can a business collaboration be built around this open source project?” You will understand how to evaluate the health of an open source community and plan for sustainable engagements with companies interested in developing products or services based on it.

I hope you can join us!

Now as I say, the OSS Watch staff are not experts in every software-intensive problem domain, and so we do not gainsay actual experts lightly. Even so, in this case I noted to myself that I might be seeing a certain amount of unsupported prejudice. The problem is that code quality is a notoriously hard property to assess. Even users of the same program can have radically different impressions of its quality, stability and efficacy. One approach to arriving at verifiable metrics of code quality is static program analysis, where software is used to analyse the source code of other software and identify where problems might occur. One company that offers static analysis software and services is Coverity, and over the last five years, partnership with the United States Department of Homeland Security, they have been periodically assessing the quality of selected large open source projects. As might be hoped, the picture has been one of gradually increasing code quality with each survey.

This year for the first time Coverity made a direct comparison of open source and proprietary code quality, and the results were interesting (you may need to register in order to receive the pdf of the report).  In the open source projects they examined (Linux, PHP, and PostgreSQL) rates of software defects were lower than in the corpus of proprietary closed code with which they compared (0.45 vs 0.61 problems per 1,000 lines of code respectively). Of course, we must be cautious about such a circumscribed survey. The three projects they chose are well supported, mature and active. They also, in common with the proprietary comparators, use the Coverity software to identify errors as part of their development processes. Therefore one could conclude – and Coverity seem keen that we do – that the real lesson here is that using their software reduces error rates whatever your licensing or development model. Still, it is useful to have some more evidence in the discussion of open source vs proprietary code quality.

Sky Map is an application for Android mobile devices that was born out of the so-called 20% time that Google grants its engineers for the pursuing of personal projects. Back in 2009 when Sky Map was launched, one of the few hardware advantages that the few Android phone then on the market had over the iPhone was a hardware sensor compass. The ‘wow’ moment of the first public display of Google’s Android hardware (the G1) was a demonstration of how the Streetview service could be used in combination with the device’s compass to display information relevant to the direction you are facing. To build on this brief window of competitive advantage (the iPhone acquired a compass in its next hardware iteration) Google’s Pittsburgh office (then based on the campus at Carnegie Mellon University) developed and released Sky Map. The functionality – showing information about the night sky in the direction you were looking – was useful and educative and spawned tens of imitators over the next few years.

Given that the software no longer promoted a competitive advantage of Android hardware, and that the competition for apps of this kind has been getting tougher and tougher, it’s not entirely surprising that in Larry Page’s seemingly endless round of belt-tightening the project has been let go. Sky Map is returning to its roots on the Carnegie Mellon Campus:

“Today, we are delighted to announce that we are going to share Sky Map in a different way: we are donating Sky Map to the community. We are collaborating with Carnegie Mellon University in an exciting partnership that will see further development of Sky Map as a series of student projects. Sky Map’s development will now be driven by the students, with Google engineers remaining closely involved as advisors. Additionally, we have open-sourced the app so that other astronomy enthusiasts can take the code and augment it as they wish.”

This is an interesting approach. Although it’s not clear yet exactly what kind of student projects will be invited (computer science? astronomy? both? neither?) the idea of taking end-of-life, production code and open sourcing it to facilitate learning and teaching is a model I would like to see more generally adopted, for a few reasons.

Firstly, it is likely to teach open development methodologies to student software authors, something which is still notable by its absence in too many academic primary and secondary software development programmes. Secondly, it provides a compelling means of community engagement for the academic institution, opening a window into their teaching for the outside world and inviting collaboration. Thirdly, it advertises the skills of the students with a directness and accessibility that mere CV distribution cannot really match.

Although I’m not thrilled by Google’s year of the long knives (goodbye Google Sets *sniff*) solutions like the one proposed for Sky Map are genuinely exciting, and I’ll be watching for the resulting academic projects with interest.

So the fact that the top two slots in one of Netcraft’s surveys are now filled by open source web servers is interesting in itself, but there’s something more to this. Unlike Apache HTTP Server which is developed under the supervision of a US not-for-profit foundation, Nginx has recently become a commercial company offering paid support and successfully raising $3m in series A venture capital funding. As well as paid support, Nginx has announced that the intend to implement an Open Core model for their business going forward.

Now the Open Core model is what we used to call ‘proprietary extensions’, meaning that the open source code is supplemented with closed source paid add-ons for those that want them. In a way it is similar to the shareware model that did so much for PC gaming during the 1990s, bringing games like Doom to offices everywhere. One often cited problem with the Open Core model is, however, that users of the open source ‘core’ are at liberty to build competing open source versions of your proprietary extensions. Indeed you can find that ideological opponents of the partial freedom that Open Core embodies may be motivated to compete simply because of that ideological opposition, essentially enforcedly ‘opening’ the parts of the project functionality that you wish to keep closed. The only really effective defence against this risk is to be the best-resourced and most skilled team working on the code, thereby ensuring that your extensions cannot be easily replicated by competitors. So Open Core is an interesting strategy, in that it has drawbacks from both the purely ‘open’ point of view and the more traditional closed source approaches to software exploitation. In the past it has been accused of attempting to benefit from the ‘Halo Effect’ of open source while in fact leveraging closed methodologies for value realisation, but the fact that Nginx has managed to achieve so much in such a short period makes it a technology and a company to watch.

Once the software is booted the user has access to an almost ridiculously long list of tweaks and features, including saving pictures as ‘RAW’ (meaning that the data from the camera’s sensor is saved to the card unaltered, rather than being crushed down into a smaller JPEG file), greater control over exposure times and the ability to construct more complicated ‘bracketing’, meaning that a series of shots can be taken with differing focal lengths or levels of white balance, allowing creation of HDR images and focus-stacked images. Even more geektastic is the ability to script the functionality of the camera using UBASIC or LUA, allowing a user to build functionality like time lapse photography and the taking of pictures only when motion is detected.

One question that remained with me, even as I contemplated spending more unwise pounds, was what Canon’s attitude was to this project. After all, some of the functionality that CHDK contains can be obtained from Canon in its more expensive models. They could close the technical loophole that allows the additional software to be run fairly easily, so one must assume that they do not see the existence of open source expansions of their equipment as a threat to their business model. Might they even see it as a selling point? Certainly it seems that running CHDK is likely to void your warranty, so perhaps the existence of a group of customers who opt out of expensive warranty provision is seen as a bonus.

Discovering this went some way towards alleviating the guilt of my spending. After all, I had got a large amount of functionality at essentially half price. But… if you want to run long scripts then you really need the attachment that lets the camera run off mains power. That’s not such a bargain. I could also probably do with a better tripod… Oh dear…

Rage, the id game which uses version five of the id rendering engine (id tech 5, as it is known) has just been released. This is the point at which the source to the previous engine would usually be released as open source. However in this case there is a problem. Back when id tech 4 was being written for the game Doom 3 over the period 2000-2004, many games developers were looking into what were then cutting edge graphical technologies for inclusion in their games. One such technology was stencil shadowing, which accurately projects shadows from moving objects onto surrounding surfaces based upon the light sources which are illuminating them. This is hard work even for the specialist graphics hardware in PCs and consoles, and so any algorithmic optimisations that are possible are highly valued by the industry. So, various developers hit upon the same optimisation around the year 2000. This optimisation has come to be known as Carmack’s Reverse, even though it was first presented by William Bilodeau and Michael Songy of Creative Labs back in 1998. John Carmack discovered it independently some time later, and was perturbed to discover that Creative had already patented the process.

Faced with a choice between licensing the patent from Creative or making his code sub-optimal, Carmack decided to strike a deal with Creative that allowed him to use the technology at no cost. Perhaps coincidentally, id also agreed to use sound rendering technology by Creative in their game.

So the game was shipped and everyone was happy, until half a decade later when it came time to ship the code as open source. Obviously whatever deal was agreed between Creative and id did not involve making code available that embodied Creative’s patent under an open source licence for the whole world to use. In a tweet on the subject Carmack explained:

Lawyers are still skittish about the patent issue around “Carmack’s reverse”, so I am going to write some new code for the doom3 release.

It will be interesting to see how Carmack replaces the code, but the issue is also of interest because it illustrates the importance of keeping good records of the inbound IP in a software project. id’s lawyers caught what could have been an expensive potential infringement of Creative’s rights when they ‘skittishly’ requested that Carmack rewrite the code.

Adobe’s announcement that it will be dropping Flash Player for mobile devices from its future plans has been widely interpreted as a victory for Apple, and in particular their late Chief Executive Steve Jobs. Perhaps because of his essay Thoughts on Flash, the absence of Flash technology from Apple mobile devices has seemed to be a personal decision of Jobs. In that essay Jobs made a group of points about exactly why he saw Flash as a detrimental technology, certainly for Apple mobile devices, and to some extent for Apple computers in general (“We also know first hand that Flash is the number one reason Macs crash.”) Competing phone and tablet makers pointed to their devices’ ability to run Flash, although not always that well. Apple’s refusal to engage with Flash on mobile led Adobe to declare that Apple mobile devices could not access the ‘full web’, particularly the video content that at that time was most frequently packaged as a Flash object.

In fact, Flash became so synonymous with web video packaging that it is easy to forget that it started life (as FutureSplash Animator back in the dark days of dial-up) as primarily a vector graphics animation package. It provided the possibility of small files containing large images and enhanced interactivity (this was before Javascript was well supported or unified). Gradually Javascript and broadband made these selling points more moot, and Flash then made the leap into bundling video codecs and providing a unified way for browsers to display video. Now, partly as a result of Apple’s stand against it, native video decoding in the browser combined with HTML 5′s <video> tag have once again made Flash less relevant. Now, it could be argued, the chief use of Flash is in rapid prototyping and dissemination of simple web games, many of which go on to spawn native titles on the bigger gaming platforms. Even that function is likely to be somewhat supplanted by HTML 5 apps in the future.

So has Flash as a whole been doomed by Apple’s tactics. It’s worth looking at that Steve Jobs essay again to find out. Among the many legitimate criticisms he levels (instability, insecurity, poor efficiency) Jobs also attacked the fact that Flash provided a path to developing mobile apps (both in the browser and compiled to native code) that was out of the control of the platform owner:

We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.

Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps. And Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.
Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.

In other words: Apple did not want development tools for their mobile devices to exist which were not under their control. Jobs cited this as ‘the most important reason’ that he rejected Adobe’s technology. Yet only months after that essay Apple backtracked on the restriction and permitted Flash tools to compile Adobe Flash Actionscript applications for submission to the App Store. Indeed, if you don’t own a Mac, using Flash to generate iOS apps is one of the very few alternatives available to you. In fact, Flash Builder, the tool which does the actual compiling of Actionscript programs into iOS applications, is really the open source development environment Eclipse distributed with a proprietary Adobe plugin. Potentially the concession won by Adobe could lead to entirely open source tool chains for the development of iOS apps.

So while Jobs’ tauntings over the possibility of a robust and useful Flash Player Mobile (“We have routinely asked Adobe to show us Flash performing well on a mobile device, any mobile device, for a few years now. We have never seen it”) have proved prescient, in fact Adobe won a crucial concession from Apple almost a year ago. That concession widened the potential role of open source tools in developing iOS apps (it’s always been possible for Android). Adobe have also announced that they intend to ‘aggressively contribute’ to HTML5, perhaps indicating that they will be extending their development tools to allow Actionscript programs to be emitted as HTML5 web apps.

What really emerges from the struggles over mobile Flash is a strong sense of the entropy of the mobile device space at the moment. Rhetoric is deployed and attitudes struck, only for the originators to back away in a matter of months. App Store policies change monthly and with them the possibility of using open source code on the devices they serve. Competitive head-butting between closed source behemoths (like Adobe and Apple) can result in the opening up of data standards (as the pressure from iOS users has resulted in more HTML5 compliant video on the web – although let’s not get into the patents around those). For open source authors and proponents, the mobile space remains a changing and challenging environment. What the skirmishes around Flash demonstrate, though, is that the struggle of closed source vendors for competitive advantage can provide opportunities for free and open source code.