Another Licensing question

[rbatemanmi]

I've read with interest a couple of queries here about licensing VLC for use by various projects.

Like others, I too would like to use VLC in a project. However, I am unable to do so because parts of my system (in this case Libraries) are not under my control. I am wondering if the folks at VideoLan.org would consider changing the license the libraries only are licensed under?

Using the pure GPL v2 (and above) limits linking. If you were to relicense the libraries only under the LGPL, I could link to your libraries and use your wonderful tool. Heck, I'd be willing to bet many others would do the same. More users means more developers and more capabilities for VLC. There isn't much of a loss to you or the VLC project.

Of course, you could say that I should use the ActiveX module on Windows. My only concern with that option is I want to be cross platform compliant. And in my case, if I can reduce the amount of work a user has to go through to use my program, the better life is for me. Installing VLC is more complicated than linking to a library.

Thanks much for your time!

Bob

[Jean-Baptiste Kempf]

Relicensing VLC under LGPL is impossible since it would need all the authors to agree to switch to it, which is unlikely.

Sorry.

[sfed]

A further related question: I see that Chris Meadowcroft has published a C# library with bindings / loading of libvlc.dll using the LGPL license, which would allow proprietary applications to link to VLC indirectly under the LGPL license as long as (if) any changes to the C# bindings library are published as source. This code is also used in the french freebrowser source code, and possibly other places. I have seen some of this code published also on the VLC wiki as example of binding to the dll library with C#. It this technically legal to publish this code under LGPL and use it to interface with VLC dll library to a proprietary app? Or would the only interface for use to C# be the ActiveX interface. If extensions to existing functionality were desired (the current ActiveX control only has limited callback functionality, for example), the other possibility would be for the company to make necessary extensions/changes (if any) to the ActiveX and/or VLC code required for functionality and publish source with the modified VLC distribution, correct. I am glad to hear that use of ActiveX interfaces is not considered to fall under GPL, as those interfaces are public interfaces and would fall under use of the product as published, allowing for replacement/recompilation of the product as desired by the end user. For clarification, what is the VLC team stance on the use of the published C# library bindings and their LGPL status? Thanks.

[Jean-Baptiste Kempf]

No, if you build an application on this library you have to be GPL or GPL compatible.

The library can be LGPL, but the whole program has to be licensed under the GPL.

[sfed]

Sorry if the following runs on...please bear with me.

I was not talking about building an application on VLC, but merely using VLC to playback video from another application. That could be accomplished, for example, by calling it indirectly from a command shell - that does not bring the calling program (the shell in that case) under the GPL? Your prior statements lead me to believe that VideoLan does not consider use of the ActiveX bindings provided to infringe on the GPL?

The C# bindings distributed on the VideoLan site are not usable as LGPL even though they state LGPL in the license? LGPL allows an application to bind to a library dynamically to use the published interfaces as presented and not bring the accessing application under the license. Since the only purpose of the bindings is to access VLC dynamically through it's dll library, how can the C# bindings be considered LGPL under your interpretation? I am not talking about statically linking anything to VLC, but only dynamically accessing the C# bindings as a separate DLL which would be allowable under LGPL. The C# bindings I mentioned are also not statically linking to VLC, but accessing the library dynamically using public interfaces as well.

I believe that you stated elsewhere (quoted below) that proprietary applications could play video using VLC through the ActiveX interface? ActiveX can be interfaced to C# as well - how is that any different? The aim as I understand it is to allow anyone using the -proprietary- software which performs its own functions to replace or update the GPL/LGPL portion of the code and have full access to that source for their own purposes. Obviously any changes to the VLC source itself would have to also be GPL and made available to anyone receiving the distribution according to the license, and the GPL terms have to be followed regarding disclosure of the GPL software/source availability.

Can you clarify the below statement as to what interfaces a proprietary application can use with VLC to play video on Win32 and Linux/etc. and not run afoul of the GPL. Also, if the C# bindings when used dynamically (as an independent library) are not, in fact, usable as LGPL then the license should be changed to indicate that.

