Koha trademark case settled

Earlier in the year, I wrote a case study on Koha, the open source library management system released under the GPL, detailing the history of the project and how the sale of assets had created confusion and disagreements between the Horowhenua Library Trust (HLT) who originally commissioned the system, and PTFS who now holds the copyright for most of the project’s original assets, publishing their own fork under the name LibLime Koha.

At the time of writing, the major issue at hand was PTFS’s trademark application for the mark KOHA in New Zealand, which HLT and Catalyst IT who provide commercial support for Koha were opposing.  This month, the case was settled, with the commissioner ruling against PTFS and rejecting the application.

HLT and Catalyst opposed the application on 6 grounds:

  1. The mark was likely to deceive or cause confusion.
  2. The application for the mark was contrary to New Zealand law (specifically, The Fair Trading Act 1986), on the basis of ground 1.
  3. Use of the mark would amount to passing off, also in breach of New Zealand law.
  4. The mark was identical to an existing trade mark in use in New Zealand.
  5. PTFS wasn’t the rightful owner of the mark, HLT was.
  6. The application was made in bad faith, on the basis that HLT owns the mark.

Interestingly, grounds 3, 4, and 5 were rejected by the commissioner, largely on the grounds that HLT’s use of the name Koha didn’t constitute a trade mark.  When HLT originally open sourced Koha, the evidence presented showed that it intended Koha to be given away for free so other libraries could benefit from it.  The commissioner didn’t consider this to constitute trading, and therefore Koha, while identical to the mark being registered, didn’t constitute a trade mark.

As ground 5 didn’t show HLT to be the rightful owner, ground 6 was also rejected as PTFS weren’t seen to be acting in bad faith by trying to register a mark which clearly belonged to someone else.

However, HLT and Catalyst’s success in this case hinges on the fact that when the trademark application was made in 2010, HLT’s Koha software had existed for 10 years and was well known in New Zealand’s library sector.  Since the commissioner considered the mark being registered to be identical to the name Koha, and HLT’s software to be the same class of product as PTFS’s, it was found that the two could be confused by a substantial number of people, allowing ground 1 to succeed.

Furthermore, the cited sections of the Fair Trading Act had a similar but stricter requirement that there not be a real risk that such a confusion or deception might happen.  The commissioner believed that due to Koha’s prominence in the industry there was a real risk in this case, allowing ground 2 to succeed.

The application for the trade mark has now been defeated, with HLT and Catalyst being awarded nearly 7,500 NZD in legal costs between them.  What affect this will have on the use of the Koha name in New Zealand isn’t clear – since HLT have been shown not to own the mark themselves, they are unlikely to be able to stop PTFS from using the name in New Zealand should they choose to.  However the Koha community in New Zealand can now rest easy knowing that they won’t be stopped from continuing to use the name as they always have.

I hope that other open source software projects use the case of Koha as a lesson to ensure that your branding and IP is well-managed, so that cases like this can be avoided.

You can read the Commissioner’s full ruling here.

CIO.com – How to Choose the Best License for Your Open Source Software Project

You need sound coding skills to create good software, but the success of an open source project can also depend on something much less glamorous: your choice of software license.

Last week I spoke to Paul Rubens of CIO.com about the issues that need to be considered when deciding which licence to use when releasing your code, including why a licence is necessary, the varieties of Free and Open Source Software licences, and how you provide licenses for the non-software parts of your project.

You can read the full article at CIO.com.

Open Hardware at CERN

Last week I took the opportunity to visit Oxford’s Hackspace and see a talk by Javier Serrano of CERN.  Serrano has been working together with Moorcrofts, an Oxford-based legal firm, on the latest version of CERN’s Open Hardware Licence (OHL).

CERN’s systems have unique requirements in terms of scale, synchronisation and geographic distribution.  As a result, a lot of their hardware is produced to bespoke specifications.

4251257693_14fca303ba

Serrano spoke about the models available when considering closed/open and commercial/non-commercial licensing.  Due to the long lifespan and iterative nature of CERN’s systems, a commercial proprietary solution would create vendor lock-in which isn’t acceptable for their requirements.  An open solution without commercialisation wouldn’t be sustainable.  He concluded that an open, commercialised solution provides “the best of both worlds” in terms of sustainable support and sharing of knowledge, which is one of CERN’s core goals.

The licence itself takes inspiration from the GNU GPL for software, with modifications to make it more applicable to hardware.  The licence is designed to cover the documentation for the hardware (such as CAD files and bills of materials), allowing the documents to be distributed, modified, and used to manufacture products given that the documentation is made accessible to those receiving the products.

Serrano described the licence as “weak-copyleft”.  It is designed to ensure that modifications to the design, used complete or in part, are shared back to the community.  However, it does not attempt to stipulate that the designs of other products that are integrated or linked with the OHL products also have their designs shared.

