4 Tips for Keeping on Top of Project Dependencies

Posted on May 8, 2013 by Scott Wilson

Almost any software project involves working with dependencies – from single-purpose libraries to complete frameworks. When you’re working on a project it’s tempting to bring in libraries, focus on meeting the user need, and figure out the niceties later. However, a little thought early on can go a long way.

This is because every dependency can bring its own licensing obligations that affect how you are able to distribute your own software. In some cases, in order to release the software under a particular license you may end up having to rewrite substantial amounts of software to remove reliance on a library or framework that is distributed under an incompatible license.

So there is a tradeoff between being agile and productive in the short term, against the risk of needing to do a costly refactoring triggered by a compatibility check before – or even worse, after – a release.

For larger projects, and organisations with multiple projects, this starts to stray into the territory of open source policies and compliance processes, but for this post lets just focus on the basics for small projects.

1. Make it routine

A good strategy is to build good dependency management practices into your general software development practices – similar to the concept of building in quality or building in security.

In other words, given that the cost of fixing things later can be significant, it’s worth investing in the practices and tools that can ensure potential issues are spotted and fixed earlier.

At its simplest, this can just mean developing a greater awareness as an individual developer of where your code comes from, knowing that what you reuse can limit your choices for how you license and distribute your own code.

So in practical terms, this means being careful about copying and pasting code from the web, and making sure you know the licenses of any dependencies, preferably before working with them, but certainly before building any reliance on them into your code.

It may also make sense to handle any required attribution notices for inclusion in a NOTICE and README as you go along, rather than just rely on a release audit to always pick them up.

2. Let tools take some of the strain

There are also tools that can help make things easier. For example, if you use Maven for Java projects, there is a License Validator plugin that can help flag up problems as part of your compile and build process.

Alternatively, Ninka is an Open Source tool for scanning files for licenses and copyrights. While it can’t follow import declarations or dynamically linked libraries, it can be useful to periodically check builds. A similar project is Apache RAT (Release Audit Tool) which was originally created for use within the Apache Software Foundation for reviewing releases made in the Apache Incubator.

For larger projects and organisations there are also complete open source policy compliance solutions like Protek from Black Duck, or Discovery from OpenLogic.

It’s also worth pointing out that, while tools can be a part of the solution – and can be invaluable for large projects – ultimately it’s still your responsibility to make sure you meet the obligations of the software you are reusing.

3. Remember to check more than just the licences!

If a dependency has a compatible licence, thats great. But what about if the project that distributes it doesn’t bother checking their own dependencies?

This is where it’s good to have an idea about the governance and processes of projects you depend on.

There aren’t just licensing risks associated with dependencies – if you rely heavily on a library that has only one or two developers then you also run the risk that it may become a “zombie” project with implications for the rest of your code, for example, if security patches are no longer being applied.

Beware of zombie projects!

The commercial tools mentioned above are also typically backed by a knowledge base that can also flag up other issues with dependencies, such as governance or sustainability problems. However, just having a check for the project on Ohloh is often good enough for most smaller projects to check that a library is still “live”.

If you need to know more about the sustainability of a particular project, OSS Watch can carry out an Openness Review to check its viability using a range of factors – get in touch with us if you want to know more.

4. Keep track of past decisions and share knowledge with colleagues

Some organisations make use of component registries to keep track of which components they approve on in their software projects. This can save time spent by developers researching the same libraries, but makes most sense when you have a lot of projects that probably need the same kinds of components, in which case focussing on reusing the same set of libraries makes sense.

Another reason for using a registry is where you need to perform more detailed evaluations, for example for security, and so checking a dependency is more involved than just figuring out which license it uses, and that the project isn’t dead.

Some examples of commercial registries are Sonatype Component Lifecycle Management and Black Duck Code Center. Again, for a smaller project or an organisation with a relatively small set of projects this can be overkill, and just having a shared document somewhere where you can keep note of which libraries you’ve used can be effective.

For example, you could share a spreadsheet with colleagues containing some basic information on each library like what version you’re using, what license it’s under and the date and results of any investigations you’ve done into sustainability, security or risk assessment.

Is it worth it?

