Risk Factors You Ought To See for Proprietary Software
I’ll start off with the traditional “I am not a lawyer” disclaimer.
I just read Computerworld’s article about McAfee’s statement that open source licenses are a “risk factor” for their business. Jeez. Who would have thought that a company that makes their livelihood off of fighting viruses (mostly in proprietary closed source software) would be such a whiner. OK, I know that those “risk factors” probably include everything that could possibly go wrong so that the company or executives won’t get sued by shareholders. And I know that some associate at a law firm got paid $300 an hour to read about the GPL lawsuits in the newspaper and then add a new risk factor as a way to up their billable hours. But, come on, you can’t really be serious.
If we’re going to get that paranoid, companies might as well start including risk factors for the proprietary software they use. Companies could include risks like:
- Proprietary software we use could be really buggy and break down, making it impossible for anyone in the company to get any work done.
- Proprietary software companies that supply our software may be bought by Oracle and then “integrated” or “end of lifed”, forcing us to spend a boatload of money and time on upgrades.
- We could get sued for violating proprietary software licenses because we haven’t paid attention to them since we bought the stuff.
- We almost certainly are using proprietary software on a heck of a lot more machines than we paid for, and if the vendor finds out we could owe a big fat bill.
- Our proprietary software suppliers could decide to raise our maintenance by 3x and then we’re really screwed because we don’t have any alternatives.
I think all of my suggested risk factors are a lot closer to reality. Yes, companies do need to pay attention to open source licenses. Yes, companies do need to comply with open source licenses. Yes, an open source software license could have ambiguities. Yes, there is a possibility you could get sued if you don’t comply with an open source software license. Yes, open source needs to be part of your governance or compliance program.
But all of those statements are equally true for proprietary software.
If you pay attention to open source license compliance, you won’t need to worry about updating your “risk factors”.
Oh come on, this is such a nonsense post.
I’m afraid that thoughtless blog posts like this one do the whole of the Open Source Community a disservice. It’s clear that you haven’t read or understood the McAfee article you quote, and by descending into superlatives of “$300 lawyers” and the like you omit the main point.
McAfee is exactly correct; it does indeed face a huge threat from Open Source licenses. Or rather, specifically, the GPL (GNU Public License). It is ignorant to claim otherwise. Just about every propietary software company in the world does.
The reason is that the GPL has an explicit “copyleft” clause, which stipulates that any code originally released under the GPL must always remain Open Source, even if incorporated into other code.
Here’s what that means in plain English. Imagine I develop a cool utility for, say, parsing an XML data stream. Doing the honourable thing, I release my utility out into the open under the GPL. Imagine then that proprietary software company A finds my utility and decides to use it in its next release. It even gives me credit for that part of the functionality, and let’s say they even visit my home page and make a generous donation too.
This happens all the time - why would developers at company A rewrite such a utility if my Open Source one already exists! We can even assume that I’m perfectly happy for them to use it!
The catch is this; by using my utility, which is under the GPL, company A has inadvertently accepted the GPL terms FOR ITS ENTIRE PRODUCT. Only it probably doesn’t know this. So it continues to sell the application, of course. And protect the IP. Which breaks the terms of the GPL and can lead to them getting sued, just like Skype…
The real point is this; you have to be COMPLETELY Open Source. It’s no good trying to stay proprietary and picking up Open Source code snippets. One or the other. You want to use Open Source? Then go Open Source entirely, or otherwise leave all that excellent code alone and write your own.
Phil
Phil,
Thanks for the feedbackand your comments. I completely understand what you are saying about the copyleft provision of GPL. If a company wants to use GPL software and create a derivative work and distribute it, they need to comply with that provision. If that doesn’t work for them, then they need to select a different piece of open source that’s under a different license. Yes, that may mean they can’t use every piece of open source, but it’s highly likely there is an open source solution that has a license that will fit their needs.
My point about McAfee is that if they don’t pay attention to the open source license provisions, then, yes, there is risk. However, there is risk if they don’t follow license provisions for proprietary software as well. Different risks, but still risks. Some might say that the copyleft provision is a bigger risk, but I think that if you add up all of the risks around proprietary software, they are not insignificant.
I am not saying “all proprietary software is bad, all open source software is good”. Our customers all operate in mixed source environments — proprietary, open source and custom. Although I used a tongue-in-cheek approach, the underlying point is the that BOTH TYPES of software have to be managed — with evaluation of licenses, addressing of risks, etc.
Kim
“This happens all the time - why would developers at company A rewrite such a utility if my Open Source one already exists! We can even assume that I’m perfectly happy for them to use it!”
It’s very possible to do that *without* violating any copyright.
Being the only(obviously you can’t sell something that isn’t yours) copyright holder you can fork(same code, two licenses) and sell it.
This works the same with all copyrighted material. Just taking something is theft, GPL or proprietary alike .
@Phil:
“This happens all the time - why would developers at company A rewrite such a utility if my Open Source one already exists! We can even assume that I’m perfectly happy for them to use it!
The catch is this; by using my utility, which is under the GPL, company A has inadvertently accepted the GPL terms FOR ITS ENTIRE PRODUCT. Only it probably doesn’t know this. So it continues to sell the application, of course. And protect the IP. Which breaks the terms of the GPL and can lead to them getting sued, just like Skype…”
So you’re saying that if any non-open-source company offered you the ability to use its code for a limited purpose (say for a particular in-house use, or for inclusion in the software you sell at the cost of a per-sale royalty), it’s alright for you to just ignore the terms of the agreement and distribute their code without consideration for those terms?
If you want to offer your code to companies and you want them to be able to include it without forcing their code to be public, don’t use the GPL. There are a multitude of other licenses available to do just that. Do you want them to contribute changes back to your libraries, but don’t need them to contribute the code that uses those libraries? Use the LGPL. Do you only care that they give you credit, but they can include your code any way they like without revealing any source code? Use the BSD license or use the MIT license if you don’t care that they use your name in their promotional material.
People who choose the GPL do so PRECISELY BECAUSE it keeps the code in the open. If you don’t agree to the terms, write the code yourself or purchase license to code that does what you want on more agreeable terms.
[...] On a related note, a great post appeared on the OpenLogic website earlier in the week about the risk factors of using proprietary software, which was a tongue-in-cheek response to yet another FUD-spreading proprietary software company, this time McAfee, complaining about the risk factors of adopting open source software. This humorous list verges on the paranoid but contains a few home truths worth remembering if you are preparing for an LMS, authoring tool or some other elearning software procurement. I have copied these lock stock and barrel from the OpenLogic blog post: [...]