Cisco Settles, But Where From Here?
Until September 20, 2007, nobody had ever sued anybody for violating the General Public License (GPL) — not a single company, project, or individual developer in the license's then-eighteen year existence. This momentous first, settled in a mere month, was only the beginning — the beginning of a landslide of litigation large enough to make Apple's lawyers cry.
Civil complaints poured forth from the Software Freedom Law Center like Henry Ford's Model T, landing in the laps of High Gain Antennas, LLC and Xterasys Corp, Bell Microproducts and SuperMicro Computer, even communications powerhouse Verizon. Each was eventually forced into the same settlement: provide the source code, appoint an Open Source compliance officer, and pay out an undisclosed amount. And the Open Source community rejoiced.
The SFLC even went so far as to publish a guide to not getting sued, over and above the general advice that if a SFLC lawyer calls you up and says it plans to sue you, for the love of all that is technological, do what you're told. What had never happened, even amongst the SFLC's barrage of litigation on behalf of BusyBox, was to come, however.
On December 11, 2008, the Free Software Foundation, as represented by the Software Freedom Law Center, sued Cisco Systems for violation of the GPL. Earlier this week, the parties settled that suit, to the tune of the normal terms: Cisco will appoint a watchdog for Linksys, people who bought the Linksys products in question will be informed of what the GPL means for them, a license notice will be added to Linksys' website, the relevant source code will be made available on its website, and an undisclosed amount of cash will be coughed up — we suspect it won't be at the associate membership rate. Still, it's better than the original demand, that Cisco "disgorge to Plaintiff all profits derived," — rather like they planned to feed Cisco an industrial-size dose of Open Source ipecac. The full fifteen page complaint PDF, and the accompanying twenty-three pages of licenses, are available online.
Still, what made suing Cisco so different from all the other companies the SFLC has chased down?
Aside from being a gold member of the Linux Foundation — at $100,000 a year — Cisco Systems just happens to be one of the largest contributors to the Linux kernel, undoubtedly the most widely known Open Source project, period. As of the Linux Foundation's April 2008 Linux Kernel Development report, Cisco was responsible for 0.5% of the work being done on the kernel.
Doesn't sound that significant?
Consider that shortly before the FSF filed suit, the Linux kernel was reported to have reached nearly six and a half million lines of code — over ten million if counting actual lines, which include comments, text files, and blank lines. The numbers total out to, on average, for every day of the last two and a half years, more than 3,600 lines of code have been added, 1,500 removed, and 1,400 changed. Linus Torvalds — the belovéd creator who has been working on the code for almost twenty years, and whom the Linux Foundation pays, full time, to continue doing so — stands at 0.6% of changes. Not bad for a company, unlike firms such as Red Hat, that aren't focused around Linux products, and doesn't .
Also fairly impressive for a company who several months before opened up a highly-popular line of routers to third-party development of Linux-based modules. That wasn't it, though, as almost two months to the day before they were sued, they announced a $100,000 competition — for those who are counting, that bumps the total up to $200,000 on Linux for the year, not counting the salaries of the unknown number of people they pay to make those 0.5% of contributions — to encourage, and of course, reward developers for designing and developing those Linux-based modules.
Was it pure altruism? Of course not, but whose corporate development is?
That is, of course, not to ignore Cisco's other Open Source contributions, including those to Apache and Eclipse, among others. Their microgrant program for non-profit organizations interested in the Open Source community and Cisco and the $400,000 — that's up to $600,000 — Cisco donated to the Silicon Valley Education Foundation to support cost-free Open Source solutions to retain teachers and improve attendance are nothing to sneeze at either.
The point of this Open Source Cisco CV? Aptly enough, a gnome: Don't bite the hand that feeds you.
Did Cisco screw up? Yeah. Should they have listened when it was pointed out? Yeah. Should they have to make it right? Yeah. However — and this is where the pragmatist diverges from the ideologue — people don't like to be sued. Cisco is making a lot of contributions to Open Source projects. That doesn't excuse violating licenses, not in the least, but it isn't just a case of "if they don't make them, somebody else will." They're going to figure this stuff out anyway, and there are two choices: Open Source or proprietary. If Cisco makes advancements first and patents them, then other people can make the same advancements until the cows come home, they still won't be able to do anything with it. The lost money doesn't really matter, that can me made up somewhere else, but making enemies does. We don't want to turn our allies into enemies, and make other allies wonder if we're going to do the same to them.
Making enemies is just the beginning, however. This lawsuit — yes, this one individual lawsuit — could have brought the whole thing crashing to the ground. Non-profit organizations — even those represented pro bono by other non-profit organizations — don't have the financial resources that a corporation with $39,000,000,000 in annual revenue. Companies like Cisco have lawyers, and a lot of them. Not your friendly neighborhood lawyer who draws up wills and gets people out of traffic tickets — flesh-eating lawyers who aren't concerned that the enemy is a non-profit organization contributing to the greater good. An army of attorneys puts out a tidal wave of paperwork, much of which requires thousands of reams of documents in response — just take a look at the SCO litigation — and if there isn't an army of attorneys on the opposite side — the SFLC has eight, to spread amongst all its clients — it can very quickly lead to bankruptcy. For that matter, the plaintiff could lose, and even if the defendant wasn't awarded damages, they are entitled to recoup their costs. Armies of lawyers aren't cheap, and bankruptcy is not what we want.
Perhaps worse, from a utilitarian standpoint, is what each of these lawsuits means for the GPL. The GPL has never — not once — been tested in court. Never. Each time somebody files a lawsuit over the GPL, they hand its opponents the opportunity to dispatch it once and for all. There is kinda-sorta-maybe-possibly if-you-turn-it-this-way-it-looks-like-the-Mona-Lisa case law regarding other licenses that gives a general idea of how such a case might turn out, but with the possible exception of one federal circuit, that case law is merely informative, not binding.
Eventually, a defendant is going to decide not to settle, and if the plaintiff is still solvent after the flood of paperwork is finished, the court is going to rule on whether the GPL has any merit or not. If the court finds it does not have any merit, it's over. Sure, there can be appeals — and one, possibly two more rounds of paperwork, not to mention that if it went that far, not every attorney is a member of the Supreme Court bar, and experienced attorneys who are don't come cheap. Once the appeals are over, if they ever even get a start, the possibility exists that the GPL will be over too. It's a very real possibility: it wouldn't be the first time a license, contract, or other agreement was ruled void. Where does that leave all the projects that are licensed under the GPL, especially the ones, like Linux, that have too many contributors to be able to get them all to consent to a new license? Where does it leave licenses similar to the GPL?
We can scoff, we can laugh, we can insist that it could never happen, but that doesn't change reality. These lawsuits aren't just fun little jaunts to get companies to give out source code, they're very real opportunities for the whole ship to go down faster than the Vasa. That just isn't something we can afford to have happen.
Lest there be any confusion, we don't want that to happen. We don't want companies to get away with violating the licenses that make our work possible. For that matter, we don't want them to violate them in the first place, so there's no it to get away with period. We want companies to fulfill their obligations, we want developers to feel safe in licensing their code under the GPL and other licenses, and we want companies to feel safe in using Open Source code. We can't, though, sugar coat the reality that these lawsuits are as much a threat to us as they are to the offenders. It's a disservice to us all to assume that winning is a forgone conclusion — after all, Dewey Defeats Truman.
Justin Ryan is a Contributing Editor for Linux Journal.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide