A new FUD angle: securities laws

Posted Jan 19, 2006 14:27 UTC (Thu) by jwb (subscriber, #15467) [Link]

Haha hilarious. Wasabi's FUD says that if you are violating the terms of the GPL, you may also be violating Sarbanes-Oxley, and therefore you may go to jail. But the same is true of _any_ intellectual property license: free software, open source, or proprietary. Even the BSD license that Wasabi Systems is trying to sell.

Posted Jan 19, 2006 14:44 UTC (Thu) by proski (subscriber, #104) [Link]

Jay Michaelson: "If companies are violating the GPL, they don't have the right to use that software".

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

Posted Jan 19, 2006 16:23 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

Reverse FUD:

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!

Posted Jan 19, 2006 17:05 UTC (Thu) by xoddam (subscriber, #2322) [Link]

"... they don't mean it's free like the air, which you can breathe with
no requirements."

Maybe breathing is an unencumbered use of air, but in most countries
there are severe restrictions and requirements when you start burning
things in it.

Neither air nor the Free Software commons is free for despoiling.

Posted Jan 20, 2006 1:21 UTC (Fri) by Wol (guest, #4433) [Link]

"Why the FSF doesn't enforce the GPL wrt LKMs".

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

Posted Jan 20, 2006 3:04 UTC (Fri) by danieldk (subscriber, #27876) [Link]

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

Posted Jan 20, 2006 3:14 UTC (Fri) by ivor (guest, #31998) [Link]

..and if a company actually respects the GPL, uses GPL software, makes modifications/improvements to it and has a proper culture and development process in place that provides those changes back to the community they've got nothing to worry about have they? They don't need to worry whether they are keeping track of their secret changes correctly.
So companies only need to worry if they're cheating, lying, stealing, trying to rip people off, are trying to simply follow the letter but not the spirit of the GPL, etc etc etc? So what. Big deal. Cry me a river.

Posted Jan 20, 2006 7:25 UTC (Fri) by wookey (subscriber, #5501) [Link]

The White paper is actually quite a useful summary of OSS licences, the difference between GPL and BSD, what happens if you don't comply, the legal status of Linux Kernel Modules (and that they are clearly against the sprit of the GPL), and (presumably - I know very little about it) a summary of the extra requirments of Sarbanes-Oxley. It starts off each section very well, clearly explaining a number of things that many people are no doubt still unsure about, but it is does appear to be written with a bias, pushing their BSD-licensed stuff and scaring people off the GPL, and starts to go downhill when we get into details.

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.

Posted Jan 20, 2006 9:32 UTC (Fri) by Spike (guest, #14160) [Link]

This is such a joke. "Even if an executive thinks the company is complying, s/he may still be breaking the law if adequate control measures are not in place. What that means is unclear - but, at a minimum, it requires a lawyer." This alone says We're spreading FUD cause we have no real idea what SOX is about. I work in corp. IT and we are working on SOX compliance. The key to SOX compliance as we have been told is providing "control Practices" that make changes to Accounting/Financial data have an audit trail. Some Examples are.

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.

Posted Jan 31, 2006 17:24 UTC (Tue) by filker0 (subscriber, #31278) [Link]

What is the status of plug-ins to user-space programs written under the GPLv2? Are they derivitive works of that program? What if the program in question actually implements a plug-in interface that is compatible with a pre-existing commercial (read proprietary) products plug-in interface, such as for Photoshop? Is the plug-in still a derivitive work of the GPL'd program? Of Photoshop? If the plug-in was intended for the proprietary program, clearly that plug-in can't be expected to inherit a GPL status by association.

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?