Keyword - LGPL

Entries feed - Comments feed

10 March 2014

First achievement unlocked!

Oh boy, this has been a long and bumpy ride!

Today, the first Beta of VLC for WinRT is getting deployed on the store.

As many of you know, the road to come to this point has been long... Very long.

I've been driving or helping some ports of VLC on mobile, but this port has been the hardest, by an order of magnitude.

I'll speak a bit more about the lateness of this port, another time. Today, I'll introduce a bit to this application.

Continue reading...

24 June 2013

VLC for Android and LGPL

This is just a very short post (almost a bookmark-post) to share that we finished the releasing of the VLC engine on Android to LGPL.

This is now live in the release that was done today, named 0.1.2.

It mostly includes:

  • the Java code in the org.videolan.libvlc namespace,
  • the jni code gluing between libVLC and the Java code.

The corresponding commits are here and there.

This should allow to use the VLC engine in any other application on Android.

But be warned: so far, it is very difficult to build :)

20 November 2012

How to properly(?) relicense a large open source project - part 3

Relicensing VLC to LGPL

As you might know, or might have read, I have spent a lot of my time to relicense libVLC, aka VLC engine, from GPL to LGPL.

This is a continuation of the LGPL posts, please read the previous posts, if you have not done it already.

Here is the last part, that should answer a few questions I've had.

Part 3: numbers and Q/A

How many lines of code were relicensed?

I have not done the total count, but the LGPL modules are now around 230,000 lines of code.

The GPL modules are now around 150,000 lines of code.

Does this mean the VLC will come back on the iOS store?

Well, the honest answer is still maybe. I do not have a crystal ball.

First, I have no checked the compatibility between the AppStore and the LGPL, and then, as far as I know, MobileVLCKit, MediaLibraryKit and the VLC audio and video outputs for iOS are still totally GPL.

And, as far as I know the legality of the AppStore terms and the GPL is still shady.

Did you have to contact companies?

Yes. There was a limited number of people who used their corporate email and therefore, we needed the check from their hierarchy. I can think about SFR, Viotech, BBC, M2X, Jutel and Actech, but their might have been more.

When working for companies, it is probable that you handed over our patrimonial rights to the company. Therefore, we needed to get the OK. Since this is more a singularity than the norm, this went quite smoothly, in all cases.

Are you crazy?

Probably, yes. Why?

Did you have some difficulties to convince some people?

Well, yes. Some people, notably very old contributors, wanted more details and information with the change. But a couple of mail or a call were enough to explain everything.

Do you think the GPL is a bad license?

No, the GPL is a great license, but it is not the magic silver bullet that works all the time. Moreover, times have changed, and a lot of companies know that contributing back is more cost-effective than forking a project, licensed under a more liberal license.

Did you learn stuff doing this?

A lot. Legally, mostly, but also socially and about our community.

What about other modules?

The main question is about the streaming modules. So far, I don't know. It might come, or might not. This will depend a bit of the first reactions on the current relicensing.

Are you available for hire?

Yes :)

What if you did a mistake?

Well, I am quite sure I did not. I've spent a lot of time to make stuff correctly, and it was long and boring.

Yet, in the unlikely eventuality I did a mistake, here are the failsafes:

  • I am quite sure of the support of the top 32 (2⁵) contributors of VLC, which account for more than 47200 commits which represent over 91% of all VLC commits,
  • I have received 230 people agreements, which is a large chunk of coders contributors on VLC, probably more than the half,
  • The code from people not responding was not relicensed,
  • The process was correctly done and validated,
  • VideoLAN and ECP support the change,
  • VLC would very likely be considered as an Œuvre collective under the direction of VideoLAN by legal ruling in France. I will detail this point in the next part,
  • Unknown contributors that we haven't heard back from will probably be considered as missing, in a similar case than the case of an œuvre orpheline.

Therefore, I don't think I did a mistake, and if I did a mistake, I think it will be only on a very limited piece of code (easy rewritable), and I think VideoLAN and VLC authors would be allowed to relicense it anyway.

French Authorship law and community projects

NOTA BENE: if you are an idealist developer, you are forbidden to read the following because you will not like it.

There are 3 main cases for intellectual works done by a group of authors: l'œuvre composite, l'œuvre collaborative and l'œuvre collective. Of course, those concepts apply very badly for software.

  • The composite work is clearly not in the scope of VLC, because the GPL takes care of that.
  • The collaborative work implies that we only deal with physical entities, which is not true; and that the software is finished, in order to be divulgué, which is clearly not the case for VLC.
  • The collective work implies that some entity is in charge of publication, which is more or less true, seeing that VIA and VideoLAN have done that so far; but it implies that each contribution cannot be traced back to a single author, which is also not true.