Reusing code is good practice and should save you time and expense – so it’s annoying if the administration associated with it starts affecting your productivity.

You can make a judgement call about what level of risk you feel is acceptable; for example, on an internal-only research project the risk of having to undergo a major refactoring should the project be successful may be one worth taking.

However, for a production system, or a component that is itself intended for reuse, you may just have to accept that you have to be a bit more diligent in how you reuse code.

Photo by DieselDemon used under CC-BY-2.0.

Trademarks and FOSS

Posted on May 2, 2013 by Rowan Wilson

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 wikipedia.com 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 modeltrademarkguidelines.org, 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.

Open Source meets Open Standards

Posted on March 21, 2013 by Scott Wilson

OSS Watch Briefing Paper: Open Standards and Open Source

Open source software and open standards are two of the key interventions in technology policy, whether that policy is made by governments, public sector organisations, or companies.

Open standards can ensure interoperability and assist portability, allowing the switching of solutions and avoiding vendor lock-in. Standards can also help to create new markets, and can also encourage innovation within markets by imposing useful constraints.

Open source software offers benefits of greater flexibility and the potential for reduced development costs and better software quality through collaboration and reuse.

Together, open source and open standards provide the basis for solutions that offer interoperability, cost reduction, and flexibility; no wonder they are seen as such a powerful tool for technology policy!

However, whats often less clear is how the two interact in practice. There is, for example, a fairly widely-held view that open source software is somehow inherently more likely to support open standards. However, in practice this is not necessarily the case, and there are a number of barriers that can actually make it less likely for open source projects to implement standards than their closed-source counterparts.

Open source and open standards should complement one another - but can also counteract each others benefits if policies are developed without paying attention to the way they interact

For example, implementation of a standard requires access to documentation; in many cases this involves payment for access, or paid membership of a consortium – something that open source projects may have difficulty with unless a benefactor or sponsor does this on their behalf. Also, if a project wishes to publicly claim that it implements a standard, this may involve a formal conformance process requiring paying fees for testing and accreditation.

So for policy makers and CIOs, the selection of standards, and the standards setting organisations they originate from, can have a significant impact on the availability of open source solutions to meet their requirements.

Mandating standards that involve patent licensing fees, mandatory expensive conformance testing and assurance, and restricted access to documentation will exclude many potential solutions and providers. This will have the impact of increasing costs, and potentially eliminating the benefits of standardisation altogether if organisations have little practical prospect of switching suppliers.

Conversely, if standards are selected that provide a low barrier to entry to open source then this can be good not just for individual solution procurement, but for interoperability as a whole.Unlike closed-source solutions, with open source it is possible to inspect the implementation of standards and to conduct independent interoperability and conformance testing rather than rely principally on vendor claims. The presence of open source implementations can also influence uptake of a standard; either by making open source libraries available for use within other products, or by providing a good target for interoperability testing for other entrants.

Open source and open standards are key components in technology policy; but its important to know how they can work together – and potentially work against each other.

A new OSS Watch briefing paper provides an overview of the main issues facing implementation of standards for open source projects and developers; for more information see Open Standards and Open Source.

How Can Services Be Open Source?

Posted on November 6, 2012 by Scott Wilson

For many organisations, the key dilemma they face in procurement is not between closed source vs closed source software, but between deploying software and using online services – whether its infrastructure, platform, or shared services. However, open source plays a part in all these kinds services, but it can do so in two distinctly different ways, which carry different advantages and risks for providers and customers.

Cloud Quine

A fun diversion for computer scientists is something called a [quine]; a quine is a program that can print its own source code, including the code used to print the source code! However, there was something about this concept that attracted activists such as Bradley Kuhn, particularly as software was more often deployed as web services rather than distributed and run directly on users machines, and this wasn’t covered by existing licensing (the “ASP loophole”).

What if you could license software used to run a service, so that users could always download it, including any modifications the service provider had implemented?

This is the idea behind the Affero GPL (AGPL) license. If a piece of software uses the AGPL, when its deployed to run as a service – whether its to provide infrastructure-as-a-service or an application as a shared service – users can download the complete source code including all modifications used by the service provider.

So, for example, if you take an AGPL-licensed program such as StatusNet, a Twitter-likestatus-sharing system, and you deploy it and make some tweaks to the user interface and add a few features, anyone can download your modified version and run their own instance of it. Another example is ownCloud, which is offered as either AGPL or under a commercial license.

For customers this does offer some interesting risk mitigation; if for whatever reason you no longer which to use your existing service provider, you have the capability to switch to an identical service run either in-house or by another provider, as the complete source code for running the service is available. However, for a service provider it may be less attractive, as you have limited ability to differentiate your offering in the service itself – though you can still excel at customer service, reliability, pricing and other non-software services.

Secret Sourcery

However, while Kuhn, Moglen and others were developing the AGPL, an alternative model for open source was emerging, based on using liberal licenses such as MIT, BSD and ASL.

In this model, while the core software used for offering the service is open source, some of the “glue” code that binds it together, and typically the user experience offered for the service, is closed source.

For example, while most of the software used to run Github is open source, GitHub itself cannot be downloaded and run elsewhere as some of its code is closed source; a strategy that Tom Preston-Warner outlines in his post “Open Source (Almost) Everything“.

For service providers it does offer the capability to provide greater differentiation of their offering – whether its a better user experience, or extra features.

For customers, however, it does create more of a problem, as its less obvious how you might be able to migrate to another provider as, unlike in the AGPL world, you don’t have access to the complete platform. Its also possible for a service provider to fold without the services it ran being able to be recreated. This is a business risk; and is one reason why open standards for cloud services are such a critical (and highly contested) area.

However its also a question of degree – for some services there is very little provided above and beyond an open source software stack and the value added is in areas such as pricing, reliability and customer service. For example, a provider may offer CloudStack or OpenStack largely as-is, or provide hosting of largely unmodified open source applications such as Moodle.

For others, the service is largely proprietary with a few bits of open source software at a fairly low level, representing a more serious level of potential lock-in depending on how well the service supports open standards.

Each service provider can therefore present quite a complex picture in terms of risk mitigation.

Making a choice

Today, the “secret source” approach is by far the most common model for services – whether its infrastructure as a service or shared application services, and is also likely to be the model used by most of the shared service providers currently used by universities and colleges.

But are they aware of the pros and cons of this model? Or even that there might even be a choice of model? Would they have a preference of one model over the other for services offered by sector organisations such as JISC?

I think these are questions worth asking for the education sector. For the wider world, “secret source” is clearly dominant, but if we want to go down that route too, it would be better to do it through choice rather than ignorance.

Format? Y/N

Posted on October 24, 2012 by Rowan Wilson

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.

Twin Peaks Mysteries

Posted on October 19, 2012 by Rowan Wilson

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.

So if Red Hat’s accusations are justified, then Twin Peaks have been infringing Red Hat’s (and probably others’) copyright by refusing to abide by the terms of the GPL v2. The traditional FOSS community response to GPL violation is to insist that the violators either comes into compliance or stops distributing their infringing software. However this case is a little different. Here are the relevant parts of Red Hat’s counterclaim, taken from the ‘Prayer for Relief’ section (where they say what they want to happen):

…

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.

Open Source and the Windows Store

Posted on October 5, 2012 by Rowan Wilson

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.

Governance of your open source project matters

Posted on August 31, 2012 by Sander van der Waal

When you are making your software open source, there comes a point when you have to think about how to respond to anybody that wants to engage with you or your team. As we have said on this blog before, a governance model is crucial in order to manage expectations and make sure you retain control where you need to, while sharing responsibility where you can.

We have published a set of documents about open source project governance models back in 2010, and have made sure they are kept up-to-date since. We also provide templates for a model with a Benevolent Dictator and one for meritocratic projects. All of our documents are released under a Creative Commons licence, which makes it easier to take our template and apply it to your own project.

If you set up a governance model for your project, people who have in interest in your project can easily see how your project is structured. It will help them understand how they can engage with the project, how decisions are made within the project, and how they may have an influence in the project’s strategic direction. If you are reluctant to give up influence in your project, you can design a model that will allow you to more tightly remain in control. When community development goals are more important, and you are looking to expand your community with others that may help guide the project in the right direction, the design of your governance model can reflect that. Whatever your approach, by making sure it is written down and the processes are thought through, you manage expectations of newcomers and prove to be a reliable partner for parties interested in investing in the project.

