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

In a modern Microservices Architecture, a complex software is divided in different separated services. Does this give us new borders for the interpretation of "software as a whole" within the meaning of GPLv2? Must each Micorsoervice be considered as an "independent programme" meaning that the copyleft effect would stop at the border of a single service?

Monday 11:40 a.m.–12:10 p.m.

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.

Dr. Lutz M. Keppeler

I am Salaried Partner of "Heuking Kühn Lüer Wojktek" (or short HKLW), a huge German (domestic) law firm with more than 350 lawyers. As I am specialized (amonst others) in Open Source Law, it is my daily business to help clients with OS-Compliance issues. I, furthermore, have represented clients in OS-cases before German courts, including several "McHardy-Cases". I am also supporter of the Free Software Foundation Europe and have participated (and was speaker) at the FSFE legal licensing workshops in Barcelona.

Even though I mostly council undertakings, i also represent open source developers. My approach is to help making the world a better place by helping Undertakings to understand how to reach compliance and how to deal with the community.

Personally I have tried to programme computer games as a kid, but have, nevertheless, studied law after high school. Now I can combine the two thinks which I am most interest in.

Apart from OS-law I am specialised in IT-security law and data protection law. I am practising law for more than 8 years (5 years as an admitted lawyer to the German bar).