Slashdot Mirror
VMware May Violate Linux Copyrights
Nailer writes "Bloomberg believe VMware's IPO today may the largest technology offering since Google. But doubts have been cast over the company's supposedly proprietary ESX product, as top 10 Linux contributor Christopher Hellwig claims the software may violate Linux kernel copyrights. 'Is Hellwig right, and is VMware a derived product of Linux? Unless vmkernel can be loaded without the Linux kernel, it would appear so. VMware was developed from another, long ago OS created as a research project, but it's unclear whether vmkernel was ported from that OS or rewritten as the Linux-requiring binary blob. What's more of an issue is that VMware had these serious questions posed directly to them a year ago, repeated in a public forum many times since, but have yet to respond at all.'"
Copyright gets infringed, licenses get violated.
The Banjo Players Must Die!
ESX runs directly on the hardware. They're saying ESX is what's violating the copyrights.
When does this happen in the movie?
'Q. Does ESX Server Run on Linux? On Windows?
A. ESX Server runs natively on server hardware, without a host operating system.
Ok, so ESX doesn't need a host OS. It's pretty clear that ESX installs directly on the hardware without needing Windows, Linux or any other OS installed first - ESX itself is the OS. The question then is whether the ESX OS is based on Linux. To reitterate The question then is whether the ESX OS is based on Linux
init 11 - for when you need that edge.
Because ESX server (the specific product in question here) runs differently than the Windows and Linux Workstation products (the key word being "hypervisor"):
"[The] VMware ESX hypervisor virtualization approach provides lower overhead and better control and granularity for allocating resources (CPU-time, disk-bandwidth, network-bandwidth, memory-utilization) to virtual machines. It also increases security, thus positioning VMware ESX as an enterprise-grade product." - Wikipedia
Whereas the desktop products operate over the OS layer, ESX is closer to the bare hardware (Type 1 versus Type 2 hypervisor - Read more. The question in this case is why it needs the Linux kernel "loader" if it is a self-contained kernel. My understanding of the product isn't deep enough to speculate.
WASTE - The Secure P2P
Whether or not VMWare violates Linux copyrights, the mere fact that this is being discussed may add to the perception of the GPL as a "viral" license, and steer developers/businesses away from using Linux and other GPL software in their products.
"Anyone who [rips a CD] is probably engaging in copyright infringement." - David O. Carson
You heard it here first. In the next major ESX release, VMware will ditch the Linux service console altogether in favour of their own proprietary one. Admins around the globe cheer as they have to learn yet another system.
I joined two users too late.
Strange that during a training session the instructor consistently referred to the underlying platform as a highly modified RedHat. They didn't even try to claim that this was anything else, or even just their own Linux, they used the brand name of the starting point.
There is, of course, a way that they aren't violating linux copyrights: They may simply be using the Linux Kernel to get the hardware into a known state prior to loading the VMkernel. Similar projects include LinuxBIOS, and Linux's own kexec (kexec lets you boot a new linux kernel without actually 'booting').
Of course, it is a violation if ESX is actually running a modified Linux Kernel, instead of using the Linux Kernel as a bootloader. Using the Linux Kernel as a bootloader is a done deal; just look up 'kexec' for proof of it. (Though I'm fairly certain kexec isn't what VMware uses).
But even then, remember that ESX is their "enterprise" product, which acts more like a hypervisor, and is not to be confused with VMware Workstation, VMware Player, or VMware Server.
-- Sometimes you have to turn the lights off in order to see.
- Linux boots.
- Userspace tool kexec's the hypervisor (an odd way of doing things, so I wouldn't be surprised if this isn't actually what happens).
- The Linux kernel continues to run in a VM, providing an admin UI and drivers to the other guests, just as it does with Xen.
Looking at the patches that the VMWare guys have been sending in for hypervisor support, it seems like step three, at least, is accurate. Xen does the following in a typical install:- Linux is installed, with a Xen-compatible kernel.
- User reboots.
- Xen Hypervisor boots.
- Xen Hypervisor loads a Linux (or NetBSD or Solaris, or Windows with Xen Enterprise) domain 0 (privileged) guest, which runs the (userspace) management tools and provides device drivers.
There has, I believe, been some work done making Xen boot using kexec from Linux, so you can skip step 2 if you want. If you do this, then you get exactly the same set of steps as VMWare ESX.Now, to be fair, Xen actually does include some code (stuff like atomic operations, for example) from Linux (and is GPL'd, making this a non-issue), but this was done to save time, rather than because the code has to come from Linux.
I am TheRaven on Soylent News
It could be viewed that Linus' statements constitute a verbal license. Licenses don't always need to be granted in writing. A license is a permission. I lend you my car, I don't necessarily need to write you a note saying that it's okay to borrow my car for such-and-such time period for the purposes of so-and-so...I just say "Here, borrow my car. Here's the keys." That's a permission, and that's exactly what a copyright license is - a permission to do something normally reserved for the copyright holder. So the GPL is a license, but so is Linus saying "You can write a binary driver so long as it can stand on its own without the kernel".
Note that IANAL.
My blog
From what I understand, the Linux 2.4 kernel (Service Console) does the initial boot, but only addresses a limited amount of RAM (usually between 256M and 384M, depending on how many VMs you plan on running). It then loads the vmkernel, which takes the rest of the RAM and takes over scheduling functions from the Service Console, and directly addresses the hardware. With the exception of the initial RAM, everything else the Service Console does is through the vmkernel. The way it was explained to me was that the SC essentially becomes a pseudo-VM itself, relying on the vmkernel for hardware access.
In turn, the Service Console has some hooks into the vmkernel to perform management functions, monitoring, etc. The SC functions as a bridge between the vmkernel and the outside world. That's the way I understand it, anyway. Could be totally wrong. I have heard rumors in the past, though, that VMware is planning to ditch the Linux SC in future versions in favor of their own service console OS. Which would render the whole argument moot.
"So according to VMware ESX actually has two kernels - the vmkernel, and a Linux kernel. This sounds a bit odd, given a computer can only run one kernel at a given time otherwise which one determines who gets access to the CPU, memory, and other hardware?"
Uhh, this is a virtualization system. The ESX kernel provides a hardware abstraction layer which the linux kernel in the service console can access.
So yes, it IS running two kernels, the ESX kernel which has priority, and the linux kernel running on top of it in a VM like every other virtualized kernel, once it gets running. Duh.
But the meat of the FA seems to be that "Because a Linux kernel is used to initiate the ESX kernel, and because the linux kernel has a binary blob driver to help in the bootstrap process, QED ESX kernel is considered a derivitive work, because Linus says that things which require kernel changes are derivitive works" WTF?
FUD is bad. No matter the source.
The Linux kernel allows binary blobs. VMWare uses an F@#)(* huge binary blob to bootstrap ESX and other stuff. OOOHHH SCARY bogeyman violate GPL. Either sue (Linus does have standing. The SCSI author actually does have standing if it includes his code anywhere in the hacked up kernel) or get off the pot.
And Just say no to FUD.
Test your net with Netalyzr
I've read somewhere that SCO was offering a special discount on linux licenses this week. Quick! get one before the offer ends!
Lots of proprietary software runs just fine on Linux, including drivers, without violating the GPL. VMWare's ESX Server is sort of a special case as people seem to think a part of the product is itself derived from Linux. "Derived from Linux" is not the same as "running on Linux".
Sometimes I have to ask: where the fuck are the lawyers? Did we finally kill them all? ;-)
Folks, software creators like Linus or the FSF people, can put whatever terms into licenses that they want, but one thing they can't do is define derived works. Congress does that (very poorly, so the courts end up mostly stuck with the job). And unless you make something that is a defined work, do never need to get bound to the license in the first place, so.. words in the GPL do not matter, and Linus' opinion does not matter. Well, it matters in the since that we're talking about smart people who have obviously given the issue some thought. But that's all.
What I'm getting at, is that Linus is making an argument. He is not giving an authoritative declaration as a copyright holder or licensor. He can't.
Linus has determined? (inferred? decided?) that if something works w/out Linux, it's not a derived work, and if it doesn't work w/out Linux, it is a derived work. I think that's very arbitrary, and brings up so many (apparent?) counter-examples that it would terrify everyone in the software industry except for maybe the BIOS guys.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
1. It details information that is from an older and nearly 2.5 year old revision of the Product. The Current Version is 3.0.x and the relationship of the Linux system and the VMKernel has changed substantially.
2. VMWare licenses the Implimentation of Linux used in ESX from Red Hat, however nowhere is that mentioned in the Article.
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
Go read this article (http://hardware.slashdot.org/article.pl?sid=07/08 /09/171248) from last week and note that Dell apparently will be booting a version of ESX from BIOS. If ESX can be booted with an alternate bootloader, it must not be that closely tied to RedHat.
Nothing for 6-digit uids?
That is simply incorrect.
By your statement any userland program that made use of Linux-only interfaces (e.g. hugetlbfs, most anything in /proc or /sys, video4linux devices, etc) would also be a derived work, which is obviously not the case. Even within the realm of kernel-internal interfaces, it is difficult to argue that a derived work is created by using interfaces whose function and calling requirements you understand without needing to know the specifics of the implementation (though this seems to be the thrust of the thinking behind EXPORT_SYMBOL_GPL).
Personally I would argue that nothing short of code-copying creates a derived work, but other intelligent people hold contrary views. I'm waiting for the day that someone wakes up to the fact that the whole EXPORT_SYMBOL* nonsense is at its heart a form of Digital Restrictions Management. Not that closed-source modules haven't caused me rare moments of headache, but in this case the cure seems more repugnant than the ailment.
Cyrano de Maniac
My point is that there is a difference between using an OS as a bootloader and integrating an OS kernel with another one. There is precedence for the former (Novell Netware) and also for the latter (Windows 3.x/9x/Me). Linux doesn't integrate with the BIOS. It doesn't need it, it can be loaded with ANYTHING that bootstraps into the kernel. ESX Server seems to require a poorly hacked Linux 2.4 kernel. Nothing else can boot it. That's the difference.
My blog
I think Christopher Hellwig put it best: Exactly. Linux would've pushed legal action by now if they thought it would get them anywhere. The defense rests, end of story. So what is the point of this article? To whine about how unfair this is? Ok, maybe. But such is life.
--
Capitalism: When it uses the carrot, it's called Democracy. When it uses the stick, it's called fascism.
Capitalism: When it uses the carrot, it's called democracy. When it uses the stick, it's called fascism.
I've never used ESX, but I would imagin that no matter what, ESX needs driver support.
Being a hypervisor, it has to access all kinds of devices like VGA consoles, serial ports, Fibre Channel HBAs, SCSI HBAs, IDE controllers (for CDROMs), Ethernet adapters, etc., etc. So my question is, where does the ESX hypervisor (vmkernel) get these? Does it pull them from Linux or did they write their own? This hardware _HAS_ to be setup, initialized, and arbitrated. Does vmkernel have it's own stack of device drivers, or does it conveniently run the ones in the Linux "bootloader"?
I'm thinking there's more to this than just the binary blob issue...
Then you had a poor-quality instructor. Every VMware instructor I've had has been crystal clear that the Service Console runs a heavily modified version Red Hat, but that the vmkernel - the OS that's bootloaded by the SC, which handles virtualization and hardware access, or in other words the underlying platform - is a completely proprietary OS.
If you are talking about the kernel, then you should read the COPYING file: if your work is a derived work of the Linux kernel, then it must be released under the GPL. If it is not a derived work of the kernel then you can do whatever you want.
If you are talking about one of the many platforms based on Linux (e.g., RHEL, Debian GNU/Linux, etc) then you must consider the licensing terms of every work which you derive from (e.g., the GNU C Library, GTK+). I harken back to the days of Netware NLMs. Netware didn't seem to want some sort of ownership for people loading things onto their kernel, nor did Microsoft demand rights for people distributing TSRs. So why is this different? And look where it got them. Well, I have no idea if Netware is still alive and/or relevant today, but the sheer number of crappy proprietary drivers written by two bit hardware companies has locked them to the shitty old i386 architecture, and it looks like this will continue to be the case for decades to come.
BTW, I must correct your implied assertion that the free software community wants "ownership" of a vendor's code. This is not the case! We merely want vendors to respect the licensing terms of any works from which they create a derivative work.
That's not surprising at all. You're interacting with the service console, which runs Linux. It's more interesting to me that your Nagios box thinks the SC is running 2.6.8. And Debian, at that. The Service Console for ESX 3 actually runs a heavily modified RHEL 3 - 2.4.21 as of 3.0.1. ESX 2.5 ran Red Hat 9, I believe.
You're overstating the GPL's claimed definition. GPLv2 simply references copyright law's definition of derived works; only GPLv3 specifically references shared-library linkages as inferring derivative status, and even then only when the 3rd-party code is written to the interface provided by the GPLed code ("shared libraries and dynamically linked subprograms that the work is specifically designed to require", such that use of a common, standardized interface not specific to some GPLed work is explicitly acceptable).
The GPL is not viral. Copyright is viral. You can't take any copyrighted work and incorporate it into a new work of your own without permission from the copyright holder (excepting Fair Use). The work you incorporated "infects" your work.
Copyrighted work distributed under the GPL is different only in that it does give permission for creation of derivative works, given certain limitations. If you don't want to comply with the license, don't incorporate GPL'd code into your software. Go buy some commercial code and use that instead -- but be sure to comply with the terms of that license, because "viral" copyright will burn you if you don't. Or, if you prefer, you can write your own code so you don't need a license at all.
This is not rocket surgery. It's not even the slightest bit confusing, except when made deliberately so by FUDsters.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
err... we have a ESX server and the "run directly on the hardware" doesnt mean that they use their own OS... its using a redhat linux with just the vmware services, but you can even ssh to the servers and run a uname -a :
/etc/vmware/ |grep esx
/usr/src/
# uname -a
Linux srv-esx1 2.4.21-37.0.2.ELvmnix #1 Fri Mar 30 10:21:21 PDT 2007 i686 i686 i386 GNU/Linux
# ls -l
-rw-r--r-- 1 root root 111 Aug 14 16:01 esx_checksum.conf
-rw-r--r-- 1 root root 29777 Aug 14 15:28 esx.conf
# ls -l
total 12
drwxr-xr-x 2 root root 4096 Jan 24 2003 debug
lrwxrwxrwx 1 root root 22 Jul 24 05:41 linux-2.4 -> linux-2.4.21-37.0.2.EL
drwxr-xr-x 16 root root 4096 Jul 24 05:41 linux-2.4.21-37.0.2.EL
drwxr-xr-x 7 root root 4096 Jul 24 05:42 redhat
the "directly on hardware" is marketing talk saying that you dont need and shouldnt even bother with the host OS, vmware takes care of it (installation, support, updates, etc)
higuita
Higuita
This can be quickly resolved with some stock....
There are no loopholes. It's either legal or it's not.
By the standards of "derivative work" many purists would like to impose, any program written for Windows is a derivative work thereof, and therefore requires the permission of Microsoft to distribute.
IMO, a derivative work has to include some significant* part the work from which it is derived, not merely reference it. But I don't have a team of lawyers to back up that opinion, alas.
*by which I mean things like the names of API functions aren't sufficient.
Under that logic almost all FSF software would be the property of Sun, AT&T, HP, IBM, etc. since for a long time it required SunOS, Solaris, HP/UX, AIX to run on. I'm pretty sure that none of those companies made public "linking exception" statements. Not to mention Linux used the minix filesystem. Oh the irony of A. Tennenbaum owning Linux due to the GPL advocates glommy perception of linking. Anyone who looks at linking as creating a derivative work is seeing the world through a very narrow slit in the blinds.
The reality is is that a lot of kernel developers and linux advocates don't actually understand the law involved and spout what they would like the terms of the code to be and have some mental convolution that fits those terms in the the GPL.
I read the article and as far as I can see, while there may be a technical legal issue with the VMWare kernel being loaded by a Linux kernel (or some part thereof - insmod), thereby in some extremely technical sense making the VMWare kernel a "derived work" - this is really reaching in my opinion.
Particularly since it would seem obvious that that they could easily rewrite the thing to do its bootloading in some other way. The Linux kernel appears to be have been used only as a convenience to make the system more portable than their original development OS. And this was probably done "back in the day" since they're using a 2.4 kernel.
And if said Linux kernel being used is described as a "badly hacked 2.4 kernel", then who the hell cares? Hellwig seems to be pissed that VMWare asked the kernel maintenance list for some support or something, but basically seems to be on a "crusade" like the FSF fanatics. He's all pissed off about something that nobody else in their right mind couldn't care less about.
Perhaps VMWare should rewrite their boot loader (they certainly have enough money and smarts to do so), but basically I agree with the first poster - this appears to be either FSF fanaticism or an attempt to influence the VMWare IPO or both.
It's really beginning to seem like a religious crusade for some "fundamentalists" to root out "heretics" in the OSS world. The same socialists who deride proprietary companies for preventing "freedom" are more than willing to use a state-enforced license to drag people into line with their ideology. This is not "freedom". It is coercion.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
I am a former VMware programmer. Obviously I do not speak for the company, just myself.
VMware is not infringing anything. First, they have high standards of ethics. Even if they didn't, they would be too smart for that. When ESX was designed, there were other choices for the console OS, FreeBSD for instance. But they figured out that using Linux was legal and did so. Both VMware and Linux benefit from this. Yes, it is not a "standard", well-understood relationship such as running some app on top of the kernel. But it respects the technical aspects of the license and I believe its spirit as well (although my interpretation of the "spirit" may differ from yours).
One could argue that Linux benefits more from VMware than the other way around. In many cases VMware ESX introduced Linux to corporate data centers that wanted nothing to do with it. The sales people had to work hard to convince potential customers that the product was NOT running on Linux, that Linux was just running in a separate VM to help along with various tasks.
Linux is also helped by the fact that virtual machines offer a low-cost way of experimenting with new systems, and add a layer of freedom in the conservative corporate IT environment.
As to whether VMware should be free software, there are situations for which free software is just not the right model and VMware is a good example. In the early years of the company, someone tried to start a competing free-software product (at some point called Freemware) but it didn't go far. VMware is a large (huge) system. It took a lot of unglamorous work from a lot of people under the same roof to bring it to life. It was almost a miracle that it would run. It stressed CPUs in truly novel ways. (The programmers hit and had to work around previously unknown bugs in the CPU.) I, the eternal pessimist, feared that we'd never be able to make it stable enough for a viable product. Fortunately I was wrong, and in any case Windows was a lot less stable than VMware those days, so it didn't matter that much.
Luigi
http://www.vmware.com/download/vi/open_source.html
So what is the problem? I bet the reason the forums have not gotten an answer is because the user never bothered to look for the answer. He wanted it answered for him instead of actually you know doing some of the legwork himself. That or just posting FUD. The code is there for all to see.
There's a couple of things you have to understand first. You *can* pay Microsoft for the privilege of writing code to their kernel.
However, there's this bunch of freaks who release their code to the world, for others to use. Their payment is that if you *derive* stuff off their work, you have to pass your source code on as well.
You pick your payment plan, and off you go.
Not too many people have to write things that hook into the kernel itself. MYSQL certainly doesn't. For the most part, people who do that either need it internally (you did not re-distribute, so do not have to pass your source code along), or do it for another reason (to support whatever). If you are doing it to support whatever, then just obey the license. Again, your choice of licenses - pay Microsoft, or pay by passing along your source code.
Why should anyone develop their code, and let you use it for free? *YOU* certainly are not willing to do so.
ESX is like free software, it's better when it's free.
"Piter, too, is dead."
No.
Derived from Linux source code = Have to show the code
Running on Linux = whatever you want to do
Derived from linux concepts (commands, interfaces, etc) or using linux API's = whatever you want to do
Please don't spread rediculous misconceptions about what the GPL forces to be free, it hurts the GPL movement because people will avoid it for fear its will "infect" their code, I had to get our lawyers sign off that checking our proprietary code into the GPL'd CVS would not force our code to be GPL; arguements that using Open Office make your term paper GPL or that somehow the ability to run Halo under WINE means you have a right to the source code is the type of anti-GNU FUD MS wants to spread.
The spirit of the GPL is meant to discourage closed source anything. Businesses SHOULD stay away from it unless they have a plan for profiting off of their own open source code.
If you distribute your code, you're not even allowed to link to GPL libraries without your code falling under the GPL.
There is plenty of great BSD/LGPL/MIT/etc licensed code out there which is much less of a legal nightmare.
An assertion is made that VMware infringes on Linux-related copyrights held by others, but no concrete proof has been shown. Why should they have to disprove an as-yet unproven allegation, regardless of who made it? When SCO made a statement about Linux without concrete proof, the overriding opinion was "Prove it." Why wouldn't the same standard be applied to someone making a statement about VMware? Shouldn't they be given the assumption of innocence until proven guilty?
I'm not saying they infringed and I'm not saying they didn't, as I honestly don't know. Regardless, shouldn't the impetus on the accuser to prove their case?
"It's too bad stupidity isn't painful." - A. S. LaVey
Under that logic almost all FSF software would be the property of Sun, AT&T, HP, IBM, etc. since for a long time it required SunOS, Solaris, HP/UX, AIX to run on.
FSF did not distribute SunOS, Solaris, HP/UX etc. and therefore they were not bound by those licenses. The same applies to say NVIDIA, since they don't distribute GPL-covered software either. VMWare has no such luck -- they distribute both GPL-covered and proprietary software, and they even do it on the same CD. Now, the GPL could have outright forbidden this "mere aggregation", which would obviously have been completely enforceable. Instead, the GPL allows shipping both on the same media -- but only if both pieces work independently of each other. And the VMWare hypervisor seems to not work without the Linux kernel. Whoops.
Finally! A year of moderation! Ready for 2019?
libraries are okay because they're just linked
Incorrect. You *cannot* link a GPL library into a non-gpl app. Check with your lawyers. Seriously..
Does anyone know of this actually being tested in court. The GPLv2 only speaks of derivative work. But I don't think that linking follows the traditional concept of derivative work. Just because it's in their FAQ doesn't make it law.
Nuh-uh -- read the license before you spout off.
Static linking implies derivation, because the executable contains code from the library as well as the covered program. Shared library linkages only imply derivation if the program in question is written to use an interface which is specific to the covered program -- so the standard C library does not apply. It makes sense: If I'm writing to the libgnome API, I'm creating a product which would not possibly work without libgnome. If I'm writing to the standard C API, I'm creating something which works with all manner of standard C libraries; if my code happens to be dynamically linked against a GPLed C library implementation, that doesn't change the fact that that code was not in any way written with knowledge of the specific implementation.
The GPL, taken literally, can be reasonably complied with.
Microsoft: "You've got questions. We've got dancing paperclips."
Agrees that writing software against a different program's API implies derivation? No court, but it's a pretty damned easy argument to make, at least for programs written in C and C++ (and other languages where libraries' headers are included during a precompilation phase): You're writing your code the way you do only because of the external API being structured the way it is, and would not write your code that way otherwise. Moreover, structures and values from the API's header files are copied into your source during precompilation. There may not be settled precedent -- but in a precedent-setting case, this would be a favorable side to be on.
Agrees that writing software against a standard API doesn't imply derivation from any specific implementation of that API? Well, duh. If you statically link your code with that implementation to generate a binary, that binary certainly is a derivative work -- but if you're doing dynamic linking, your generated binary does not contain any portion of the work (other than the structures &c. from the header -- but because those are generated to conform with the 3rd-party API, there's no creative [and thus no copyrightable] element in them), and your source neither contains any portion of the work or is influenced in any way individually traceable back to the work.
The FSF's position may not have been fully validated by case law, but it is a very reasonable interpretation, prone to being effectively argued in court. Remember that to a significant extent, the reason there is relatively little case law regarding the FSF's interpretation of their licenses is that offending parties whom the FSF has communicated with almost universally settle.
Show me on the doll where his noodly appendage touched you.
Oh my, do we really want this? Microsoft is spending hugely on their own Virtual Server range and we want to put road blocks in front of VMWare?
Do not mock my vision of impractical footwear
>> VMkernel does not run on Linux kernel.
>> Please, let me reiterate this again: VMKernel DOES NOT RUN ON Linux.
RTFA. According to everyone, including VMware, vmkernel is started from Linux.
The article has been updated to include a video of an ESX machine booting.
Run 'strings' on the 'vmnix' kernel on your machine (or just watch it boot). It's Linux. Nobody hides this fact.
As TFA mentions, vmkernel is started by S90vmware, which insmods vmkmod to load it.
Apparently the source to the Linux bits /is/ available. It's the "depend on Linux for hardware IO" that Hellwig (and others?) object to as a licence violation.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
I agree.
As their definition is vastly looser then any standard definition used by a court, it's not like the court will use a stronger interpretation. It is also very difficult for someone to argue that they felt in compliance of the license, while using a different definition of "derived work".
I disagree.
If I create a non-GPL'd program that dynamically links to a GPL'd (not LGPL'd, GPL'd) library and I distribute that non-GPL'd program without the GPL'd library, I am not distributing the GPL'd library and so the legal proscriptions against distributing someone else's copyrighted work do not come into play.
I also do not need to accept any terms of the GPL in order to distribute my non-GPL'd program because I am not doing anything with the GPL'd library (the work to which the GPL applies) that I have to accept the GPL in order to do - I am not distributing the GPL'd library, or a modified version of it.
The only question is whether I have to accept the GPL in order to distribute my non-GPL'd program because my non-GPL'd program constitutes a derived work according to the legal definition of "derived work". I don't have to use the FSF's broader definition because unless the courts agree that my non-GPL'd program is in fact a derived work I am not doing anything that is prohibited by copyright law, and all the GPL does is give me additional privileges that would otherwise be disallowed by copyright law.
I think if the law and case history were anywhere near clearly supportive of FSF's position on this, they would plaster citations all over their website. AFAIK they don't, and they don't seem particularly eager to defend their legal theory concerning derived works.
The SCO lawsuit makes me wish my company were in Utah. We need a new building.