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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Server Hardening
- May 2016 Issue of Linux Journal
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- The Humble Hacker?
- The US Government and Open-Source Software
- BitTorrent Inc.'s Sync
- The Death of RoboVM
- Open-Source Project Secretly Funded by CIA
- New Container Image Standard Promises More Portable Apps
- ACI Worldwide's UP Retail Payments
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide