Slashdot Mirror
First Legal Test of the GPL
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."
Others have commented already on what happens if the FSF wins or loses this suit. What happens if they go ahead with it when there's really no point to it (as has been pointed out many times already)? Does the FSF risk making the whole OSS movement look like a bunch of sue-happy idiots that no one will want to work with?
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.
42. You agree that you will not diff the binary to check for similarities with GPLd code.
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?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.
>We recognize that Avery?s opinion is not binding
>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.
Hint: what you did in college may not work in a copyright infringement lawsuit.
4) Contact the copyright owner and negotiate a different license agreement.
-Yarn - Rio Karma: Excellent
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.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
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
Another important non-technical interpretation of this is intention. It seems quite clear that SloMedia turned the software into a DLL with the intention of circumventing the GPL. I think this will be more important than the spirit of the GPL, because spirit is vague and open to much debate, and no one at SloMedia was obliged to read RMS's writings to understand what he was trying to do with the GPL. But it is possible to pretty much prove what SloMedia's intention was (and hopefully the FSF will be able to do that).
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.
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.
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
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!
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
This makes writting proprietary code for Linux *very* tricky. How do you know you're not including some file which includes some file from either the /usr/include/linux or /usr/include/asm directories?
/usr/include/errno.h includes /usr/include/bits/errno.h, which in turn includes /usr/include/linux/errno.h But /usr/include/linux is a symlink to /usr/src/linux/include/linux, and the file /usr/src/linux/include/linux/errno.h is part of the GPL'd, not LGPL'd, linux kernel! So every program which includes has to be GPL'd!
For example, you include to handle POSIX errnos- a very common occurance.
I've not seen the libraries, yet, but are you sure they're GPLed and not LGPLed? It would make a huge difference, in all of this.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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
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.
> RMS (the gun-nut)
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
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.
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.
Actually dynamic linking to GPL code does make the linking program based on that code. There is no grey area when is come to the GPL. Linking in pretty much any form is a violation fo the GPL. Consider this... Let's say I take some GPL software break it down into various components, compile those as dynamically linked libraries, then write my own proprietary application that links to those libraries I created from GPL code. This has to be a GPL violation otherwise there is no GPL. It is possible that a court might decide this, but I would not consider that a good thing. Secondly, the existence of the LGPL implies that dynamic linking is a violation of the GPL, otherwise why would the LGPL exist. Dastardly
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
Bleh!
The problem with that argument is that you have to use the actual headers for the link. Thus the license breakage. If you were able to create your own headers independently that allowed linking, you would probably be okay for that reason. However, if you use their headers to create the link, you ARE including their program into yours.
Engineering and the Ultimate
If Microsoft was distributing it as part of IE, then yes, it would. In fact, you can't create a GPL plug-in for IE (well, at least you can't distribute the binaries). This was the same problem KDE had a while back before QT released their code under the GPL.
Engineering and the Ultimate
You can find more information about this at Advogato where one of the guys involved in this posts about his experiences.
It also contains some technical evidence as to which functions were lifted and how they know.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
Good morning boys & girls, can you say CLASS ACTION?
These guys are harming the whole community.
--- The reclining dragon deeply fears the blue pool's clarity.
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.
This space for rent. Call 1-800-STEAK4U
The SUN JVM in an interpreter/compiler, and is licensed such that works produced by the output of the compiler are not subject the the licensing of that compiler. This issue is about one program being included inside another.
This space for rent. Call 1-800-STEAK4U
I really dislike extremely misleading articles like this. Avery Lee said that he is asking for HELP to enforce the GPL with Vidomi, not that he's filing suit. There are other forms of help that do not necessarily involve litigation.
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 wrote a Type 1 MICR font (GnuMICR) by hand, as far as I know, the only freely available MICR font out there, and licensed it under the GPL. (Postscript is a language, my font is a "program", IMHO).
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.
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 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.
--Bob
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
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.
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.
>What if I take GPL'ed code and create a COM
>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
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
"this License, and its terms, do not apply to those sections when you distribute them as separate works?"
Oops.
COM) It all depends on your interpretation of "derived work". It's true that if significant functionality was derived from a GPL COM object, you'd be in trouble. (I don't know if Virtua Dub actually wrapped the DLLs in COM or not, but it shouldn't matter.)
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).
--
Business. Numbers. Money. People. Computer World.
Of course it would help! With the wonders of UTICA and DCMA, you can pretty much put whatever you want in licenses and have it be binding!
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.
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.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
merely because I viewed some GPL source
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.
He's not talking about copying the code in the sense of "cp gpl.c mynew.c", but he's copying the code all the same.
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.
From the first section of the GPL, describing the intent of the license:
...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.
does that mean ... you're bound by joe schmoe license that i invented c under??
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.
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.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
> However, if you'd like to use the GPL'd code in a program of your own
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.
Unfortunately this case, if it ever gets heard, will go up against one of the areas that the GPL is weakest -- dynamic linking.
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.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
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 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.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
Of course people are seizing onto the GPL's slippery definition of linking-- to add to the melting pot of opinions, the MySQL folk specify that you must pay them for a special GPL exception license if You have a commercial application that ONLY works with MySQL and ships the application with the MySQL server. This is because we view this as linking even if it is done over the network. e.g. any kind of reliance == linking. I'm not sure whether this makes the case weaker or stronger against dynamic linking as GPL-covered linking.
Matthew @ Bytemark Hosting
My home page http://www.csh.rit.edu/~benjamin/ has been entirly copied unto virtuadub's site. If they has ssi on you could see all of it. They must have liked the layout of my site that quite a bit. A wierd sensation wakeing up and seeing my website on some other server.
Do you changes clothes while making the "chee-chee-cha-cha-choh" transformation sound?
First of all, if you really could get around the GPL (say the Linux kernel) by writing a LGPL wrapper (glibc), then it would be pretty easy to just bypass the GPL.
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.
--
Every program ever written under linux would be a derivative work of the kernel, which is GPL.
*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.
--
i hope vidomi is forced to release their software source
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 only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
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
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
I believe he FSF saw this coming from the very beginning, that's why they came up with the LGPL. Vidori claims that they have released all the changes they've made to the GPLed code itself (the DLL) but those are exactly the term of the LGPL, no the bare GPL.
posting this? http://www.vidomi.com/index.php?artid=6#news
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?
You are wrong. Linux applications tend to use the GNU C Libraries which is LGPL - specifically allows closed apps to link against it (even dynamic linking require uses of the header files which are used to form the main application and therefore you have a derivative work).
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.
Of course it is a company like SloMedia. Sony and Cisco's lawyers would no doubt run a mile from the case knowing the likely outcome.
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.
They've already arguably agreed to the GPL and their users have the right to demand the source for their application under the license propegation.
;)
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
Yes, Brian allowed XFree to include it under their license but it was originally LGPL.
All this happened AFTER they GPLd it. NeXT spoke to the FSF and Stallman has this to say about what happened...
.o files, and let users link them with the rest of GCC, thinking this might be a way around the GPL's requirements. But our lawyer said that this would
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
It looks like Vidomi are trying to remove themselves from this while still allowing the code to be used with their closed source product. By decoupling the GPLd code into dynamically shared libraries and distribtuting them seperately, the GPL violation is less obvious but still quite present.
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?
> whether dynamic linking to a library makes something a derivative work in the copyright sense.
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.
>Which proves again,GPL is completely unusable in >commerical settings.
>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!
>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.At >least commercial entities do not claim to do >have a higher goal like FSF does.
>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.
>Agreed. The problem here is that FSF claims to >be on higher moral ground. They do pride >themselves in vilifying other licenses and >sometimes outright accusing others of limiting >freedom ( a very serious charge.)
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.
>There's also a possible: >4) Pay Avery Lee to license his work to SloMedia >(assuming he holds sole copyright). That is a really good point that I forgot. Thanks!
>It might seem tired and overused argument but >GPL really does force people into GPL
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!
It might seem tired and overused argument but GPL really does force people into GPL version of what software freedom is about.
No. Yes, the GPL embodies the concept of "Free" as used by GNU. Why is this a problem? Providing you agree with this definition and see it as a good thing, the GPL is a good choice of license. If you disagree with it, then you're not obliged to use the GPL. The authors of the GPL decided that preventing people from being able to release code released under the GPL in propriatory products was a lesser evil than allowing them to do the same thing, and as a result you can't. I agree with them, and by implication so does everyone that releases software under the GPL. I'm not being forced to do so, and you're not being forced to use my code - nobody is being forced to accept the GNU version of freedom.
But the whole idea of FSF and GPL is to do away with copywrited software and any limitations that come with it. Yet you are stubbornly defending GPL using laws this license was designed to destroy.
It's called pragmatism. Idealistically releasing code into the public domain would just result in corporations folding it into propriatory software. Releasing it under the GPL forces them to redistribute the source to the software and encourages them to view this as a viable practice. Over time, people's attitudes are changed.
Right. There's reluctance. It's unproven. It's new. But there's awareness. Without the GPL, we wouldn't have had that to the same degree. People would happily take free code and make propriatory apps out of it. The idea is not to get free code used everywhere, the idea is to get free code used everywhere while keeping it free. If that's not what you want, then fine - don't use the GPL. It's not being forced upon you.
So what's the difference between linking with a DLL and forking a processes that is GPLed - you can achieve the same levels of functionality. In Windows, the DLL and EXE file format are exactly the same. So renaming a .EXE to .DLL would be a violation of GPL? Taking this argument to it's logical extreme, any program that can create a pipe to another process could be in violation of GPL.
-- Virtual Windows Project
So how about this? I turn the GPLed library into a standalone program. In my non-GPLed program, I spawn a process running the library. To make a call, I send one line to the library program and get one line back as the answer. Ok or not?
The LGPL is the correct choice only if you want to allow your code to be used in commercial programs (such as Ogg Vorbis have chosen), which Avery Lee doesn't. The GPL was the right choice for him, and hopefully the courts will recognise the difference between the GPL and LGPL.
Actually, if he had the resources to fight Microsoft he might have won. I'm not sure what law prevents you from reverse engineering a file format!
That's the trouble with the law, and probably what Vidomi were relying on - that the guy with more money often wins regardless of the merits. I guess they wern't expecting the FSF themselves to get involved.
FYI that first "UTICA online" link you gave has a "myths" section that claims a lot of Stallman's concerns are invalid.
Among other things it says that UTITA wouldn't change existing reverse engineering law, and says that free software shouldn't be concerned about shrinkwrap licences beacuse a) it's OK to have a non-shrinkwrap licence/warrantee, and b) it's OK to have no warantee at all, like most free software.
I don't know the truth of any of this - just pointing out what the web site says.
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.
From the Linux 2.4 COPYING file:
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Just dropping in some useful reference info...
Someday, you're going to die. Get over it.
this merely says that if my program uses/extends gpl code, and also has legitimate non-gpl functionality (menu bar/tool bar/quit button don't qualify as legitimate functionality), then i don't have to release the code of my non gpl using program. i do however HAVE to release the sections of my code that use the gpl code.
Wrongo, boyo.
If you use GPL'd code in your application, and that code gets compiled into a binary or group of binaries that rely on each other to work, the entire code of that app must be GPL'd. This is the "viral" clause that the more virulent anti-GPLers point to as a reason not to use it.
Let's say you have five source files going into a single executable. Two of those files include chunks of GPL'd code from, say, parted (just a shot in the dark). Since identifiable sections of the work are derived from GPL code, the derived work must be distributed under the GPL.
The LGPL might let you get away with that little trick, but not the GPL. The FSF recognized this issue and came up with the LGPL as a less-restrictive alternative.
.
Someday, you're going to die. Get over it.
Their website is driven by php-Nuke, a GPL'ed weblog, and all credit has been stripped on that as well... except for the page source:
META NAME="AUTHOR" CONTENT="Vidomi"
META NAME="COPYRIGHT" CONTENT="Copyright (c) 2001 by Vidomi"
META NAME="DESCRIPTION" CONTENT="PC Video"
META NAME="GENERATOR" CONTENT="PHP-Nuke - http://phpnuke.org"
Everyone will start to cheer when you put on your sailin' shoes.
The first intelligent comment on this thread so far.
War is necrophilia.
No. It was a *patent*. Learn something about the law before contradicting Vergil Bushnell. Patents work like this: One person invents something, and files a patent on it. If the patent is granted, nobody can use that invention without paying her. Even if the reverse engineer it, or independantly invent it.
Become a FSF associate member before the low #s are used
What, when it comes to it, is the difference between a Library, and a complete executable called from within another application. Does the GPL make a clear distinction?
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
"Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
If you had a closed source application, with a plug-in architecture, and somebody made a GPL plugin, then how does the GPL view this? The closed-source app is now making use of GPL code, however the programmers did not intend this obviously.
Now in the Vidomi case, their application replies heavily on the GPL code for a lot of its functionality, whereas in this case the GPL code is only adding some extra user-desired functionality. Now how if the GPL plugin added some great functionality, then I do not think that the plugin could ever be distributed as a part of the application, nor the application advertised as having the GPL'd plugin's functionality, otherwise the GPL would be being broken.
Still, expect Vidomi to argue that it is a plug-in, and that contrary to the application making use of it, it is in fact the reverse - the applications plugin API means that the GPL plugin is in fact making use of the application!
As for the Vidomi case, it is clear cut. They are breaking the GPL. DLL or not, it is providing core functionality to the software. Konqueror works without kHTML (albeit it does nothing!), their software works without the GPL'd DLL (barely, it appears).
The code is not LGPL'd, which would allow the software to link to it, it is GPL'd. Now I am a BSD man myself, but I respect the wishes of people who want to use the GPL to share their work in an environment where other people can use it as long as they don't change it or share their changes with the copyright holder - the author, and follow the GPL in its entirity (excepting special excusions granted by the author).
Vidomi has made the GPL code available, but they haven't followed the GPL in its entirity, and the author has not made any special exclusions. This is the kind of small case that the GPL needs to set a precedent before taking up the larger GPL abusers (allegedly).
It is hard be be clear and to the point when doing law stuff. That is why I am a programmer, not a lawyer. And can't /. make this text area bigger? :)
Also, they are arguably core OS utilities as well. If you took a non core OS GPL utility (say an application that did X), and wrote your closed source program that called X for part (or all) of its functionality, then provided that program as part of the distribution, then what is the situation? The program isn't linked in to your own program in any way, however your program is arguably a derived work. The same goes for pipes and CORBA, etc.
The GPL has to sort these issues out now - GPL software distribution terms and conditions, like:
You may only distribute this code/application as part of a GPL'd application unless the code does not provide functionality to said application, but rather provides an additional facility. (e.g., supplying emacs with a ray tracer, or something).
"If [proprietary sections] 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 [proprietary] sections as part of a whole which is a work based on the [GPLed] 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."
The question then is "does dynamically linking to GPL code automatically make the linking program a work based on that code". I can imagine a case where proprietary standalone tools were developed, each dynamically linking to the same GPLed library for some functions. These tools, or sections of proprietary code, could be "reasonably considered independent and separate works in themselves". Why then is an application (which is nothing but a much larger "section" of proprietary code) automatically infringing on the GPL if it also links against a GPLed library? If *none* of the code within the application is a derivation of GPLed code, then isn't that an "independent and seperate work"? Seems like there is still a grey area here.
It's 10 PM. Do you know if you're un-American?
I see you're not responding to flames, so I will try to keep it civil. Do you intend to go to court over this matter? If Avery decides to sue that is?
How we know is more important than what we know.
Ok, let's flip the page then.
Let's say I write a windows printer driver and GPL it. Using your logic, MS Word would have to be GPL'd, because word could use my printer driver.
This is, obviously, silly.
I have a feeling that another liscense will have to be created for 'interfaces' -- because what we really have here are 3 things:
* code
* libraries/programs
* how to call the code in the library
The GPL covers code and programs pretty well. The LGPL was meant to address libraries. But nothing has ever mentioned the interface to the library; the assumption that the interface is mated to a specific library and only that library is blatently false.
Something that uses an interface to a library is not a derrative work of the interface; it just uses it. Something that implements an interface would be a derrived work from the interface.
From a different angle (some answers I think would be 'yes', others 'no', however I think you'll find that the question is far more subjective than some make it out to be)....is a car a derrivative work of an engine, or does it just use it? Is an engine derrived from gasoline? Is gasoline a derrivative work of crude oil? Is a tranmission a derrivative work of an engine? Or is it a derrative work of the drivetrain? Or is the drivetrain a derrivative work of the tranmission? Is my word processor a derrivative work of the printer drivers it uses to print on? How about the display drivers? What about the fonts? What about the library which renders the fonts on the screen? Is netscape a derriative work of a webserver? What about a gif library? Or a jpeg library? It certainly uses them, but could the browser exist without gifs or jpegs?
But, there is another issue to keep in mind:
There is very little precedent for people putting out their source code and allowing other people to make derivative works.
Thus, this issue does not come up in an example like that. Standard proprietary development is done under contractual restrictions.
So, we've got monied interests on one side, and people who want freedom on the other. Personally, I'd say to give it to the good guys.
Of course it would help! With the wonders of UTICA and DCMA, you can pretty much put whatever you want in licenses and have it be binding!
I know this was tongue in cheek, but does Avery live in MD? It would be interesting to see if we could (ab)use UCITA by enforcing the license under that.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
At least it's a company like SloMedia, not Sony or Microsoft. I doubt SloMedia has the same legal resources as Cisco, for example. IANAL;TINLA (I am not a lawyer; This is not legal advice), but it seems like a common legal technique is testing your suits in easy cases to set a tentative precident, which gives you more power in later cases. So in the grand scheme of things, this is probably good for the GPL.
-Ted
I'm not intentionally trying to be a troll so bear with me.
From what I can tell the majority of the pro-GPL arguments seems to be the owner of the copyright chooses the license by which distribution and use of the copyrighted material is controlled. Now the argument in this particular case is the vendor is violating the GPL by only providing the modified GPL source material while keeping the rest of the code propietary. The argument goes since the GPL'ed code is central to the overall program, the rest of the code should fall under the GPL.
Now here goes the potential troll section.
The originator of the GPL'ed code is controlling the distribution of the GPL'ed code by dictating the terms by which the code can be used. If I were to write a license so the material can only be viewed by an approved viewer, according to the main argument expressed in the comments written by pro-GPL commentators, how could a user view the material by an unapproved viewer? The fact the viewer may not be used with the user's favorite tool is immaterial. The user can always get an approved viewer. Fair Use would not necessarily apply because the user has access to an approved viewer, not necessarily a convient one.
For those who haven't figured it out, IANAL and the case I'm talking about involves the MPAA. Personally, I think what the MPAA is doing is stupid and things like the CSS and the regional codes should go away. I don't think I like the viral nature of the GPL because I think it overly restricts the options of the developer. By dictating the terms by which code associated with GPL'ed may be distributed, the GPL is forcing the software to be open not by the superiority of Open Software Process but because of strong arm tactics. Open Software should stand on it's own not be propped up by methods by which Open Software proponents would ordinarily decry.
RSwan
I think the really interesting question here is will the suit seek to force SloMedia to remove their use of GPL'd code, or whether it will attemept to force them to open up their code.
At least according to the VirtualDub fellow's Web site, Vidomi's software is linked to his code as libraries, and is non-functional without it. (They offer a fig-leaf "independent" option that apparently does nothing useful).
Linking to GPL'ed software for its vital program functions means Vidomi's code is NOT an "independent and separate work", and thus is subject to the GPL on the libraries it depends on.
Seems like a smoking gun to me, assuning the VirtualDub fellow is right (and he seems to know what he's talking about).
"My strength is as the strength of ten men, for I am wired to the eyeballs on espresso."
Unfortunately for the principles at stake in this case, I tend to agree with the publisher of the software using the GPL'd code in DLLs that they're not violating the terms of the GPL license.
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.
I am no fan of the GPL but you are completely wrong and the GPL stands on solid footing on this issue. The independent excemption in the GPL applies if the works "can be reasonably considered independent and separate works in themselves" Just because something links to the kernel doesn't mean it is a derivative work, because the code could be "reasonably considered independent." You could compile the code for a different (POSIX compliant) kernel. In the case of kernel modules you are simply utilizing a service (no different from a TCP/IP request to Appache) of the GPL'd application, not creating a derivative work. In this particular case, Vidomi's work is clearly derivative and an extension of the GPL'd work. Their intent of the DLLs was to circumvent the GPL. They will lose if this ever gets to court.
Someone you trust is one of us.
Ah, but RedHat's distribution is not a work "based on the" individual GPL components.
Someone you trust is one of us.
If you wrote a COM object in a DLL and used the strict GPL with no ammendments (say like Linus' ammendments to the linux kernel's GPL), nobody could use the DLL without beign GPL'd. Now, if you stated in your licence that use of the IDL methods (public API) was excempt, things would be different. The client/server case would not violate the GPL because in the client/server model the client and the server are recognized to be independent programs (your browser is a different program from the web server). However, if your client server model were something a DCOM server and a DCOM client, they would fall under the GPL, because the same portion of the Program (the DCOM object) exists in both Programs.
Someone you trust is one of us.
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!
Someone you trust is one of us.
Whilst I thought I understood how the GPL works, judging from many of the threads here, apparently I don't.
Some possible cases:
Software loads a KDE lib to do something. Can this software ever be proprietary since KDE is GPLed?
Software links against glibc. Must it then only be GPL?
I was under the impression that a piece of software could use GPL libraries as long as said libraries were not shipped with the product itself: any enhancements made must have the code published under the GPL BUT any GUI or unrelated (to the GPLed code linked to in the library) component of the system can be proprietary. If this is correct, then this presents a special issue for proprietary products since they often link against other 3rd party libraries over which they have little control. Is it possible then for somebody who has accidentally linked against a GPL library to now be liable for making all their code public? I admit this is perhaps more of an issue for Windows programs as they can load libraries at anytime either directly or through COM.
If I wrapped a GPL component with a wrapping layer, publishing that wrapping layer under a "GPL compatible license" would this then satisfy the requirements? Or, as I understand from what this person is claiming, is there no way to publish software that uses GPL code (library format or not/ directly or indirectly) and make it proprietary.
I think it would help A LOT, for people wanting to develop proprietary software for Linux, if there was an authoritative faq somewhere on the does and don'ts, what is expected by the community, and how to publish. I'm interested in writing software for Linux even though all my experience is in Windows. I dont' really expect to ever publish anything that would be worthy enough to sell for money and don't mind sharing my code. But if I ever did come up with a realy nifty idea and wanted to cross platform it, such a faq would help me a lot.
Do not spread "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0" over the internet, thank you.
What jackass marked legal analysis from someone who doesn't even know what the term is "insightful"? Am I misunderstanding that term? I thought it meant that the posting displayed some innovative thinking, originality, and was interesting in that it pushed thinking in a different direction. I was unaware that the term meant "inaccurately regurgitating arguments made by someone else".
I think that as long as your "new" source code is merely a straight machine-translation of the original, and still performed exactly the same function, it would be pretty easy to argue in court that the "new" source code is still equivalent to the old. (An aggressive lawyer would go after you for attempting to willfully violate the license terms.)
You'd have to manually add or change functionality to claim creative control over the "new" source code, and given the way the GPL is written, as long as you have any original GPLed code left in the source code (translated or not), you're still in violation.
Of course, in the absense of perfect formal verification tools which can match the functionality of two programs regardless of naming, your "technique" would probably make it difficult for people to easily tell that you were violating the GPL. If it came down to a court case though, I wouldn't count on a simple translation to protect yourself.
Hey! I released this code under the GPL:
int main (int argc, char **argv)
{
}
Your work is quite plainly derivative of mine, therefore you MUST release it also under the GPL!
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 ' FIGHT THE POWER!!!!
Remember guys, this is Amerika. Just because you have the most votes, doesn't mean you get to win.--Fox Mulder
And if the FSF loses, it won't be that big a deal... GPL 3 would just have to include a clause saying "no dynamic linking with a non-GPL program"
Actually, that would not help at all.
If something is not a derivative work, then the license of some other program is irrelevant,.
Programs under GNU/Linux are not linked against the kernel.
...
System calls are not in libc, they are exported directly from the kernel. Things like select, open,
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.
They provide the source code to the GPL libraries. Anyone can take those for at most a copying fee. So the GPL programs do not form part of their intellectual property on which sales could be based.
This case is clear and simple, and it comes down to the question: If I make a program that dynamically links to another, is my program a derivative work of the linking program ?
Think in terms of component models and independence of components. If all linking programs are derivative works, then there is no intrinsic independence of copyright in computer systems at all. That is the statement upon which the defense will call upon human judgment to question the sanity of the FSF lawyers.
If you put a lot of work and time in your program, and all you want is that the program's source code remains available for everybody, and some company disrespect that wish and steals you code without releasing it, would you he happy about that?
This is not about placing GPL code in proprietary closed works.
This is about whether dynamic linking makes something a derived work.
Vidomi is providing source code to all programs that are GPL'd and is dynamically linking to them with their own code.
Does dynamic linking make something a derivative work in the copyright sense ?? I don't think it does.
Furthermore, the license of the GPL explicitly states if a program requires the GPL'd code to produce it's intended results then it is a derived work.
If dynamic linking does not make a program a derived work, then it matters for shiit what the GPL says. No license can apply to something that is not a derivative work of the licensed work.
Everyone needs to keep in mind that copyright does not protect functionality - it only protects expression. Copyright does not protect against reverse engineering. If I code against an API and make my binary, is my program a derivative work of the library providing the API ?? How about if there are multiple programs that could provide the API (such as Lesstif, Motif) ?? Is my program a derivative work of Lesstif when I link to its library, and a derivative work of Motif when I link to its library ?? How can that possibly be the case ?
How about if I use C function calls and change the LD_LIBRARY_PATH ? Does my program's licensing change ??
This is not even so difficult conceptually. APIs are NOT protected by copyright intrinsically - only the expression in the source code is. Inasmuch as library functionality can be legally reverse engineered, and the linking program doesn't need to know who wrote the dynamic link library in order to use it, these are independent in the copyright sense.
In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.
US Copyright law provides no protection against ideas, methods, or functionality. It only protects expression. If I have a copy of your copyrighted work, you would need to have an EULA to protect against any usage of its functionality.
Put more simply, you cannot protect functionality with copyright. An additional contract is required, and this is the entire point of an EULA.
The GPL and LGPL and BSD license and artistic license have no contracts. Each grants the user more rights than those intrinsic to copyright, but each takes away NO rights. There are no intrinsic rights in copyright protecting usage. See US Copyright Law 102b.
Just because something links to the kernel doesn't mean it is a derivative work, because the code could be "reasonably considered independent."
Thanks for making my point. Something that requires an API, but not specific expression used to generate that API, is not a derived work, and thus the license of the program providing the API is irrelevant.
In this particular case, Vidomi's work is clearly derivative and an extension of the GPL'd work. Their intent of the DLLs was to circumvent the GPL.
I think they will argue the intent of the DLL was to make a clear separation between the API provided by the GPLd work and the code that they generated in house to provide additional functionality. Anyone may download the GPl'd code - thus it cannot form a substantive part of Vidomi's intellectual property. The IP is only the in house proprietary portion of the code.
Copyright does not protect ideas and methods embodied in the copyrighted work. In that sense, I do not think library APIs are protected by copyright law.
Now, get yourself an EULA, and everything may be different...
The GPL cannot be more specific on issues like this - it is beyond its control.
The GPL only applies to copyright issues. If another program interfaces in some way with a GPL program, but is not considered a derivative work, then the interfacing program is not bound by the GPL. Period. There is no re-wording of the GPL that will affect this in any way. GPL is limited by copyright. Copyright can only affect other programs that are derivatives.
The entire question of this lawsuit is whether using a dynamic link library makes something a derivative work. Consider - in many cases you can change the DLL but preserve the API without changing the function of the program. In those cases dynamic linking is clearly NOT making something a derivative work.
In other cases it may be less clear.
This will be a test of the weakest portion of the GPL that is assumed to be defensible by the FSF - whether dynamic linking to a library makes something a derivative work in the copyright sense.
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).
I don't know if you are trolling or if you really believe this, but you're completely off-base. A short bit of research at http://www.findlaw.com/ should be sufficient to set you straight. Copyright on source code applies to the code itself - NOT to the underlying algorithms. Just as, for instance, the copyright on "The Hunt for Red October" prevents me from actually copying any lengthy section of that book, but does not prevent me from writing my own novel about a russian submarine captain trying to defect...
If you implement a program using an algorithm you saw somewhere else, but without actually copying any code, you're legally in the clear. Of course, employers may want their employees to do even more than is absolutely legally necessary to avoid the appearance of wrongdoing. There is some guesswork involved in whether or not a court is going to believe that a given work is "derivitive" of another, and if one can make a good case that no one working on project a ever saw the code from project b that could put an end to a suit rather quickly. Otherwise, it might drag out longer and be more expensive to defend. So it does make sense for a microsoft to prohibit their NT coders from even reading linux source for instance. But it's not at all a legal requirement for them to do that.
"That old saw about the early bird just goes to show that the worm should have stayed in bed."
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Your code does something like this:
main()
{my_get_info()
my_code_do_this(info)
my_code_do_that(info)
if (desired) call gzip(info)}
Their code looks more this:
main()
{call restrictive_liscence_scare_consumer()
call cheesy_advert_flash_screen()
call renamed_GPLed_code()
call another_renamed_GPLed_code()
call GPLed_code()}
Your work does something. Theirs is clearly derivative, if not just hijacked, or dare I say "pirated" as most comercial software vendors would? There's a big difference between using a utility like to do something for your program and what they did, which is to rewrap virtua dub so they could sell it.
Rotten tomatoes on you SloMedia!
Friends don't help friends install M$ junk.
OTOH, it's pretty easy to write down a list of function names and signatures, and have somebody else independently write new header files. Function names and parameter order are purely functional elements (like numbers in a phone book), and are not subject to copyright. If they actually did this, I think the judge would buy it.
-- ;-)
Kuro5hin.org: where the good times never end.
IMO, this case comes down to whether SloMedia used VirtualDub header files, or created their own headers from scratch. In the former case, they are screwed, and in the latter case they are not.
-- ;-)
Kuro5hin.org: where the good times never end.
Amen. The only way RMS will be able to distinguish userland-loaded binaries from kernel-loaded binaries is if the judge doesn't understand him.
-- ;-)
Kuro5hin.org: where the good times never end.
-- ;-)
Kuro5hin.org: where the good times never end.
-- ;-)
Kuro5hin.org: where the good times never end.
Before pursuing them in court, the author should offer to license the code for use in a closed-source product for the price of $5 Billion (or a similarly outrageous figure). The company will, quite sensibly IMO, be unwilling to pay the price. At this point, he has actual monetary damages (at least according to the BSA and, apparently, US courts) to sue for. IANAL, but it seems pretty open and shut :-).
.sig: file not found
now's the time to sit down, strip out all the comments, re-arrange a few algorythms and re-name the variables. duh.
They're releasing the code for the dll, but not the program that links to it.
But as the GPL'd library is not necessary for the operation for the main program, the main program could be considered an "operating system" for the library, which would become an "application." Running copylefted applications on a proprietary operating system is common; just look at GNU Emacs for Solaris and Windows and some popular plugins for Winamp. Read More about the operating system loophole in the GPL.
Will I retire or break 10K?
Can the terms of a license agreement require that licensees give up arbitrary rights pertaining to things other than the licensed code? Suppose you buy a piece of software and after installing and using it for a while, you decide to read the shrinkwrap agreement. You discover to your horror, that by running the software you agree to give your first-born son to the software company.
Legal. Know the real reason that AOL is blocking Jabber transports from accessing the AIM network? The AIM4 EULA contains language to the effect: "You may not use unauthorized client software to access AOL's servers." Yes, strings are often attached to licenses, and I still use AIM3 (holes and all) on my winbox because its EULA doesn't have such obnoxious terms.
Will I retire or break 10K?
If I have a copy of your copyrighted work, you would need to have an EULA to protect against any usage of its functionality.
Not if you're using it to provide a service to which the public can connect, such as running a server daemon. The courts would probably interpret that as "public performance" of Apache, mod_perl or PHP, MySQL, and whatever nuke/slash/scoop/everything/other weblog engine you're using.
Will I retire or break 10K?
IANAL, but IMHO the GPL and FSF allow this. BTW, HBO ran D.A.R.Y.L last night. LOL.
People shape laws. Not the other way around.
1) they don't understand the difference between gpl and lgpl. 2) they think gpl means "open source" (look at their site!) 3) they don't understand that they could solve this by working with the author. must be embarassing to sift through the gpl and construe meaning that isn't there. i think the court would agree that the strongly worded gpl and lgpl definitions far outweigh the "seperate distribution" course they are trying to take. RMS has said many, many times that you absolutely may not treat a GPL lib as an so/dll w/o releasing your linking code. it's in print all over the fsf site.
Treatment, not tyranny. End the drug war and free our American POWs.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
If Microsoft were to advertise that certain features were available in Internet Explorer by way of third party plug-ins that just happened to be GPLed, would this force IE to be GPLed itself? I don't think so.
If the GPL isn't legally binding in this situation, it doesn't matter what the writers meant or what their emotional state was when they wrote it.
Of course it does.
Rate me on picture-rate.com
"and dear god does this website suck now." -- CmdrTaco
If Vidomi wins this case, then Trolltech may decide to reevaluate their position...
This could get interesting. There could be a compromise perhaps- if vidomi can come up with a plugin for their app that can substitute for the GPL library, which would became a separate download...
This is a half-assed and noncompliant solution. It's sufficient to purposes if your code is LGPL, but not GPL.
/Brian
They're trying to pretend the code they're using is LGPLed and putting the questionable stuff in DLLs to get around the letter of the license.
/Brian
Even though reverse-engineering (for the most part, DMCA excluded) may be a legally-sanctioned practice in the US, UCITA has a sinister way of blocking it.
Specifically, UCITA gives software publishers wide lattitude to create so-called "contractual use restrictions" -- such as the "no reverse engineering, decompilation, etc" clauses that appear in most EULAs.
Since anyone using a EULA'ed program "agrees" to the terms of the license agreement, reverse engineering becomes not a matter of copyright, but a contractual issue.
Insidious, eh?
Sincerely,
Vergil
Vergil Bushnell
Insects and Grafitti Photos
Theoretically, your assertion about contracts is valid. The legal term "contract" means "meeting of the minds."
However, in the case of mass-market, boilerplate shrinkwrapped EULAs, there really isn't any meeting of the minds. If I download or purchase software as a consumer, I don't sit across the table from the software publisher's lawyers and hammer out a mutually agreeable resolution. EULAs are considered "contracts of adhesion" -- meaning they're unilateral, take-it-or-leave-it "agreements".
Before shooting your mouth off about "communists", why don't you take a look at a few software EULAs (I've put up a few here).
sincerely,
vergil
Vergil Bushnell
Insects and Grafitti Photos
Here's a little summary of the VirtualDub/ Microsoft patent dispute with links to more comprehensive articles.
Sincerely,
vergil
Vergil Bushnell
Insects and Grafitti Photos
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". 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.
--
Friends don't let friends use multiple inheritance.
And perhaps you wouldn't look like such a jackass on Slashdot in the future if you actually clicked the link that I provided in the parent comment, which is NOT simply giving credit. It is also offering the source of the code in question for download, along with whatever modifications that they made to it.
Sheesh, the posters here are getting dumber every time I come back...
--
Friends don't let friends use multiple inheritance.
It has already been argued elsewhere here that they in fact did not comply with the GPL. They complied with the LGPL, but not the GPL. That is an important point, of course, the crux of the argument. Vidomi seems to be playing dumb, and Lee seems to me to be morally and legally justified; he is outraged that Vidomi used his code in a way that violated his understanding of the license, which, IMHO, is the correct interpretation.
So I dispute your premise that Vidomi is legally in the clear here.
Look at it this way: If Lee instead decided to sell his software, and Vidomi took it and used it as a reasonably large element in their tool - strike the 'large' part, it's irrelevant - would you not expect that under traditional business law, Lee would be entitled to compensation? Vidomi would be sued and lose. Now, Lee entered into the GPL, which, if you read the text of the agreement (or any of a number of posts here), clearly points to exactly where Vidomi was in the wrong. Lee believes this, FSF should (I ain't got all day to follow this story), and a number of people here and elsewhere (hopefully on the bench of your local court) agree with them.
SDMI: Finally! Music that won't rip or burn! Brought to you by the fine folks at RIAA.
...I really like this retort, from the discussion page at Vidomi, entitled "You Just Don't Get It":
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!
SDMI: Finally! Music that won't rip or burn! Brought to you by the fine folks at RIAA.
Believe it or not, I know about glibc and its license. But...how is glibc implemented? In terms of kernel system calls. glibc is (in part) a wrapper around the kernel. So we have:
So, to clarify my original question: How goes glibc pull off the magic trick of being an LGPL library implemented using GPL underlying code?
--
When all you have is a hammer, everything looks like a skull.
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.
--
When all you have is a hammer, everything looks like a skull.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Well, that's what it looks like to me.
RMS (the gun-nut) has an article on this topic which may be useful.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
It seems that the code in question was released under the GPL, 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. Yeah, yeah, RMS no longer likes the LGPL, 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.
These guys make tools to rip movies... 'nuff said.
It would be interesting to put it under the GPL (for the self-referentiality...) 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.
As a state gets corrupt, its laws multiply; the most corrupt states have the most numerous laws. (Tacitus, Annales 3:27)
And the "recently" links to a 9 month old story. Come on guys, we've had plenty of false alarms more recently than that --like yesterday!
Unsettling MOTD at my ISP.
That it is still a violation regardless of whether or not it is a dynamic or static link. That's why there is an LGPL. Think of Trolltech and Qt right now. Their library is GPL, and almost every application is dynamically linked to it. I'm sure the outcome of this case will be *very* important to them. If the GPL doesn't hold water for dynamic linking, then we may never see another GPL'd Qt.
People/companies depend on the GPL. And Vidomi needs to play by the rules.
-Justin
Dynamic linking could be an easy-out for companies, and this would not be good for the GPL. If a company wants to extend a GPL program or include some its code, they could just put the guts into a shared library and now they have circumvented the GPL. This is BAD. The viral effect is now completely gone. We might as well license everything by the BSD license then.
Also, certain programs make more sense to be dynamically linked. Like most libraries. Does this mean there can be no GPL libraries? Do you know how screwed over Trolltech would be if the GPL didn't apply to dynamic libraries?
Dynamic linking MUST be covered by the GPL (and it is) otherwise it could be used as a loophole.
-Justin
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
What if I take GPL'ed code and create a COM 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?
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!"
Natural != (nontoxic || beneficial)
If I write a prograg that uses one file(compiled) that has GPL'ed code then, that file is subject to the GPL any other files that do not contain GPL'ed code are NOT SUBJECT to the GPL.
but it's true. Binaries can't really be diff'd for similarity. You can say I stole your code, but I can say I just reverse-engineered your code without ever looking at the source. A few perl scripts later, and I've got a set of source files that don't look anything like the originals. Any similarities can be chalked up to similarities in the problem domain.
Dancin Santa
Doesn't the GPL stand on the same ground as all the ridiculous new EULAs floating around? I mean, I bought a pieces of software that said I have to a) register to use (or it expires in 7 days), and b) that I can't sell or even give away when I don't want it any more! Apart from the obvious (What happens if the company goes out of business and I have to re-install the damn thing?), if they can actually enforce that kind of garbage, then I don't see how anyone can legally voilate the GPL either. I'm sure Vidomi has a nice EULA of their own. It seems like Open Source wins if GPL triumphs, and if not, then consumers can tear up their EULAs! Xesdeeni
It's copyrights that apply to implementations; if implementations were the only things protected by patents, everyone who wrote their own LZW implementation would be immune to the Unisys patent on the GIF format, and there would never have been a "Burn all GIFs" movement.
--
Having 50 karma is an itchy feeling; I know I'll get
Scientists restrict study to entire physical universe; creationist
It's VirtualDub, not Virtuadub. And the homepage is here not virtuadub.org. Do the slashdot editors even click on the links submitted to them anymore?
Finally, Open Source has a business model: the lawsuit!
If you fall off a building, go real limp, because maybe you'll look like a dummy and people will be like hey, free dummy
We are attempting to deal with this GPL issue openly and with integrity. We emailed the FSF almost two weeks ago, requesting their input, and have not heard from them. We are disappointed that so far we haven't been able to engage with them on this issue. We are actually hoping that the increased exposure of this issue on Slashdot will help move this forward. Just yesterday I emailed Avery Lee, author of virtualdub, with an update on our recent activities and an outline of another possible change in how Vidomi interacts with GPL code, with the goal of determining if he felt this approach was GPL compliant. We recognize that Avery's opinion is not binding on anyone, but it is certainly something we value. We've also been communicating privately with a number of people who have expressed concern about the issue and have been willing to offer their constructive input. We welcome further constructive input and hope that this situation is fully resolved very soon. dean@vidomi.com
What Slashdot definitely lacks is an equivalent of Kuro5hin's Meta forum where Slashdot-relevant things could be discussed. Then one wouldn't have to file legitimate complaints like this one under other topics, they wouldn't get moderated to Offtopic or Troll, and maybe they'd even get read...
Otherwise, there can never be a sensible discussion among Slashdot users how Slashdot community problems might be solved.
There is absolutely no reason to panic.