Forgot your password?
typodupeerror
GNU is Not Unix

First Legal Test of the GPL 524

Posted by CmdrTaco
from the its-only-a-matter-of-time dept.
Trepidity writes "In stark contrast to the plethora of false alarms recently, there's a pretty clear-cut case that Vidomi, a DVD ripping product by SloMedia, is composed of a great deal of code from VirtuaDub, a GPLd product. As SloMedia have refused all requests to either release their source or stop using the code, the developer is planning to file suit with the aid of the Free Software Foundation, in what could be the first legal test of the GPL's enforceability."
This discussion has been archived. No new comments can be posted.

First Legal Test of the GPL

Comments Filter:
  • by Anonymous Coward
    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?
  • by Anonymous Coward
    Yeah, but let's be honest - this is one of the more questionable parts of the GPL. The GPL itself doesn't say anything specific [IIRC], but RMS has decided that dynamic linking in a DLL is not OK, but dynamic linking to non-GPL OS functions [at load time] is OK, which is a completely arbitrary distinction based more on intent than on actual technical differences.

    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.

  • by Anonymous Coward
    You don't need to waste time renaming functions and variables. All you have to do is bury a clause in the click-license legalese that says:

    42. You agree that you will not diff the binary to check for similarities with GPLd code.

  • by Anonymous Coward
    I'd like someone in the know to please clarify what is and is not a violation of the GPL. The part I'm getting stuck on is the separate/independent clause.

    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?
  • by Anonymous Coward
    For EVERYONE's sake, let's hope that Vidomi is correct and that dynamic linking does NOT make something a derivative work.

    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.

  • by Anonymous Coward
    >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.
  • by Anonymous Coward on Wednesday May 23, 2001 @10:31AM (#202754)
    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.
  • by oGMo (379) on Wednesday May 23, 2001 @11:51AM (#202757)

    While IANAL, it's obvious you're going on mostly hearsay, popular opinion, and misunderstandings (whether intentional or not). Let's see:

    Consider that libraries are CREATED with the intent that someone else will use the API and header files.

    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:

    I have never agreed with RMS (and Trolltech's) assumptions that dynamic linking makes something a derived work.

    Your opinions on the matter don't affect the matter, of course. Save this thought for later. Going on:

    It would certainly make ALL third party software vendors beholden to OS vendors, for example.

    Hmm, better not give software vendors any bright ideas here.

    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).

    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.

    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).

    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.

  • Why not? Why would IE be _entitled_ to someone's third party plugins just for existing? I see no problem with the position that if they want to play proprietary software, it should be possible to make a license for stuff they _cannot_ take advantage of, and therefore they must reverse-engineer and/or separately develop anything from scratch.

    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

  • Something basic like Qt or GTK is likely enough to be on the computer already that you don't need to distribute it with your binaries, so binaries that link against it are not considered to be derived works.
    This isn't the case. GTK is LGPL, so it doesn't matter. Qt most definately is not LGPL -- of you are writing a proprietary program, you cannot link it against Qt without purchasing a seperate license. This is irregardless of the ubiquity of the Qt libraries.
  • 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).
  • by Ian Bicking (980) <ianb.colorstudy@com> on Wednesday May 23, 2001 @10:09PM (#202762) Homepage
    There's also a possible:
    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.

  • by Danse (1026) on Wednesday May 23, 2001 @12:20PM (#202765)

    Nope, you got it wrong. It is GPL proponents who are outraged at corporation for their EULAs and yet they are using the very same methods.

    Not even close. You can do whatever you want with a GPL'd program as long as it doesn't violate copyright law. You don't even have to agree to the license. However, if you'd like to use the GPL'd code in a program of your own, then you can do so by agreeing to the GPL which states that you must release the source code to the resulting derivative program as well.

    Contrast that with standard industry EULAs which routinely take away all sorts of rights such as publishing benchmarks, using the program in a way that criticizes the maker, making backup copies, running the software on more than one machine, etc. It becomes quite ridiculous. There is no real comparison between the GPL and EULAs. At least with GPL'd software you can use it without having to agree to such a ridiculous licensing agreement. If these corporations put this many restrictions on simply USING their software, imagine what kinds of restrictions they would put on using their source code!

  • This 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?

    For example, you include to handle POSIX errnos- a very common occurance. /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!
  • 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.
  • Vidomi's software is quite obviously a derivative work of VirtualDub, in that without VirtualDub's software Vidomi's doesn't do any of the things that it is advertised as being capable of.

    An appropriate metaphor would be if I wrote down my time-honored recipe for toasting bread and then created a cookbook containing this recipe and 400 other recipes straight out of the Betty Crocker cookbook. I could use this cookbook all I wanted to in the confines of my own house (fair use), but if I tried to sell copies of this cookbook it would rightfully be described as a derivative work.

    The GPL states that any time that you link (dynamically or statically) a piece of GPLed software you are creating a derivative work. That is why BSD advocates get so excited about GPLed libraries like GNU readline. They know that GNU readline is cool, but linking your software with it forces you to release your software under the GPL because it is a derivative work.

    This is also why most GNU system libraries are licensed under the LGPL (a completely different license). Here's a link from the newly created GPL FAQ [gnu.org]

  • 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
  • Most likely outcome is that they will get the authors of the original code to agree to sell/donate it under a different license to them. This will look like a win for everybody.

    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.

  • I think the LGPL can cover your "interfaces" problem just fine.

    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.

  • Sorry, the reason your non-GPL program can call fopen() is that fopen() is under the LGPL, not because other systems have an fopen() call.
  • by Dastardly (4204) on Wednesday May 23, 2001 @01:20PM (#202782)
    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
  • Is that Avery complied with Microsoft's request. He might not have agreed with it but he did remove the offending code and binaries and moved on. Now he's on the opposite side of a similar issue and he can't get any kind of respect from the offender.

    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

  • 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.
  • 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.
  • by Uruk (4907) on Wednesday May 23, 2001 @10:28AM (#202787)
    You can find more information about this at Advogato [advogato.org] 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.

  • Good morning boys & girls, can you say CLASS ACTION?

    These guys are harming the whole community.
  • 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.

  • 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.
  • by John Fulmer (5840) on Wednesday May 23, 2001 @12:29PM (#202791)
    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 [dyndns.org]) 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.
  • well, no, my analogy doesn't work when you misread and/or change it. I specifically said "distribute a copy of Windows under my own license while ignoring MS's license". I thought that that made it clear that "..provided you had a license to distribute copies of windows" was NOT included.

    My point is that your anaogy is invalid because you made the a priori assumption that Vidomi is violating the GPL by shipping the DLLs. If you think about it a bit, you'll see that this assumption is incorrect.

    Vidomi is shipping two things:
    • a modified version of the VirtuaDub DLLs
    • their own proprietary software that dynamically links with the VirtuaDub DLLs
    Ignore the proprietary software for a moment. Aren't they allowed to distribute the modified DLLs? Yes, provided they allow access to the source (which they do). So the DLLs are being distributed while still abiding by the GPL. In other words, if you want to make an anology including Microsoft Windows, you have to assume that the company is shipping licensed copies of Windows, because the VirtuaDub DLLs they're shipping do conform to the GPL.

    The problem everyone has is with the proprietary code that Vidomi wrote. That's why I'm asking how you'd feel about it if they weren't shipping the modified DLLs at all. Because the DLLs are GPL compliant, so shipping those DLLs isn't the real issue here.

    In your thought experiment, they would have had to compile at least a header into the original program in order to dynamically link later. Whether this was the original header or a reverse engineered header, its still a derivative of the original work. The header would be GPLd, compiled in -> entire work GPLd. You need the LGPL for that to work.

    Unless the VirtuaDub headers contain inline code, that argument doesn't hold up at all, especially not if Vidomi was using reverse engineered headers. Using your logic, WINE [winehq.com] is completely illegal, because it contains "reverse engineered headers" from Windows. Typical headers are really just interfaces, and it's long been argued that duplicating that form of interface is fair use.
  • by mcelrath (8027) on Wednesday May 23, 2001 @10:26AM (#202800) Homepage
    Looks like (relevant parts of) the source code is available right here [vidomi.com]. Could be a short case.

    --Bob

  • 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.

  • by ansible (9585) on Wednesday May 23, 2001 @11:32AM (#202808) Journal

    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.

  • by landley (9786) on Wednesday May 23, 2001 @10:36PM (#202809) Homepage
    >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
  • by Laxitive (10360) on Wednesday May 23, 2001 @11:29AM (#202812) Journal

    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.

  • by jms (11418) on Wednesday May 23, 2001 @12:21PM (#202815)
    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. They sue to get your son. Would the judge hand him over?

    That would depend on whether or not you live in a state that has passed the UCITA legislation.

  • by grub (11606)

    Well, yes, the program can run, but it can't perofrm the functions it is intended to perform, so it can't do the things it advertises, and the things users obtain it for, so practically, and legaly, it can NOT ber run with out it.

    Nonsense. I could write "Hello, World" with some funky twist so that it will only work on Linux, yet release my code as BSD licensed.

    What you are suggesting is tantamount to "Your car won't run without gas, so your car is the property of Exxon."

    Hell, the programmers of GPL code need food and water, do they by extension own the food on the shelves of the supermarkets?

    grub
  • 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).
    --
  • 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.
  • by rhavyn (12490)
    The GPL explicitly states that if the program requires the GPL to do its intended purpose then the program is derived from the GPL code. Now, go over and look at the website and notice how many features that are advertised as being part of this program won't work without the GPL'd code. Then come back here and tell me that it would fulfill it's intended purpose without that DLL.
  • Linus was wrong.

    Actually, I think he was right. The key point is the first part of the GPL quote:

    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.

    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&quot.

    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:

    ...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...

    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.

  • 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.
  • by MSG (12810) on Wednesday May 23, 2001 @11:47PM (#202832)
    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.
  • by Sloppy (14984) on Wednesday May 23, 2001 @05:20PM (#202842) Homepage Journal

    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 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.


    ---
  • > 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.
  • by Royster (16042) on Wednesday May 23, 2001 @11:01AM (#202846) Homepage
    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.
  • by Royster (16042) on Wednesday May 23, 2001 @12:36PM (#202847) Homepage
    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.
  • 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.
  • My home page http://www.csh.rit.edu/~benjamin/ [rit.edu] 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.
  • nope, I tried with ie, netscape and even wget and I am getting my web site!
  • ooops my bad. Turns out some funky thing is happening to my router... Adding to my todo list to fix....
  • 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.

    --
  • by Shadowlion (18254) on Wednesday May 23, 2001 @11:34AM (#202857) Homepage
    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.

    --
  • Vidomi can operate without these GPL DLLs can it not?

    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

  • by JabberWokky (19442) <slashdot.com@timewarp.org> on Wednesday May 23, 2001 @11:35AM (#202862) Homepage Journal
    Yes, but remember that linking to a dll occurs at runtime not at compile time, so the people linking to the dll are the end users, not Vidomi. I don't see how Vidomi can be held accountable for actions that end users might take with their program.

    Ah, but you fail to realize that lawyers are not programmers. Most of the time, this is a bad thing, but this may very well be a good thing in this case.

    They won't care if it's Corba, DCOM, or staticly compiled. Hell, they don't even know what that means. All the law cares about is: "Did this action violate the spirit of the license". Sure, they'll try and interpret the license every which way by pulling out each relevant sentence and dissecting the meaning of every word, but it won't be a technological analysis. Technical, yes, but not technological.

    They will look, see what the license says:

    2.b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

    (later in 2) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

    I boldfaced the important bits. Are they distributing a piece of software that is a work (as a whole) that is based on the GPLed software? If so, it must be GPLed, even if it's connecting to the code on a seperate server... as a higher level interpretation (which is my own, and not legal), even if the GPL code were to reside on a server: if the app requires the GPLed code as a basic part of its core functionality, then the GPL applies to the work as a whole.

    --
    Evan YMMV IANAL, but I used to work with them.

  • by Hugonz (20064) <hugonz.gmail@com> on Wednesday May 23, 2001 @11:09AM (#202863) Homepage
    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.

  • by sweetooth (21075) on Wednesday May 23, 2001 @10:33AM (#202864) Homepage
    posting this? http://www.vidomi.com/index.php?artid=6#news [vidomi.com]
    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=3 [vidomi.com]
    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...

    NeXT initially wanted to make this front end proprietary; they proposed to release it as .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
    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
  • by Phill Hugo (22705) on Wednesday May 23, 2001 @10:40AM (#202871) Homepage
    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?
  • by Phill Hugo (22705) on Wednesday May 23, 2001 @11:15AM (#202872) Homepage
    > 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!
  • by DeathBunny (24311) on Wednesday May 23, 2001 @12:08PM (#202878) Homepage
    >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!
  • by jonathanclark (29656) on Wednesday May 23, 2001 @01:02PM (#202885) Homepage
    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.

  • by jonathanclark (29656) on Wednesday May 23, 2001 @05:39PM (#202886) Homepage
    Ohh.. I can't resist a troll...


    executables have stripped relocation tables, you can only load them to address 0x400000


    That's not true. Most exe's have relocation information. You can strip it out, but it's pretty rare that EXEs have this information removed. Even if they did it just means the process that loads them needs to be loaded at a different base address. There is nothing special about 0x400000, many exes have a base address other than that. Notepad.exe uses 0x1000000 for example (under w2k). Use the program "rebase" that comes with W2k to change the base address to whatever you like. You can load an EXE without relocation information as DLL. Also DLLs don't have to have relocation information assuming they are not going to conflict.

    even if the relocation table would be present, the OS doesn't permit loading & dynamically linking against an executable. It was originally possible, but the changed because it can cause security problem.

    Try it yourself :

    HMODULE m=LoadLibrary("c:\\winnt\\system32\\notepad.exe");

    Amazing!! :)

  • by EasyTarget (43516) on Wednesday May 23, 2001 @11:10AM (#202918) Journal
    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
  • by Ted V (67691) on Wednesday May 23, 2001 @10:29AM (#202959) Homepage
    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
  • by Vecna! (74330) on Wednesday May 23, 2001 @11:04AM (#202968)
    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.
  • by selectspec (74651) on Wednesday May 23, 2001 @11:27AM (#202972)
    From the GPL [gnu.org]:

    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!

  • by Ded Mike (89353) on Wednesday May 23, 2001 @12:11PM (#202991) Homepage
    RE: I'm not sure what law prevents you from reverse engineering a file format!
    It's called UCITA [ucitaonline.com] and it's very, very bad [badsoftware.com]. The CPSR, 26 States Attorneys-General, the ACM, and many others [cpsr.org] oppose it vigorously. You should, too.

    Because state reptilesentatives are more worried about their bribes^H^H^H^H^H^H...errr...campaign contributions and the falling tax-base, more than they are about your rights either as consumers or developers, and because the supporters of this unconstitutional law have such deep pockets, UCITA is slowly gaining ground against its opponents.

    From Richard Stallman's updated ' Why We MUST Fight UCITA [linuxtoday.com]'
    UCITA has another indirect consequence that would hamstring free software development in the long term -- it gives proprietary software developers the power to prohibit reverse engineering. This would make it easy for them to establish secret file formats and protocols, which there would be no lawful way for us to figure out.
    FIGHT THE POWER!!!! [linuxtoday.com]

  • by blakestah (91866) <blakestah@gmail.com> on Wednesday May 23, 2001 @10:57AM (#203005) Homepage
    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).
  • by blakestah (91866) <blakestah@gmail.com> on Wednesday May 23, 2001 @11:34AM (#203006) Homepage
    > 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)

    Companies backing down do not set legal precedent. That is the entire point of backing down.

    The QT problem has NEVER been addressed in court. They make the same assumptions RMS does - that dynamic linking makes something a derivative. In fact, I think RMS convinced them of it.

    The interface between kernel and application is via an LGPL application and Linus specifically permits binary only drivers in Linux (basically making the header files required to use them effecticely LGPL)

    When I create a binary and use system calls, I am dynamically linking to the kernel in exactly the same sense as I am linking to a dynamic library when I make a call to a function in that library. I have no necessity to use gcc to make the binary - there are other compilers available, and I can write the program in assembly and in theory create the same executable bit for bit. I don't NEED to include the header file - gcc may require it, but I can certainly code around it.

    This has never made sense to me - that ANY dynamic link library makes ALL linking programs derivative works. It seems to me that the entire purpose of creating a dynamic link library is exporting a PUBLIC API and header file that allows someone to create reasonably separate programs that can access a function.

    Functions, as even a cursory glance at copyright law will tell you, are not copyrightable. Only the source is. I have no need to use the source to use the API, with the exception of the header file.

    If the FSF wins, it would be an almost unprecedented increase in copyright coverage.
  • by rgmoore (133276) <glandauer@charter.net> on Wednesday May 23, 2001 @10:37AM (#203071) Homepage

    I think that you're missing the bigger issue. Basically, Vidomi is turning a GPLed library into a dll and linking a proprietary program against it. They're releasing the code for the dll, but not the program that links to it. Since the GPL claims that work that is commonly distributed as an organic whole constitutes a derivative of any packages that make up the whole, that appears to be a GPL violation; the whole thing should be released under the GPL. If Vidomi wins, it will mean that the GPL is substantially weaker than people have generally believed, as it will be possible to make part-GPL/part-proprietary programs by isolating the GPLed part in a dll.

  • Interesting that VirtualDub is enmeshed in yet another Intellectual Property dispute. In 2000, Avery Lee (the creator of VirtualDub)was forced to remove support for Microsoft's patented [164.195.100.11] ASF (Active Stream Format) file format from his GPL'd program. Apparently, Lee had reverse-engineered the ASF format for compatibility purposes.

    Here's [cptech.org] a little summary of the VirtualDub/ Microsoft patent dispute with links to more comprehensive articles.

    Sincerely,
    vergil
    Vergil Bushnell

  • by _|()|\| (159991) on Wednesday May 23, 2001 @10:48AM (#203098)
    Looks like (relevant parts of) the source code is available

    Avery claims that Vidomi is derived from the GPLed VirtualDub. If this is true, then Vidomi source must be released.

    Vidomi hopes to create a "user does the link" loophole. This is analagous to the Objective C front end situation described in "Copyleft: Pragmatic Idealism [gnu.org]". NeXT gave in. Perhaps Vidomi will, too. Or perhaps, as the headline suggests, this will go to court and set a legal precedent.

    Tom Christiansen, a vocal GPL critic, has argued a position similar to Vidomi's. Dynamic linking is an interface. If there is a non-GPLed implementation of the interface, then the program is not necessarily derived from the GPLed library. People have written GPLed replacements for proprietary programs, why not the other way around? However, I suspect that a court would see through the sham replacements in this case. Vidomi advertises functionality that requires GPLed code; therefore, it is a derived work (under copyright law), subject to the license of the original code.

  • by Bluesee (173416) <michaelpatrickkenny@@@yahoo...com> on Wednesday May 23, 2001 @12:44PM (#203110)
    ...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!
  • by isomeme (177414) <cdberry@gmail.com> on Wednesday May 23, 2001 @12:54PM (#203113) Homepage Journal
    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.

    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.

    --

  • by nagora (177841) on Wednesday May 23, 2001 @11:42AM (#203116)
    1. The author of a work can place conditions on the uses of that work which involve copying it (that's why it's called copyright).
    2. If you want to copy the work but don't want to follow the author's rules then you're out of luck and you'll have to do the work yourself.
    3. Programmers can use the LGPL which says "dynamic linking is OK," or the GPL which says "Dynamic linking is NOT okay unless you open your sorce code".
    4. SloMedia have dynamically linked to a piece of code which the author has said is not available for dynamic linking unless the linking program's source is released (GPL)
    5. SloMedia should have written their own code if they don't want to abide by the programmer's wishes.
    6. SloMedia should loose in court once the court is aware that the decision to use the GPL rather than the LGPL is a conscious declaration by the author that SloMedia's use of the code is not allowed.
    7. SloMedia might have got away with it if the GPL'd code was not in DLL's which means that they personally must have copied the code at least into a DLL-wrapper.
    8. The weak point of the GPL on this issue would be if they had simply said "If you happen to have made this code into a DLL and have it lying around, then our program will detect and use it". This is a difficult issue for the GPL since SloMedia would not then have done any copying of the work and it would be hard to apply the author's rules on them.
    9. But they didn't.

    Well, that's what it looks like to me.

    RMS (the gun-nut) has an article [slashdot.org] on this topic which may be useful.

    TWW

  • by IvyMike (178408) on Wednesday May 23, 2001 @11:13AM (#203117)

    It seems that the code in question was released under the GPL [gnu.org], and to me, it seems clear that the GPL has been violated in both the letter and the spirit of the license.

    I am tempted to argue that the more appropriate license would have been the LGPL [gnu.org]. Yeah, yeah, RMS no longer likes the LGPL [gnu.org], but if I were creating a library, I still would LGPL it. However, I wasn't in charge this time :) and the choice of using GPL for a library has merits too.

    Of course, it seems that Vidomi is confused: even though they might want the software to be LGPL'd, it isn't, and they are probably in violation because of the stricter GPL.

  • by mblase (200735) on Wednesday May 23, 2001 @10:27AM (#203132)
    ...is readily available from this link [vidomi.com] on their Web site. Text follows:
    We at Vidomi respect licenses and copyrights. From the beginning, we evaluated the GPL license to determine how to be in compliance. We have been explicit about how Vidomi can have increased functionality using GPL code, any revisions Vidomi made to GPL code have been licensed under the GPL and the source code for this GPL code is available for free at Vidomi (opensourcerelease.zip at

    The following language from paragraph 2 of the GPL explicitly concludes that it is possible for a program to in some way interact with GPL code and yet the proprietary independent and separate work not have to be licensed under the GPL:

    "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....Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program."

    We believe we are in compliance with these terms of the GPL (as well as others).

    At the same time, we are interested in constructive feedback as to interpretation of the GPL license and Vidomi's approach to compliance with the license. We have been in on-going discussions with Avery Lee, author of Virtual Dub, for about a month, and just two days ago received from Avery more constructive feedback which we are now evaluating and will respond to soon. We welcome the community's input on this issue and will evaluate feedback to determine if we should make any adjustments to how Vidomi interacts with GPL code.

    dean@vidomi.com

  • by rxmd (205533) on Wednesday May 23, 2001 @10:37AM (#203134) Homepage
    Would it be technically possible to write a program that takes source code as input and heavily modifies it (i.e. renaming of identifiers, restructuring of source, restructuring of call order (should be possible for given languages using a virtual-machine concept), insertion of loops, heavy optimizations and so on) so that the result has no similarity with the original?

    It would be interesting to put it under the GPL (for the self-referentiality [absurd.org]...) and use it to modify GPL's source code so that effectively, it's GPL'd-ness could no longer be proven or even ascertained :-)

    Then one could create legally interesting situations.

  • by bziman (223162) on Wednesday May 23, 2001 @10:39AM (#203162) Homepage Journal
    According to this note [vidomi.com] posted last week on the Vidomi web site, they will "no longer provide an option of including the GPL code with the Vidomi code in the same download and installer." Furthermore, they say they have "contacted ... the Free Software Foundation (FSF) last week to request their input on this situation." And finally, they say, "in no way do we mean to disrespect Avery Lee".

    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

  • by rabtech (223758) on Wednesday May 23, 2001 @11:50AM (#203164) Homepage
    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!"
  • by Dancin_Santa (265275) <DancinSanta@gmail.com> on Wednesday May 23, 2001 @10:32AM (#203180) Journal
    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
  • by tb3 (313150) on Wednesday May 23, 2001 @11:36AM (#203205) Homepage
    The end result may be the same, but the distinction is the usage. A library (more specifically, a DLL) runs in the same memory space as the calling program and has the same net effect as if it was compiled as part of the program. This is like taking someone else's source code, compiling it into your program, and not releasing the source.

    Perl and gzip, on the other hand, are separate programs onto themselves, are called by your code at the command line level, so they run in separate memory spaces.
    -----------------

  • by deanvidomi (454512) on Wednesday May 23, 2001 @11:48AM (#203263)
    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

Facts are stubborn, but statistics are more pliable.

Working...