If you would like to see some real-world examples of governance models, I’m pleased to be able to say that there are a few respectable projects that have taken up our resources as an inspiration for their own governance model. The Qt project, for example, is governed by a meritocratic model that is based on our briefing note. Similarly, Yahoo!’s Mojito project uses a model that’s based on our meritocratic governance model.

While it may take some time to think through how you want to set up governance in your project, it is time well-spent. If you need any help with this, feel free to contact OSS Watch any time.

Community and commentary

Posted on August 21, 2012 by Rowan Wilson

One interesting sidenote to the recent litigation between Oracle and Google has been the order by presiding judge William Alsup that both sides disclose whether they paid anyone who wrote publicly about the case. The deadline for this disclosure was last Friday, but as with most things legal, the issue is still dragging on.

Before going into the detail of why that is, however, it is worth examining how public commentary shapes the important issues around technology these days. Few people would represent print journalism as the most ethically directed profession out there, but there at least public guidelines and accepted professional standards do exist. Naturally the lines blur a little. Journalists want early access to new technology and it is an open secret that publicists at software and hardware companies will use this fact to apply pressure for positive commentary. All in all though traditional journalism is constrained from out-and-out paid partisanship by national laws and professional standards bodies.

Unfortunately, though, traditional journalism is also constrained from digging too deeply into the details of complex technical or legal issues. It must appeal to a broad readership in order to pay for itself and so will tend to focus on digesting the complexity into generalist and sometimes misleading headlines. This was particularly apparent in the Oracle v Google case itself, where every story in the later stages was inaccurately reported in the more mainstream tech press as ‘the end’.

For those who want more detail, there exist the specialist blogs. Unconstrained by word count limits or the need to provide general interest, blogs like Groklaw and FOSSPatents provide endless analysis to the sleepless obsessives. One might think that this would lead to their being largely irrelevant to the mainstream, but this does not seem to be the case. For example during the SCO v IBM case over copyright infringement in Linux, Groklaw became so influential that SCO asked the court to order IBM to disclose if it was bankrolling the site. IBM denied that it did (pdf link):

