Swish is a popular payment app in Sweden owned by the major banks. The app allows users to transfer money between each other as well as paying in stores. In late 2014 an anonymous hacker discovered a security flaw that enabled users to access the transaction statements of other users. The hacker also discovered that the app included a software-library called AndroidPinning which had been released under the GPLv3 license. This was the start of an open source licensing-dispute that shows how easy it is to find oneself in a dispute and how that easily could have been avoided.
The GPLv3 is a so-called reciprocal license. These licenses are also known as copyleft, hereditary or restrictive licenses. You can think of them like “pay it forward”-schemes; the terms allow you to copy, modify, and distribute the software but in exchange you must reciprocate those same terms upon further distribution downstream.
The following is the relevant provision of the GPLv3.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License [emphasis added]
When it was made public that the Swish-app included GPLv3-licensed code, users promptly posted requests on the Facebook-page of Swish to access the source code of the entire app.
“Hello, you seem to be using a GPL’ed library. I would like access to the source code of your Android app. These are the terms you accepted when you chose to use the library.”
It was also reported that the author of the library AndroidPinning had made inquiries into the company’s alleged use of his code but that he had not received any response.
After initially denying the use of any code licensed under the GPLv3 —and stating that the hacker who discovered the security-flaw had mistaken the file for another with similar code— the company went on to acknowledge that there was code licensed under GPLv3 in the app. It maintained however that the file was a remnant of early testing and that it had not actually been used in the distributed version. The company held the view that the inclusion of the GPL-licensed code did not require them to release the source code of the entire app. Finally, the company announced that a version without GPL-licensed code would be released.
This dispute illustrates two common questions in open source licensing.
What Source Code Must Be Released?
The question of which source code must be released under the GPL license family in order to fulfill the reciprocal obligation is by far the most contentious in open source licensing. This is unfortunate considering the general need of actors for legal certainty as well as the wide-spread use of the GPL licenses (GPLv2 is the most commonly used reciprocal license).
The reciprocal obligation under the GPLv3 sets forth that the “Corresponding Source” of a “covered work” must be distributed under the same terms. What constitutes a “covered work” is defined under Section 0 as “either the unmodified Program or a work based on the Program.”
It is not clear on its face what a work “based on” the program is when a program is distributed as binary machine code. Hinging an obligation on what constitutes a “work based on” something in machine code form like this is unfortunate since it cannot be said to have any meaning to a licensee reading the terms (nor to anyone else for that matter).
Supposing the software in question is deemed a work based on the program, the license does exclude “[a] separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library.” The definition of a “System Library” that would be excluded however takes aim at operating system components and cannot be said to exclude any of the uses discussed here.
this uncertainty motivates caution and thorough analysis
The ins and outs of the extent of the reciprocal obligation is best left for another time. In short, it is decidedly unclear what source code must be released in order to fulfill the reciprocal obligation. Unclear terms of a license require interpretation, and any operation of interpretation will always involve some degree of uncertainty. The result will also likely differ from jurisdiction to jurisdiction. This uncertainty motivates caution and thorough analysis before actually distributing a product containing software that has been licensed under any of the GPL licenses.
Not all reciprocal licenses are this lacking in quality however. The Mozilla Public License Version 2.0 is a good example of a thought-through license. Notably, the MPLv2 hinges its reciprocal obligation on source code files rather than the compiled binaries. It is therefore clear which source code must be released under the terms of the MPLv2.
Is It Sufficient to Re-Release The App?
To answer the question of whether re-releasing an app that is free from GPL-licensed code is sufficient, you must first conclude at what point you cease to be bound by the reciprocal obligation. This will also likely differ from jurisdiction to jurisdiction, but it can generally be assumed that obligations cease upon either being fulfilled or rescinded. This means that releasing a new version of the app would not absolve you from the obligations that have arisen from having distributed prior versions. The reciprocal obligation is not affected by subsequent versions. This further motivates ensuring compliance before distributing.
The Swish GPLv3-dispute shows how easy it is to find oneself in an open source licensing dispute and how troublesome it can be to get out of it. This is due to unclear terms in common licenses and the ease with which an organization can mistakenly include and distribute software associated with burdensome obligations. Since the reciprocal obligations have the potential of being show-stoppers, there are good reasons to invest resources in preemptively ensuring compliance.
What this dispute does not show however is the danger of potentially having to negotiate with a large group of licensors. This due to the licensing model of reciprocal licenses whereby you are granted a license from each developer that has contributed to a project. Resolving a dispute with the original author may therefore leave many contributors as potential enforcers. These can possibly “go rogue” and assert their own rights without following community policies on enforcement.
This was not an issue in the case of AndroidPinning since Moxie Marlinspike in practice was the sole author and licensor (another person had removed a whitespace). In the case of Linux however, with 795 lines of code added per hour, the complexity is Byzantine and makes negotiating with all authors utterly unfeasible.
- Inform managers and developers about which licenses are “safe” and which require further scrutiny
- Introduce compliance audits prior to any distribution
- Identify all authors before engaging in settlement negotiations