We are in a mix here, because no situation perfectly fit. Seeing the jurisprudence of the last 30 years on this, we would probably be considered to be in the last case by a judge.

Seeing that the very large majority of contributors have agreed, that we have contacted all the contributors (and I have proofs of that), that VideoLAN is doing the coordination, that we are not denaturing the spirit of the final work, a French judge would very likely consider that VideoLAN and the main VLC authors have the rights to relicense the last pieces anyway.

This was confirmed by a few lawyer friends of mine.

Do I like this situation?

Not really, but dura lex sed lex.

And it probably saves us from overzealot annoying people.

Yet, I don't think I did a mistake.

14 November 2012

I did it!

Hello HN: you should really read part 1, part 2 and part 3 about this change.

This afternoon, I finished the relicensing of most of the code of VLC to LGPL, like promised:

VLC modules LGPL commit.

F*ck Yeah

You should read my posts on this subject.

Thanks to all VLC contributors, especially the important ones!

Last year, I also did the VLC core LGPL commit.

8 November 2012

How to properly(?) relicense a large open source project - part 2

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.

This is a continuation of the LGPL posts, please read the previous post, if you have not done it already.

So, I had a list of contributors on the parts I was considering to relicense, thanks to the previous work.

Cleaning the contributors list

This huge list was dumped in a spreadsheet, using LibreOffice. I used during all the relicensing with crazy big formulas to keep my status up-to-date.

While I thought curating the list was useless, it revealed very important, since some developers use pseudonyms or change e-mail addresses. I thought my list was already unique in the past, but it was not.

Of course, a lot of emails were invalid, so manual corrections where necessary.

Splitting the list

During the core relicensing of VLC, an important number of users allowed us to relicense all the VLC code, so I had to mark them as such in the spreadsheet.

For each group of modules, I had a different blame log, since the complete relicensing seemed too big a task, and logical groups could be relicensed individually.

Then, with an export of the csv, the raw blame.log, a bit of awk, grep, cut, I had a list of people remaining to mail. This list would get update, after every batch of answers.


The next step is the obvious one, mailing the developers. I did that with a small Python script made by Ludovic.

This was a short letter, with explanations and a prototype for an answer.

I have mailed no more than 30 contributors in a single batch, because processing the answers (or lack of) could be quite long.

Answers and reactions

In average, the answers were like this:

  • 25% of the emails just bounce,
  • 15% of people answer positively during the next hours,
  • 10% of people answer positively during the next days,
  • 50% do not answer at all.

After a second and a third mail, I usually got around 50% of positive answers.

A few points are interesting:

  • People answering fast were usually the ones that were GPG-signing their mails (this was asked in the LGPL letter).
  • Quite a few people were surprised that I would mail them ("I only wrote one small commit", "This was minor code").
  • Many people explained me they did not care what license the code was under, as long as it was open source. Some of them gave a full VLC relicensing authorization. Two even gave all the transmittable rights to VideoLAN.
  • A few people thanked me for taking the task of relicensing.

Finding and stalking

Now is probably the harder part, where you will think I am crazy.

So, after the first part, we get usually half of the answers. We need the other half.

For the bouncing emails, finding quickly an updated email online, fixing the videolan aliases solved many issues.

But for the rest...

Techniques for stalking

The first ones are obvious:

  • Ask older contributors, especially for people from Ecole Centrale Paris for contact
  • Use google (most of the time, it gives a link to VLC, though)
  • Look on freecode, github, gitorious for an alternative contact
  • Find a website (they are geeks!).

Some are a bit intrusive

  • Use LinkedIn and ask for an introduction
  • Friend them on Facebook
  • Create an account on another weird social network
  • Ask one of their friends and annoy them
  • Ask their boss.

Or clearly bad:

  • Find their phone in a Phone Directory
  • Use whois on some of their domain
  • Use whois on a domain hosted on the same machine of their domain
  • Go to their workplace.


Then, I used IRC, mails on multiple addresses, phones, fax and other means to get them to mail me.

Over, over, over and over, and over.

This could get really annoying to do, to be honest.

Getting rid of people

At some point, you realize that some of the contributors are not going to answer.

So, now, you need to actually analyze their code contributions and starting working on it.

First, is there code still in place and not deleted? Is the license LGPL, by any chance?

Then, is this module very important? Can we drop its priority?

Then, is this feature important or not?

And then, I deleted some code, reverted some commits, rewrote some and or isolated code from them in a separate files to reduce the future impact.

This is not nice? Well, not answering is not nice either.

Follow up

You can read the last part about this relicensing.

7 November 2012

How to properly(?) relicense a large open source project - part 1

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.


To get a proper listing of contributors, I used 3 things:

  1. git blame
  2. git log
  3. grep, awk

on our vlc git repository.


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.


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.


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.


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.

- page 1 of 2