GPL violation by ratDVD ?

[multicone]

This is what ChrisHJW wrote on another forums (http://forums.afterdawn.com/thread_view.cfm/215044) :

Hi,

we, the matroska team, have patiently been waiting that the full sourcecode of the menue navigation filter would be released, in order to fulfil the GPL license of the libdvdnav library which has been used for it. We frankly admit that we would like to use the code as an inspiration for our own menue filter, in order to make MKV file playback with menues possible on DirectShow players like WMP.

We understand from looking at oyur code that you have wrapped the libdvdnav lib into a COM object, and that you are linking to it from your navigation filter. However, please allow us to tell you that this is most definitely NOT in compliance with the GPL license of libdvdnav :
http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface
http://www.gnu.org/licenses/gpl-faq.html

Doing what you did is NOT enough to fulfil the GPL license, and we are urging you to release the FULL SOURCECODE of your filter to the OSS world within the next 2 weeks.

matroska is an opensource project itself, and we are releasing all project code under a L-GPL or even BSD license, to allow people to use our format free of cost or obligation. Your strange behaviour about wrapping your filter around a libdvdnav with a COM interface can do nothing else but make us believe you have different intentions with your program than actually serving the users.

Christian
matroska project admin
http://www.matroska.org

[Doom9]

Actually, the matter of COM has come up in the developer forum before: http://forum.doom9.org/showthread.php?t=97210

I cannot claim this is a general consensus, but the way we left that thread seems to hint that COM actually allows you to use GPL code without falling under the linking clause.

I only have VC# installed so I cannot try and compile, but it does appear to me as if the libdvdnav download package on the ratDVD site does contain the whole component so I fail to see the GPL violation.

[[Toff]]

In my opinion, using COM to interface a GPL library with another program still make this program a combined work.
The communication interface is too tightly linked to the GPL library. Which make COM different from using things like pipes with external executable.
I would place a COM wrapper between static linking and dynamic linking on an interfacing point of view. It's even more convenient than using a DLL.

What's also important IMO, is the role taken by the library you are using in your program. If your program can't do his main goal without the GPL library then it's definitely combined works.

The GPL should probably be updated to take care of those grey case, and make them clearer. Otherwise it will definitely become null and void.


So to come back on this particuliar case, the ratDVD directshow filter can't do much without libdvdnav so it's definitely combined works and the source of the whole filter dll should be released.

[Cyberace]

I'm also very disapointed that the haven't released the full source code, however not only for the navigation part but for the codec (encoder/decoder/muxer/demuxer) part.

I very much doubt that ratDVD don't use any code at all from exsiting GPL/LGPL codecs projects, (or even take advantage of the patents/specifications held in copyright by the MPAA for MPEG-2 and MPEG-4, or Dolby for AC3, which could be worse for them legally), but if they don't they don't have to even release the source code of the codecs they have created from scratch, however if they just used a single line of code from a GPL'ed project inside their codec code then they must comply with the GPL license and release the full source code, (or if they used any from a LGPL'ed project they must release any changes of that code) ...they seem to have managed to legally workaround the GPL with libdvdnav and imdbexport by encapsulating the code inside a COM server to dynamicly load these when needed (though I don't see any ratDVD headers for them which they technicaly should have released too), however I don't see how they can ever get around it with the GPL and other licenses and copyrights of existing video and audio codecs without violating those licenses, numerous copyrights and even laws, ...I don't know, maybe they plan to release the full source code soon in which case I pre-apologize now, I hate to sound like a OSD-zealot but I'm really disappointed that they are still holding on to their source code to tight. If they don't plan to make money on it then why don't they just not join the OSD community (example start SourceForge.NET project for it)?

EDIT: btw, I agree with [Toff] that using COM (to get around the PLG) for a function that ratDVD can't do without is a clear GPL violation.

PS! I asked too here (link) (http://club.cdfreaks.com/showthread.php?t=138951) about ratDVD support in MPlayer, VLC and XINE and never got a reply :( ...the problem there is that the filters that the ratDVD developers released is only a (pre-compiled) DirectShow-filter binary, (not the full source code to the codecs nor the muxers/splitters), and VLC, MPlayer, XINE, etc. are not DirectShow-based so do not support DirectShow filters nativly (because DirectShow is Microsoft Windows propriotory). ...so again best would be if the ratDVD developers open sourced their codecs and muxer/splitter so that non-DirectShow players can playback ratDVD.

[multicone]

...so again best would be if the ratDVD developers open sourced their codecs and muxer/splitter so that non-DirectShow players can playback ratDVD.

I take any bet they will never do that because IMO

a. they still believe they can earn money with it, one way or another. Likely by selling licensed code to hardware manufacturers, inspired by the way DivX Networks is doing it.

b. we would find a lot of stolen code from other opensource codec projects. This guy was claiming he wrote the complete app including codec in about 6 months, and alone without any major help. Any XviD or Theora developer will be able to confirm that in 6 months you will NEVER write a codec from scratch, and even one that doesnt rely on existing specs at all ;) ...

[mat]

for dvdnav part, there was a reply of some developper on http://sourceforge.net/mailarchive/forum.php?thread_id=7525493&forum_id=774 .

[Doom9]

What's also important IMO, is the role taken by the library you are using in your program. If your program can't do his main goal without the GPL library then it's definitely combined works.I have to disagree on that.. from a functionality point of view, it makes no difference if you're launching another executable, using a DLL, COM server, Webservice or whatnot. And since you can launch executables without having to open the source, you can easily have a program whose main purpose cannot be achieved with the GPL'ed executable. Take MeGUI for instance.. without the encoders it's just a really fancy commandline generator for certain codecs.

as far as I can recall (it's been a while since my one and only DCOM project), there's no linking involved, and no GPL header inclusion. Basically you include the IDL, which is an abstract declaration of the interface. There are definitely no header files involved.

@Cyberace: where can we find a GPL project you have contributed to?

[Doom9]

we would find a lot of stolen code from other opensource codec projects. Do you have any evidence of that, like what the XviD team provided to prove that the Sigma codec was just a rip-off? If so, please provide it now, otherwise this is slander and will be dealt with accordingly

[Cyberace]

@Cyberace: where can we find a GPL project you have contributed to?http://www.xboxmediacenter.com/more_team.htm (XBMC, The XboxMediaCenter Project)

[Doom9]

(XBMC, The XboxMediaCenter Project)Nice :)

[multicone]

for dvdnav part, there was a reply of some developper on http://sourceforge.net/mailarchive/forum.php?thread_id=7525493&forum_id=774 .
It's becoming obvious when reading through his reply that he doesnt understand that libdvdnav is the key component in the navigation filter. He obviously believes that they are just calling libdvdnav from the main app occasionally to get some information on the ripped DVD, which is not true.

A general use DVD navigation playback filter, especially when using GPL code, would be a great thing for the complete OSS community. The ratDVD guys should either release the complete filter code, or rewrite the libdvdnav part.

[Doom9]

It's becoming obvious when reading through his reply that he doesnt understand that libdvdnav is the key component in the navigation filter. He obviously believes that they are just calling libdvdnav from the main app occasionally to get some information on the ripped DVD, which is not true.More conspiracy theories? How on earth can you tell that? You're just speculating.. there is nothing in Michael's mails at all that would support your statement.
I won't wait forever to have that presentation of proof..

[Cyberace]

for dvdnav part, there was a reply of some developper on http://sourceforge.net/mailarchive/forum.php?thread_id=7525493&forum_id=774 .Michael Roitzsch, one of libdvdnav developers posted his personal opinion on the matter here (http://sourceforge.net/mailarchive/forum.php?forum_id=774) : Although ratDVD does not (at least that's assumed) run in the same address space as the libdvdnav component, it certainly relies on its presence. Question is: Does that make it derived work? Just in case anyone drops by here, I am giving my opinion on this, which is of course in no way the official libdvdnav statement (which, I guess, does not exist, because we are just a community of individuals).

I think the mere fact that ratDVD won't work without the libdvdnav component is not useful to assume derivation. The GPL, at least the way I read it, makes no statement about usefullness. A closed source application like Maya is not very useful without a graphics driver and a mouse driver. But noone would deduce that the license of these drivers somehow affects Maya's licensing. (That's just a crude example, but I am sure there are more.)

So from the pure linkage standpoint, one would have to conclude: ratDVD is not bound by the GPL.

However, I just looked over the GPL again and found this definition for derived work: "a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language". Considering this, one could support a different standpoint:

libdvdnav being wrapped in a COM container is definitely "translation". As part of this translation, the libdvdnav API has been translated too, but is, as defined above, still GPL'ed. ratDVD now directly uses this translated API and therefore directly integrates a portion of GPL'ed work.
In short: Because Python bindings for libdvdnav would fall under the GPL, so do COM bindings. The fact that there is an address space boundary involved does not count, because it is a transparent implementation detail of the target language.

Whatever standpoint is correct would have to be finally decided by a legal authority. (Maybe someone should ask the FSF for a statement?) However, no matter what the legal status is, it would be polite, if the ratDVD guy(s) released the full source to serve the community.

MichaelSo maybe they all just haven't had time/will to look into yet :rolleyes:


EDIT: By the way, I found this 'old' forum-thread on afterdawn.com (link) (http://forums.afterdawn.com/thread_view.cfm/200950) which mentions other GPL violations by ratDVD, I'm not sure if those are still valid though.

[Doom9]

I'm not sure if those are still valid though.Number one: I see the authors and license files in the distribution of both filter and binary. Number three is not correct though since there's no header inclusion with com.

Even in the FAQ, the definition of what's permissible and not when it comes to inclusion is really muddy.. and there's almost nothing about this in the license.. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, (imho that could give a lot of leeway in terms of what can be done even with dynamically linked stuff) and what applies in the end is the license, not an interpretation attempt (FAQ).

This FAQ point is the best they have to offer on this particular case: http://www.gnu.org/licenses/gpl-faq.html#TOCNFUseGPLPlugins

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. The communication is most certainly only one way here. The IDL lists 85 method calls, so it's a subset of what libdvdnav can do. And there's no sharing of data structures (all method calls use standard C types).

BTW, this is not unlike Stationripper (http://www.stationripper.com/), it wraps streamripper (GPL) in a separate executable that has a communication interface, which is then included into the non GPL GUI program (header inclusion).

This whole discussion sheds some light on why many people prefer other licenses. Personally, I'd have no problem if the license were only inherited in case of static linking or an expansion of a GPL program, leaving out dynamic compilation and anything less tightly integrated. And in fact, even the good people at the FSF are not so sure about that: If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case.If you go by that, all you have to do to definitely get around the inclusion thing is to write a GPL derivate that wraps everything into a main method (it's a bit of additional work especially if different calls return different values, but that can be worked out).

[Cyberace]

Some good points (posted on the FFmpeg-devel mailing-list by respected MPlayer devs):

http://mplayerhq.hu/pipermail/ffmpeg-devel/2005-August/003319.htmlThe criteria is actually very simple. If the non-free program depends
on GPL program to work, then they are linked, thus the comersial
program is in violation.
It doesn't matter what interface they use and how they are connected.

This also have to say that all MPlayer frontends should be (L)GPL compatable.

It could be easily tested. Stop the internet connection, install and
run that ratDVD. If it can play DVD without libdvdnav, then it is ok.

http://mplayerhq.hu/pipermail/ffmpeg-devel/2005-August/003327.htmlIt does matter, as long as the party making the proprietary program is
distributing the GPL module with the intent that it be used as part of
their proprietary program. In this case they are, and there is no
drop-in replacement. See the objective-C case for a similar scenario
in which the infringing party settled.

Natrually no one is bound by the GPL if they are not distributing the
GPL program and the GPL program just happens to be usable when
interfaced with their proprietary program. However, when they ARE
distributing the GPL program, and their product DOES NOT WORK
WHATSOEVER without it, they MUST comply with the terms of the GPL.
Delete dvdnav.dll from RatDVD filter then see if you can navigate/use the .ratdvd menus :sly:

[Doom9]

The criteria is actually very simple. If the non-free program depends
on GPL program to work, then they are linked, thus the comersial
program is in violation.Sadly, Ivan is mistaken. Dependency alone isn't enough. If you read the FAQ, wrapping your non GPL software around a GPL executable is perfectly permissible, even sharing data structures is (see my posts above).

I'm not familiar with the objective C case, but if a software works or doesn't is also not the criteria. Once again, you can write a non open source software that is completely dependant on a GPL executable and that's perfectly permissible. Thus the only thing that matters is whether an inclusion falls under the muddy criteria in the license or not, that's the only thing that matters and that's far from clear because the license gives a lot of leeway (as most legal documents) and is thus up to a wide range of interpretations.

Looking for objective-c (I have still not found the relevant info) I came across something interesting with regards to header inclusion: look for "Including Kernel Header Files" in this document: http://kerneltrap.org/node/1735. It seems even header inclusion can be okay as long as no code from that inclusion ends up in your binary, which does make a lot of sense to me. If you think about it, a mere interface definition is an aggregation of basic system types to structs/classes and it would be kinda weird if say a linked list declaration would force anybody else who's using the same declaration to release his entire software under the GPL.