ReadWriteWeb: The Changing Face of Software Development
With modular, component-based software development (in which software is part-assembled from pre-exsisting components and part written) supplanting the older paradigm of writing code from the ground up, new risks get introduced, each of which, in turn, requires the implementation of new approaches to risk management and mitigation.
The first thing that strikes me about this shift is that it, intriguingly, parallels one we likely have seen in manufacturing over the course of industrialization. From single craftsmen or shops creating in-house pieces of integrated workmanship, we moved to optimization models that were about specialized expertise (someone making one part as efficiently as possible, and product manufacturers sourcing those parts for assembly as part of their larger designs). There might even be scope for an analogy with agricultural products and monocultures–single crops sourced from different regions and assembled by supermarkets.One legal risk with this outsourcing process ties into first year torts and the so-called neighborhood principle of Donoghue v. Stevenson (that case stood for the proposition that in cases where there is a chain of manufacturing and selling, there doesn’t have to be a direct contractual relationship between the damaged party and the wrongdoer in order to be able to make a claim in tort for personal injury or damage): what risk does the manufacturer carry, in sourcing substandard parts, and what risk belongs to the original maker of the part?
But the analogy has its limits as well. While tangible products are generally fixed, and things like included upgrades and “patches” are the exceptions, with software, these are standard. This introduces one risk with legal implications that ties into the question of sub-standard parts in manufacturing (here: software components). But there’s also risk associated with updates to those components: what obligation does a software designer have to update components? It might seem as if there is little obligation, but what about where the update fixes a significant bug that creates a security flaw in the assembled product? Does that obligation have potential to stretch beyond security-based performance to more purely performance-based areas?
A second set of risks that arise that are not analogous to product manufacturing has to do with viral licenses. These are software licenses which are open-source but require anything which incorporates any components of that software (including strings of code rather than finished products) downstream to also be open source. More on that later–but in a nutshell, this means that commercial organizations must be careful, not only that their immediate suppliers of software components are not open-source, but also that none of those suppliers’ sources of code were open source, and so on, and so on, and so on. It can feel like something of a regressum ad infinitum for the person chasing down the chain of sources.
At any rate, do check out the article, by Jason van Zyl: it’s a fascinating read.