Similarly, the licence contains a patent grant to any patents owned by the designer, but it doesn’t attempt to make this reciprocal – the licensee isn’t required to license their own patents back to the licensor.

A final notable feature of the licence is the stipulation that alongside any trademarks and copyright notices, any references to the location of the documentation must not be removed from the designs.  This means, for example, that a URL to access the documentation could be included in the top copper layer of a PCB – this would ensure than anyone receiving the board would have access to the designs.

Serrano finished by introducing White Rabbit – a network time protocol which improves on the Precise Time Protocol standard to synchronise networked nodes with tolerance of under a nanosecond. The documentation for the hardware implementing White Rabbit is released under the CERN OHL.

A big thanks to Oxhack for hosting the event, and Moorcrofts for sponsoring it.

Image Credit: Large Hadron Detail (Fred Benson) by Michael Maniberg

Should you use Creative Commons licenses for software?

Creative commons logos, ending in a question mark

tl;dr: no.

Creative Commons is a great way to license documentation, websites, articles, artwork, and other media assets associated with a software projects, but source code has some special characteristics that are better suited to using licenses recommended by the Open Source Initiative and the Free Software Foundation.

To find out why, take a look at our recently updated briefing note on Creative Commons licensing and Open Content, where we’ve added a section on this question.

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.

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.

Unlicensed code: is it ever OK?

Car With No License Plate

In an earlier post Mark Johnson responded to recent commentary about unlicensed code on Github. Mark criticised the idea put forward by some pundits that developers not licensing their software project was some kind of movement. Instead Mark sees it as emerging from a lack of education (or, quite possibly, sheer laziness). He also reiterated the point that a lack of licensing clarity discourages community and harms reuse and sustainability of software. Experienced developers won’t touch unlicensed code because they have no legal right to use it.

However, I decided to follow up by seeing if I could start from the other end of the argument and identify some good – or at least acceptable – cases for where you might legitimately make your source code available intentionally without applying a license.

Here’s what I’ve come up with.

Deferring the licensing decision

Licenses interact with your choice of business model. For example, some licenses are more useful than others when pursuing a dual-licensing strategy; some make more sense for software that provides online services; and each license provides some degree of advantage over others for particular cases (if there wasn’t, there wouldn’t be so many of them!)

However, for some projects its hard to identify early on what the business case is going to be, or even if there is likely to be any point developing one.

Your software experiment may turn into a liberally-licensed library, a copyleft and commercial dual-licensed application, or a service offered under something like the CPAL or AGPL, but maybe its too early to tell. Should you keep it under wraps while you work out where its going, or share it now and risk selecting the wrong license?

Releasing your code with no license while you are still deciding on an appropriate model is one possible option. The downside of this is that no-one will really be able to reuse your code until you do apply a license, and it is also likely to deter potential collaborators.

So even here I’d still recommend choosing a license and revisiting the choice later as the project matures: as the owner of the intellectual property for your software you always have the option of changing your mind, and your license, later on.

Changing licenses for software can be controversial and difficult, but at least you have more chance of developing a user community and partner network to have this argument with by making the initial code available under a recognised license.

Note that its also much easier to change from a more restrictive license to a more permissive one than the other way around.

Software as evidence

There is a type of project where releasing code but not licensing it (effectively sharing code with all rights reserved) may make sense. This is where you have no interest in anyone else actually reusing your code, or building on it, or contributing to it!

Why on earth would you want to do that? Well, when the purpose of releasing the code is not to create viable software, but instead to provide transparency and reproducibility.

For example, if you have written software as part of an experiment, and you need reviewers to be able to replicate or inspect your work. In this case, there is no real expectation that anyone will take your code and reuse it for something else, or integrate it into any kind of distribution.

So maybe then you can just distribute the code, but not as open source or free software?

One reason why that may not be a great idea is that no-one else being able to make use of the code is just your perspective; from another perspective, maybe your code has a value you don’t realise? As Scott Hanselman points out, you can think of this kind of these projects as a “Garage Sale” where one developer’s junk is another’s treasure.

You may also be concerned that, by distributing your code under an open source license you may be raising expectations of what the code is for, or inviting a critique of your software development skills; this is a theme that Neil Chue Hong picks up on in a post over on the SSI blog. (Neil even points to a special license, the CRAPL, aimed at this sort of case.)

Even for very specialised academic code aimed at a single objective for a single paper in a specialist journal, the case can be made for releasing the code as Free or Open Source software.

