VLC project

http://www.fsf.org/blogs/licensing/left-wondering-why-vlc-relicensed-some-code-to-lgpl

The FSF's License and Compliance Lab had previously written about the issues involved with VLC and Apple's App Store.

I first met the original group of VLC developers at the Solutions GNU/Linux conference in 2001. I had been an employee of FSF for about a year at the time, and I recall they were excited to tell the FSF about the project, and very proud that they'd used FSF's premier and preferred license (at the time): GPLv2-or-later.

What a difference a decade makes. I'm admittedly sad that VLC has (mostly) finished its process of relicensing some of its code under LGPLv2.1-or-later. While I have occasionally supported relicensing from GPL to LGPL, every situation is different and I think it should be analyzed carefully. In this case, I don't support VLC's decision to relicense the libVLC code.

The main reason to use the LGPL, as RMS put eloquently long ago, is for situations where there are many competitors and developers would face serious difficulty gaining adoption of a strong-copylefted solution. Another more recent reason that I've discovered to move to weaker licenses (and this was the case with Qt) is to normalize away some of the problems of proprietary relicensing. However, neither reason applies to libVLC.

VLC is the most popular media player for desktop computers. I know many proprietary operating system users who love VLC and it's the first application they download to a new computer. It is the standard for desktop video viewing, and does a wonderful job advocating the value of software freedom to people who live in a primarily proprietary software world.

Meanwhile, the VideoLan Organization's press statements have been quite vague on their reasons for changing, saying only that "this change was motivated to match the evolution of the video industry and to spread the VLC engine as a multi-platform open-source multimedia engine and library." The only argument that I've seen discussed heavily in public for relicensing is ostensibly to address the widely publicized incompatibility of copyleft licensing with various App Store agreements. Yet, those incompatibilities still exist with the LGPL or, indeed, any true copyleft license. The incompatibilities of Apple's terms are so strict that they make it absolutely impossible to comply simultaneously with any copyleft and Apple's terms at the same time. Other similar terms aren't much better, even with Google's Play Store (— its terms are incompatible with any copyleft license if the project has many copyright holders).

So, I'm left baffled: do the VLC community actually believes the LGPL would solve that problem? (To be clear, I haven't seen any official statement where the VideoLAN Organization claims that relicensing will solve that issue, but others speculate that it's the reason.) Regardless, I don't think it's a problem worth solving. The specters of “Application Store” terms and conditions are something to fight against wholly in an uncompromising way. The copyleft licensing incompatibilities with such terms are actually a signaling mechanism to show us that these stores are working against software freedom actively. I hope developers will reject deployment to these application stores entirely.

Therefore, I'm left wondering what VLC seeks to do here. Do they want proprietary application interfaces that use their core libraries? If so, I'm left wondering why: VLC is already so popular that they could pull adopters toward software freedom by using the strong copyleft of GPL on libVLC. It seems to me they're making a bad trade-off to get only marginally more popular by allowing some proprietary derivatives. OTOH, I guess I should cut my losses on this point and be glad they stuck with any copyleft at all and didn't go all the way to a permissive license.

Finally, I do think there's one valuable outcome shown by this relicensing effort (which Gerv pointed out first): it is possible to relicense a multi-copyright-held code based. It's a lot of work, but it can be done. It appears to me that VLC did a responsible and reasonable job on that part, even if I disagree strongly with the need for such a job here in the first place.

Update (2012-11-30): It's been pointed out to me that VLC has relegated certain code from VLC into a library called libVLC, and that's the code that's been relicensed. I've made today changes to the post above to clarify that issue.

http://www.h-online.com/open/news/item/Relicensing-VLC-to-the-LGPL-the-hard-way-1750805.html

http://lwn.net/Articles/526366/

http://www.jbkempf.com/blog/post/2012/How-to-properly-relicense-a-large-open-source-project

Relicensing VLC to LGPL As you might know, or might have read, I am spending a lot of my time to relicense libVLC, aka VLC engine, from GPL to LGPL. There are quite a few good reasons to do so, some more obvious than others, but notably competition, necessity to have more professional developers around VLC and AppStores. Other reasons also exist, but this is not the place and time to discuss those. This is a crazy task, because every developer keeps all its rights, and VideoLAN has little rights on VLC. This involves contacting a few hundred developers, some who were active only 10 years ago, some with bouncing mails, and people spread across continents, countries, languages, OS... Yet, I did it. Here is the first part of how I did it... Copyright, droit d'auteurs, public domain and VLC. As all VideoLAN projects, like x264 or DVBlast, VLC is governed under the French law, even if some don't like this fact. This means, we are not under a copyright system, but under an author rights system. As such, every author has moral rights and patrimonial rights. The first ones are nontransferable while the later ones can be transfered to another legal entity. This is quite different from copyright. Moreover, this explains why public domain is not a valid concept for everyone on this planet. Unlike a lot of large open source projects, authors of VLC keep all their rights on their code, even if the code is minimal. Therefore, to change the license, one must contact every author, even small contributors. From a community management point-of-view, this also makes sense :). VLC authors, core and modules VLC is split in several parts, but most of the code is in the core or in some modules. The core The core, that was successfully relicensed last year, involved around 150 developers and 80000 lines of code, and the very vast majority of the code was done by two dozens of people, most of whom I have not lost contact with. The modules The modules are a different piece of cake. Even, if we concentrate on the playback modules, which I did, we speak here of 300 developers and 300000 lines of code and the repartition is distributed more evenly. Listing the right people The first step, which is the most important, is to correctly list the authors. This would seem simple from an external point of view, but it is not, mostly because there was no split between authors and commiters in the CVS and SVN days. Moreover, some code was stolen imported from Xine or MPlayer... And sometimes, the author is not even credited in the commit log. And this should be the time were you think I am completely crazy. Tools To get a proper listing of contributors, I used 3 things: git blame git log grep, awk on our vlc git repository. Blaming The first obvious thing to do, is to use git blame on all the files you care, so you know, lines-by-line who actually wrote the code, even after code copy, code move or re-indentation. I ran it, with extra protection, like this: git blame -C -C -C20 -M -M10 -e $file. Of course, as some Git expert told me, this should have been enough: git blame -C -C -M -e $file but I preferred to be extra-safe. Logging The second obvious thing to do, was to check all the logs on the specific modules folder or file, in case : someone did some commits on one module the code was quite changed, so blaming does not find it yet the idea behind the code is the same. This solves what I call the authorship leak. git shortlog -sne $file was used for that task. Grepping Finally, some people where only mentioned in the commits logs or just had their names in the final file. For this, I grepped "patch", "original" "at", "@" in the commit logs. I also grepped the author sections of every file to check if there were any other author missing. Conclusion After those steps, I had a quite accurate list of people to contact. I'll skip you the de-duplicating step, because this is obvious and boring. The next posts will be about how I contacted and found people, and how they did react.