…IBM states that it does not finance, fund, sponsor or promote Groklaw; IBM does not have any agreements or arrangements with Groklaw or with Pamela Jones [Groklaw's primary author], and IBM does not necessarily agree or disagree with the content of any of the material published on Groklaw.

SCO’s problem was that no mainstream tech journalists had the time or inclination to plough through all the court filings, and so Groklaw became effectively a primary source. Unfortunately for SCO, Groklaw was severely opposed to them, and tended to engage in exasperated invective as a garnish to the reporting of proceedings. While few people were actually reading every post, that flavour of opposition to SCO seemed to be finding its way into much mainstream coverage, and – SCO argued – negatively affecting its ability to argue its case in court. Now whether one feels that SCO had a point or not here will depend on how one views the job that Groklaw did and does. One person’s impartial news source is another’s censoring shill.

Another specialist blog is written by Florian Mueller, intellectual property consultant and former campaigner against software patents. His FOSSPatents blog is updated frequently with detailed accounts from the front-lines of the smartphone wars, where Apple, Google (sometimes via their new acquisition Motorola Mobility), Samsung, HTC, Microsoft, Nokia and Oracle are all pursuing aggressive intellectual property litigation strategies to supplement their primary businesses of actually making and selling things. Mueller has become something of a primary source on these horribly complex litigations, and august news sources like the BBC quote his opinions on them. During the Oracle v Google litigation, Mueller routinely attacked Google and predicted that Oracle’s arguments would triumph. In the event, Oracle was finally forced to settle for no damages whatsoever. Mueller had already announced, before Alsup’s order, that his day-job as a consultant had resulted in his being paid by Oracle in the recent past. However Mueller argued that he had never received direction from Oracle on what to write about or write, and that his blog represented his honest, unpurchased opinions.

When Oracle and Google responded to the order last Friday, Mueller’s name was again disclosed by Oracle as a commentator whom they had paid. Google on the other hand stated that they had paid no-one to write about the case directly, but had paid almost everyone on the web in one way or another at one time or another. This latter response does not satisfy the judge, however:

The August 7 order was not limited to authors “paid . . . to report or comment” or to “quid pro quo” situations. Rather, the order was designed to bring to light authors whose statements about the issues in the case might have been influenced by the receipt of money from Google or Oracle. For example, Oracle has disclosed that it retained a blogger [Mueller] as a consultant. Even though the payment was for consulting work, the payment might have influenced the blogger’s reports on issues in the civil action. Just as a treatise on the law may influence the courts, public commentary that purports to be independent may have an influence on the courts and/or their staff if only in subtle ways. If a treatise author or blogger is paid by a litigant, should not that relationship be known?

It is easy to understand the judge’s concern here; independence from influence is an important aim for journalism, particularly where it has the power that specialist blogs have acquired in recent years. There is an issue, however, beyond the adminstrative difficulties Google will have complying with the new order (by this Friday). The thing that makes specialist blogs so valuable is ironically also the thing that makes them hard to fund. They have a wealth of detail but relatively few readers. So it is hard to fault Florian Mueller for accepting consultancy work to support himself, even though by doing so he has damaged the public’s view of his impartiality. Even where there is no disclosed or undisclosed corporate sponsor, the kind of obsessive commitment required to create such detailed analysis does not tend to come with a detached, even-handed view of the material; and if a specialist blog has a point to prove, who has the time or resources to expose its tendentiousness?

Alsup’s order has brought to light a long-standing issue with tech-related citizen journalism and its increasing power to affect multi-billion dollar ventures and litigation. No-one expects political blogs to be impartial because politics is something like a war; you pick a side and attack. Increasingly however, with intellectual property litigation increasing every year, technology is also war, and we may need to adjust our expectations of bloggers in the sphere as a result. Alsup’s order presumes that the public expects independence in its tech journalism, and it may be that – as with politics – the financial stakes are now simply too high for that to be a reasonable expectation.

Some questions about the Defensive Patent License

Posted on June 22, 2012 by Rowan Wilson

Jason Schultz and Jennifer Urban of UC Berkeley School of Law have distributed a paper which provides an interesting analysis of the state of the patent system and its relationship to open development. In essence, they suggest that rather than avoiding the patent system, open development communities should instead engage with it, seeking to patent and benefit from inventions they create. The authors identify the barriers to this that they see operating now and propose a new cross-licensing agreement process which might breach some of these barriers. At the heart of the scheme is a new licence, the Defensive Patent License or DPL. While I would recommend reading the licence (it’s not l0ng) it’s fair to say that it broadly seeks to embody the following principles (from the paper):

1) Every DPL user (i.e. licensor or licensee) will forgo any offensive patent infringement actions against any other DPL user;

2) Subject to Condition 4, every DPL user will offer her entire current and future patent portfolio under the DPL;

3) Every DPL user will bind any successor-in-interest to any part of her patent portfolio to her obligations under the DPL; and

4) If a DPL user wishes to stop offering her patents under the DPL, she may do so but only with six months’ notice to existing DPL users and future parties. She must continue to grant, and may not revoke, any licenses that are in place before the end of the notice period. Once she stops offering the DPL, other DPL users are free to revoke their licenses to her at will.

So the deal here is that, if you opt into the scheme with all your patents (and you cannot opt in with any fewer) then you will enjoy a licence to utilise all the patents of all other members. In exchange you grant them licences to all your patents, and agree to make sure that even if you sell a patent on, you will try to make sure that it remains covered by the scheme. You can opt out of the scheme again provided you give everyone six months notice. On the face of it it seems like a good idea; as members join the benefits of membership increase exponentially, and a larger and larger island of technology becomes a venue for free competition on implementation within the group. Members remain free to litigate offensively against those outside the group, and consequently retain a market for separate paid licences. How this model addresses what the authors perceive as barriers within the community is too large a subject for summarisation here, but I would recommend reading the paper to anyone interested in the academic study of open communities and their motivations.

