SFLC steals a page from the Business Software Alliance - good thing there is no patent on strike lawsuits!

Those of us who thought maybe Free Software was all about love and peace and breaking with the "tyranny" of copyright and other intellectual property might have been surprised by four recent heavily publicized lawsuits filed by the Software Freedom Law Center (SFLC) on behalf of BusyBox, a lightweight set of unix utilities licensed under version 2 of the Gnu Public License (GPL). 

These suits, filed in rapid-fire succession in September, November, and December of 2007 against Monsoon Multimedia, Xterasys, High-Gain Antennas, and Verizon, all involved the same claim that these companies (perhaps inadvertently) distributed the BusyBox program with their products without the source code as required by GPLv2.  The lawsuits all seem to have settled the same way as well: by promising to release the code, appointing an "open-source compliance officer", and paying an undisclosed sum of money to the plaintiffs.  (See links for the settlement details for Monsoon Multimedia, Xterasys, High-Gain Antennas, and Verizon - the Verizon case is unique in that the settlement mostly penalized the third-party company that supplied the product containing the offending BusyBox code).

These lawsuits in the U.S. are mirrored by actions in Europe, most recently the lawsuit brought against Skype, which distributed a flyer with its product listing the internet address where source code could be downloaded by interested consumers, but failed to distribute the text of the gpl with the product.

These companies were all punished for adopting open-source software in their products, but doing so imperfectly.  If these actions seem familiar, you might be thinking of the Business Software Alliance (BSA), which has been criticized for what some call intimidation tactics to "punish businesses that may be trying to play by the rules".  And GPL lawsuits are only going to increase: the people behind the SFLC just formed a for-profit law firm so that open-source businesses can sue for violations as well.  The "free software" folks must be thinking: "why should proprietary software have all the fun?"  It is high irony that the RedHat blog highlighted actions by the SFLC and the BSA within a few days of each other.

What should you do if you receive the dreaded call or letter from the SFLC?  Well, it might pay to take the advice given to those who have received similar [edited] audit letters from the BSA.  Some good advice from Baseline magazine:

1. Hire a lawyer.
2. Cooperate -- carefully - "Remember the sole propose of the BSA [and the SFLC] is to get as much money from your business as possible."
3. Don't rush out and buy or remove any software - it won't make any difference at this point.
4. Preserve confidentiality of evidence by having a lawyer involved in the internal collection of information, which imbues that effort with privilege.
5. Find your allies.  Baseline suggests involving your software vendors.  Verizon successfully demonstrated that it pays to make sure that the people who helped you get into this mess help get you out of it by involving the vendor who supplied the products containing BusyBox.
6. Create a compliance plan.  You will have to have one as part of any settlement with either the BSA or the SFLC.
7. Negotiate non-monetary aspects.  While the BSA might agree not to publicize any settlement, that doesn't seem to part of the SFLC's new game plan, which has involved heavily publicizing its settlements with press releases, etc. 

Litigation is expensive.  Both the SFLC and the BSA are well aware of the incredible costs that targeted companies would incur just in discovery, let alone fighting the full case in court.  Be careful out there.

While I am a lawyer, I am not your lawyer.  This is not intended to be legal advice.  I sincerely hope that you do not come within the cross-hairs of either the SFLC or the BSA [edited].

Comments

[Mark]

I'm not entirely sure how you can link the BSA and the SFLC together. As far as I know, the SFLC does not aggressively attack a business in an attempt to recoup revenue for damage already done; instead, they're looking for the company to change its behavior. I've never heard of a company driven out of business after falling afoul of the GPL, or switching their operating system due to the harassment incurred. (evidence: http://news.cnet.com/2008-1082_3-5065859.html?hhTest=1)

[Noah Clements]

SFLC did seek and receive (an undisclosed sum of) money in every suit it has filed so far. And I would consider their litigation strategy aggressive, but that's what makes it effective. You are comparing the damage done from 15 years of the BSA's "compliance efforts" with that done by the SFLC's first four suits - what I am saying is that if the SFLC does continue to use the same tactics, it is bound to see the same results.

Or to put it another way, along the lines of your example, if Ernie Ball starts to use open-source software in its music products and inadvertently did not include the source in one and was sued by the SFLC, are you sure that Sterling Ball would not react in exactly the same way as he did against the BSA action? If he wouldn't, why not?

[Hyman Rosen]

Companies in violation of the GPL are generally contacted beforehand and asked to comply. It's when they don't that litigation happens.

The freedom desired by the FSF is for users of software, not developers or distributors. If a company is shipping GPL-licensed software without complying with the GPL, then end-users are disadvantaged; they cannot examine and modify the software they have received. If this is troublesome for developers and distributors, that's perfectly fine as far as the FSF is concerned.

[Noah Clements]

Hyman, the point of the post was that if that was true in the past, it may be less true now. In at least three of the above examples, suit was filed the day after first contact by the SFLC, Monsoon Media being the exception.

Your second point is a more philosophical one about the goals of the FSF. Seeing as how the only end-users who look at the source code are developers, FSF does not really want freedom for users. The FSF wants the kind of freedom that it thinks is good for users, but in making that choice it takes away a little freedom, for your own good.