Displaying posts tagged Kallithea
2015 YIR: Bradley and Karen Speak at FOSDEM 2015
byon December 16, 2015
[ This is a blog post is the third in our series, Conservancy 2015: Year in Review . ]
At the end of January 2015, Bradley and Karen came back from LCA and left almost immediately for FOSDEM 2015, where they co-organized the FOSDEM 2015 Legal & Policies Issues DevRoom with Tom Marble and Richard Fontana. Karen gave an amazing FOSDEM-wide keynote (in the giant room :) entitled Identity Crisis: Are we who we say we are?, and Bradley gave a talk in the DevRoom.
Sadly, it looks like the cameras were not functioning for Karen's keynote, but you can read her interview with the FOSDEM organizers about the talk. Fortunately, there is video for Bradley's talk, entitled Fork and Ignore: Fighting a GPL Violation By Coding Instead (The Story of Kallithea). The video of the talk is included here (and is also available on Youtube). The slides aren't clear on the video, but you can follow along with the slides on Bradley's website.)
Bradley's talk in particular tells a story of one of Conservancy's successes from the previous year, the launch of the Kallithea project. Just a few weeks ago, Conservancy launched its own Kallithea instance for Conservancy's public repositories.
Karen and Bradley are again co-organizers of the Legal & Policy DevRoom at FODEM 2016.
Why Conservancy's Kallithea Project Exists
byon July 15, 2014
Eleven days ago, Conservancy announced Kallithea. Kallithea is a GPLv3'd system for hosting and managing Mercurial and Git repositories on one's own servers. As Conservancy mentioned in its announcement, Kallithea is indeed based on code released under GPLv3 by RhodeCode GmbH. Below, I describe why Conservancy chose to serve as non-profit home to an obvious fork (as this is the first time Conservancy ever welcomed a fork as a member project).
The primary impetus for Kallithea is that more recent versions of RhodeCode GmbH's codebase contain a very unorthodox and ambiguous license statement, which states:
(1) The Python code and integrated HTML are licensed under the GPLv3 license as is RhodeCode itself.
(2) All other parts of the RhodeCode including, but not limited to the CSS code, images, and design are licensed according to the license purchased.
Simply put, this licensing scheme is — either (a) a GPL violation, (b) an unclear license permission statement under the GPL which leaves the redistributor feeling unclear about their rights, or (c) both.
When members of the Mercurial community first brought this license to Conservancy's attention about ten months ago, the first focus was to form a formal opinion regarding (a). Of course, Conservancy did form such an opinion, and you can probably guess what that is. However, I realized a few weeks later that this analysis really didn't matter in this case; the situation called for a more innovative solution.
Indeed, I recalled at that time the disputes between AT&T and University of California at Berkeley over BSD. In that case, while nearly all of the BSD code was adjudicated as freely licensed, the dispute itself was painful for the BSD community. BSD's development slowed nearly to a standstill for years while the legal disagreement was resolved. Court action — even if you're in the right — isn't always the fastest nor best way to push forward an important Free Software project.
In the case of RhodeCode's releases, there was an obvious and more productive solution. Namely, the 1.7.2 release of RhodeCode's codebase, written primarily by Marcin Kuzminski was fully released under GPLv3-only, and provided an excellent starting point to begin a GPLv3'd fork. Furthermore, some of the improved code in the 2.2.5 era of RhodeCode's codebase were explicitly licensed under GPLv3 by RhodeCode GmbH itself. Finally, many volunteers produced patches for all versions of RhodeCode's codebase and released those patches under GPLv3, too. Thus, there was already a burgeoning GPLv3-friendly community yearning to begin.
Like with any Free Software codebase fork, acrimony and disagreement led to Kallithea's creation. However, as the person who made most of the early changesets for Kallithea, I want to thank RhodeCode GmbH for explicitly releasing some of their work under GPLv3. Even as I hereby reiterate publicly my previously private request that RhodeCode GmbH correct the parts of their licensing scheme that are (at best) problematic, and (at worst) GPL-violating, I also point out this simple fact to those who have been heavily criticizing and admonishing RhodeCode GmbH: the situation could be much worse! RhodeCode could have simply never released any of their code under the GPLv3 in the first place. After all, there are many well-known code hosting sites that refuse to release any of their code (or release only a pittance of small components). By contrast, the GPLv3'd RhodeCode software was nearly a working system that helped bootstrap the Kallithea community. We're grateful for that, and we welcome RhodeCode developers to contribute to Kallithea under GPLv3. We do note, of course, that RhodeCode developers sadly can't incorporate any of our improvements in their codebase, due to their problematic license. However, Conservancy extends again our offer (also made privately last year) to work with RhodeCode GmbH to correct its licensing problems.