VLC Core is LGPL

Because while every piece of free software is a wound against proprietary software, the more liberal licences like LGPL and the BSD/MIT-style licences are a wound against free software: proprietary interests can take free code without giving anything back.

anthonyb• 14 years ago

This is modules, not core. Core was last year: http://git.videolan.org/?p=vlc.git;a=commit;h=36ab287e77e9df...

codebeaker• 14 years ago

Congratulations to Jean-Baptiste, that's been an incredible arduous piece of work for him.

jbk31• 14 years ago

Thanks a lot :)

josephlord• 14 years ago

The really interesting story is the how(linked from main article):

Part 2 (probably the more interesting): http://www.jbkempf.com/blog/post/2012/How-to-properly-relice...

Part 1: http://www.jbkempf.com/blog/post/2012/How-to-properly-relice...

jbk31• 14 years ago

Part 3 is coming soon, about FAQ and numbers, but part2 is probably the most interesting one, indeed.

Hupo6• 14 years ago

Good for them, I guess. Though VLC's popularity still makes me pretty sad and how better video players like MPC-HC (on Windows) and mplayer/mplayer2 (on everything else) are much more unknown in comparison. I mean, most of VLC's development outside of the streaming stuff has been about playing catch-up with these two for years.

But well, the unfortunate truth is that many people are bad at computers and if they manage to mess their system playback up, VLC can certainly feel like a "rescue" with its stand-alone nature. But well, I doubt most people care about high-quality media files to begin with, and VLC sure plays those 700MB XviD AVIs and so on just fine...

Nursie6• 14 years ago

VLC has been able to handle pretty much anything you throw at it for many years and always been available across diverse platforms. It's an awesome product.

Why so negative?

Hupo6• 14 years ago

Because better and equally free and open source alternatives have existed for about as long yet remain more unknown. VLC sure plays a lot of things, but it's a a real jack of all trades and master of none.

I certainly understand it's appeal, but there's certainly better yet equally simple solutions out there as well (eg. CCCP for Windows, various MPlayer2 bundles for OS X like MPlayer.app). Of course, the "downside" of DirectShow-based playback solutions on Windows is that if a user has managed to fuck up their DirectShow beyond recognition, it's going to need a lot of unfucking before you can do anything about it, whereas VLC in its stand-alone nature can play stuff even in a situation like this. Though you could also always get a SMPlayer2 & mplayer2 bundle in such a situation too...

kimmel• 14 years ago

VLC has always lagged behind in proper x264 decoding. For most of the 1.x and the first few versions of the 2.x series I had dozens of video files with visual artifacts whilst the newest versions of mplayer at the time did not.

I maintain this kind of test suite since I do video production using open source software and I have to make sure it works in all the major video players.

VLC is useful and important but it is no where near perfect.

jbk31• 14 years ago

The main reason, is that VLC is too mainstream...

For people who want to spend hours to configure their system, MPC-HC with madVR can give better upscaling and foobar gives better audio fidelity. Most of the rest is usual rants from issues that VLC had in the past, but that 1337 video people like to bring up to explain how their setup is soooo much better.

bjustin• 14 years ago

MPC-HC is a good player on Windows, but VLC 2.0.x has been better in my experience. MPC-HC cannot handle some files that VLC plays fine, and I have not noticed any video quality difference between the two. I have stuck with CCCP for MPC-HC, which requires putting a bit more time into MPC-HC than just downloading VLC.

There are some files that MPC-HC does play that VLC does not, but these are fewer in my experience than the reverse case.

jbk31• 14 years ago

If you could send us the files, that would be very welcome :)

Nursie6• 14 years ago

On a reading of how it was done, I guess if anyone had contributed stuff under the GPL and particularly objected to LGPL relicensing the could probably still make arguments about derivative works...

Interestingly there's no mention of dissenting opinions from anywhere. Not that I'm implying that this move is a bad thing, I would just expect if you ask a large enough group of developers any question about licensing you would get a variety of arguments cropping up.

pm215• 14 years ago

The commit message includes in its list of modules which are not converted:

- iOS audio output and video display, because author refuses the license change

- Mono, Headphone and Dolby, because author refuses the license change

So there is some dissenting opinion.

jbk31• 14 years ago

2 authors out of 230 is not that much... And for example, the author of headphone objected only on Headphone and Dolby, but allowed the rest of his code to be changed.

Florin_Andrei• 14 years ago

Rip out that stuff, replace it anew.

jbk31• 14 years ago

> On a reading of how it was done, I guess if anyone had contributed stuff under the GPL and particularly objected to LGPL relicensing the could probably still make arguments about derivative works... Read part 1 and 3

> Interestingly there's no mention of dissenting opinions from anywhere. Not that I'm implying that this move is a bad thing, I would just expect if you ask a large enough group of developers any question about licensing you would get a variety of arguments cropping up.

Because the vast majority of VLC developers want their code to be used, not fight over licenses.

Nursie6• 14 years ago

> Read part 1 and 3

I have read part 1, didn't know there was a part 3.

I'm just saying that imagine (in a hypothetical situation) there is a large code module written by an original author under the GPL. Over time it is worked on and line by line it is eventually fully replaced with new code by 5 other people.

Even if you get the 5 to agree to a license change, the original 1 would still have an argument that it was all derived from his original work and should remain under GPL.

I have no idea if this situation applies to you, it was just an idle thought.

rangibaby• 14 years ago

Does this mean VLC will be back on the App Store? I remember it being pulled due to a contributor (who around ~2010 worked for Nokia) complaining to Apple.

jbk31• 14 years ago

Possibly, yes. But so far, iOS aout and vout are not LGPL.

stcredzero3• 14 years ago

You're saying that iOS about and bout must be LGPL first before there can be a VLC app in the iOS App Store? That goes against my idea of the point of LGPL, but I could well be wrong. I thought I could interface non-LGPL code with it.

comice2• 14 years ago

So every contributor essentially gets to vote on the license change, and their vote is proportional to the contribution they made (because if they vote no, their contributed code has to be rewritten).

I think I quite like it, but only because there is an option to replace their code if they vote no (which admittedly may be very technically difficult). No single contributor can truly veto the license change.

Clearly has it's downsides though.

jbk31• 14 years ago

I did delete some code, and rewrote some. But not for many people.

comice2• 14 years ago

Was there any single person with enough of a contribution that if they'd said no, you'd have abandoned the idea of a license change?

keeperofdakeys• 14 years ago

Imagine trying to do this for something like the linux kernel, it would be nearly impossible.

jbk31• 14 years ago

This is my website :) (I did not expect that to come on HN, to be honest)

Anyway, the title is, of course, misleading. VLC core, named libVLCcore is LGPL since last year (I did it too in december) and the wrapper for 3rd party applications libVLC was relicensed too at the same time.

This is different, since most modules of VLC are now LGPL. We speak about codecs, demuxers, format parsers, protocol accesses, filter and outputs. And those modules are way more important in terms of contributors and lines of code than the VLC core. In fact, we speak here of 230 people with around 300,000 lines of code, compared to 80 people and 80,000 lines of code for the VLC core.

Of course, from a higher-level point of view, all those playback modules are part of the "core of VLC" :)

pretoriusB8• 14 years ago

How does that play with the iOS VLC port?

The one that a VLC contributor working for Nokia (Rémi Denis-Courmont) managed to take down, for not being in compliance with GPL?

jbk31• 14 years ago

Rémi Denis-Courmont is the biggest contributor of VLC, so far, and he pushed forward the LGPL move... :)

belorn8• 14 years ago

Could you explain in a bit more details why you did this move from GPL to LGPL? The blog post did not want to expand on this, and I for one would very much like to hear, from your view, what benefits the project might get from this move.

Preferable in practical terms, as "more professional developers around VLC" sound a bit vague and, if that is really the stated goal, will you follow up on this with statistics to show if the license is drawing more professional developers to the project?

jbk31• 14 years ago

We are not able to enforce the GPL anyway, so let's help companies use VLC and contribute back, so this benefits all users.

Competition.

AppStores and other crap of the post-PC era. :)

ChuckMcM• 14 years ago

Very nice, so will we see a new VLC app for iOS? I've been carefully syncing and copying my copy to insure it stays on my iPad.

beagle33• 14 years ago

Wait, doesn't the LGPL require users to be able to substitute their own compiled version?

How does the LGPL relicense solve the Apple AppStore problem everyone is talking about? Apple may approve LGPLd code, but as far as I can tell, they still do not comply with it under their current distribution system.

edit: wrote iOS instead of LGPL in the first line, thanks simonh

simonh• 14 years ago

I think you mean LGPL where you say iOS in the first sentence.

I can't answer your question, but just point out that huge chunks of iOS itself are LGPL already, such as webkit, and the LGPL version of ffmpeg is already widely used.

There has been some speculation in the past that because iOS mandates static linking that this is a problem for using LGPL libraries, but I fall into the 'linking creates a compilation, not a derived work' camp and if the compilation interpretation is correct then static linking isn't a problem.

But every time I dig into LGPL interpretation and linking issues, eventually my head starts hurting and I give up.

DannyBee3• 14 years ago

1. Apple distributes source to the LGPL pieces, so that is not an issue for them.

2. The rest of what you said doesn't make much sense to me. I'm not clear on what distinction you are trying to make.

There are those that believe that the question of linking is mostly irrelevant to whether something is a derivative work. Lawrence Rosen is the canonical example of folks in this camp. But even in that camp, static linking may be a problem, it just depends on what is being done.

So it's not really true that "static linking isn't a problem".

beagle33• 14 years ago

Well, stop reading the LGPL interpretation, and start reading the LGPL itself - it is written in English (rather than legalese) and is very clear on most subjects.

Specifically, it cares that the end user can "swap out" the LGPLd code for their modified version, which is not available in the iOS AppStore regardless of compilation vs. derived work interpretation (a distinction without difference if I understand it correctly).

DannyBee3• 14 years ago

LGPL (let's stick with version 2.1 for now) gives you a set of options for a "work that uses the library".

Those options are:

1. Give out source to the library, and either source or object code to the work that uses the library (so that the work can be relinked)

2. Use shared linking and build the work into a .so that would work if the user replaced it (There is a point of contention in LGPL 2.1 as to whether you need to make it possible for the user to replace the .so. It's clear what the spirit is, but the actual wording does not require it)

3. Include a written offer for the stuff in #1.

4. Offer source from #1 through the same place that offers binaries.

5. Verify that the user already has the source, or that you already sent it to the user.

If the app store requires static linking, that rules out #2.

beagle33• 14 years ago

From section 6 of LGPL 2.1: http://www.gnu.org/licenses/lgpl-2.1.html

""" For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. """

I believe this makes #1 insufficient, (and by reference, #3, #4, #5) - as that requires apple to also distribute the material needed to sign the executable for your specific phone (as an end user) if they give you the executable signed for your specific phone.

Do you have reason to believe otherwise?

chj• 14 years ago

Every time a GPL related post comes up, it always reminds me of the sqlite project, and how the world could be simpler without those weird licenses.

http://www.sqlite.org/copyright.html

Nursie6• 14 years ago

That's all well and good, but the GPL is set up to address problems that the authors saw, that public domain licensing does not - mainly that they thought users should have the right to obtain the source to the stuff running on their machines.

Others like it because it's a way of saying 'you can use this stuff I've put a lot of effort into, but only if we get to see the enhancements you make'.

I know that neither of these things is a priority for some developers, who prefer things to be used as widely as possible and as unrestricted as possible, but that's not for everyone.

bad_user• 14 years ago

In general you cannot place your work under public domain because in many countries (including in the U.S. with some exceptions) the work must enter the public domain by itself after the copyrights expired. The copyright term also differs of course from country to country. Even worse, there are jurisdictions in which the public domain is not recognized.

koko775• 14 years ago

Did you even read the link?

> Even though SQLite is in the public domain and does not require a license, some users want to obtain a license anyway. Some reasons for obtaining a license include:

> * You are using SQLite in a jurisdiction that does not recognize the public domain.

> * You are using SQLite in a jurisdiction that does not recognize the right of an author to dedicate their work to the public domain.

> * You want to hold a tangible legal document as evidence that you have the legal right to use and distribute SQLite.

> * Your legal department tells you that you have to purchase a license.

> If you feel like you really have to purchase a license for SQLite, Hwaci, the company that employs the architect and principal developers of SQLite, will sell you one.

sanxiyn2• 14 years ago

See also this post on Mozilla relicensing:

http://blog.gerv.net/2006/03/relicensing_complete/

sanxiyn2• 14 years ago

Sun RPC should be mentioned here.

The long, sordid tale of Sun RPC, abbreviated somewhat, to protect the guily and the irresponsible http://spot.livejournal.com/315383.html

GNU/Linux - finally it's Free software http://webmink.com/2010/08/30/gnulinux-finally-its-free-soft...

The Saga of Sun RPC http://ebb.org/bkuhn/blog/2010/08/27/sun-rpc.html

crististm2• 14 years ago

Lots of efforts that otherwise could have been used on something more productive.

GPL was just fine. No VLC on AppStore - I could live without. Hey, I can live without Apple too but this is not about me.

bcantrill• 14 years ago

Congratulations to JB and team on completing this Herculean task! I had the pleasure of meeting JB when he and I shared a ride from the airport in Porto Alegre for this year's FISL.[1] When he asked me what I was going to be presenting on, I (not yet knowing anything about JB's work) had some trepidation in responding: my presentation was on corporate open source anti-patterns[2] -- and one of my conclusions was that the GPL has essentially outlived its usefulness. Fearing that this was a very controversial conclusion, I approached it gingerly in my conversation with JB; needless to say I was very relieved to learn that he and the VLC team had come to broadly similar conclusions -- and surprised that they felt so strongly that they had taken on the arduous task of relicensing. Congratulations again to JB and team; I'm sure that they join the ranks of us who never want to engage in a(nother) licensing discussion as long as we live!

[1] http://dtrace.org/blogs/bmc/2012/08/01/post-revolutionary-op...

[2] http://smartos.org/2012/07/27/corporate-open-source-anti-pat...

jbk31• 14 years ago

Thanks :)

georgeorwell• 14 years ago

From your second link, why do you think the licenses of DTrace and ZFS have limited their Linux popularity? Aren't their licenses compatible with (read: convertible to) the GPL?

throwaway54-762• 14 years ago

At least with ZFS, no:

"Porting ZFS to Linux is complicated by the fact that the GNU General Public License, which governs the Linux kernel, is incompatible with the Sun CDDL under which ZFS is distributed."[0]

See also this reasoning from the native ZFS linux kernel module port:

"In a nutshell, the issue is that the Linux kernel which is licensed under the GNU General Public License is incompatible with ZFS which is licensed under the Sun CDDL. While both the GPL and CDDL are open source licenses their terms are such that it is impossible to simultaneously satisfy both licenses. This means that a single derived work of the Linux kernel and ZFS cannot be legally distributed."[1]

[0] https://en.wikipedia.org/wiki/ZFS#Linux

[1] http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue

VLC Core is LGPL

Related Stories