|
|
Subscribe / Log in / New account

Relicensing VLC from GPL to LGPL

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing.

By Nathan Willis
November 21, 2012

Select a software license can be tricky, considering all of the effects that such a choice has for the future: library compatibility, distribution, even membership in larger projects. But agreeing on a license at the beginning is child's play compared to trying to alter that decision later on. Case in point: the VLC media player has recently been relicensed under LGPLv2.1+, an undertaking that required project lead Jean-Baptiste Kempf to track down more than 230 individual developers for their personal authorization for the move.

VLC had been licensed under GPLv2+ since 2001; the development team decided to undertake the relicensing task for a number of reasons, including making VLC compatible with various gadget-vendor application stores (e.g., Apple's). Making the core engine available under LGPL terms would make it a more attractive target for independent developers seeking to write non-GPL applications, the argument goes, which benefits the project through added exposure, and may even attract additional contributor talent.

The license migration was approved by team vote in September 2011. The first big milestone was cleared the following November, a relicensing of libVLC and libVLCcore (which implement the external API and internal plugin layer, respectively), plus the auxiliary libraries libdvbpsi, libaacs, and libbluray. Kempf described the process involved on his blog. Because VLC contributors retain the authors' rights to their contributions, no matter how small, Kempf needed to locate and obtain permission from all of the roughly 150 developers who had written even a minor patch during the project's long history.

To do so, he harvested names and email addresses from the project's git repository and logs, and undertook a lengthy process of sifting through the records (both to weed out false matches, and to identify contributors who were credited in unofficial spots like in-line comments). With the list in hand, Kempf set out to contact each of the contributors to approve the licensing change. He was ultimately successful, and the change was committed. The commit notes that more than 99% of the developers consented to the change, and those agreeing account for 99.99% of the code, which he said is sufficient from a legal standpoint.

The modular community

But, as Kempf described in a follow-up post, the same method was less successful when he set out in 2012 to relicense the next major chunk of VLC code: the major playback modules. Together, they constitute a much larger codebase, with considerably more contributors (including some who are not necessarily committed VLC team members). After emailing the module authors, he said, he received responses from only 25% of them. Two rounds of follow-up emails edged the number up closer to 50%, but for the remainder he resorted to "finding and stalking" the holdouts through other means. Those means included IRC, GitHub, social networks, mutual friends, employers, and even whois data on domain names.

In the end, he managed to get approval from the overwhelming majority of the contributors, but there were some "no"s as well, plus a handful of individuals who never replied at all. At that point, he had to examine the unresolved contributions themselves and decide whether to delete them, reimplement them, refactor them into separate files, or drop the offending modules altogether. He made the license-changing commit on November 6, and listed about 25 modules that were not included. They include the work of 13 developers who either declined give their approval or were unreachable, plus a set of modules that were ports from other projects (such as Xine or MPlayer) and thus not in the VLC team's purview.

By all accounts, the legwork required to hunt down and cajole more than 230 developers was arduous: in the second blog post, Kempf noted that it could get "really annoying" to contact people "over, over, over and over, and over" to ask for an answer. That is probably an understatement; in an email Kempf said at the outset that no one thought it would even be doable.

He also elaborated on what comes next. Not every VLC module was targeted for the relicensing work of the previous year, he said. Out of the roughly 400 modules being developed, about 100 remain non-LGPL. First, for those who rarely venture beyond VLC's desktop media player functionality, it can be easy to forget all of the other functions it provides; those modules will remain under their existing licenses. In particular, VLC's media server, converter, and proxy functionality will remain in GPL modules. Other modules, including scripting and visualization, will remain GPL-licensed at least for the time being, because they do not impede the ability of third-party developers to write non-GPL playback applications, which was the leading use-case motivating the change. VLC's user interface and control modules will also remain GPL-licensed, in order to discourage non-free forks.

Kempf also pointed out that the VideoLAN non-profit organization holds the trademarks to VLC, VideoLAN, and other names, and restricts their usage to open source code. That reflects the project's concern that the move away from the GPL will be misinterpreted by someone as a move away from free-ness (in multiple senses of the word); in addition to the trademark policy, both of the announcements about the relicensing project have emphasized that despite the change, VLC will remain free software.

Holdouts

But despite the consensus reached by the majority of core and module developers, there is still the problem of those twenty-odd playback modules that, for one reason or another, are not being relicensed. Kempf explained that the main VLC application will still be able to use all of the non-LGPL modules, and that only third-party libVLC applications will encounter any difficulties with license compatibility.

Authors of such applications may write their own modules for the missing functionality, or simply migrate to another module — given the modular nature of VLC, there are several modules out there that duplicate functionality implemented elsewhere. "The results might be slightly different, but I doubt many people will notice. There are a few exceptions, (probably 2 or 3) that will get rewritten, at some point, I think."

There are two modules Kempf predicted will never be reimplemented in LGPL code — DVD playback and Teletext support — because they rely on other GPL-licensed packages without viable non-GPL alternatives. He still holds out hope for tracking down a few of the still-unreached contributors, of course — only the authors of the iOS, Dolby, Headphone, and Mono modules outright declined to relicense their work.

It is not possible to predict exactly what effect the LGPL-relicensing work will have on third-party developers targeting iOS or other "app store" markets, thanks to the often opaque processes governing which content gets in and which gets rejected. But VLC was yanked from the iOS App Store in January 2011, a decision believed to be due to the GPL license. But because Apple does not provide details about its decisions, the situation remains nebulous.

Nevertheless, hunting down several hundred individual developers from more than a decade of development is an impressive feat of, shall we say, logistical engineering. Relicensing a community project is rarely a simple task; one is reminded of the multi-year process required to relicense the Heyu home automation engine, which involved tracking down the estates of developers no longer with us. Many large software projects have contemplated a license change at one time or another, and typically the scope of tracking down and persuading all of the former developers is cited as a reason that such a change is unworkable. For example, VLC's contributor pool is far smaller than the kernel's, to be sure. But the fact that Kempf was able to successfully chase down virtually the full set of both uncooperative and unintentionally-AWOL contributors in such a short time frame is an admirable achievement. Then again, the VLC team has long enjoyed a reputation for admirable achievements.



to post comments

LGPL and app store

Posted Nov 22, 2012 13:26 UTC (Thu) by epa (subscriber, #39769) [Link] (11 responses)

If a library is distributed under LGPL, then you have to allow the user to replace that library with his own modified version (even if your proprietary application code linked to it remains unchangeable). It would seem that distributing VLC in a locked-down app store, where users cannot replace any part of the code once installed, still violates the spirit of the licence, if perhaps not the letter. It's not clear how a move from GPL to LGPL makes things any better here.

If I downloaded VLC onto an iPhone, and then wanted to exercise my right to modify the LGPLed code, how would I do that? And how is this any different to plain old GPL?

LGPL and app store

Posted Nov 22, 2012 17:46 UTC (Thu) by khim (subscriber, #9252) [Link] (3 responses)

It would seem that distributing VLC in a locked-down app store, where users cannot replace any part of the code once installed, still violates the spirit of the licence, if perhaps not the letter.

LGPL2.1 only talks about use of a suitable shared library mechanism for linking with the Library. It does not give you the ability to replace said library. LGPL3 is different, but that's another story, we are talking about LGPL2.1+ here.

If I downloaded VLC onto an iPhone, and then wanted to exercise my right to modify the LGPLed code, how would I do that?

It's your problem, really.

And how is this any different to plain old GPL?

That part is easy: any application distributed from Appstore includes proprietary Apple's DRM components - and thus such distribution is incompatible with GPL2 (but obviously compatible with LGPL2.1). Note that there are some Android devices which are Apple-style locked down and will only accept applications from one fixed source. That's fine: as long as application itself is not copy-protected GPL is not violated.

LGPL and app store

Posted Nov 23, 2012 8:28 UTC (Fri) by epa (subscriber, #39769) [Link] (2 responses)

Have a look at section 6 of LGPL 2.1. If you distribute a program that uses the library you must provide a way for the user to relink it with a modified version of the library.

LGPL and app store

Posted Nov 23, 2012 14:54 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

Have you looked on said part?

You must do one of these things:

Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.

If user can somehow install library then it must be used. If user have no means to install the library, then it's user's problem, not a developer's problem. That's why I've said "it's your problem, really": LGPL2.1 does not cover this case at all.

LGPL and app store

Posted Nov 23, 2012 16:15 UTC (Fri) by epa (subscriber, #39769) [Link]

Yup, it says that if the user installs a modified library then it must be used. You can argue that the letter of the licence doesn't exclude technological measures to stop the user from installing a modified library, so you can ship the code on a locked-down device to prevent the user from having freedom to change the library despite what the licence says. This is the problem that newer GPL and LGPL versions address.

However I think the spirit and intent of the licence is that the user has freedom to modify the library (as explained in the LGPL's preamble). This is why I wrote in my original post still violates the spirit of the licence, if perhaps not the letter.

Licensing VLC under LGPL rather than GPL doesn't avoid this problem. You are still going against the intent of the licence by distributing via a locked-down app store. You mentioned linking against Apple's proprietary DRM components, which is more likely to be the reason they did it.

LGPL doesn't help with app stores, anyway.

Posted Nov 22, 2012 19:47 UTC (Thu) by bkuhn (subscriber, #58642) [Link] (6 responses)

I've studied the terms of both Apple's and Google's application store, and neither permits LGPL-covered applications any more easily than GPL-covered ones. I'm left baffled why VLC has done this. I've written more about this issue on my blog.

LGPL doesn't help with app stores, anyway.

Posted Nov 23, 2012 18:38 UTC (Fri) by DonDiego (guest, #24141) [Link] (5 responses)

This was not about app stores, much less Apple ones, why do you and others keep assuming that it was? Note that I'm not pulling this statement out of thin air, I talk to the VLC people regularly.

LGPL doesn't help with app stores, anyway.

Posted Nov 23, 2012 23:17 UTC (Fri) by DonDiego (guest, #24141) [Link]

Note that the iOS / OS X version of VLC is still GPL as it uses components that are still GPL, c.f. what j-b said on his blog.

LGPL doesn't help with app stores, anyway.

Posted Nov 24, 2012 0:25 UTC (Sat) by giraffedata (guest, #1954) [Link] (2 responses)

This was not about app stores, much less Apple ones, why do you and others keep assuming that it was? Note that I'm not pulling this statement out of thin air, I talk to the VLC people regularly.

It sounds like this is a great opportunity for you to say what this undertaking is about. The only example the article came up with of the purposes of the relicensing has to do with an Apple application store, which you have reason to know is false; do you accordingly know what the real reasons are?

LGPL doesn't help with app stores, anyway.

Posted Nov 24, 2012 14:01 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (1 responses)

From the article:

> Other modules, including scripting and visualization, will remain GPL-licensed at least for the time being, because they do not impede the ability of third-party developers to write non-GPL playback applications, which was the leading use-case motivating the change.

LGPL doesn't help with app stores, anyway.

Posted Nov 25, 2012 12:27 UTC (Sun) by DonDiego (guest, #24141) [Link]

There you go. While I have to admit that the blog entries do not prominently talk about the reasons why the relicensing was done, it's not like there is no statement at all in that direction.

Note that the FOSS alternatives to the VLC backend/plumbing code are all LGPL or even more liberally licensed. This reminds me more of the decision to make glibc LGPL rather than GPL - plenty of alternative libc implementations exist. Thus for third-party devs there is no incentive to use the more restrictively licensed library.

LGPL doesn't help with app stores, anyway.

Posted Nov 24, 2012 0:50 UTC (Sat) by apoelstra (subscriber, #75205) [Link]

> This was not about app stores, much less Apple ones, why do you and others keep assuming that it was? Note that I'm not pulling this statement out of thin air, I talk to the VLC people regularly.

It's purely speculation. All the media outlets I've seen have clearly said "we don't know why, but this kinda makes sense, and it hasn't been denied".

Relicensing VLC from GPL to LGPL

Posted Nov 22, 2012 14:12 UTC (Thu) by gerv (guest, #3376) [Link]

As someone who did this for the Mozilla codebase, which involved more people but a shorter timespan, and took significantly longer, I give a round of applause to Jean-Baptiste Kempf for a great effort :-)

Gerv

Relicensing VLC from GPL to LGPL

Posted Nov 22, 2012 15:15 UTC (Thu) by bronson (subscriber, #4806) [Link]

> only the authors of the iOS [& other] modules outright declined to relicense their work.

That's odd... Isn't iOS a big reason the change was made?

Relicensing VLC from GPL to LGPL

Posted Nov 23, 2012 1:11 UTC (Fri) by pabs (subscriber, #43278) [Link] (3 responses)

The reaction from Bradley Kuhn:

http://ebb.org/bkuhn/blog/2012/11/22/vlc-lgpl.html

Relicensing VLC from GPL to LGPL

Posted Nov 23, 2012 13:38 UTC (Fri) by njwhite (subscriber, #51848) [Link] (2 responses)

I agree with Bradley. I remain completely baffled as to why this was done. More weird still is that nobody in the VLC project seems to be publically stating why.

Relicensing VLC from GPL to LGPL

Posted Nov 29, 2012 12:05 UTC (Thu) by jospoortvliet (guest, #33164) [Link] (1 responses)

If you had read the comments above you would have known Bradly was barking up the wrong tree. At least, attempting to debunk an argument which wasn't important in the first place.

Relicensing VLC from GPL to LGPL

Posted Nov 29, 2012 13:44 UTC (Thu) by njwhite (subscriber, #51848) [Link]

Yes, you are right, though I don't think the above comments you're referring to had been written when I wrote mine.

I do think that the reasons for the change weren't communicated very well at all, though, hence why Bradley and others (including myself) were unclear on the issues.

Relicensing VLC from GPL to LGPL

Posted Nov 26, 2012 19:25 UTC (Mon) by tstover (guest, #56283) [Link] (2 responses)

If this doesn't have anything to do with iOS and friends, then why not go ahead and change to LGPLv3? Why do some people still perceive v3 as bad and v2 good? V3 really does improve all sorts of things.

Relicensing VLC from GPL to LGPL

Posted Nov 26, 2012 19:48 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

I thought GPLv2 code couldn't link to LGPLv3 code. Maybe there was some other GPL version incompatibility that I'm mixing it up with? If promoting usage of VLC as a backend of third party code is the goal, LGPLv2 would open it up for more (existing) applications.

Relicensing VLC from GPL to LGPL

Posted Nov 26, 2012 20:31 UTC (Mon) by DonDiego (guest, #24141) [Link]

There is a VideoLAN press release about why they staid with GPLv2 when v3 came out. I would say that it is safe to assume that the same reasons apply for going LGPL v2.1+ instead of v3.


Copyright © 2012, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds