Slashdot Log In
First Legal Test of the GPL
Posted by
CmdrTaco
on Wed May 23, 2001 01:19 PM
from the its-only-a-matter-of-time dept.
from the its-only-a-matter-of-time dept.
Trepidity writes "In stark contrast to the plethora of false alarms recently, there's a pretty clear-cut case that Vidomi, a DVD ripping product by SloMedia, is composed of a great deal of code from VirtuaDub, a GPLd product. As SloMedia have refused all requests to either release their source or stop using the code, the developer is planning to file suit with the aid of the Free Software Foundation, in what could be the first legal test of the GPL's enforceability."
This discussion has been archived.
No new comments can be posted.
First Legal Test of the GPL
|
Log In/Create an Account
| Top
| 524 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Re:easy: (Score:3)
FUD, FUD, FUD (Score:3)
While IANAL, it's obvious you're going on mostly hearsay, popular opinion, and misunderstandings (whether intentional or not). Let's see:
Yes, they are, and it's not too unreasonable that the person who creates the library may wish it to only be used for Free Software purposes. Like, say, TrollTech. This fits perfectly with their intent. It's their code, if you want your own nice widget set that's closed, write it yourself, or pay TrollTech their due. Next up:
Your opinions on the matter don't affect the matter, of course. Save this thought for later. Going on:
Hmm, better not give software vendors any bright ideas here.
OK, this is complete tripe. The standard C/C++ library (glibc) is under the LGPL, Linus has made special provision for allowing use of the kernel interface however you'd like (allowing binary drivers for instance). Let me reiterate: this is just pure FUD.
Um, and RMS is wrong why? Remember, your opinions don't make it so. You certainly haven't shown it legally to not be the case. The only real reasoning you've shown is FUD. This assertion, therefore, doesn't seem to have a whole lot of weight behind it.
Remember, RMS has quite a legal team. He very well understands what the license means, and it's been analyzed by many other legal teams (IBM, who could find no holes; MS, who is running scared). Let's see what the real lawyers with informed opinions have to say.
Re:Vidomi's position (Score:3)
4) Pay Avery Lee to license his work to SloMedia (assuming he holds sole copyright).
It's pretty common that Free Software programmers write proprietary code for a living. And many of them would be willing to provide non-GPL licenses for money. I believe this has been a major source of revenue for Cygnus (don't know what it is now that Redhat owns them). And it's only fair.
Re:Vidomi's position (Score:5)
Nope, you got it wrong. It is GPL proponents who are outraged at corporation for their EULAs and yet they are using the very same methods.
Not even close. You can do whatever you want with a GPL'd program as long as it doesn't violate copyright law. You don't even have to agree to the license. However, if you'd like to use the GPL'd code in a program of your own, then you can do so by agreeing to the GPL which states that you must release the source code to the resulting derivative program as well.
Contrast that with standard industry EULAs which routinely take away all sorts of rights such as publishing benchmarks, using the program in a way that criticizes the maker, making backup copies, running the software on more than one machine, etc. It becomes quite ridiculous. There is no real comparison between the GPL and EULAs. At least with GPL'd software you can use it without having to agree to such a ridiculous licensing agreement. If these corporations put this many restrictions on simply USING their software, imagine what kinds of restrictions they would put on using their source code!
This is just what the FSF has been waiting for. (Score:3)
The FSF has been waiting patiently for a violation of the GPL by a company small enough that they have a good chance of actually winning the case. Unfortunately they aren't the owners of the copyrighted software, but apparently the author of VirtualDub is willing to let the FSF do most of the heavy lifting. Once they win a case then they have precedent supporting their view of the GPL.
Hopefully this actually goes to court, and hopefully the FSF get the win that they have been waiting for. Otherwise we are in for some interesting times on the Free Software front.
Re:Grey area (Score:3)
More info... (Score:5)
It also contains some technical evidence as to which functions were lifted and how they know.
Lawsuit? Probably not. (Score:3)
I've been a VirtualDub supporter/contributor (financially) for a couple of years. It's a great program, and Avery, what I know of him, is a pretty quality guy. Is he thinking of suing Vidomi? I don't know. And neither does anyone else, from the references posted in this article.
I, and I assume others, submitted a MUCH less inflamitory, more accurate entry. I wonder why THEY weren't used instead? It's this sensationalism in article selection and lack of even basic fact checking that really makes me wonder about value of Slashdot as a 'news' portal.
jf
Huh? (Score:5)
--Bob
Real Men read binaries all the time (Score:5)
You might be able to get away with such a Perl script hack in college, but not in the real world.
Changing variable names won't substantially change the binary code the code compiles into.
Even switching compilers and optimization levels doesn't give you much obfuscation. Besides, how many viable compilers are there for any particular platform? It's not hard to try them all.
To substantially change the generated code (in a hard to detect fashion), you need to change the fundamental structure. And then you need to be careful and not introduce new bugs. And you still have to test it a lot. You might as well write it from scratch.
Try running 'objdump --disassemble /bin/ls' on your Linux system for yucks.
Re:DLLs and COM (Score:3)
>component out of it. I releast the full source.
>3 months later, I decide to start writing a
>closed-source app and I find the component would
>be useful.
>Should my application now be covered under the
>GPL?
You're the author. Your rights to use the code do not originate from a license granting you access to somebody else's copyright. You OWN the copyright.
A license you grant delegating some of your rights to other people doesn't limit YOUR rights to your own work.
Unless, of course, you sign over the copyright. But that's not what a license does. (If your employer paid you to create something, they may own the copyright due to their contract with you. And the FSF wants people to sign their copyrights over to them so they'll have a stronger position if they ever have to sue anybody. But that's a seperate issue.)
Rob
Re:A true test of the GPL (Score:3)
I think you are wrong here, and fall into a common trap - the "technical" trap. You assume that any law is true to it's fullest technical interpretation, and that anything that can be interpreted as meeting those technical considerations, is affected by the law.
But laws are human, and are meant to be interpreted by a human, and not a robot. A human (judge) can take a look at a situation, and make value judgements about the validity of the law or not.
A good example is the Napster case - the judge decided that Napster was illegal because it was aiding in piracy. But all Napster is, is an online opt-in search engine/database. Does that mean that all search engines are now illegal, because they too can be used for piracy? No - because as humans, we can see the difference between Napster and search engines, even though someone can make a claim that Napster == Search engine.
Likewise, it's kind of obvious that this product pretty much relies on GPL code to be useful. Perhaps it offers some token functionality without the GPL code, but, that functionality is pretty irrelavent. A human can take a look at it, and make a value judgement on the situation.
Laws are not interpreted by turing machines (nor are they expressed in lambda calculus) - and that's a very good thing indeed.
-Laxitive
Re:Huh? (Score:3)
That would depend on whether or not you live in a state that has passed the UCITA legislation.
Re:It's funny... (Score:3)
Yes. If you design a language, and place a restrictive license on it, then the people who use *your product* are bound by your license. (Although, some people may be legally allowed to reverse engineer the software) Additionally, if your language is an open specification, and you write documentation for the language that includes example code, then you may place a license on those examples. (A *lot* of docs are written this way, unfortunately) People who read your documentation are bound by the license of the example code.
If i read the source code to... diablo 2... can blizzard bust my balls cause i figured out how they did something and put it into my game?
Yes. Yes they can. That's what copyright protects. That's why proprietary software engineers are generally required to stay the hell away from Free Software code, and Free Software engineers don't read proprietary code.
As an example, you won't find the Wine project accepting code from former Microsoft employees, because if those people violate the license used by their former employer, Wine as a whole may be judged to be in violation.
Derivative Works (Score:3)
This is a horrible implication for Free Software (and non-monopoly commercial software too), as it could effectively allow someone to use IP laws to protect an interface. This must not be allowed to happen! If judges agree with you on this point, Linux dudes may win the battle but they will lose the war.
If interfacing to another piece of software causes your software to become a derived work of the other, then we're all in for a shitstorm of trouble, and this particular case will be small potatoes by comparison.
---
The GPL and Linking (Score:3)
The question of what constitutes a "derivative work" in the case of software has not ben litigated to my knowledge. The GPL gets its strength from copyright law. Copyright law reserves several rights to the copyright holder among these are the creation of "derivative works".
But Copyright law does not cover anything which is a "method of operation". It could be argued that an API exposed by a DLL or other dynamically linked object is a method of operation and not protected by copyright. Thus merely using a library routine might not be viewed as creating a derivative work.
If this were not the case, we would be in a worse situation. Then MS, for example, could claim that any piece of software using services provided by a MS DLL is a derivative work. Similarly for any platform where routines are exposed through an API and where there isn't license text specifically allowing the use.
Re:GPL, Distribution, Intent and Spirit (Score:4)
This is certainly the point of view in the GPL community, but it if far from clear whether the courts will endorse this view. Header files describe an API. An API is arguably a 'method of operation' in the context of copyright law and 'methods of operation' are not protected by copyright.
Another interesting take on linking (Score:3)
Re:A true test of the GPL (Score:5)
*bzzzzt!*
Programs under GNU/Linux are not linked against the kernel. Programs under GNU/Linux are linked against the GNU C library, which is LGPL'ed (Library GPL). The LGPL says that you can link non-GPL'ed software against the C libraries and be OK, which allows for commercial, closed-source applications to be developed for GNU/Linux.
So even if the GPL is held to be enforceable against libraries, commercial apps are safe and can continue to co-exist because the LGPL'ed C library gives them the exception they need.
--
Re:Huh? (Score:3)
Ah, but you fail to realize that lawyers are not programmers. Most of the time, this is a bad thing, but this may very well be a good thing in this case.
They won't care if it's Corba, DCOM, or staticly compiled. Hell, they don't even know what that means. All the law cares about is: "Did this action violate the spirit of the license". Sure, they'll try and interpret the license every which way by pulling out each relevant sentence and dissecting the meaning of every word, but it won't be a technological analysis. Technical, yes, but not technological.
They will look, see what the license says:
2.b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
(later in 2) 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.
I boldfaced the important bits. Are they distributing a piece of software that is a work (as a whole) that is based on the GPLed software? If so, it must be GPLed, even if it's connecting to the code on a seperate server... as a higher level interpretation (which is my own, and not legal), even if the GPL code were to reside on a server: if the app requires the GPLed code as a basic part of its core functionality, then the GPL applies to the work as a whole.
--
Evan YMMV IANAL, but I used to work with them.
GPL is NOT LGPL (Score:3)
Did you bother to look at vidomi.com before.... (Score:3)
Also for those don't want to load the page they have three interesting news bits, the first is titled "Credit where Credit is due. They acknowledge the following sites
http://hiroko.ee.ntu.edu.tw/
http://www.freeamp.org/
http://www.flaskmpeg.net
http://www.virtualdub.org/
http://www.mp3dev.org/mp3/
Then they have a link to the source at this url http://www.vidomi.com/download.php?op=mydown&did=
The next item reports that they will no longer allow download of the GPL'd items with the non GPL'd items, and that they will shortly release a GPL kit.
Where's the problem?
GPL, Distribution, Intent and Spirit (Score:5)
The header files describing the libraries had to be used to produce the application linked (dynamically) to it and so their application forms a derivative work. This is why GPL shared libraries are not linked against elsewhere and is why the LGPL was produced.
Even if Vidomi produced an middle man DLL, that middle man DLL would be subject to the GPL for the same reason and anything linked against it would also be. However, it would be interesting as it would make Vidomi responsible for prosecuting any violation of their proxy DLL. I still think most courts would not favour their case after the situation was clearly explained.
It is really a true shame that Vidomi have put their own interest in front of the Avery's, it shows them in a very bad light, although it would be interesting to see the GPL subject to court-time but I think the outcome is predictable.
I can only suggest they save their time in court, GPL their application and get on with writing applications that people want to use, that is what its all about, right Vidomi?
Re:A true test of the GPL (Score:5)
I think it does since the libraries header files are used in the subsequent work. The courts will always take into account NON COURT precedent in the absence of previous similar findings and there they would run into the NeXT Object C compiler based on GCC (NeXT backed down, its GPL now!), the QT problem, the absence of linking to GPL libs on Linux/UNIX systems, the intent of the LGPL to specifically permit this (this alone should tell you the intent of the GPL is NOT to permit it)
You statement about making 3rd party developers beholded to OS vendors is wrong. They already ARE beholden to them but most sucessful OS's permit free linking to their application without license propegation to the result. The LGPL allows this too and is why glibc and mesa are LGPLd.
The interface between kernel and application is via an LGPL application and Linus specifically permits binary only drivers in Linux (basically making the header files required to use them effecticely LGPL)
You are incorrect on a lot of counts here and you're not alone.
Re:Vidomi's position (Score:4)
That's just pure stupidity. No one is forcing you to use GPL code. As I've said before, anytime you use ANY copywrited material (outside of fair use) in a derived work, you have agreed to abide by the license given to you by the original copywrite holder. If you don't like that license, don't use THAT code.
There are three easy ways Vidomi could have avoided this whole issue:
1) Use VirtuaDub and release thier software under a GPL compatible license.
2) Don't use VirtuaDub, write thier own code.
3) Look for and use code whose license *is* compatible to Vidomi's license, use that.
Seems simple enough.
>license that is not much different than "evil" >they are trying to fight.
That's ridiculous. The GPL prevents you from using GPL code in a proprietary application. That's not evil, that's *the* primary feature of the GPL.
If you don't *want* that feature, don't license your code under the GPL.
And as always, whatever license you use will have to be compatible to the licenses on any other code you have incorporated into your program. That's not specific to the GPL, that applies to everything that isn't Public Domain!
EXE versus DLL. (Score:3)
Re:EXE versus DLL. (Score:3)
executables have stripped relocation tables, you can only load them to address 0x400000
That's not true. Most exe's have relocation information. You can strip it out, but it's pretty rare that EXEs have this information removed. Even if they did it just means the process that loads them needs to be loaded at a different base address. There is nothing special about 0x400000, many exes have a base address other than that. Notepad.exe uses 0x1000000 for example (under w2k). Use the program "rebase" that comes with W2k to change the base address to whatever you like. You can load an EXE without relocation information as DLL. Also DLLs don't have to have relocation information assuming they are not going to conflict.
even if the relocation table would be present, the OS doesn't permit loading & dynamically linking against an executable. It was originally possible, but the changed because it can cause security problem.
Try it yourself :
HMODULE m=LoadLibrary("c:\\winnt\\system32\\notepad.exe")
Amazing!!
Inquiry? (Score:5)
I ask since the product I do support for uses perl and gzip as part of it operation. We ship -unmodified- copies of these in binary form and supply the source (simply a copy of the relevent release's source from the Gnu sites) on demand. We call gzip from within some of our code to compress data 'on the fly', and we use perl everywhere, from install scripts through to cron jobs, and a whole bunch of perl utilities we ship that complement the primary product.
My understanding (both from our legal bods, and from stuff I have seen in slashdot discussions) is this is quite legal, and the GPL actually is written to accomodate this sort of use (we use the GNU stuff in it's entirity, without extending it's functionality).
But I fail to see a real difference between calling these utilities as standalone executable, and calling something within a library, surely the net effect is the same?
EZ
At least it's a Small(er) company (Score:4)
-Ted
GPL can probably be circumvented (Score:3)
The GPL is, at heart, a copyright license. It controls the right of a person to use, copy, modify and distribute a work that is copyright. As such, the scope of it's effectiveness is bounded by the scope of the copyright laws.
The crux of the GPL's leverage is it's application in derivative works. If a portion of sourceode licensed using the GPL is combined with other material into a whole, the resulting work will be a derivative work, and the GPL's terms will apply to that work. I seriously doubt that a court will apply any of the computer-science analysis to the code, meaning that terms like "execution thread" and "shared memory" will be ignored. The court will ask "is the GPL'd code combined into a file with the non-GPL'd file", and the answer will be "no". From that point onward, I think the court is going to look very skeptically at the idea that run-time linking can create a derivative work.
In the case of DLLs loaded at runtime, there is never a time when the GPL'd code is combined with the rest of the software to form a derivative work. Interaction with the DLL is in the form of interfaces where the operating system mediates the exchange of data between the calling program and the DLL, and the return of data from the DLL to the calling program. The two pieces of code are never combined into one whole program.
Even if the author of the code in the DLL were to claim that the header files used to construct the DLL calls represented a copyright, and if used in the sourcecode for the calling program represented the creation of a derivative work, the company could simply replace the header files with ordinal values and value types in the description of the external function and call the functions in the DLL without even using the names of the functions or the names of the variables being passed, thus eliminating that source of copyright infringement.
Let me give you another example. Using Windows, printer drivers are stored in DLLs. They are accessed by software at run-time to set printer settings, to rasterize output, and to peform various other kinds of error checking.
If the GPL is held to apply to software that links at runtime to DLLs, it would mean that every Windows printer driver in the world would be required to conform to the GPL in order for GPL'd software to use them.
It has been suggested that the exemption in the GPL for code distributed with the operating system covers printer drivers, but unfortunately many drivers are installed by users and are not a part of the operating system distribution.
Here's an even more extreme example. If the model of "run time calling" is found to create derivative works comprised of the calling software and the target of the call, then anything using an RPC mechanism is also going to have to follow the rules of the GPL. Including the results of RPC calls made using HTTP. Meaning that GPL'd web browsers could only legally connect to GPL'd web servers.
My opinion is that a court will not find the combination of a program using GPL'd code through run-time calls to a GPL'd library to form a derivative work. If it does not form a derivative work, the GPL cannot apply to the calling code. If it does not apply, then distributing a closed-source program that relies on run-time calls to GPL'd DLLs is going to be a legal method of circumventing the copyleft of the GPL.
If the court does hold in that direction, it will essentially mean that the LGPL is a pointless license; anyone will probably be able to encapsulate GPL'd code in DLLs, and as long as they distribute that code in compliance with the GPL, distribute proprietary code that calls those DLLs in the same package. If that happens, the only benefit to using the LGPL will be to allow static linking at compile time to LGPL'd code, something so trivial to replace with a run-time link that the LGPL will become irrelevant.
I am actually glad to see a court test of this issue, because it will help clarify the scope of the GPL and provide the first real road map for how copyleft licenses can be applied to derivative works. It's a valuable lesson to be learned, regardless of the copyleft in question.
Re:Vidomi's position (Score:5)
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.
What idiots. Clearly if you write non-derived modules and distribute them individually, such pieces are not under the GPL. Once you package it all up for distribution everything falls under the GPL. What an idiot. Time to get an attorney people or fork over the code!
Re:VirtualDub and IP (Score:3)
Because state reptilesentatives are more worried about their bribes^H^H^H^H^H^H...errr...campaign contributions and the falling tax-base, more than they are about your rights either as consumers or developers, and because the supporters of this unconstitutional law have such deep pockets, UCITA is slowly gaining ground against its opponents.
From Richard Stallman's updated ' Why We MUST Fight UCITA [linuxtoday.com]' FIGHT THE POWER!!!! [linuxtoday.com]
A true test of the GPL (Score:3)
For EVERYONE's sake, let's hope that Vidomi is correct and that dynamic linking does NOT make something a derivative work. Consider that libraries are CREATED with the intent that someone else will use the API and header files.
I have never agreed with RMS (and Trolltech's) assumptions that dynamic linking makes something a derived work. It would certainly make ALL third party software vendors beholden to OS vendors, for example. Every program ever written under linux would be a derivative work of the kernel, which is GPL. Imagine if someday the kernel developers decided that all of a sudden ALL works ever developed under linux were actually GPL'd (not that this is a likely scenario, but it is a possible one if RMS is right).
Fortunately, RMS is wrong. GPL libraries do not make all dynamically linked programs derivative works, and I expect this lawsuit to uphold that point (and sanity in general).
Re:A true test of the GPL (Score:3)
I think it does since the libraries header files are used in the subsequent work. The courts will always take into account NON COURT precedent in the absence of previous similar findings and there they would run into the NeXT Object C compiler based on GCC (NeXT backed down, its GPL now!), the QT problem, the absence of linking to GPL libs on Linux/UNIX systems, the intent of the LGPL to specifically permit this (this alone should tell you the intent of the GPL is NOT to permit it)
Companies backing down do not set legal precedent. That is the entire point of backing down.
The QT problem has NEVER been addressed in court. They make the same assumptions RMS does - that dynamic linking makes something a derivative. In fact, I think RMS convinced them of it.
The interface between kernel and application is via an LGPL application and Linus specifically permits binary only drivers in Linux (basically making the header files required to use them effecticely LGPL)
When I create a binary and use system calls, I am dynamically linking to the kernel in exactly the same sense as I am linking to a dynamic library when I make a call to a function in that library. I have no necessity to use gcc to make the binary - there are other compilers available, and I can write the program in assembly and in theory create the same executable bit for bit. I don't NEED to include the header file - gcc may require it, but I can certainly code around it.
This has never made sense to me - that ANY dynamic link library makes ALL linking programs derivative works. It seems to me that the entire purpose of creating a dynamic link library is exporting a PUBLIC API and header file that allows someone to create reasonably separate programs that can access a function.
Functions, as even a cursory glance at copyright law will tell you, are not copyrightable. Only the source is. I have no need to use the source to use the API, with the exception of the header file.
If the FSF wins, it would be an almost unprecedented increase in copyright coverage.