(For another good discussion of this topic, see Randall LeVeque’s post Top ten reasons to not share your code (and why you should anyway)

The Contractual Obligation Software Project

Sometimes you get to work on a project as part of some sort of funded initiative, which, while not stipulating sharing your code as open source, does expect you to at least make the code “available” in some fashion.

So, like an artist locked into a record contract, when the funding runs out you may be tempted to just make a code dump somewhere in order to meet your obligations, and in a fit of spite not even bother put a license on it either.

However, the “garage sale” metaphor works well here, too. Maybe the project or initiative didn’t exactly set the world on fire, but maybe some of the code written in the process could still be salvaged for something.

Gists and examples

You often find code snippets in blog posts or as solutions to questions on StackOverflow. This is very rarely explicitly licensed, but the assumption is that its usually OK to copy and paste without worrying too much about licensing. If you’re conscientious, you can always pop in a comment with a link to where you found it.

However, there are also grey areas, such as Gists, which are a bit more than a few lines of code, but not quite project in their own right.

Even with a small snippet of code, its not always clear whether or not copyright protection applies. For example, a lengthy example of how a standard Java library should be used would probably not be protected as it doesn’t involve much creativity. However, a two-line program that offers a novel solution to a problem could well be considered protected under copyright.

So, in some cases you may be justified in not bothering with a license for a snippet or Gist, but to avoid all uncertainty its still better to put in a license header, or at least make it clear you’re willing to license the code for anyone who wants it that thinks its necessary.

Creating Fear, Uncertainty and Doubt

OK, I wouldn’t say this is a great reason, but it could be a reason.

Maybe you really do want to make people uncertain about whether they can use your code because … well, because thats the way you roll.

Maybe you’re happy to license your code, but only with people who ask you nicely first, and you don’t want them to be able to distribute their code as free or open source software for some reason.

Or maybe you are looking to bait the uncautious into copying your software so you can threaten them with lawyers and shake them down for money, because you are actually a Copyright Troll.

A copyright troll

Not necessarily wise, but not necessarily evil either

From this brief excursion I would conclude that distributing unlicensed code is never a great idea, and rarely even a good one, but I can see there are circumstances where you might consider doing it. In each case, though, there is usually a better option worth taking.

Car image by Su-May . Copyright Troll Image by redtimmy

Unlicensed code: Movement or Madness?

One of the hot topics of commentary on open source development at the moment is the licensing situation on GitHub.  When code is committed to GitHub, the copyright owner (usually the author or their employer) retains all rights to the code, and anyone wishing to re-use the code (by downloading it, or by “forking” and modifying it) is bound by the terms of the license the code is published under.  The point of discussion in this case, is that many (indeed, the majority) of repositories on GitHub contain no license file at all.

There are two troubling points to the commentary on this phenomenon.  The first is that some discussions suggest that publishing with no license is “highly permissive”, implicitly allowing anyone to take the code and do with it as they wish.

In fact, it’s usually the case that having no license on your code is equivalent to having an “All Rights Reserved” notice, preventing any re-use of your code at all.  Whether it’s the copyright holder’s intention to enforce these rights isn’t being made clear, but it’ll be enough to put off any company who might want to engage with such a project under an open development model.

The second troubling point is that commentators are time and again dressing this up as a wilful movement.  James Governor coined the term “Post Open Source Software“, while Matt Asay claims “Open Source Is Old School, Says The GitHub Generation“.  These commentaries seem to imply that there’s some sort of “No License Manifesto” being championed (in a similar fashion to the Agile Manifesto, perhaps).

The only movement I’ve seen which would be akin to this is the Unlicense, which encourages authors to wilfully lay aside any claims to their rights, effectively a Public Domain dedication which Glyn Moody has suggested is the way forward for open source.

However, what we’ve seen on GitHub shows no such conscious setting aside of rights, it shows a lack of education.  Publishing articles touting release without a license as how all the cool new kids are working encourages behaviour which could prove damaging to the development of a project’s community, and the wider community in turn.

Fortunately there are voices of reason in these discussions.  Stephen Walli of the Outercurve Foundation points out that governance == community.  If a project seeks to “fuck the license and governance” as James Governor suggests, then they risk doing the same to their community by alienating contributors (particularly those that are part of a larger organisation, rather than individual developers), as these contributors have no predictable structure to work within.

If the project lead might turn around and say “I dont feel like accepting your contributions, and by the way, if you keep using my code I’ll sue you”, you’ve got very little incentive to work with them.

By neglecting your community in this way, you project is at risk of being limited to a few individual contributors who know and trust one another implicitly.  I can’t believe that developers seeking to allow permissive use of their code would be happy with this as an outcome.

GitHub haven’t yet made any suggestion that they feel this is a problem they should work to solve.  It’s our responsibility as a community to ensure that we educate newcomers to become responsible open source citizens, rather than encouraging them to follow established bad practices.

Licensing and governance analysis form 2 cornerstones of OSS Watch’s openness rating.  If you’d like advice on how to improve your projects management of these areas, please get in touch.

4 Tips for Keeping on Top of Project Dependencies

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.

Photo of a stack of cards

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.

A zombie

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

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.