Our goal here at Mycroft AI is to create an assistant that runs anywhere and interacts exactly like a person. We envision a future where Mycroft is run by both enthusiasts and large international conglomerates. By small charities and large banks. To make the technology accessible we need to publish it under a legal framework that encourages adoption by individuals and organizations both large and small.
From the beginning, the intention with Mycroft was to produce a body of work that was available to everyone. Those involved in the early project realized closed systems created walled gardens that would inherently discourage collaboration. Given the huge task ahead, they knew the vision could only be achieved by collaborating with thousands of developers globally. The wider the code was used, the more valuable it would become to everyone. That is the win-win of open source!
It was obvious that “open source” was the way to create collaboration. The team built their first prototypes and last year published them on Github. However, Github requires selecting exactly which license to release code under. The GNU Public License — aka GPL — always comes to mind when talking open source. And everyone wants the latest, so the most recent revision was selected, GPLv3. The mycroft-core code was released under GPLv3 and the library Adapt was released under LPGLv3.
Since I joined the Mycroft team I’ve had concerns about the licenses that were chosen. For some time I have been thinking about and discussing the challenges of the GPL licenses… see my posts on StackOverflow about GPL with Classpath Exception. One big challenge that I see is that the licenses were crafted largely for C world, using terms such as “object code” in the GPL and “linking” in the LGPL. These concepts are vague in the world of Python, and vague is not good when talking about the law.
Additionally, version 3 of the GPL included a clause referred to as “anti-tivoization”. As the name suggests, it was added because of the Tivo. It forces hardware that utilizes GPLv3 software to not only publish the code but also include a mechanism to allow the end-user to replace the software.
This sounds fair at first, but in the world of industrial, medical and automotive equipment there are often regulations and policies for safety purposes. Providing a path for a user to replace regulated software is sometimes illegal. As a result, GPLv3 software cannot be used in that equipment.
Finally, GPLv3 also introduces an idea sometimes called patent-left. Code under GPLv3 must also grant patent rights to downstream users. This hasn’t been fully tested in a court case yet, but a fair interpretation of it leads to the very real potential that a patent license could be automatically granted to any company by making trivial use of the GPLed code. And since there are no taksie-backsies with the GPL — once you publish code, the license cannot be revoked — they could legitimately lose the ability to enforce a patent with a single ill-planned commit by a junior programmer. To any company with a patent portfolio, this prospect is terrifying. For more on this, see this article.
The net result? By selecting GPLv3 we’ve made Mycroft less open, less collaborative and less useful than it would have been under more open licenses like MIT, BSD or Apache. Individuals and companies that want to make use of the software in commercial applications are taking risks with their patent portfolios and run the risk of ending up on the wrong side of a copyright suit. While adopting GPLv3 is probably a moral victory, in practice the license makes the software less accessible and less collaborative.
Because of this, we’ve made the decision to undergo the painful process of changing the license. This is not a simple, easy or inexpensive because it requires the permission of everyone who has contributed to the project, but we feel this change is critical to our community’s success.
We only want to do this once so our team has been working with DLA Piper, one of the top firms in the open source world, to review lots of different options. After careful consideration, our team feels the Apache 2.0 license provides the best legal protection for both the contributors and users of Mycroft. The Apache Software Foundation has expended lots of time creating terms that are legally safe and binding. As a result, the Apache web server has been widely adopted around the world in commercial, non-profit, private scenarios. It underpins many technologies, both open and closed and has thrived. This is the model we want to follow.
For most of you, the net result of this is… nothing will be different. Only existing contributors will need to take action during the relicensing effort. Future contributors will need to take an additional step during development to clarify the legal status of their contributions, but that is a topic for another post.
But the real impact of this change is that Mycroft will be easy and clean for anyone to adopt in whatever they are building. Speakers, TVs, medical devices, industrial equipment, STEAM projects and more. After this is complete we’ll be much closer to the goal we set out to achieve – producing an AI for Everyone.
Steve has been building cutting edge yet still highly usable technology for over 25 years, previously leading teams at Autodesk and the Rhythm Engineering. He now leads the development team at Mycroft as a partner and the CTO.