As I wrote previously concerning indemnity, I constantly encounter both governments and companies claiming they have policies permitting or even favouring open source software. Yet there's still a huge amount of proprietary software being procured by them.
A policy alone is not enough. To implement it, legacy procurement rules have to be changed, especially in government. While these rules may provide both protection and value for procurement of products and services the enterprise has seen before, they typically discriminate against new approaches. Legacy procurement rules stifle innovation.
A common problem encountered during the procurement process is when the procurement department attempts to use legacy outlooks on copyrights. This can come in two flavours:
- Negotiating the license terms for the software
- Demanding assignment of rights for additions
Let's look at both of these in more detail.
Open source licenses are not negotiable
Corporate legal advisers are used to conducting negotiations with others. These negotiations are by their very nature between their employer and another entity--bilateral negotiations, where the outcome is usefully understood as a truce between the two parties. So it's natural that when they encounter open source software as part of a procurement, they will attempt to use the normal approach; propose their standard terms for the software copyright license and then negotiate towards middle ground acceptable to both parties.
But this doesn't work when open source software is involved. The copyrights will typically belong to a diverse set of developers, and the open source license used to make those copyrights available to the community is non-negotiable for two reasons.
- First, because the entity from whom the procurement is sought will rarely own sufficient of the copyright to be entitled to vary the license.
- Second, because open source licenses gain that name by a rigorous process of scrutiny at the Open Source Initiative (OSI) followed by approval by the OSI Board, so changes for a single context will not be acceptable.
While the copyright licenses that a procurement department typically negotiates are bilateral, open source licenses are multilateral. They are best regarded not as a truce but as a "constitution for the community", encapsulating the way it views the governance of the source code commons at its heart. If you find open source licenses involved in procurement negotiation activities, there is almost certainly something wrong.
It could be that the supplier is erroneously referring to the software as a deliverable of the contract, in which case it should be removed. It could be that the procurement department has too broad a scope for its rules and has not understood that open source procurement involves the purchase of a subscription to support, development and advice services rather than of a software license. If this is the case, the procurement rules need changing to recognise the new case that open source procurement presents.
Open source is not work for hire
When a company buys contract services, it's not unreasonable to expect any copyright arising from the work to be the sole property of the company. As a consequence, standard contract terms usually include language that transfers ownership to the company. In many cases a transfer is not possible, so it's also common to see that language backed up by the grant of an exclusive, world-wide, perpetual license to the copyright.
But when purchasing a subscription for open source, it's a whole lot less reasonable. An open source subscription does involve delivery of a service level agreement, with assumptions of timely application of skills. But when those skills are applied to fix problems, the resulting code needs to be contributed to the free software commons that's at the heart of the open source community involved. If it's not, it won't be maintained and the fix will only be temporary.
It is in no-one's interest for new code that's written as part of a subscription to be assigned exclusively to one party. Demanding copyright assignment is not appropriate; instead, the procurement agreement should require that an open source license (that's one approved by OSI) is applied to all new code and that community rules are followed.
Legacy procurement rules that try to demand custom copyright licenses and the assignment of new copyright to your company could be costing you dearly. They could be preventing you getting the freedoms open source brings, and along with them the flexibility and control that will make you competitive. It's worth fixing the rules and gaining the freedoms.
This article first published at ComputerWorld UK. Follow Simon as @webmink on Twitter and Identi.Ca
Comments are closed.