A new FUD angle: securities laws

GPL v2: "You are not required to accept this License, since you have not signed it".

How much of the code in Wasabi's system is covered by the original BSD system? Do distributers *really* comply with those licenses? Have those PHB and their lawyers verified that?

If not, they may be facing criminal charges, according to this white paper!

In other words, they are useless attorneys or they are *deliberately* FUDding.

I would have thought it was blatantly obvious to any half-way competent attorney that in order to enforce a copyright licence, you need to own (or have rights to) the copyright you are trying to enforce.

HINT TO WASABI ATTORNEYS: the FSF does not have any copyright rights to the linux kernel! (Actually, that's not quite true, but unfortunately for the FSF, Linus has veto rights as far as this issue is concerned, and he has been pretty blatant (ie read the COPYING file) that he will use them.)

Cheers,
Wol

To quote their site: Wasabi provides a wide range of GNU toolchain optimization and customization services, with some of the leading experts in the industry.

Let's hope for them that they don't break any federal securities laws ;).

Nearly every page says 'If you violate the GPL <bad things will happen>'. Which is all true, but of course if you don't, then bad things won't happen, and the world will in fact be rosy.

And by the time we get to "You mustn't let engineers make sure you are in compliance, because only lawyers can do so under Sarbanes-oxley", my FUD-detector starts to wail (really? - I bet the engineers are better-informed than the suits), and as many others have pointed out this applies just as much to your BSD and proprietary code.

Then we have "The simplest answer is not to cheat. However, there are [] problems with this simple response. First, most companies do cheat, because compliance is expensive". OK - now they are just talking bollocks: GPL-compliance overheads are small, if not tiny. I know - I do this stuff for a living. Just make the code you ship available, either on-line, or on a CD with the product - How expensive can that be? He's right that non-compliance has been rife, but I think that was actually largely ignorance, laziness and incompetence, and the GPL-compliance project seems to have reduced the incidence markedly.

And oddly enough I find myself capable of confirming GPL compliance (or the lack of it) without the aid of lawyers (well, except where I read what they write on-line).

Here's another fine quote: "Moglen's solution, in his response to Michaelson above, is simply to "share and share alike," i.e. make all code open source, including, presumably, code to modules which might be considered derivative works. This solution would indeed assure compliance with the GPL, but would render LKMs useless."

Of course - kernel modules are completely useless if they don't let you keep drivers proprietary - no other purpose could possibly exist :-) The persistent use of 'LKM's when he means 'Proprietary LKMs' does smack of FUD.

So, overall - a very informative paper, rather spoilt by bias.

Who logged in with what ID when.

Who updated what data in the ERP system.

Were changes properly authorized ....etc

All around proper accounting practices. One could easily comply with SOX and not the GPL or vise versa because one is a proper use license and the other is Corp. Financial Law. Possibly related in some ways but, certainly not directly. This is total bunk.

If code written to work as a plug-in for the user-space program, even if it emulates a non-GPL'd program's published plug-in interface, is automatically GPL by law, we start to slide down into what I believe is the absurd. If a GPL image processing program accepts Adobe Photoshop plug-ins, and I use a non-GPL plug-in with it, have I violated the spirit of the GPL? If so, why even support that interface in the GPL'd product?

When you write loadable driver modules that make no modifications to the kernel data structures themselves, simply use published binary interfaces for the version of the kernel that they support, is the code itself, by association, a derived work? If I choose to distribute the source code under a BSD, Mozilla, or other Open Source license, have I violated the GPL? From what Linus says, no, I have not; From what some others are saying, yes, I have.

I am an open source advocate, and have been for many years, but it has been my reading of the GPLv2 that, to be a derived work, it must be based on that work and not simply patterned to work with it. I view loadable driver modules as a plug-in using a documented binary interface, thus not a work derived from the kernel, whether it's all-new or ported from another OS. If the driver module goes around the published interface and manipulates internal kernel data structures directly or requires kernel changes outside of the module itself to operate, that's another matter entirely.

I'm working on an embedded project where we have some proprietary hardware for which we are writing Linux drivers. In one case, the driver is completely new; none of its code is based on pre-existing drivers for the device, as no pre-existing device was around. In the other case, there was a similar device used in another project that used LynxOS for the platform, and the bulk of the internals of that driver are derived from that source. In a sense, that driver is being ported from LynxOS to Linux. By the definitions that are being offered, the first driver is definitely a derived work, whereas the second is questionable, even if the changes required to port the driver are extensive.

The embedded device has a very specific application. We have exactly one customer for the product. There will be few of these devices deployed, and they are unlikely ever to find their way onto the open market. We will give the customer the sources to our device drivers; they will likely never look at them, and they are even less likely to want to change them. We will *not* give the source code for the FPGAs that implement some of the hardware interfaces to anybody; they are not open source, and they're not being done by a group that is working with open source software. The people who are making the decisions may wish to use a different Open Source license (in fact, they do.) The decision has not been made yet, and won't be for some months. Management believes that the customer may have the right to the code, but for a device that will never exist outside of an integrated product (it's built onto the board) there is no real need to submit the source to the Kernel maintainers.

So, is the path we're taking leading us to a violation of the GPL?