Slashdot Mirror
McAfee Worried Over "Ambiguous" Open Source Licenses
willdavid writes to tell us InformationWeek is reporting that McAfee, in their annual report, has warned investors that "ambiguous" open source licenses "may result in unanticipated obligations regarding [McAfee] products." "McAfee said it's particularly troubling that the legality of terms included in the GNU/General Public License -- the most widely used open source license -- have yet to be tested in court. 'Use of GPL software could subject certain portions of our proprietary software to the GPL requirements, which may have adverse effects on our sales of the products incorporating any such software,' McAfee said in the report filed last month with the Securities and Exchange Commission. Among other things, the GPL requires that manufacturers who in their products use software governed by the license distribute the software's source code to end users or customers. Some manufacturers have voiced concerns that the requirement could leave important security or copyright protection features in their products open to tampering."
Are they worried because they've used GPL licensed code in their products?
their EULA which has been rigorously tested time to time in International Court of Justice.
Don't want to be bound to the terms of the GPL? Don't use GPL code!
Just another piece of FUD.
If you're worried about "uncertainties" with respect to any software license, don't include code in your application that might cause those licensing terms to apply to it. End of story.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
there is no free lunch. these manufacturers are seeing the "gold mine" open source software as a way to do less work. Well, you've got to comply with the terms of the license if you distribute it. no 2 ways about it.
...require testing in court?
I would have thought that Copyright law was pretty unambiguous, and that any conditions imposed regarding distribution of a copyrighted work is at the whim of the copyright holder.
This would apply to any distribution license.
No need to test anything in court, unless you wish to discuss the finer detials of Copyright Law itself.
"Some manufacturers have voiced concerns that the requirement could leave important security or copyright protection features in their products open to tampering"
Uh, that's the very idea of the GPL. It lets people who bought the product use it in any way they see fit, which includes "tamnpering" with it. It even allows you to redistribute it. The only thing it prevents is redistribution under a different license without permission. Didn't anyone give McAfee the memo?
It has been tested in both USA and Euro courts, If you've been reading Groklaw at all in the last few years. And no, I don't mean SCO.
C|N>K
Translation: "We fucked up and didn't do our homework."
When all software out there is Open Source, leaks will be found and closed. That would mean no more virusses. That would mean no more McAfee.
What is the best defence they can come up with? FUD!
If anybody is dependent on closed source and the slow process of bringing out patches, it is these guys. In an ideal world they should not even exist.
Don't fight for your country, if your country does not fight for you.
1) Don't use any license that requires you disclose your code if you rely on obscurity for your security.
and
2) Only use code owned by others and covered by a strong copyleft in a product, if you are willing to release all the code for that product under a strong copyleft.
It is really not that complicated.
Or, to put it more simply: If you want to use some copyrighted software, you need a license. If you can't get a license you want to accept, then you don't get a license, and can't use the software.
Very very simple.
Do you guys have a clue as to what goes into the risks section of an SEC filing? Pretty much anything conceivable. That way if it happens it is harder to get sued by an ambulance chasing lawyer who found *one* unhappy shareholder and filed a class action suit. So if you are a publicly traded company you probably should have a risk enumerated that a programmer will violate policy and inappropriately incorporate GPL'd code.
Unless your favorite flavor of open source is BSD!
:)
Go Apple!
Sometimes my arms bend back.
Their best bet is to tighten up on their recruitment and code review processes. That would certainly beat complaining that it MAY turn out that some of their employees may be breaking various laws and that if they are then the victims may be gosh darned unreasonable about it.
While you may not have meant it, your comment pokes at another plausible reason for McAfee to dislike FOSS. After switching to Linux a ways back, I never even had a reason to buy McAfee products. Their business is dependent on vulnerable software for them to come in and protect; clearly any solid development model would be a threat to their wellbeing. It's not (just?) problems with FOSS software that bothers McAfee, it's FOSS's strengths, too.
"A witty saying proves nothing." - Voltaire
How about your write your OWN DAMN CODE instead of complaining, or just STEAL Theo De Raadt's. He WON'T mind AT ALL, honest :)
Translation: "Some manufacturers have voiced concerns that the requirement could leave important user-restriction features or copyright fair-use prevention features in their products open to rightful destruction."
They fail to grasp the most important aspect of GPL: every end-user is also the master of said software; it is not up to anyone else to decide what he can and can't do. Features which keep the end-user out are not part of (publicly distributed) GPL software, period.
If you don't have sufficient code review processes in place, and you don't know where your employees are copying code from, that's very much your problem. McAfee may be that unprofessional, but if they are they deserve everything that's coming to them.
I'm old enough to remember when discussions on Slashdot were well informed.
It already exists, it's called Dazuko. It's licensed under the GPL for the Linux kernel, and BSD license for FreeBSD. But the Linux kernel license makes it quite clear that making system calls from user space (essentially all kernel extensions like this just provide extra syscalls and ioctls) does not constitute a derivative work so far as the GPL is concerned. Otherwise any piece of proprietary software running on Linux would be necessarily screwed.
Something like inotify doesn't cut it for a virus scanner, since it needs to intercept read / write calls to be able to scan the files before the data is read. Something like systrace on {Net,Open}BSD could do it, but there is a known security vulnerability in that entire approach (which also affects virus scanners on other platforms).
I am TheRaven on Soylent News
I have been reading a fair bit of legal analysis (IANAL) relating to the GPL v2 and have been discussing various ambiguities relating to the GPL v3 with people at the SFLC. These licenses *do* have some ambiguities (though I think they are less of an issue for the GPL v2).
The major issue for the GPL v2 is that it is not 100% clear where the boundary relating to mere aggregation is. In general it is easy to read "a work based on the original work" meaning derivative work (i.e. a transformation or adaption of the original work in the same way that a movie may be based on a book, or a sequel may be based on another book), while aggregation seems to read as a collected or compiled work, but these simple interpretations are at odds with the FSF's interpretations. I.e. dynamic or even static linking would seem to create (possibly non-literal) compilations under copyright law, not derivations even if the linker strips out unused portions (this is because that process would not be creative enough to create a *new* copyrighted work in the form of the new library code). Hence the simple reading of the GPL v2 would seem to allow one to link proprietary applications to, say, GNU Readline. This question has not been resolved in court yet.
The GPL v3 has the same issue, but adds a few more. For example, does section 7, paragraph 2 govern sections of BSD code included verbatim in a GPL v3 application? I.e. must one be allowed to change the license of a file to the GPL v3 in order to call it compatible? (Eben Moglen says "Yes" while Richard Fontana says "No"-- both are members of the SFLC and both were involved in the GPL v3 development process.)
There are also a few false ambiguities-- for example the question as to whether mere use of software inside an organization might ever one to license patents out (the relevant section of the GPL v3 only applies to explicit patent licenses), though clearly one would want to stop using software before filing patent suits due to patent retaliation clauses.
LedgerSMB: Open source Accounting/ERP
And there's good reason for this. You don't necessarily know the provenance of the source code.
Here's an example: I was doing evaluations of the two open source identification products available today (from Black Duck and Palamida), and I found an instance where it appeared that code that was originally released under the GPL had found it's way into code that was released under the Apache license. I did some due diligence on this, looking back in the repositories to see when the initial checkins had been done to determine which project had the code first. Admittedly, that's not fool proof, but was the best I could do under the circumstances.
So, now imagine if someone in good faith takes the code from the Apache licensed project and uses it in their proprietary product. They comply with the Apache license. Then someone from the GPL project comes along and says "Hey! You're using OUR code that was made available under the GPL, you have to release the source code for your product." Legally speaking, that could be the result. And some people don't want to take that chance.
So as far as I can tell, here's what this story is actually about:
McAfee makes a virus scanner for Linux. Presumably the "on-demand" scanning uses a closed-source kernel module. Some kernel developers (i.e. copyright holders) assert that it violates the GPL to distribute closed-source kernel modules (although NVIDIA's and ATI's lawyers presumably disagree). This has never been tested in court. If one of the kernel copyright holders decided to litigate and won, then McAfee might have to stop selling their product, or significant alter it. Since there is a risk of this happening, they are required to disclose it to investors.
Refactoring isn't just "any random change of the code".
Refactoring means modifications of the code that are not supposed to alter its functionality. Things like renaming variables or moving code or data from one place to another.
I re-factor a lot of code, much of it I did not write (but sometimes its my old code where I didn't get it perfect or account for future developments).
Semantic transformations of code that do not alter functionality allow you to remain relatively sure that you are not breaking anything (especially if there's good test coverage) while fixing a bad design, or after having found a novel way to reduce code duplication or such. Once code duplication and tight coupling was removed or reduced, adding new functionality, finding and fixing bugs is much easier.