

Parts of VLC are now re-licensed under the LGPL - etix
https://plus.google.com/u/0/b/104597325891170264649/104597325891170264649/posts/fhYhcagWBp6

======
hartror
Fantastic, in a recent review of media libraries I did libvlc looked very
attractive. However the lack of LGPL prevented its inclusion in the final
selection which was a shame.

Now of course we are 6 weeks down the track with a different library but we're
a while off feature complete and if libvlc can do everything we need . . .

Decisions decisions.

~~~
jbk
And cases like this one are exactly the motivation of the change.

Contact me, if you want.

~~~
hartror
Thanks!

------
albertzeyer
Some more interesting information:

<http://www.videolan.org/press/lgpl.html>

 _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._

Maybe another motivation was the licensing problem with the Apple App Store.
This should be resolved with LGPL. ([http://www.zdnet.com/blog/open-source/no-
gpl-apps-for-apples...](http://www.zdnet.com/blog/open-source/no-gpl-apps-for-
apples-app-store/8046))

~~~
jbk
Apple Store was not the motivation: it requires the change of license of way
more code than just libVLC, notably most of the decoders and demuxers modules,
and this is not yet done.

Having more people using libVLC is important for us, though...

~~~
forrestthewoods
Is it possible to use LGPL on iOS to begin with? I've seen _lots_ of debate on
the subject but never a concrete answer. The requirement for users to be able
to update to a newer version of the library has been the sticking point. I've
sent a few e-mails to the FSF asking for clarification but have not gotten an
answer. :(

~~~
jbk
First, the problem is not iOS, but the AppStore.

GPL and LGPL are totally fine with iOS.

About the AppStore, the issue is mainly that it does not allow shared-objects,
as far as I know, and makes it hard to replace parts of the code. However,
IIRC, AppStore allows Frameworks. So, if a Framework is LGPL, and therefore
weakly- linked, it might be just fine.

But, yes, it is normal that the FSF does not answer, since this is a complex
issue.

~~~
zbowling
This isn't really correct.

When you say AppStore you have to make a distinction between Mac and iOS.

As a platform, iOS doesn't allow you to bundle any dynamically linked
libraries with your application (so everything everyone ships on iOS is
statically linked). You can dynamically link system libraries though. Since
they don't allow you to download and execute any code not shipped with the
app, this hasn't been a big issue (except with trying to use LGPL code and to
port apps that are already configured around dynamic loading or use different
processes to isolate functionality).

Now Mac apps fully allow dynamically linked libraries bundled with your app
(even with sandboxing enabled). There are fewer restrictions on the Mac
AppStore in this respect. Like for example, plugins are fully allowed and
supported. Code added to the app after the fact is fine (as long as the
advertised core in the app store is there without downloading additional
code). On this, working with LGPL restrictions are little more plausible.

A framework is basically a bundle of dynamic libraries and headers in a
package. Frameworks for that reason are no different than dynamic libraries,
so your usage of the term here and false distinction from "shared-objects" is
incorrect here.

LGPL requires that you allow the user to be able replace the LGPL library out
completely and that you release the source to the library if you, the user,
who I distributed a binary copy from, requests it. This is just not possible
on iOS with static linking of course, but it is possible on Mac OSX.

The bigger issue is that Apple is the "distributor" of the app and not the
developer that gave the copy to Apple. If I wanted to request LGPL code, I
would have to contact Apple because I obtained the application from them not
the developer that gave them a copy. Apple doesn't have a facility for this.

~~~
gillianseed
Well, unless there's been changes made to the LGPL'd code then the App using
it could simply point to VLC's webpage for the source code. LGPL only requires
changes made to the actual LGPL licenced code be made open source, unlike GPL
which requires the entire application using/linking GPL licenced code to be
open sourced under GPL.

The reason why Apple AppStore and GPL don't mix is that Apple added a
restriction as to how many times you could copy the binary while GPL
explicitly states that you are allowed to make as many copies as you want.

------
JoshTriplett
The article fails to mention why this change happened, and what motivated it.

~~~
keeperofdakeys
Presumably because developers wanted, or VLC wanted developers to be able to
use libvlc and libvlccore in their programs without being forced to use the
GPL.

------
ldesegur
VLC is the biggest POS I have ever installed on my Mac (as far as I can
remember.) Who cares about licensing and streaming when the app is not even
able to keep with video playback on latest hardware. What a joke! Hideous UI,
buried options (try removing color or reizing subtitles), even worse: skipping
frames while zero tasks running on latest i7 with 8GB RAM and 7.2K HD (I've
checked with top) !!! What a crap. So I said: VLC, go away! I switched to
MPlayer and all of those issues went away from that very moment. Good
riddance.

~~~
Maxious
The problem with VLC on OSX is nobody wants to be the maintainer.

~~~
ldesegur
I browsed the net so much trying to fix these problems and never heard about
this situation with Mac OS X. You got people out there who probably could
contribute if they knew. Are you sure about this? The Mac OS X port is so bad,
I would encourage VLC to scrap it until they can fix it, instead of giving
false hopes to users.

~~~
csytan
Different people different experiences. I'm happily using VLC on my Macbook
air, and it is pretty close to perfect for me.