The following is a quote from your (jbk) blog from September - is this not accurate? If so, then a company could also extend the vlc functionality by making changes to VLC and the ActiveX and publishing the sources and only use the published ActiveX interfaces to talk to the proprietary application:

"
Licence and proprietary application.

Ok, this part can be trickier.

If you are using a GPL-compatible License, then everything is ok for you...

If you want to build a proprietary application, then it is a bit more complicated, but not that much.

If you build an application that needs any VLC source files (headers especially), then you herit from VLC source code and your application needs to be GPL'ed. Therefore you have to use some bindings.

In fact, you can build a proprietary application that "talks" to VLC using some bindings, like ActiveX or D-Bus. If you don't need VLC internals, that is fine. In fact, in a perfect and theorical world, you could rebuild an application that would understand the same commands as VLC and that would behave in a similar way. You will be then able to switch the applications (VLC and the similar one) but still have your main program working.

So you can build a proprietary application that uses standard communication to use VLC (D-Bus and ActiveX are ok, C/C++/C# natives interface are not ok). However, you still need to respect the GPL and copyrights law, which basically mean you must show the GPL License at installing, you have to mention the VideoLAN Team and clearly states that VLC is not your copyright.

Don't take my wrong, I don't like proprietary stuffs build on VLC, but still, this is doable.

So please stop saying that you can't build an app on VLC media player!

Then profit!
"

[Jean-Baptiste Kempf]

I don't see what is unclear.

the " .Net user control that uses libvlc interface" relies on libvlc and is specific to vlc and therefore is derived work and has to be used through the GPL.

Any bindings on top of ActiveX or any generic interface that doesn't need vlc to be built and then where you can exchange VLC by another program can be whatever you want.

[Jean-Baptiste Kempf]

I was not talking about building an application on VLC, but merely using VLC to playback video from another application. That could be accomplished, for example, by calling it indirectly from a command shell - that does not bring the calling program (the shell in that case) under the GPL? Your prior statements lead me to believe that VideoLan does not consider use of the ActiveX bindings provided to infringe on the GPL?

Of course you can do that.

I believe that you stated elsewhere (quoted below) that proprietary applications could play video using VLC through the ActiveX interface? ActiveX can be interfaced to C# as well - how is that any different?

It is different in the fact that one time it RELIES ON vlc and if you don't have vlc installed, your application crashes and on the other time, you could change VLC by another application that would implement the same ActiveX interface wihtout any change in your program.

Can you clarify the below statement as to what interfaces a proprietary application can use with VLC to play video on Win32 and Linux/etc. and not run afoul of the GPL. Also, if the C# bindings when used dynamically (as an independent library) are not, in fact, usable as LGPL then the license should be changed to indicate that.

ActiveX and D-Bus are generic COM interfaces that let applications speak to one another. Therefore you can use VLC through that from any application because you can exchange your VLC with another application that implements the same interface.

[sfed]

So, since VLC has DBus and ActiveX interface, which is it legal to interface with, if it was wanted to use features of VLC in a commercial application that were not available in the current DBus and ActiveX interfaces, could someone modify the DBus and ActiveX sources and VLC source as necessary to provide the extended interfaces, package the modified release of VLC and label it according to the GPL rules, and publish the source and provide it under GPL licensing rules when that version of VLC is distributed. Then, separately implement that modified ActiveX/DBus interfaces in a proprietary application to use the features of the modified version? That would seem to satisfy the interpretation of GPL by using only interfaces made "public" by the ActiveX or DBus interfaces. Is this correct? Thank you.

[sfed]

By the way, thank you very much for your detailed responses - it goes a long way to help clarify this issue, as the ins and outs of what is ok and what is not in specific applications of the GPL are not usually spelled out very clearly. GPLV2 leaves a lot up to interpretation, fortunately or unfortunately. I hope this dialog will help others looking at the same issues to make decisions as to whether to attempt to contribute to a GPL codebase or go to proprietary or LGPL codebases instead. I am happy that at least use of the VLC ActiveX and DBus interfaces are not being considered as "linking" to the application.

[Jean-Baptiste Kempf]

So, since VLC has DBus and ActiveX interface, which is it legal to interface with, if it was wanted to use features of VLC in a commercial application that were not available in the current DBus and ActiveX interfaces, could someone modify the DBus and ActiveX sources and VLC source as necessary to provide the extended interfaces, package the modified release of VLC and label it according to the GPL rules, and publish the source and provide it under GPL licensing rules when that version of VLC is distributed. Then, separately implement that modified ActiveX/DBus interfaces in a proprietary application to use the features of the modified version? That would seem to satisfy the interpretation of GPL by using only interfaces made "public" by the ActiveX or DBus interfaces. Is this correct? Thank you.

I think it is. But as usual, I am not a lawyer.
Contributing the modifications on ActiveX to the core team would be nice.

[Jean-Baptiste Kempf]

By the way, thank you very much for your detailed responses - it goes a long way to help clarify this issue, as the ins and outs of what is ok and what is not in specific applications of the GPL are not usually spelled out very clearly. GPLV2 leaves a lot up to interpretation, fortunately or unfortunately. I hope this dialog will help others looking at the same issues to make decisions as to whether to attempt to contribute to a GPL codebase or go to proprietary or LGPL codebases instead. I am happy that at least use of the VLC ActiveX and DBus interfaces are not being considered as "linking" to the application.

Here, I disagree with you. I am quite sad the GPLv2 lets people build proprietary applications on top of VLC, but COM is too generic to spread the virality. This is life...

[sfed]

Well the GPL does say that "The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program)." I've always thought that if a program was being launched/used as intended in the documentation, and not hard linked into a piece of software, that should be considered "running" the software, regardless of what action leads to the software performing its function. I don't believe that the other interpretation (that of the FSF regarding dynamic linking) has ever truly been tested in court and am not convinced that dynamic linking to published (publicly documented) interfaces would stand up as bringing software under the GPL at least according to GPLV2. Time will tell.

That being said, I would be happy to contribute back any changes if they would be of value to the project. I am not completely sure how to go about that - submit patches to a specific version and let someone else evaluate whether the patch is worthwhile integrating? It is actually relatively easy (actually easier) to perform the same functionalities I have in mind with other non-GPL native interfaces, and the same ActiveX interface could be used with other technologies. I could (and may) also create the same interfaces for ffmpeg directly which can be LGPL and not have the same issues with dynamic library linking.

I would rather use VLC than DirectShow because I believe that there is more control over how the video is rendered, separate from the interface itself, and also think that VLC can be used successfully on systems with lower hardware requirements. The application I have in mind is not really sold in any quantity, and is not any kind of application like VLC, really just one-off specific-use multimedia projects.

I do believe that there would be a lot more widespread interest in contributing to GPL applications from commercial developers if, as in this conversation, it was made more clear how they can be used and extended to interoperate with other (commercial and other licensed) software legally, creating advantages for commercial developers to extend or add capabilities to the GPL software that would support the use in these applications, especially applications which do not directly compete in the same space. How can a GPL application replace or provide a viable/reasonable alternative to commercial software if the interface is so restrictive as to not allow, for example, use of ActiveX interfaces to interoperate with other software? As I said, I am glad that your interpretation, at least, allows for this.

My potential application of VLC would probably not even be noticed in the scheme of things, however I really would like to be doing the right thing up-front as much as possible, and I think this conversation has helped toward that end. Thanks again for your views.

[Jean-Baptiste Kempf]

My personal views are simple.

I don't see really like business that use our work but usually don't give anything in return...

[sfed]

I appreciate and understand your point of view - I'm not sure how allowing software to use GPL services that are an alternative to commercial software that is available to do the same things (sometimes technically "free" and well-documented as well, although not open-source - i.e. Windows Media Player) - it is any different than allowing companies or individuals to use the software internally to make money (allowed by GPL - look at many commercial websites powered off of GPL software) or people at home using free software in place of software they would otherwise have to purchase and not giving anything back... You are saying on top of VLC, I am just saying that VLC is providing a service - playback of video, generally as a small part of another application. A lot of such applications have no real general interest, other than "how was that done?", as is the case with a lot of the software that I create. Anyway I'm just trying to make a point that allowing some legal interop with proprietary software can create incentives for companies and individuals to contribute where there would otherwise be no reason to do so. It is a fact of pragmatic life that much software cannot be developed completely in GPL code even if that was desired because of patents or licensing of other components that must be used.

[Jean-Baptiste Kempf]

Well, I have the right to disagree, in my personal opinion to that.

You buy WMP when you buy windows. You buy the spyware at the same time, but that is another topic.

VLC isn't just playing videos, it comes with a big integration of codecs, video output and bindings with everything you could want. It even arrives with a way of using it with proprietary software. It is more about having a framework than just playing videos. An application on top of DirectShow just plays video. VLC isn't the same.

Anyway, there is a way to build proprietary applications on VLC, I detailed them and explained it quite clearly to you, doing that on my free time (as all the work we do on VLC)...
But this is my right to not like the way many proprietary applications use VLC without ever contributing back. That's all.

[svlasov]

If you build an application that needs any VLC source files (headers especially), then you herit from VLC source code and your application needs to be GPL'ed. Therefore you have to use some bindings.

Not that I encourage anyone write closed-source software with libvlc, but back in 2003 Richard Stallman stated:

Someone recently made the claim that including a header file always
makes a derivative work.

That's not the FSF's view. Our view is that just using structure
definitions, typedefs, enumeration constants, macros with simple
bodies, etc., is NOT enough to make a derivative work. It would take
a substantial amount of code (coming from inline functions or macros
with substantial bodies) to do that.

[Rémi Denis-Courmont]

The use of GPL headers became a hot topic because of Android's bionic and the Linux kernel.

But this new debate is mostly irrelevant to LibVLC. If you use LibVLC headers, you most probably call LibVLC functions and link the LibVLC run-time library. Then it is a widely held belief that your work is derived work of LibVLC. For the kernel, the situation is different: you cannot "link" the C library with the kernel. The C library simply raises software interrupt 0x80 (or similar mechanism depending on the CPU) to initiate a system call.

In a sense, the system call is just a protocol, whereby the C library is a client implementation, and the kernel a server implementation. And they interoperate. Both of them are derived from the system call protocol, which is not copyrighted. And you can play similar tricks to avoid GPL contamination in LibVLC-based programs. For instance, LibVLC can be used through the (LGPL'd) Phonon framework. VLC can be driven by the MPRIS protocol through D-Bus, sending text commands to the VLC Remote Control interface, or querying the VLC HTTP interface AJAX URLs . You could also define your own protocol for your own use, write your own wrapper around LibVLC that implements that protocol, and then use that protocol in your proprietary software.

Of course, this is ultimately all up for court's interpretation.


In any case, whether it is legal or not, the VLC developers cannot like it. Profiting from the VideoLAN project and their work while not contributing anything, is against the spirit of open-source and the VideoLAN project. Besides, VLC development direly needs more workforce.

[hfsdev]

Jean-Baptiste Kempf said:

ActiveX and D-Bus are generic COM interfaces that let applications speak to one another. Therefore you can use VLC through that from any application because you can exchange your VLC with another application that implements the same interface.

So any proprietary software that uses ONLY the ActiveX control provided with VLC installation doesn't need to be GPL, nor have a GPL compatible license?

I mean, if my software binds to VLC only through the ActiveX control ("axvlc.dll"), I don't need to GPL my software, is that right?

[hfsdev]

I'm very sorry for this unecessary bump on this thread. After some time researching I found this:

http://www.videolan.org/press/lgpl-libvlc.html

Thank you!