Editor’s Note: I find it sad that people feel compelled to start conversations about Open Source licenses with the acronym IANAL. Open Source licenses shouldn’t require a legal team to interpret, and one shouldn’t construe commentary on licenses as legal advice. Yet here we are regardless, with all manner of laws and statutes, and I’m compelled to tell you: I am not a lawyer and am not authorized to practice law.
Open Source Licenses
Working with Open Source software is both a blessing and curse for many people. On the one hand, there is a wealth of software out there that allows developers to rapidly build projects, products, and solutions. On the other, there is also a raft of open source licenses to navigate through, understand, and comply with. Compliance, depending upon the license, could be anything from doing nothing, to giving your modifications back to the community, or providing instructions on how to run modified software on your hardware platform.
In a previous life I was my employer’s “open source compliance officer”, responsible for reviewing all of the open source applications and libraries the development team wanted to include in the product, as well as work with tools such as Black Duck and Palamida to scan our software in the event something slipped by. To “optimize” the amount of work I had to do reviewing every software package I sent out a simple bulletin to group: “If the license is GPLv3, find something else. Otherwise, come visit and we’ll review it.”
My insistence that the GPLv3 was off the table was all based around the Tivoization clause. Our product contained a TPM device, required signed software delivery, and we did not (and would not) provide the means to install your own software.
For the rest of licenses I would dutifully pore through the text, highlighting phrases such as to copy from or adapt all or part of the work and source form shall mean the preferred form for making modifications. I would reason in my mind what constituted a derivative work and debate whether or not linking against a shared library would require us to open source the software using the library. After making a decision about a certain license I’d leave it for a week and then come back to reevaluate it, sometimes finding that my mind had changed.
In the end I came to appreciate that the best open source licenses for both producers and consumers are the shortest and simplest. They steer clear of paragraphs of definitions and avoid references to the WIPO copyright treaty or the Berne Convention. Simple doesn’t have to mean permissive either, though it’s true most simple licenses are. Both the Eclipse Public License and Mozilla Public License strike a fair balance between simplicity and ensuring improvements are shared back with the community.
Perfect
Perfect is a new web server and toolkit developed in Swift. With the release of Open Source Swift, Perfect aims to be used “on the server” (whether that be Linux or OS X-based) and the client (presumably iDevices). The Perfect team decided to release the source code on Github and license it under the GNU Affero GPL v3. This choice resulted in an issue being opened requesting clarification on the license and a barrage of questions and comments regarding what the AGPL has to say about linking, and so on. Others just flat out said, “I can’t use this.”
The authors of Perfect felt compelled to make a statement (on a Github issue):
Although the linking terms of the AGPLv3 can be read very aggressively, that is not our intent – we do not ever intend to cripple anyone else’s work, or attack people for “linking to Perfect”.
That may be satisfactory answer to some; personally I would want to see that clarification in more specific terms on their licensing page, and preferably in the additional terms section of the license itself.
An Argument Against Using the AGPL
Obviously what license Perfect chooses is their business, but the question is, why is their selection of the AGPL even an issue? No one opened issues against open source Swift asking for “clarifications”. There is no one saying “I can’t use this” to the Zewo team. Even the folks at MongoDB felt like they had to clarify the license stating You [sic] application, even though it talks to the database, is a separate program and “work”.
The reason why everyone feels compelled to clarify their use of the AGPLv3 is it is an unclear license when it comes to whether “using” the Program or “linking” to the Program implies that you have created a “work based on the Program.” If it does mean that you have created a “work based on the Program” then the AGPLv3 would call that a “covered work” and subject your application to the terms and conditions of the license.
In the case of Perfect, folks are concerned about whether or not the mere use of the Perfect server on their systems binds them to the AGPLv3, and whether or not building applications that use the PerfectLib library creates works “based on the Program.” The AGPLv3 is pretty clear in its Preamble that it was designed to prevent modified versions of the program from “hiding in the cloud”; if you modify the source of the Perfect server and then run it and provide a network service based upon it to others, you are obligated to release your modifications. But is developing a web application that “uses” Perfect to route requests to handlers, render web pages, and send responses mean you’ve built a derivative?
My interpretation of the AGPLv3 (reiteration of IANAL disclaimer) is that merely “using” the server or client libraries does not constitute a derivative work, and that interpretation is based upon the definitions section of the license text itself:
To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work. A "covered work" means either the unmodified Program or a work based on the Program.
A covered work as defined by the license is either the unmodified Program or a work based on the Program. By the definition of the license, a work based on the Program is a work that is a “copy” or adaptation of all or part of the work. Merely using an API as it was intended to be used is not an adaptation of something. Or, consider the ImageMagick applications. If I write a script that uses ImageMagick to take a JPEG, rotate it, resize it, and then punch a hole out of the center with a mask, have I created an adaptation of ImageMagick? No, as an adaptation is the act or process of modifying an object to render it suitable for a particular or new purpose or situation. I’ve modified nothing, only used it as intended.
Even though after making that interpretation, it is clear that others do not agree. For example, the Opa programming language keeps the compiler under the AGPLv3, but switched to the MIT license for the framework. Why? The license is barred from being used at many companies, Google being the most notable one. If the license is clear and there is no “fear, uncertainty, and doubt” around whether or not one can use a library without licensing your application under the AGPLv3, why bar it?
The reality is that there is doubt and uncertainty, and when you’re running a business you fear things that can jeopardize it. This concludes me to believe that if you’re a software developer or developers working on a nascent application and framework you want to see widely adopted, don’t choose the AGPLv3, and definitely steer clear of the GPLv3. If you are a developer at Megacorp, Inc., and want to use an application that’s licensed under the AGPLv3, do your homework and prepare your case. Unless you get a clear answer from the authors of the software as to what you can and can’t do, I wouldn’t recommend building an application on top of it.