We’re happy to bring our readers this fascinating post by Balaji Subramanian, a 2nd year student at Nalsar University of Law, Hyderabad. He draws a connection between the Open Source movement, and the Soviet military hardware sector! This is his 4th post in the SpicyIP Fellowship applicant series. His previous posts include 2 posts on improving usage of the Traditional Knowledge Digital Library (here and here), and this post on policy concerns on granting Trademarks to military hardware on classes outside of their core areas. [The deadline for submission of entries for our Fellowship application has now passed. We shall be going over the submissions received thus far and will announce the winners soon].
Open Source Killing Machines: From Russia With Love
By: Balaji Subramanian
There are many histories of the open-source movement, but almost all of them commit what may be a cardinal error of treating the open-source movement as synonymous with the open-source software movement – see this example from the FreeBSD Project. The Wikipedia version, to be fair, includes a brief account of how US car manufacturers in the early 20th Century engaged in cross-licensing (both formal and informal) of patents across the industry, but concerns itself primarily with open-source software (and exclusively with software for any history of truly open-source technology).
My claim, in this post, is that the open-source movement (at a subconscious level, at the very least) predates the advent of open-source software, and even modern software programs as we know them. I find a philosophy that closely resembles the open-source culture in Cold War-era Soviet military export policies, and from this I postulate that these were early examples of open-source hardware. The open-source hardware discussion seems relatively sparse, and the little literature that exists deals with much more modern developments such as the Arduino. The Soviet Union, however, seems to have pioneered the development of the very same principles, albeit for vastly different reasons.
Consider that iconic example of Soviet military hardware – the AK-47. Many have questioned its rise to popularity – it has been variously described as unsophisticated and inaccurate, and its wide use today, over six decades after it was born, is constantly met with incredulity. There exists a fascinating economic analysis of the rifle’s popularity that sets out a clear reason for its enormous sales despite being far from the best product in the market – the path dependent lock-in.
Path dependence and vendor lock-in are eerily familiar in the context of the open standards and software debate – by popularising her product or standard universally, the innovator can then capitalise on this new market for “after-sales” service, and so on. While path dependent adoption processes are usually followed by vendor lock-in, the freely replicable nature of the weapon precluded this development in the AK-47’s case (and in the case of weapons, generally – simplicity was of legendary importance for Soviet designers), pushing it in the opposite direction towards modification, adaptation and the status of a weapon in the global commons.
This free replicability was no accident – it was an essential feature of Soviet foreign policy at the time, brought about by the convergence of several factors. First, the Soviet Union was engaged in a global arms race with the US, with either side trying to distribute weapons to as many aligned countries as they possibly could. Second, the USSR saw its national interest in pushing as many states as possible down the communist path, with the US similarly propagating capitalism. Third, and most importantly, the USSR had no patent laws that vested exclusive rights in inventors. The Soviets were, in fact, notorious for their flippant disregard for IP law – look no further than their first real heavy bomber or their earliest jet engine for examples.
Here, it is important for us to keep in mind what exactly the driving principles behind open-source are. For this, I refer to the ten principles that make up the definition of open-source software, and attempt to adapt them to a military hardware environment. Of these principles, I identify three as embodying ‘core’ open-source concepts – free redistribution, availability of source code, and a structure that allows for derivative works. The very idea of open-source technology rests on these principles, while the other principles (such as non-discriminatory licensing, for example) are subsidiary inasmuch as they represent means to achieve the ends enunciated in them. It is important to test Soviet practice against these principles, rather than merely the normative content of the license agreements.
First, we have free redistribution (“free as in free speech, not free beer” – here, the focus is on freedom to redistribute rather than redistribution for no cost). There appears to be no history of the USSR challenging redistribution transactions – there have been instances of the US purchasing MiG-29s, the zenith of Soviet fighter aircraft design.
The second principle is the availability of ‘source code’, or documentation that enables someone with reasonable expertise to understand and manufacture the product. Since arms exports were accompanied by relatively comprehensive technology transfer agreements, the ‘source code’ for these systems was readily available to countries aligned with the USSR. (Some examples of the efficacy of such technology transfer include China (in the 1950s, which now exports clones of Soviet weaponry) and India (specifically in the case of jet engines – HAL has been manufacturing them for quite a while now))
Third, the license must allow for derivative works. In order to fully appreciate the similarities in the proliferation of Soviet weapons to that of free software, consider the phenomenon most characteristic of open-source development: forking. Just as developers freely modify and adapt source code to suit their specific needs, creating and distributing forked releases, militaries around the world adapted the original AK-47 design to suit their requirements. Some of these derivatives, such as the IMI Galil and the Ukrainian Vepr were largely similar to the original platform, while others merely borrowed the design principles embodied in it. Similar to open-source software, some of these rifles competed directly in the original AK market. Forking, thus, is as endemic to Soviet assault rifles as it is to free software.
While Soviet military exports conform to the first three principles almost entirely, they hit formidable hurdles in the next set – ‘integrity of the author’s code’, or ‘attribution’ requires that any modifications be designated appropriately to avoid confusion with the original. It’s unclear if the Soviets insisted on compliance with these principles, and unlikely, at any rate. Further, true open-source technology is non-discriminatory in distribution – unattainable here for obvious national interest considerations. At any rate, these principles represent values subsidiary to the first three, and the means through which they are to be realised. Thus, Soviet arms exports fulfil the core criteria required to merit a place in the history of open-source – they represent technology that was distributed freely, accompanied by the technical documentation required to manufacture and modify them, and finally, with similar modes of distribution being enforced for products derived from the original technology.
The open-source movement has been derided as a logical extension of communism, most notably by Bill Gates. Without adopting the negative connotations that the West ascribes to the tag, we must acknowledge that inasmuch as open-source challenges the strict correlation between labour and personal reward and replaces it with a paradigm in which developers contribute uncommodifiable labour in pursuit of goals other than individual rewards, open-source and communism share important foundational ideas. The relationship between the open-source movement and communism is a question to which I cannot possibly do justice in this severely constrained space. It is enough to note that regardless of the nature of this interplay, a communist government, especially the USSR (for reasons detailed above) appears to be relatively more conducive to the open-source movement than a capitalist system.
In any case, the underlying reasons behind the USSR’s policy framework that facilitated such open technology transfers are relatively unimportant to us. We are concerned with the open-source distribution model, and the export policies largely fulfil the definitional criteria on that front, at least in sufficient measure to be termed ‘proto open-source’, if not open-source in our modern definition. It matters not, thus, whether technology was open-sourced for world peace or hegemony – the open-source movement does not give importance to the underlying motives of the developer as much as the manner in which she chooses to distribute technology.
