First Legal Test of the GPL 524
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."
Another possibility (Score:2)
Re:Huh? (Score:2)
It would be easy to play games with this. What if a non-GPL program needs a GPL program to function, but communicates using pipes [and the GPL program modified to use pipes is released]? What if they communicate using method X? It's all dynamic linking at the end of the day, just in various forms of indirection. Once SOAP is widespread, can a non-GPL program make RPC calls against a GPL program? How far will RMS push this? Because at the boundary this kind of "abuse" can and will take place.
I look forward to seeing the results of this case after the expert witnesses have been called to testify.
In this DMCA age... (Score:2)
42. You agree that you will not diff the binary to check for similarities with GPLd code.
I'm confused on a couple of points. (Score:2)
Here's the gist. If I design a system or solution which runs on Linux, and uses a few GPL'ed tools, do I have to GPL the *system*? Here are some facts about this situation:
- No GPL'ed code is modified. We're talking your basic './configure && make && make install' here.
- I provide the GPL'ed tools and their source when I distribute/publish my "system"
- The system is written such that it needs the GPL'ed tools to run. There's no easy method for making the system work without the GPL'ed tools.
- It is quite possible (nay, simple) to distribute my proprietary un-GPL'ed "system" completely independent of the GPL'ed stuff. In fact, we may do that anyways, have a two-stage install, first stage is to install all the GNU/linux stuff and tools, stage 2 is to add in our "value add". But my "system" will not work without being able to use the GPL'ed tools. In other words, it is trivial to distribute and publish the work separately, but the "system" will not function properly or at all without the availability of the GPL'ed tools.
Opinions and thoughts anyone?Re:A true test of the GPL (Score:2)
I would disagree.
Consider that libraries are CREATED with the intent that someone else will use the API and header files.
Libraries created with the intent that someone else will use the API and library files are licensed under the LGPL. That's what it's for.
I have never agreed with RMS (and Trolltech's) assumptions that dynamic linking makes something a derived work.
You are entitled to your opinion.
Imagine if someday the kernel developers decided that all of a sudden ALL works ever developed under linux were actually GPL'd
Then suddenly a lot of people would stop using Linux. What's the problem? If you don't like a license agreement, you don't use the product. You don't argue that it means something it doesn't.
Fortunately, RMS is wrong.
*chuckle* I may not agree with RMS on some things, but I'm not stupid enough to bet against him.
Re:Update from Vidomi (Score:2)
>on anyone
Bzzt. Wrong. He's the copyright holder! He has specifically stated that what you're doing is not okay. Therefore, you do not have the right to modify, distribute, or copy the code.
>We are attempting to deal with this GPL issue
>openly and with integrity.
You are not respecting the author of code which you rely upon for functionality.
Using your argument, I could create a wrapper that loads your entire application as a DLL. I could then freely distribute your copyrighted code with it because, hey, it's not a derivative work.
Re:easy: (Score:3)
Re:Vidomi's position (Score:2)
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:VirtualDub is GPL, not LGPL (Score:2)
What is so wrong with that scenario? It's not like _we_ are allowed to use _IE_ code anytime we want. GPL ain't public domain in intentions. GPL is a _protected_ _area_. It makes perfect sense to exclude some. If you want to be more inclusive, use LGPL- that is what it is FOR. If it bugs you that GPLed stuff is out there teasing you but you can't have it without giving up your old ways- aw poor baby :P
Re:GPL is NOT LGPL (Score:2)
Re:Huh? (Score:2)
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:2)
Which proves again,GPL is completely unusable in commerical settings.
Depends on what you want to do with the software. If it's something that you don't plan to sell anyway (and IBM and Microsoft both have a lot of software that would qualify) then there's no real problem with using GPLed software.
If you want real and usefull code exchange between profesionals with no social or political strings attached go for BSD style license.
Seems to me that corporate types should be even more averse to BSD style licenses than to the GPL. After all, GPL software authors are asking for something in return for their work, it just isn't money. BSD licensed software authors are just giving their code away. Which one is closer to selling as the corporations want to do?
It really pisses me off that these corporations think they can jam all sorts of crap into their EULAs to take away our rights to do anything with their software except exactly what they want us to do with it, but then they turn around and balk at the GPL. Seems like a bunch of hypocrites.
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!
Re:GPL, Distribution, Intent and Spirit (Score:2)
For example, you include to handle POSIX errnos- a very common occurance.
Re:Vidomi depends on GPL'ed libraries (Score:2)
Re:This is just what the FSF has been waiting for. (Score:2)
Vidomi's software is quite obviously a derivative work of VirtualDub, in that without VirtualDub's software Vidomi's doesn't do any of the things that it is advertised as being capable of.
An appropriate metaphor would be if I wrote down my time-honored recipe for toasting bread and then created a cookbook containing this recipe and 400 other recipes straight out of the Betty Crocker cookbook. I could use this cookbook all I wanted to in the confines of my own house (fair use), but if I tried to sell copies of this cookbook it would rightfully be described as a derivative work.
The GPL states that any time that you link (dynamically or statically) a piece of GPLed software you are creating a derivative work. That is why BSD advocates get so excited about GPLed libraries like GNU readline. They know that GNU readline is cool, but linking your software with it forces you to release your software under the GPL because it is a derivative work.
This is also why most GNU system libraries are licensed under the LGPL (a completely different license). Here's a link from the newly created GPL FAQ [gnu.org]
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.
Ahem... (Score:2)
I believe that you are confusing RMS and ESR. To my knowledge, RMS is uninterested in firearms. And that's a rather small difference compared to their relative beliefs in software licensing.
Be careful with your TLA's...
--Lenny
Re:Removing vs. Opening (Score:2)
They could also be pains in the ass and work around the GPL this way: My understanding is that this is a plugin that plays movie files. Their big hole is that they are advertising features of this plugin, and that there is no other plugin. They could remove the advertising and say something like "Plays many movie formats" and then also provide some dummy plugin (perhaps also under the gpl) that does something useless like play .gif movies. That way the program "works" without the gpl plugin and they can legitimatly say it is not a derived work. This may make some gpl purists mad, but I don't see this as being too bad an outcome either.
Re:GPL can probably be circumvented (Score:2)
Most of the your problems and absurdities are due to your assumption that people will put stuff under the GPL when it makes absolutely no sense to do so (at least assumming they want their stuff to be used).
In for your printer driver example, it is true that a GPL printer driver can not legally be used by a non-GPL program. Contrary to what MicroSoft is trying to claim, this does not mean that MSWord is suddenly forced to be GPL. It means you cannot use MSWord with this printer driver. This probably makes this printer driver pretty useless for the majority of users and thus the author was really stupid for putting it under the GPL rather than the LGPL or another license.
Re:I'm confused on a couple of points. (Score:2)
Re:Grey area (Score:3)
Funny thing about that (Score:2)
I think the people at Vidomi are a little jealous that one guy can code up a program that makes their product look like a toy. VirtualDub is like a Swiss Army Knife of video, it might be a little clumsy but it is small and it does everything you need it to.
Chris Cothrun
Curator of Chaos
Re:VirtualDub is GPL, not LGPL (Score:2)
Re:VirtualDub is GPL, not LGPL (Score:2)
More info... (Score:5)
It also contains some technical evidence as to which functions were lifted and how they know.
Ha ha ha! (Score:2)
These guys are harming the whole community.
Legal vs. GPL? (Score:2)
No, what the have done is legal according to the LGPL, not the GPL. GPL2 and LGPL1 were released together to address exactly this issue.
Re:No harm intended/done? (Score:2)
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
I had a (somewhat) similar issue - it gets murky (Score:2)
I had a request from a guy who wanted to do a closed-source check printing program, and wanted to use my font. I told him that I would license it to him for a fee, but that he could not use it under the GPL if he hard-coded the font into his application. i.e., his application WOULD NOT WORK without my font. If he had made a font selection dialog, and happened to distribute my font with his program as one option, then that would probably have been fine by me.
For kicks, though, I asked the GPL newsgroup, and none other than Linus responded that he thought they were in the clear if they wanted to bundle my font with their app. I didn't really pursue it much further...
In any case, this DLL linking is probably more clear cut, and I think it's most likely a violation. But whenever you get interactions between GPL and non-GPL'd code, it gets tricky.
Re:Vidomi's position (Score:2)
My point is that your anaogy is invalid because you made the a priori assumption that Vidomi is violating the GPL by shipping the DLLs. If you think about it a bit, you'll see that this assumption is incorrect.
Vidomi is shipping two things:
- a modified version of the VirtuaDub DLLs
- their own proprietary software that dynamically links with the VirtuaDub DLLs
Ignore the proprietary software for a moment. Aren't they allowed to distribute the modified DLLs? Yes, provided they allow access to the source (which they do). So the DLLs are being distributed while still abiding by the GPL. In other words, if you want to make an anology including Microsoft Windows, you have to assume that the company is shipping licensed copies of Windows, because the VirtuaDub DLLs they're shipping do conform to the GPL.The problem everyone has is with the proprietary code that Vidomi wrote. That's why I'm asking how you'd feel about it if they weren't shipping the modified DLLs at all. Because the DLLs are GPL compliant, so shipping those DLLs isn't the real issue here.
In your thought experiment, they would have had to compile at least a header into the original program in order to dynamically link later. Whether this was the original header or a reverse engineered header, its still a derivative of the original work. The header would be GPLd, compiled in -> entire work GPLd. You need the LGPL for that to work.
Unless the VirtuaDub headers contain inline code, that argument doesn't hold up at all, especially not if Vidomi was using reverse engineered headers. Using your logic, WINE [winehq.com] is completely illegal, because it contains "reverse engineered headers" from Windows. Typical headers are really just interfaces, and it's long been argued that duplicating that form of interface is fair use.
Huh? (Score:5)
--Bob
Re:Vidomi's position (Score:2)
Um, no.
It proves again that the GPL can't be indescriminately combined with proprietary software.
But remember that proprietary != commercial. Though you do have to structure your business differently if you're developing GPL'd software.
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:Vidomi's position (Score:2)
"this License, and its terms, do not apply to those sections when you distribute them as separate works?"
Oops.
Re:Huh? (Score:3)
That would depend on whether or not you live in a state that has passed the UCITA legislation.
Re:Huh? (Score:2)
Well, yes, the program can run, but it can't perofrm the functions it is intended to perform, so it can't do the things it advertises, and the things users obtain it for, so practically, and legaly, it can NOT ber run with out it.
Nonsense. I could write "Hello, World" with some funky twist so that it will only work on Linux, yet release my code as BSD licensed.
What you are suggesting is tantamount to "Your car won't run without gas, so your car is the property of Exxon."
Hell, the programmers of GPL code need food and water, do they by extension own the food on the shelves of the supermarkets?
grubRe:COM objects? (Score:2)
For example, if I write a GPL media player COM control, does Word and IE have to be open sourced because someone could embed the control there?
DCOM) MS DCOM/COM+ eventually turns into MS-RPC, so your distinction doesn't make any sense.
I can write open source server component (OK - talks to the OS DCOM libraries) and talk to it with a closed source client (talks through the OS DCOM libraries and RPC to get the unrestricted 'output' of the server).
--
Re:A true test of the GPL (Score:2)
Commercial software left mere copyright protections behind long ago. Don't ask me why- I personally do not buy the argument that software needs copyright, patent, AND DMCA monopoly grants in order to foster innovation. If anything, it accomplishes just the opposite. What a travesty!
It's to the FSF's moral credit that the (L)GPL uses the most reasonable protection mechanism for software (copyright) and stops at that.
Re:Huh? (Score:2)
Re:I had a (somewhat) similar issue - it gets murk (Score:2)
Actually, I think he was right. The key point is the first part of the GPL quote:
The case he presented was a non-GPL'd program that was not derived from his GPL'd code, but was capable of using his GPL'd code in a generic fashion (via a font selection dialog.) The GPL, in the above passage, seems to explictly recognize this case, as long as the non-GPL'd and the GPL'd products can "reasonably considered independent and separate works".
What's a reasonable way to consider two products independent and seperate works? In the font case, well... if there is nothing in the source code that references the font explicitly, I'd think that would be a good indication that the works are truly independent.
So, if the bloke who wrote the check printing program took the neccesary steps to ensure that it is a "independent and seperate work" from the GPL'd code, it seems that he wouldn't be required to distribute it under the GPL. Which brings up the second point:
If the first assertion is true - that is, the check writing program was an "independent and seperate work" that was not derived from the GPL'd code - then the distribution is not an issue, since the requirement to distribute under the GPL only applies if you distribute the non-GPl'd code "as part of a whole which is a work based on the Program". Since the whole of the work was not based on the GPL'd program, then it would seem that the GPL allows distribution of the GPL'd program in conjunction with the non-GPL'd program, without the requirement that "distribution of the whole" be under the terms of the GPL.
Final note: if the argument that a non-GPL'd program can be forced into being GPL'd by a plug-in or other non-essential component is accepted by a court, I would be very surprised... since it implies that someone other than a copyright holder can alter the license under which a work is distributed. Keep in mind that this is apparently not the situation with VirtuaDub and SloMedia... SloMedia has, by all accounts, failed to produce an "independent and seperate work", which probably puts them four-square in violation of the GPL.
Re:It's funny... (Score:2)
It's not viewing the GPL'd source that will get you in trouble, it's copying it.
The thing is, if you read someone's code and copy it into your application using your memory as the medium, that's legally the same as just electronically copying the file.
In other words, if you read someone's source code, you're probably bound by the license of said code. Applying their solution to your product, whether you copy it by mind or by wire, is governed by the same licenses.
I understand, BTW, that Microsoft programmers are explicitly forbidden by their management from reading the code to any GPL products to avoid this problem.
Re:It's funny... (Score:2)
If you read code to learn from it, you're memorizing someone else's code. Applying that code to your product later may not be copying the code verbatim, but it's copying all the same. If the author of the original code can prove that you've done this (this applies to code under *any* license), then they can pursue the same legal recourse as if you'd used the original code directly.
Re:It's funny... (Score:2)
...a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another
language
Reading itself is not covered per se, but application of that "algorythm/way of doing it" legally constitutes a derivative work. That means that if you read GPL code to see how a thing is done, the code you write to mimick it must be GPLed itself.
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.
---
Re:Vidomi's position (Score:2)
Wrong. You can do that, as long as you don't distribute the resulting software to anybody, unless also your code is under the GPL.
The GPL is not about use, it's about distribution.
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)
Um Something is really weird here (Score:2)
Re:Um Something is really weird here (Score:2)
Re:Um Something is really weird here (Score:2)
Re:A true test of the GPL (Score:2)
How do you think you have native GNU/Linux applications that are closed-source? The glibc libraries are specifically LGPL-ed so that commercial applications may be developed and linked without requiring that they be GPL-ed themselves.
Second, there's plainly no reference to the LGPL in the text of the GPL.
I don't recall saying that there was.
Third, you haven't read Linux's COPYING file. Linux is not under the GPL -- there's a special Linus modification at the top of the file allowing anyone (even proprietary apps) to link to the kernel.
That's all well and good, and is probably the reason why (as the poster above you stated) people can link to symbols that the kernel exports (select, open, etc.).
However, Linux _is_ under the GPL; Linus, as copyright holder and ultimate licenser, can add as many exceptions onto the licensing as he wants. The GPL gives you certain rights; Linus can give you other rights, or modify the rights that the GPL gives you (but then it no longer qualifies as "true" GPL licensing). In this case, Linus chose to allow people not only the rights afforded by the GPL, but also one that wasn't: linking with non-GPL software.
--
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:Microsoft must be drooling (Score:2)
The more likely outcome is that Vidomi has to stop using GPL'd source and pay damages for copyright infringement.
Also, Microsoft is relevant to this lawsuit, but not in the way you think.
Look at this comment and footnote from the web site:
Yes, I can dual-license the code, but I have chosen not to in this case [link to footnote]
[Footnote] I have chosen not to because their software is, as far as I can tell, primarily meant to rip DVDs (MPEG-2 + AC3), and also installs the DivX 3.11a codec, a hacked version of Microsoft MPEG-4 V3. I'm not a lawyer, and moral issues aside, it is probably in my interest not to have my code specially licensed in a commercial package which is, with high probability, illegal.
In other words, the software distribution in question may also violate Microsoft's copyright. I would be speaking to Microsoft lawyers about a possible joint lawsuit.
--
The $75,000,000 question (Score:2)
I thought not, but I don't have a windows box to play with it... I was under the impression that those flask functions in the DLL were crucial to the stated functionality of the program.
Is this true or not?
--
Evan
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?
Re:No harm intended/done? (Score:2)
The Java argument is why Free javalike systems (like kaffe and gnu classpath) were produced, so people can use Java and know that their application can run on a free system.
However, Sun do no require that Java application linking against their classes be subject to their licenses. The GPL does require that.
You cannot link a closed source application to a GPL library becuase it becomes a derivative work, there are parts of the library in the main app even if the bulk is loaded at runtime.
Re:At least it's a Small(er) company (Score:2)
You only have to find out why GCC has a GPL'd Objective C compiler front end to see that larger companies with Real Lawyers tend to consider the GPL clear enough to make them unfavourable in court.
Remember that Vidomi/SloMedia are not asking for the court case, Avery is. They will probably back down if they have any sense, if they do it now, the demands for their application under GPL may die down but I'd be pushing to get it to court just to prove the point.
Its a pretty clear cut case and most courts will side with the intent of the author, especially now Vidomi has published their intent not to play fair on their own web site.
Re:GPL, Distribution, Intent and Spirit (Score:2)
In the event of court, I think three outcomes are possible...
1) They are deemed not in violotion of the agreement and the GPL as it stands has no safe guard against this (this is UNLIKELY people, judges are looking for FAIR findings and the intent of the GPL here is clear enough. The FSF has compiler and linker programmers to explain this to the judges, they have clear industry set precidents that linking against GPL libs is not permitted and they have a case that most judges will genuinely find interesting to understand.
If you need a precident, courts more often defend the right of the author than the recipient, you've seen that before!
2) They are deemed in violation of a binding agreement and as such must honour it. GPL source for their application to customers.
3) They are deemed to not be bound to the agreement and as such are forbidden from using the GPL code in future unless they properly accept the GPL.
The latter is probably the most likely (the courts will probably side with your view that their code should be protected) and I'd probably give this judgement myself. Both parties walk away relatively happy and neither is massively harmed as a result.
I'd guess a token fine to be paid to the FSF and Avery would be ordered to set a clear winner precident, not enough to warrent appeal but enough to indicate the court is happy with our own precidents.
But that's all assuming Vidomi are stupid enough to do this. They aren't and the GPL will probably never get to court. As soon as you put a decent lawyer in front of it and explain the technology, they just arn't confident of anything other than it being upheld. That's why its never been to court before and a handful of companies have considered it before involving their lawyers.
There's a rumour its because Eben Moglen kicks ass and no one wants to take him on, but I'm not sure if its true
Re:A true test of the GPL (Score:2)
Re:A true test of the GPL (Score:2)
NeXT initially wanted to make this front end proprietary; they proposed to release it as
not evade the requirements, that it was not allowed. And so they made the Objective C front end free software.
Notice that it is the FSF lawyers who said "No" and NeXT accepted this as fair play. This is a precident that a court will consider.
Full text is at...
http://lwn.net/1998/0409/pragmatic.html
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:2)
>If you want real and usefull code exchange >between profesionals with no social or political >strings attached go for BSD style license.
The GPL has never claimed to be without strings. I don't understand what's so complicated about that. Anytime you use ANY copywrited code (that includes GPL and BSD code) you MUST obey the conditions that code was licensed to you under!!!
The only difference is what conditions the original copywrite holder is asking for. Admittedly, in the case of the BSD license they really aren't asking for anything.
As for the GPL being usable or unusable in commercial settings, it still depends on what you intend to use it *for*. I use lots of GPL'ed code in my job. It works fine for me because my employer isn't planning to re-distribute that code under a more proprietary license. If they *did* wish to release their code under a more proprietary license, then yes, BSD licensed code would then fit our requirements better.
The point is, the original copywrite holder *always* has the right to set the terms on how you can use thier copywrited material. If you don't like thier terms, don't use thier code!!!! Write your own, or find some code that is under a license you *do* like!
Re:Vidomi's position (Score:2)
>Who is a bigger hypocrite here ?
Vidomi. Vidomi and the FSF both have the legal right to enforce conditions on the use and redistribution of thier copywrited material.
The FSF doesn't agree with the conditions that proprietary software companies put on thier software, but I haven't seen them try to violate those licenses by, for example, using proprietary code in a free software program.
Vidomi expects us to obey thier license conditions, while at the same time they are attempting to violate and subvert the license conditions of VirtuDub. They seem to believe that thier license matters, other peoples licenses don't.
It doesn't take a brain surgeon to see the hypocracy here.
Re:Vidomi's position (Score:2)
Where is the problem here? The FSF does believe that proprietary licenses are depriving people of important freedoms. Given that belief, it would be bizarre if they *didn't* accuse proprietary software companies of limiting other peoples freedoms!!
Regardless of whether you agree with Stallman and the FSF or not, I think they've been remarkably consistant and logical in support of thier beliefs. They've talked the talk, and they've walked the walk. They don't just talk about software freedom, they've written hundreds of thousands of lines of code and release them under a license that fits *thier* beliefs in software freedom.
Re:Vidomi's position (Score:2)
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.
Re:Huh? (Score:5)
I think that you're missing the bigger issue. Basically, Vidomi is turning a GPLed library into a dll and linking a proprietary program against it. They're releasing the code for the dll, but not the program that links to it. Since the GPL claims that work that is commonly distributed as an organic whole constitutes a derivative of any packages that make up the whole, that appears to be a GPL violation; the whole thing should be released under the GPL. If Vidomi wins, it will mean that the GPL is substantially weaker than people have generally believed, as it will be possible to make part-GPL/part-proprietary programs by isolating the GPLed part in a dll.
VirtualDub and IP (Score:5)
Here's [cptech.org] a little summary of the VirtualDub/ Microsoft patent dispute with links to more comprehensive articles.
Sincerely,
vergil
Vergil Bushnell
VirtualDub is GPL, not LGPL (Score:4)
Avery claims that Vidomi is derived from the GPLed VirtualDub. If this is true, then Vidomi source must be released.
Vidomi hopes to create a "user does the link" loophole. This is analagous to the Objective C front end situation described in "Copyleft: Pragmatic Idealism [gnu.org]". NeXT gave in. Perhaps Vidomi will, too. Or perhaps, as the headline suggests, this will go to court and set a legal precedent.
Tom Christiansen, a vocal GPL critic, has argued a position similar to Vidomi's. Dynamic linking is an interface. If there is a non-GPLed implementation of the interface, then the program is not necessarily derived from the GPLed library. People have written GPLed replacements for proprietary programs, why not the other way around? However, I suspect that a court would see through the sham replacements in this case. Vidomi advertises functionality that requires GPLed code; therefore, it is a derived work (under copyright law), subject to the license of the original code.
Not to MLP, but... (Score:4)
Let's say Virtual Dub wasn't GPL. Let's say Avery Lee was selling his software, and providing source code with each copy sold. Would it be right to copy his code into your own product without compensating him? If he demanded too high a price for his work, would it be okay for you to take it anyway? No. You would have to choose: Pay his price, or forego that code.
In this case, in exchange for using the code Mr. Lee is demanding you publish the rest of your own code under the GPL. Is the price he demands too high? If that is the case, then either you "pay", or you find some other code to do the same work.
Nice and Sweet. There it is in a nutshell. In fact, this leads me to ask the question: Can you write software that would use existing GPL programs without releasing it as GPL? There, I would think the answer would be "yes" in a court of law. But it Should be "no", by the above argument.
[OT] By the way, it has always been my opinion that the Law should be based on common sense. I dunno, it makes all this IANAL stuff somehow a little more irritating. YSNHTBAL!
Re:Vidomi's position (Score:3)
Not quite so clear as it might first seem, alas. The key question is what level of "packaging" creates a real connection between components. For example, Red Hat routinely distributes applications with non-GPL licenses (Apache, BSD, etc.) bundled with the pure-GPL Linux core product. Other than a few extremists, nobody considers this a GPL violation, despite the fact that the non-GPL apps cannot operate without access to Linux system services.
The line between 'bundling' and 'linking' gets fuzzy when discussing dynamic link libraries (and similar loose-coupling technologies). I personally feel that Vidomi has violated the terms of the GPL, but I'd hate to try to prove it in court.
--
A summary of the issue (Score:4)
Well, that's what it looks like to me.
RMS (the gun-nut) has an article [slashdot.org] on this topic which may be useful.
TWW
GPL v. LGPL (Score:4)
It seems that the code in question was released under the GPL [gnu.org], and to me, it seems clear that the GPL has been violated in both the letter and the spirit of the license.
I am tempted to argue that the more appropriate license would have been the LGPL [gnu.org]. Yeah, yeah, RMS no longer likes the LGPL [gnu.org], but if I were creating a library, I still would LGPL it. However, I wasn't in charge this time :) and the choice of using GPL for a library has merits too.
Of course, it seems that Vidomi is confused: even though they might want the software to be LGPL'd, it isn't, and they are probably in violation because of the stricter GPL.
Vidomi's position (Score:5)
Automatic modification of GPL'd code possible? (Score:3)
It would be interesting to put it under the GPL (for the self-referentiality [absurd.org]...) and use it to modify GPL's source code so that effectively, it's GPL'd-ness could no longer be proven or even ascertained :-)
Then one could create legally interesting situations.
No harm intended/done? (Score:3)
It seems to me that their product relies on the features of readily available libraries, and for the convenience of the users, they were shipping them together.
Imagine you write an application in Java... the Sun JVM is freely downloadable, so you can expect the user to go get it himself. But for the convenience of the user, some companies bundle the JVM with the product. Not a really big licensing issue. And besides, for the GPL components, they are making the source code available.
This is like saying that any application that runs on Linux must be GPL'd because it relies on the open source platform. As much as we'd like that, the license does not actually require it.
I think this will be worked out without any litigation and that when everyone gets together and talks about it, they'll find everyone is within their rights.
--brian
DLLs and COM (Score:3)
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?
In cases like this, I think the courts must consider if MOST of the app's functionality is relying on the component, or just a small part. If it is a large part, then the program can be considered a derivative of a GPL'ed work, rather than a regular program take advantage of a small GPL'ed library.
Of course if they ship a binary that doesn't include ANY GPL'ed code in it, but the user is required to download the GPL'ed library to make the program work, tough beans. Otherwise, any program making use of any GPL'ed library on any Linux system must be GPL'ed, or it is in violation of the license.
-------
-- russ
"You want people to think logically? ACK! Turn in your UID, you traitor!"
It's funny... (Score:3)
Dancin Santa
Re:Inquiry? (Score:4)
Perl and gzip, on the other hand, are separate programs onto themselves, are called by your code at the command line level, so they run in separate memory spaces.
-----------------
Update from Vidomi (Score:5)