Originally at http://www.ip-wars.net/story/2005/3/26/25110/8669
In a report on Ken Brown's latest paper, evidently not publicly available but reported upon in http://www.techworld.com/opsys/news/index.cfm?NewsID=3373&Page=1&pagePos=2 Ken Brown once again raises the spectre of Open Source Software coming under legal siege from the forces of proprietary software.
The gist of his assertion seems to be that many open source contributors work for companies with IP policies which under some circumstances leave their contributions open to legal question. Quoting Brown, from the article:
"Every day, an untold amount (sic) of employees beholden to strict employee/invention/intellectual property agreements, in their spare time (and even during work-hours) freely give away ideas, code, and products to open source projects."
This is probably true in a strict sense, but it does not address the likelihood that most such contributors are probably sensible enough to have at least tacit permission from their employers.
Brown's feeble attempt to create fear around F/OSS is clearly telegraphed shortly after:
Once the first significant litigation happens, it could open the floodgates against what Brown calls "public domain software". "Almost any ruling against a user, distributor, or developer of open source, could result in a precedent that could significantly change public domain software practices," he writes. Any precedent could "open the gateway for deluge of similar, copycat lawsuits".
It is more than a quibble to note that Brown equates F/OSS with "public domain", which it is clearly not. I think this is willful obfustication, and I'll go on to explain a "tinfoil hat" theory of why this assertion is being made.
But let's look at what the risks clearly are.
As presented the presumed risk Brown asserts is that BigMeanCompany would assert rights to shut down a F/OSS project to which its employees have contributed. For this to be a threat to F/OSS generally, this would have to happen in not just a couple of cases but to so many of the thousands of F/OSS packages out there that the risk of using F/OSS internally by a company would be deemed significant and real. The natural question arises, excepting the SCO fiasco, has it ever happened? Not that I've heard.
So could this happen on a large scale?
Well lets take a single hypothetical case. BigMeanCompany finds out that one of its employees, Johnny Programmer, is making contributions to GreatFOSSWare.
Now its options are:
- Give their blessing and sanction allowing him "work" time and company resources to work on it.
- Give their acquiescence, so long as it doesn't interfere with his work.
- Tell him to stop.
- Assert ownership of the code and demand it be removed from GreatFOSSWare.
- Try to claim ownership and marketing of GreatFOSSWare and/or claim royalties from users.
Now BigMeanCompany's mandate is to make money. That's going to color the range of their options.
Now unless GFW is a single developer project, number five is almost impossible. Other coders have contributed so BMC - as SCOX has discovered with Linux - has no real possibility of a claim of ownership of GFW. Even if Johnny's contributions comprise the bulk of GFW, there is the significant legal expense of establishing ownership - against Johnny's wishes and prior assertions. Depending on the employment laws in Johnny's state that could get very expensive indeed and is likely to take a long time during which GFW languishes against similar F/OSS projects.
But let's presume Johnny's state allows draconian IP provisions and he is the main contributor. Look at how little there is to gain: GFW is a mostly single contributor project... i. e. even if Johnny has no life at all outside work and his hobby it isn't that big. Now look at freshmeat for most small projects. Most small projects have three to a dozen competitors doing similar things. So BMC has to spend the legal resources to take ownership of Johnny's contribution, spend the programming resources to package it, and budget the ongoing marketing and support resources for GFW, now BMCGreatWare. to compete against ... three to a dozen free projects. Not if BMC wants to stay B it won't.
Similarly for number four, they'd have to assert ownership of part of the code. But even if they go to the expense of doing so what is there to be gained? Unless GFW competes directly with something BMC markets, there is no point in paying lawyers to establish the ownership. And Johnny would have had to have been dumb indeed to contribute to a project in direct competition with his employer. As a rule dumb people do not make good programmers.
And both options four and five are going to be very public and create backlash. Unless Johnny has been very obviously naughty and directly, negatively impacting BMC's business the negative publicity isn't going to be worth the trouble.
Option three is quite reasonable. Quite likely Johnny, being smart enough to be a programmer, had at least an email from his boss saying it was OK. A change in management or a new boss with other ideas, and they change their minds. Or perhaps they feel his work has become sub-par and his time spent on his outside interests are detrimental. Whatever the reasons, it is not a larger problem. Johnny looks at his situation and either quits contributing or looks for work where they won't bother him about his "hobby" interests.
Look again at Brown's thesis. That the BMC's could act against the F/OSS projects that their employees are involved in. That clearly presumes that the Johnnys of the world don't have their employer's permission (a proposition I think unlikely in most cases) and that they have motivation. After all I could sue any or all of a dozen neighbors and acquaintances for anything from dog doings on my yard to various habits I find offensive; somehow I've never been sufficiently motivated. There's nothing to gain, and aggravation and bad feelings as the only possible result. Of course I have the "right" not to have the neighbor's dog defecate in my yard, but so long as it is a rare occurrence the nuisance isn't worth larger trouble. The legal maxim is that you have only the rights you assert. And aside from the hassle legal rights are notoriously expensive to assert. For most sane people, and sane companies, with real lives and real businesses to be used solely as a last resort.
The only possible reasons for aggressive actions against F/OSS software which does not directly compete with the company's business is raw malice towards F/OSS itself. And BMC, like all companies is in business to make money. Most haven't the will or resources - the time, money, and good will of their clients and the public - to expend on philosophical malice.
Not when there are other options:
Option two is the status quo. Nothing changes. But Johnny is happy, and his skills are sharpened and his experience widened by his avocational project. By being in the grinder of a public F/OSS project he is constantly exposed to new ideas - requests and discussion to take his project to the bleeding edge of newer technologies is an everyday occurrance. Likewise he gains experience persuading others to help, to guiding volunteers and testers. These people skills are subtle but very real. If Johnny has a future in programming at the lead or manager level, what he learns will be invaluable.
And option one is potentially a public relations coup. Or at least a minor boast in the trade press of BMC's industry, or at minimum something to fill in the in-house newsletter when the HR people need something to do besides messing up the insurance policies.
So in the larger scheme of things I don't see many BMC's acting against their employees interests in F/OSS. It's bad for morale at the least. When added to the negative consequences and the lack of any real gain, and the unlikelyhood that enough F/OSS contributors to significant software are sufficiently idiotic to make such a scenario possible in the first place by not getting some level of prior permission, and I can't imagine enough of this kind of nonsense occurring to make an overall difference to F/OSS generally.
The only real possibility for enough potential gain to make action against a F/OSS project to be financially worthwhile would be against the large projects - Linux itself, Samba, Apache or a few others of similar stature. A very long and expensive gamble indeed and with SCO's experience of an attack against Linux now all but "in the books" I doubt most other companies are willing to follow in their footsteps. Large projects have large and varied contributors from all over the world and it is impossible for one company to take proprietary control of such a project under an OSI approved license without being in violation of it in other respects - exactly IBM's counterclaim eight against SCOX. And one thing not brought out, since SCOX's target was already one of the largest companies on the planet, any attack on the major F/OSS projects, any attempt by a company to claim a significant proprietary interest in one of those large projects, would be met with legal counterclaims from a wide variety of well financed attacks from numerous companies who now have a "stake" in these F/OSS projects.
Lets also consider things from the more abstract level. F/OSS has been likened to the commons of classical economics, and many who argue against F/OSS cite "the tragedy of the commons" as weighing against it. But the tragedy of the commons is played out as a zero sum game with finite resources. Software doesn't fit this economic model. Software can be used and reused by anyone wishing to partake. More the GPL and other OSI licenses give a small incremental value to contributing to this commons: if you use a piece of F/OSS and donate your changes, not only are you free to use and distribute your changes to your clients and customers, as well as internally, but there is the real value of having those changes and modifications peer reviewed, critiqued and sometimes corrected by other teams of programmers using that same software. Thus amid the pool of all F/OSS projects those of greatest value to your company remain current an vital partly by your own actions and feedback resulting from your contribution. Additionally all the free software you may use but do not actively develop is available as needed, kept current and maintained by others for their more demanding needs just as you've done for your own.
This creates what is almost an ecology of Free Software and the companies that use it. Those companies which compete around the commons but use the commons cooperatively gain a competitive advantage over those who spurn the commons completely, and to some extent greater use and contribution to the commons gives additional advantage over other commoners to the extent that the software in the pool aids that company in its niche. Similarly the commoners have an interest in protecting the commons, and like militias of old will band together in its defense.
The danger to this ecosystem comes only from those who do not take sustenance from the commons and are powerful enough to withstand the joint hostility of those who would defend it. Those few who would fence the ranges or poison the lake against all who would peaceably use it. Remember that "tinfoil hat" theory I mentioned? Why confabulate a Free Software licenses - free to use under license terms but properly and lawfully copyrighted by its authors - with public domain? Because perhaps someone is hoping for legislation or court rulings that GPL'd or other Free Software licensed software would be held in the public domain and donated collective copyrights abrogated. Then perhaps, an interest established in contest could claim an entire work polluted and withdraw it by force of law from the commons, and then claim sole proprietary right.
It sounds very much like Mr. Brown is beyond surveying the ranges and watercourses and is now digging postholes on behalf of his sponsors.
-- TWZ
------------------------------------------
Copyright 2005 by Terrence W. Zellers. This article is made available for publication under terms of the Creative Commons Attribution-ShareAlike 2.0 license as published at http://creativecommons.org/licenses/by-sa/2.0/
|