The range and border of copyleft in a Microservices Architecture
By Dr. Lutz M. Keppeler

Since more or less three years it is a "hot-new thing" to organize bigger developments in a Microservice architecture, i.e. the organizing of all functionalities in a collection of loosely coupled but separated programs. Amongst others, this very much improves modularity of a modern software. If a service reaches it’s “end of life” or proves dysfunctional it can be easily removed. The communication between the different Microservices is realized by standardized APIs. This allows the services to be programmed by totally different teams and sometimes even in different languages.

What does this mean for the very important interpretation of the terms of Sec. 2 GPLv2 (and similar wording in other license): “If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.” One could argue that a separate modularized service must per se be an “independent and separate work”. This argumentation could be supported by the FAQ of the FSFE, according to which the “mechanism of communication” is of utmost importance and “pipes, sockets and command-line arguments” are considered as “communication mechanisms normally used between two separate programs”. Taking this into account, the border of any copy-left effect could be narrowed to a respective Microservice (depending on the specific API). As a rule of thumb, I will argue that – on average – the lower the communication between the programs is located in the OSI-layer-model, the more speaks in favor of a “communication mechanisms normally used between two separate programs”. For example a communication based on IP-addresses, like sockets, (OSI layer 3) speaks in favor a separate program. On the other hand, there are often central data bases, it-security features or further elements which put the separate Microservices “in brackets”. If this “bracket-elements” are weighty, it can be argued that several (or all) Microservices form one program as a whole.

I look forward to introducing this idea and fruitfully discussing its consequences with interesting people at the Copyleft Conference.