Making free code pay
Take two teams of software developers. How can Team A churn out application X in half the time that it takes Team B? Both teams are the same size. Both teams have equally competent coders. And the code produced by Team A is better quality, better documented and more robust than that produced by Team B.
The answer is simple: Team A only had to do 50% of the work of Team B, because it built on work already done, debugged and free to use, from web sites like SourceForge, PlanetSourceCode and Koders. The cake came free; all Team A had to do was ice it. Team B had to make the cake as well. Clearly, a company whose developers are twice as productive is at a huge competitive advantage in the marketplace.
So what’s the catch?
A lot of code is available from reputable internet sources under so-called ‘academic licenses’. These are very liberal open source software licences which allow code to be reused freely (and free of charge), and incorporated into commercially licensed software very simply. The only obligations on the re-user are (generally – and depending on the terms of the licence) to acknowledge the original author somewhere in the software manual and code, and to make sure that certain disclaimers appear in the end user licence for the software. There’s no obligation to release the source code of the software you have created using that code. But some popular code isn’t available under an academic licence: and one of the more pervasive licences is the Free Software Foundation’s Gnu GPL. In brief, if you incorporate GPL code into your own code base, once you distribute your software, the whole of your application has to be licensed to all third parties free of charge, together with the source code.
Imagine if there was some GPL code in Microsoft Excel, you would not only be able to make, use (and sell) as many copies of Microsoft Excel as you wanted without paying a penny to Microsoft, but Microsoft would also have to give you the source code. Deliberately using such code is not necessarily a bad thing for a software house. Companies like RedHat and MySQL do very nicely out of ‘giving away’ their software under the GPL and charging for consultancy, maintenance, development and support. But to adopt the open source business model with your eyes open is one thing. To have it thrust upon you by a wayward programmer is something entirely different.
What does a software company do?
Option one is to ban the use of downloaded code, and to ensure that all code produced in-house is freshly created by your developers. As employees and contractors (with properly drafted copyright assignments, of course) all the code they cut will automatically belong to the company, untainted by any of this open source nonsense, GPL or otherwise. If they need third party libraries, they can buy in commercial ones.
The problems with this approach are:
- You are paying programmers to reinvent an awful lot of wheels – wheels which are available at no cost, right now, to your competitors.
- Your programmers will resent having to do what they regard as boring unnecessary work.
- Even if you ban internet access at work - which will create interesting issues when you try to recruit developers - it’s almost a given that a developer with a particularly thorny problem will take the time at home to search sites such as SourceForge to see how others have cracked that problem. After all, they will get the kudos (and maybe a cash bonus) for tackling the problem quickly. So a ban of this nature is unlikely to be practical.
Option two is to turn a blind eye. Since the code is available on the internet to be freely downloaded, the authors can’t complain if people do download it and use it in their commercial products, can they?
This approach may work until a piece of GPL (or similar) code finds its way into your codebase.
But how will anyone ever find out that GPL code has been used in this way?
Sometimes, a piece of software will appear which mimics the behaviour of a piece of code so closely that the authors of the original GPL code become suspicious. By careful analysis of the suspect code, and some skilful reverse engineering, it is possible to ascertain that the suspect code incorporates GPL code. In practice, however, it is most likely that one of the developers working for the shady company blows the whistle to the Free Software Foundation or GPL-Violations.org, which then takes up the case.
Keeping track
Option three is to allow your programmers access to these sources, on the understanding that the provenance of all code is carefully documented, and that the legal team checks the licences to make sure they are compatible with the business aims of the company and its project. This keeps the programmers happy, maximises productivity and minimises the risk of software violation. What is required is a ‘found source’ policy, guiding the developers in terms of which sources of found source they can use; how its use is to be documented; to whom they should refer any usage or licensing queries; and to whom they should report any violations.
This is exactly the tack taken by messaging solutions supplier Scalix. The company uses and integrates open source components into its products, and also happily opens its own codebase to allow for contributions and enhancements from the broader community. The company reckons its engineers have been around long enough to know that use of this source is subject to differing licence terms, and while it encourages the use of third party sources, it makes sure that this is done on a fully-disclosed, open basis and that any licensing issues are referred to the legal experts before the code makes it into the source tree. If the correct documentation is maintained, both within the source code as comments, and as a separate dossier, then any due diligence issues or licence queries arising out of the code base can be tackled by reference to that documentation.
Due diligence is becoming increasingly necessary for software developers. Looking for capital? Potential funders or acquirers of a company now routinely undertake due diligence on the provenance of a company’s codebase. In addition, potential customers, particularly where they are outsourcing certain services to you, will want to ascertain that code has a legitimate provenance.
These organisations are using increasingly sophisticated tools, such as BlackDuck, which can scan your codebase and cross-reference it to a huge database of source code which BlackDuck has created, quickly revealing whether any of the open source code on the database has appeared in your code. Interestingly, software houses are now starting to use the BlackDuck software internally to scan their own codebase daily, to ensure that during the course of that day no unaccounted for code has crept into their codebase.
This can be a great selling tool: the software houses are essentially demonstrating that they keep their IP house in order, and that they do their own due diligence on software provenance. At least one large Indian outsourced development house uses BlackDuck in this way to assure its customers of the provenance of the code it cuts.
The third way, it seems, gives our Team A all of the advantages of plundering the riches of open source, without finding themselves at the end of an unanticipated lawsuit. Do you have an open source development policy?