Possible GPL violation by Vidomi
Posted 23 May 2001 at 17:00 UTC by atai 
This is a possible GPL violation case which needs public awareness and
the community needs to throw strong support behind the original
author. The
company Vidomi included code from
VirtualDub, a GPLed video
editing/processing program for Microsoft Windows, in their product and
is trying to avoid following the GPL.
Vidomi is also distributing
DivX, a hacked version of Microsoft's MPEG4 codec, in the same product,
which means Microsoft's copyright may also be violated as well. For
this reason the original author, Avery Lee, wants his GPLed
code removed from the
potentially illegal product.
VirtualDub, by
Avery Lee, is an excellent
video editing and processing package for Microsoft Windows and is free
software under the GNU GPL. VirtualDub was previously mentioned in
Advogato in a story where Microsoft forced Avery Lee to drop support
for ASF files because Microsoft has a patent on the ASF file format.
Now a possible GPL violation has occured over VirtualDub: part of it
was incorporated into
Vidomi, a
product that "makes and plays top quality DivX/MPEG4 video from your
existing source files." Even though the author has pointed out the
potential GPL violation, Vidomi is just having a "
"discussion" and not taking
concrete steps to follow the GPL's requirements and the author's
wishes, who wants the GPLed code removed from this product. Vidomi
also contains DivX, a hacked version of the MPEG4 codec of Microsoft,
and is in possible violation of Microsoft's copyright.
Vidomi has placed parts of VirtualDub in DLLs which are loaded at
program startup. Dynamically linking via shared libraries
into the same address space does not make the DLLs separate works from
the main program, for the purpose of the GPL, for C and C++ programs.
According to Avery
Lee,
For a month now I have been trying to get the makers of Vidomi to
remove VirtualDub-derived source code from their distribution. Vidomi
(build .346 as of this writing) is MPEG-to-AVI converter that uses code
licensed under the GNU General Public License from DVD2AVI and
FlasKMPEG to decode MPEG-2 video. These modules are kept in DLLs and
are automatically and invisibly loaded by Vidomi at startup. The
FlaskMPEG module, ncodefls.dll, exports 24-bit to 32-bit RGB conversion
and resizing capabilities that are directly derived from VirtualDub
code. Vidomi has placed the source code for these derived modules on
their website but the main application is proprietary, closed source,
and this is what I have a problem with.
This is a list of the exported functions from ncodefls.dll. The
VirtualDub-derived functions are in red. The DIBconvert function even
has exactly the same name as the function in VirtualDub and FlasKMPEG,
except for the "flask" part.
ordinal hint RVA name
1 0 00001870 flaskCrop
2 1 00001900 flaskDIBconvert_24_to_32
3 2 000016C0 flaskDeinterlace
4 3 000016B0 flaskInit
5 4 00001770 flaskResize
6 5 000016D0 flaskStartDeinterlacer
7 6 00001700 flaskStartResizer
8 7 000016F0 flaskStopDeinterlacer
9 8 00001840 flaskStopResizer
Dynamic linking does not save you from the source code requirements of
the GPL. The requirement of the GPL is that your application must be
reasonably independent from the GPLed code, with no mention of static
or dynamic linkage. I do not consider an application that
automatically installs the GPL modules, each of which exports specific,
individual functions from the original program, and automatically and
invisibly loads the DLLs on startup to provide major functionality to
be "independent" of the the GPLed code. The company has taken various
token methods to try to ward me off, such as providing token useless
capability when the DLLs are not available (AVI input with no
resizing), and putting disclaimers on their web site. None satisfy me
as long as Vidomi still advertises VirtualDub functionality in its UI
and on its front web page, and places the recommended "with GPL"
download in big, highlighted type, away from the tiny download in the
corner that doesn't have it.
I don't consider it independent as long as it still needs my code to do
what it is supposed to do.
I repeatedly said that I wanted it out. They claim they're compliant
under the GPL and that, in any case, they are trying to address my
concerns. Which of course means that they still haven't taken the
fscking code out. The with-GPL installer is still there, Vidomi still
advertises GPL functionality as its own in its interface (and on the
web page unless you notice the asterisk), and STILL automatically and
invisibly loads the DLL on startup. And although it has not yet
reached this point, I am confident that when their patience runs out,
they will have their lawyer claim that they are compliant with the GPL,
and my concerns be damned.
Although the FSF has been contacted, they cannot take action
directly since they are not the copyright owner of the software in
question. The community should throw its support behind Avery Lee to
force Vidomi to remove his GPLed code from a potentially illegal
product.
Are you sure of this? AFAIK, there is nothing illegal about DivX, it is
an independent implementation of Microsoft's codecs.
Hm., posted 23 May 2001 at 18:12 UTC by Uruk »
(Apprentice)
Proceed carefully I suppose. I'm not saying that it doesn't or can't
happen, but I kinda get skeptical about claims of GPL violation when I
hear them.
With regard to the FSF, I think bringing them in or letting them know is
an excellent idea. If anybody is willing to fight, it's going to be
them. Has anybody considered transferring the copyright to the FSF?
That might be needed if things get serious. Of course I can think of a
bunch of reasons why you wouldn't want to do that, too.
But maybe you're approaching this backasswards. Maybe rather than
emphasizing that they should take the code out of their product, you
should go the other way and try to get them to GPL theirs. As in, take
the opinion that they're welcome to keep using the source code, with the
condition that they GPL the rest of their source code to be in
compliance with the GPL. With the GPL there's two ways in that sense -
you can get them to remove the source code, or you can continue to let
them use the source code after they've GPL'd their app. Arguably the
latter is better because it increases the amount of free software in the
world. Just a thought, anyway.
Normally we would want the product source released under the GPL. This
case is a bit different. DivX is a hacked version of some Microsoft
software (there are some later DivX work which are "original work,",
but the DLL in question here is a hacked version of some Microsoft DLL)
and this company will not be able to release the source of that. Since
there is no legal way for this company to release all the source code
of this product under the GPL, the only thing legal is to not
distribute the product at all.
Of course that does not have to be the concern of Avery Lee. He just
wants his code out of there. Let Microsoft deal with that company
regarding DivX.
Obviously I put in the wrong title
The 2nd
response by JM makes a distinction between DLLs and plugins per the
GPL. Seems like a reasonable difference between a library that has to
be there for a program to run, and a separate executable that gets
leveraged at run-time if it exists. But what about shared libraries in
Unix? There you have a low-level linking that can be deferred until
run-time, and avoided entirely if a particular path of execution is
never taken. If plugins make the GPL no stronger than LGPL, I think a
court might not see the difference between them and shared libraries or
DLL. So whether the FSF goes to court or not, goodbye GPL V2.0, hello
LGPL
and GPL V3.0.
The GPL really doesn't get that techincal with the method of derivation.
If it is a derivative work than the terms of the GPL must apply to that
work. Of course there are ambiguities to exactly what constitues a
dervative work. Vidomi correctly, and perhaps opportunistically,
identifies the related section of the GPL:
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program, and
can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based on
the Program, the distribution of the whole must be on the terms of this
License, whose permissions for other licensees extend to the entire
whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
To me seems clear that Vidomi is a derivative work, since it is not
independent of the VirtualDub program. However, the courts might see it
differently. I don't if there have been other cases which test the GPL
in this way, but this would be good legal case to establish a precedent
and hopefully put some teeth into the GPL.
From my reading of the GPL, there is no way for Avery Lee to force
them to remove his code. The only way that this can happen is if he
takes them to court and sues them for breach of license. This might be
a good thing, because if the courts feel that Vidomi has
violated the license, then the source code for it will become GPL'd. It
would also set a precedent for companies use GPL'd software. Make sure
you follow the rules or all your work could become public property.
When you're dealing with companies, you have to play by their rules,
and that means lawyers. You can't depend upon a companies integrety to
play fair like you can with other people.
From the GPL FAQ:
If a program released under the GPL uses plug-ins, what are the
requirements for the licenses of a plug-in.
It depends on how the program invokes its plug-ins. If the
program uses fork and exec to invoke plug-ins, then the plug-ins are
separate programs, so the license for the main
program makes no requirements for them.
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, so plug-ins must be treated as
extensions to the main program. This means they must be released under
the GPL or a GPL-compatible free software license.
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.
To me this raises some additional things to think about:
1) Why weren't these distinctions between fork-and-exec and dynamic
linking clarified in GPL V2.0? The concept of dynamic linking is
defined (and permitted) in the LGPL. Maybe it will get defined (and
restricted) in GPL V3.0.
2) What about a fork-and-exec process that uses shared memory to
communicate with the original process? Is that a borderline case as
well?
3) Clearly derivative works that evolve the original source code of a
GPL library seem in the clear (as far as GPL enforcement). But doesn't
all the concern over pure "use" of GPL-ed libraries steer dangerously
close
to advocating the enforcement of a "user interface" copyright? Will we
see the LPF and the FSF split on this issue in the future?
If someone includes GPL'ed code in their redistributed code they are
not implicitly GPL'ing their own code, they are simply in
violation of the GPL.
That's if the GPL is enforceable, which is a big if. I expect
that the GPL will be knocked down in court to have essentially the same
restrictions as the LGPL.
-Bram Cohen
If the Avery Lee owns the copyright on the majority of the code. He
should
just offer a commercial license to the company for that part. The money
he recieves can be used to fund development of the GPLed version, which
the company may not be able to use, depending on how copyright on
modifications is assigned. Code gets forked in the worst case, but the
code forking turns into revenue for the GPL developers.
Simple, everyone wins...
[ Home | Articles | Account | People | Projects | FAQ ] 
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank