Gitlab, Gitorious, and Free Software
This article originally appeared as a guest post on the GitLab blog.
In early March of this year, it was announced that GitLab would acquire Gitorious and shut down
gitorious.org by 1 June, 2015. Reactions from the community were mixed, and understandably so: while GitLab itself is a formidable alternative to wholly proprietary services, its acquisition of Gitorious strikes a chord with the free software community that gathered around Gitorious in the name of software freedom.
After hearing that announcement, as a free software hacker and activist myself, I was naturally uneasy. Discussions of alternatives to Gitorious and GitLab ensued on the
libreplanet-discuss mailing list. Sytse Sijbrandij (GitLab B.V. CEO) happened to be present on that list; I approached him very sternly with a number of concerns, just as I would with anyone that I feel does not understand certain aspects of the free software philosophy. To my surprise, this was not the case at all.
Sytse has spent a lot of time accepting and considering community input for both the Gitorious acquisition and GitLab itself. He has also worked with me to address some of the issues that I had raised. And while these issues won’t address everyone’s concerns, they do strengthen GitLab’s commitment to software freedom, and are commendable.
I wish to share some of these details here; but to do so, I first have to provide some background to explain what the issues are, and why they are important.
Free Software Ideology
Gitorious was (and still is) one of the most popular Git repository hosts, and largely dominated until the introduction of GitHub. But even as users flocked to GitHub’s proprietary services, users who value freedom continued to support Gitorious, both on
gitorious.org and by installing their own instances on their own servers. Since Gitorious is free software, users are free to study, modify, and share it with others. But software freedom does not apply to Services as a Software Substitute (SaaSS) or remote services—you cannot apply the four freedoms to something that you do not yourself possess—so why do users still insist on using
gitorious.org despite this?
The matter boils down to supporting a philosophy: The GNU General Public License (GPL) is a license that turns copyright on its head: rather than using copyright to restrict what users can do with a program, the GPL instead ensures users’ freedoms to study, modify, and share it. But that isn’t itself enough: to ensure that the software always remains free (as in freedom), the GPL ensures that all derivatives are also licensed under similar terms. This is known as copyleft, and it is vital to the free software movement.
Gitorious is licensed under the GNU Affero General Public License Version 3 (AGPLv3)—this takes the GPL and adds an additional requirement: if a modified version of the program is run on a sever, users communicating with the program on that server must have access to the modified program’s source code. This ensures that modifications to the program are available to all users; they would otherwise be hidden in private behind the server, with others unable to incorporate, study, or share them. The AGPLv3 is an ideal license for Gitorious, since most of its users will only ever interact with it over a network.
GitLab is also free software: its Expat license (commonly referred to ambiguously as the “MIT license”) permits all of the same freedoms that are granted under the the GNU GPL. But it does so in a way that is highly permissive: it permits relicensing under any terms, free or not. In other words, one can fork GitLab and derive a proprietary version from it, making changes that deny users their freedoms and cannot be incorporated back into the original work.
This is the issue that the free software community surrounding Gitorious has a problem with: any changes contributed to GitLab could in turn benefit a proprietary derivative. This situation isn’t unique to GitLab: it applies to all non-copyleft (“permissive”) free software licenses. And this issue is realized by GitLab itself in the form of its GitLab Enterprise Edition (GitLab EE): a proprietary derivative that adds additional features atop of GitLab’s free Community Edition (CE). For this reason, many free software advocates are uncomfortable contributing to GitLab, and feel that they should instead support other projects; this, in turn, means not supporting GitLab by using and drawing attention to their hosting services.
The copyleft vs. permissive licensing debate is one of the free software movement’s most heated. I do not wish to get into such a debate here. One thing is clear: GitLab Community Edition (GitLab CE) is free software. Richard Stallman (RMS) responded directly to the thread on
libreplanet-discuss, stating plainly:
We have a simple way of looking at these two versions. The free version is free software, so it is ethical. The nonfree version is nonfree software, so it is not ethical.
Does GitLab CE deserve attention from the free software community? I believe so. Importantly, there is another strong consideration: displacing proprietary services like GitHub and Bitbucket, which host a large number of projects and users. GitLab has a strong foothold, which is an excellent place for a free software project to be in.
If we are to work together as a community, we need to respect GitLab’s free licensing choices just as we expect GitLab to respect ours. Providing respect does not mean that you are conceding: I will never personally use a non-copyleft license for my software; I’m firmly rooted in my dedication to the free software philosophy, and I’m sure that many other readers are too. But using a non-copyleft license, although many of us consider it to be a weaker alternative, is not wrong.
As I mentioned above, software freedom and network services are separate issues—the four freedoms do not apply to interacting with
gitlab.com: not only would this affect users that use
As I was considering migrating my projects to GitLab, this was the first concern I brought up to Sytse. This problem arises because
My discussions with Sytse did not end there: there are other topics that have not been able to be addressed before my writing of this post that would do well to demonstrate commitment toward software freedom.
gitlab.com uses Google Analytics.
If you would like to help with LibreJS compliance, please contact me.
I was brought into another discussion between Sytse and RMS that is unrelated to the GitLab software itself, but still a positive demonstration of a commitment to software freedom—the replacement of Disqus on the
Considering the genuine interest and concern expressed by Sytse in working with myself and the free software community, I can only expect that GitLab will continue to accept and apply community input.
It is not possible to address the copyleft issue without a change in license, which GitLab is not interested in doing. So the best way to re-assure the community is through action. To quote Sytse:
I think the only way to prove we’re serious about open source is in our actions, licenses or statements don’t help.
There are fundamental disagreements that will not be able to be resolved between GitLab and the free software community—like their “open core” business model. But after working with Sytse and seeing his interactions with myself, RMS, and many others in the free software community, I find his actions to be very encouraging.
This post is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License.