Given this model, I find myself with many questions in mind. Some of them are probably the result of my own misunderstanding, but I’d thought I’d note them down anyway.

What is an ‘offensive patent infringement action’?

The authors define it this way: “Offensive patent infringement actions are defined as actions that are not filed in direct response to a previously filed patent infringement suit involving the same parties.” This definition is important because it pins down a circumstance in which a scheme member might have their licence revoked – and licence revocation could get very ugly and expensive for an active tech company or project. So I would be keen to see what is and is not a ‘direct response’ more rigidly defined. For example, if a party is subject to informal threats related to patent infringement from another member of the scheme, are they prevented from seeking a declaratory judgement that they are not infringing? Construably this could be the ‘first link’ in a chain of actions and could therefore be classed as offensive under that definition. I would also like to know whether ‘involving the same parties’ means involving only those parties, or at least those parties. In the latter case a ‘defensive’ action could be used to attack other scheme members once an initial offensive action had been taken.

What about the transmission of obligations?

Point (3) seeks to fix the potential problem that patents might be lost to the scheme by changing hands. In the paper itself the authors respond to one putative criticism of this mechanism – that bankruptcy of a patent holding entity might result in a patent being used outside the terms of the scheme – by pointing out that the US bankruptcy code places a responsibility on recipients of patents to honour pre-existent licences. While I imagine this is true, it does bring up an issue: the ‘orphan’ patents that are licensed in this way going to be available to members who join after the transfer due to bankruptcy? Taking the licence at face value I would assume so, but some aspects of the description of the operation of the scheme in the paper give me pause. The authors describe a situation in which a new member is invited to indicate acceptance of the licence offers of pre-existent patents in the scheme by clicking a button:

She then receives access to the pages for every other DPL user with an option to accept any or all of their DPLs for their portfolios. One can also imagine an option to accept all known DPLs in a single click. The website then distributes an acknowledgment of all license offers and acceptances to the participating parties and records them in its internal database. The licenses take effect immediately.

This seems to be attempting to embody some degree of contractual communication of acceptance, something that free and open source licensing has traditionally been believed to not require to have effect. In the case of the scheme, it’s easy to see why this is beneficial; it gives greater formality to the legal relationships while alerting licensees to the patents available to them. However I wonder if a recipient of a patent from a bankruptcy would feel the need to honour any subsequent licences accepted in this way. I could see an argument that maintained that while pre-existent, accepted licences needed to persist, they had no responsibility to grant new ones in the way that the original bankrupt member had agreed. Either way, the simple model of ‘willing licensor+their portfolio’ will necessarily become fragmented in time through processes like bankruptcy, and the scheme will need robust methods for dealing with reluctant successor patent holders.

Isn’t six months a bit scary?

This is a simple one. Six months is a scarily short lead-time to engineer around an embodied patent in the case of its licence’s revocation. If I have a physical product in the marketplace in which I have embodied a DPL’s patent, how realistic is it to expect me to either withdraw it or negotiate a new, economically viable licence in that six months – particularly when the licensor knows how desperately I need it? How widely used would free and open source software be if the licences were not effectively perpetual and could be rolled up and taken away in six months?

What about Trolls?

The scheme seeks to foster patent peace between technology practitioners, and if widely joined it could perhaps do that. Unfortunately it does nothing to restrain non-practitioner patent holders – the so-called trolls. Trolls do not need defensive portfolios as they do nothing that might infringe anyone’s patent, and their business model makes restraining their offensive use of patents suicidal. So even if the scheme succeeds famously in attracting practitioner patent holders, it will leave a large area of risk untouched. Indeed it could be argued that by encouraging the shared use of patents within the scheme and their associated technologies, it communicates risk of infringement of a troll’s patents between members. If one of the scheme’s well-utilised patents was found to be invalid by reason of prior art in a troll’s patent, the troll would have a neat scheme-created list of potential targets for litigation.

While I do have questions, I think that the aims of the scheme are laudable and I do hope that it finds a means of continuation and growth. The web site associated with the licence and paper provides many ways to feed back and shape the initiative, and I’d recommend registering your views.

OSS Watch team blog

open source software advisory service

Category Archives: Legal