|
|
Log in / Subscribe / Register

GPL enforcement: waiting for the Monsoon

By Jonathan Corbet
September 26, 2007
Some lawsuits begin quietly, others are launched with great fanfare. The Software Freedom Law Center and two BusyBox developers have recently decided to take the latter approach to address a GPL compliance problem. The SFLC's press release reads:

The Software Freedom Law Center (SFLC) today announced that it has filed the first ever U.S. copyright infringement lawsuit based on a violation of the GNU General Public License (GPL) on behalf of its clients, two principal developers of BusyBox, against Monsoon Multimedia, Inc.

Before getting into the meat of the matter, it is hard to resist quibbling about the details. To that end, one could look at another GPL lawsuit press release, this one from the FSF:

Eben Moglen, General Counsel to the Free Software Foundation (FSF), will testify as an expert witness in the Progress Software Corporation vs. MySQL AB case currently pending in United States District Court in Massachusetts. The current focus of this case is a preliminary injunction sought by MySQL AB concerning a violation of the GNU General Public License (GPL) by Progress Software Corp.

In this case, the judge declined to enforce the GPL in a summary judgment motion, though the ruling acknowledged that MySQL appeared to have the stronger argument. The dispute was eventually settled, with Progress releasing its proprietary MySQL enhancements. It should also be remembered that IBM has brought GPL-violation charges against the SCO Group. So this suit might be the first which is exclusively about GPL enforcement in the US, but it is not the first time that the GPL has been the subject of a suit.

The dispute this time around relates to Monsoon Media's HAVA series of products designed to control and distribute television signals throughout the home. In March, 2007, a HAVA owner started a forum topic by asking if the product contained Linux. Nothing happened until the end of August, when another participant noticed that the firmware image clearly contained a version of BusyBox. On September 5, a Monsoon employee replied:

I have a little secret to let you in on - HAVA runs Linux! Yes, much of the source is GPL and we should publish those sections which we have modified per the terms of GPL. A project is underway to pull this together.

This person went on to suggest that, by looking inside the HAVA firmware, the forum posters were violating the end user license agreement for that software and that they should desist. The EULA talk did not go very far (it was pointed out that anybody can download the firmware without agreeing to the EULA), but the "project to pull this together" on GPL compliance also did not seem to go very far. Responses to questions on when a release could be expected were vague at best, and often absent entirely. Evidently private communications from the BusyBox developers went unanswered.

So, September 20, the SFLC filed suit on behalf of BusyBox developers Erik Andersen and Rob Landley. The complaint could be a textbook example of a straightforward GPL-violation charge; it complains of copyright infringement and asks for remedies in the form of an injunction against further distribution and monetary damages. The suit appears to have been successful in focusing minds at Monsoon Multimedia; on September 24 the company sent out a press release stating that it was in settlement negotiations and intended to comply with all of the relevant license requirements. The company also posted a comment on LWN stating that it plans to fix the problem:

We wish at this point to apologize for this oversight, both to the copyright holders of the code which we have used and modified, and to the free software community in general. We take full responsibility for these actions. We fully endorse the concepts of free software. We are now working closely with the copyright holders to make sure that our obligations under the GPL are met in full measure.

Thus far, no settlement has been announced. Given that Monsoon has stated its intent to comply with the GPL, the sticking points can only be (1) the timing of the code release, and (2) what else Monsoon might have to do to make the developers happy. Previous GPL-related settlements elsewhere in the world have generally involved compensation for expenses incurred in the enforcement action and, perhaps, a donation to a free software-related project. There is no way to know what the plaintiffs are asking for here, and the final settlement - if and when it happens - may never be made public.

From the outside, this case does not have the look of a deliberate attempt to ignore the GPL. Instead, it looks like a small company which found free software useful in the creation of its product and which put the GPL-compliance part of the job - if it really even understood its obligations in that regard - on the back burner. Anybody who has ever worked in a small operation knows that it can be a long time before anybody has a spare moment to work on perceived low-priority jobs like that. So Monsoon never got around to its source release, even when people started asking questions. It took the filing of a lawsuit to get the company to put some resources into fulfilling its obligations.

It has been suggested that the BusyBox developers acted hastily, given that less than a month passed between the discovery of the problem and the filing of a lawsuit. Unlike some jurisdictions, the U.S. does not require that copyright actions be filed quickly in order to preserve the right to sue. The BusyBox developers might answer that there was nothing else they could do when Monsoon refused to respond to them and that they are generally tired of companies ignoring the license on their code. Whatever their reasons, it seems likely that the BusyBox developers stand a good chance of being taken more seriously the next time they ask a company to comply with the license on their code.

This case may not be the first time that the GPL has found its way into a U.S. court. Its (presumed) quick resolution does suggest that another invariant - that no U.S. court has ever ruled on the validity of the GPL - still holds. Unless the SCO Group somehow manages to continue to exist long enough to push the IBM case through to the end, it appears this situation will not change anytime soon. This is an interesting situation, considering the value of the code licensed under the GPL and how long the GPL has been in use. The conclusion is clear: there are no potential GPL violators out there with enough confidence to try to challenge the GPL in court. The GPL looks well positioned to continue to do the job it was created for all those years ago.

to post comments

GPL enforcement: waiting for the Monsoon

Posted Sep 26, 2007 18:46 UTC (Wed) by jengelh (subscriber, #33263) [Link] (8 responses)

From GARY-MM's forum post:

>Seems to me that some of you have just come out blatantly admitting you are reverse engineering the firmware - or trying to. How should we handle this?

Running strings on firmware is not considered reverse engineering, at least in Germany[1].

[1] http://www.jbb.de/judgment_dc_frankfurt_gpl.pdf (english), page 5, paragraph 6, "Plaintiff's copyright claim may also be based on the code strings identified by Plaintiff. Contrary to Defendant's claims, this evidence is not excluded."

GPL enforcement: waiting for the Monsoon

Posted Sep 27, 2007 0:57 UTC (Thu) by Ross (guest, #4065) [Link] (6 responses)

I totally agree.

In fact reverse engineering is a whole separate class of effort from running a single command. It is the opposite of normal engineering -- you take something that exists and trying to figure out how to make a set of requirements out of it (normally for the purpose of making a similar design and then implementing it).

strings is just a way to see what text is in a binary -- it tells you little or nothing about the internal structure, though, like in this case, it can tell you if there are similarities with well-known products. That's using it as more of a copy-detection tool than reverse engineering.

GPL enforcement: waiting for the Monsoon

Posted Sep 27, 2007 22:10 UTC (Thu) by giraffedata (guest, #1954) [Link] (5 responses)

It is the opposite of normal engineering -- you take something that exists and trying to figure out how to make a set of requirements out of it (normally for the purpose of making a similar design and then implementing it).

I don't think that's what is meant by reverse engineering. What you describe would be pretty useless, because the requirements are usually glaringly obvious. In typical engineering, you go from requirements to design, and then in manufacturing you go from design to implementation. Reverse engineering is like any other engineering, in that its goal is a design that fulfills certain requirements. But you get to it by starting with an implementation -- i.e. the reverse direction of normal.

In engineering a ballpoint pen, you start with requirements such as "must write upside down" and "must fit in a human hand" and end up with blueprints sufficient for the manufacturer to make one or more pens. Blueprints are the design. In reverse engineering a ballpoint pen, you take a manufactured pen and dismantle and measure to arrive at equivalent blueprints. You then give those to your own manufacturer to make identical pens.

strings is a great reverse engineering tool. It helps you see what pieces the system is made of -- what engineering choices went into it, so you could possibly make one yourself.

GPL enforcement: waiting for the Monsoon

Posted Sep 27, 2007 22:32 UTC (Thu) by jengelh (subscriber, #33263) [Link] (2 responses)

strings is more like taking a look at the pen and noticing that there's "Busybox" printed at the side (think of these self-advertising gifts companies hand out).

GPL enforcement: waiting for the Monsoon

Posted Sep 28, 2007 5:44 UTC (Fri) by sepreece (guest, #19270) [Link] (1 responses)

It's somewhere in-between. What you get from strings is not what's on the outside of the binary, but what's on the inside. Using it certainly *could* be part of a reverse-engineering effort. Whether it violates the EULA would depend on the exact terms of the EULA - if it says "reverse engineering" then you could argue intent; if it specifically says you agree not to look at the executable code, then you'd have a harder argument.

GPL enforcement: waiting for the Monsoon

Posted Sep 29, 2007 8:14 UTC (Sat) by jengelh (subscriber, #33263) [Link]

Mh, a text string in a binary is like a ink drop on paper -- it will be visible on both sides.

GPL enforcement: waiting for the Monsoon

Posted Sep 28, 2007 5:53 UTC (Fri) by Ross (guest, #4065) [Link] (1 responses)

I hope it wouldn't be useless, because that's what is usually being done.

If you are copying internal details that don't matter, just because you don't want to design them yourself, that's also reverse engineering, but it is probably also copyright infringement assuming the original is under copyright.

The point is, when you are doing this, it is because you have to be compatible for some reason -- to match an interface, protocol, connector type, etc. Some of the details of the original become requirements in the new design, because if they didn't match, your replacement part wouldn't work.

GPL enforcement: waiting for the Monsoon

Posted Sep 29, 2007 19:22 UTC (Sat) by giraffedata (guest, #1954) [Link]

I forgot about the reverse engineering to determine an interface protocol. I don't think my engineering terminology calls that interface protocol "requirements," though. Requirements I'm used to are something like "must read Microsoft Word documents," and then it is an engineering task to develop a design, which includes figuring out the Word document format, and you might do that starting with a finished copy of Word. The resulting design might be expressed in a functional specification, which would include the document format.

If you are copying internal details that don't matter, just because you don't want to design them yourself, that's also reverse engineering, but it is probably also copyright infringement assuming the original is under copyright.

To be copyright infringement, you'd have to copy the code verbatim, and then I don't see any engineering involved. If you just disassemble the code, understand how it's structured, and then write code that's structured the same way and does the same things, there's no copyright infringement. In fact, you can start with the original source code and do the same thing and you're still OK.

Patent infringement, maybe. If it's easier to analyze someone else's object code than to write code from scratch, you're probably dealing with some patentable innovation.

GPL enforcement: waiting for the Monsoon

Posted Sep 27, 2007 6:29 UTC (Thu) by ekj (guest, #1524) [Link]

Besides -- it's completely irrelevant if doing that constitutes "reverse engineering" or not.

First, reverse engineering isn't prohibited. There is no law forbidding you from trying to understand how something you own works.

If you agreed to an EULA wherein reverse engineering was prohibited, you *may* have had a problem if you a) live in a jurisdiction where such have any weigth whatsoever and b) if the company actually owned what they're "licensing" -- which fails to be the case here.

In any case, the firmware is freely downloadable completely without agreeing to any EULA, so that point is moot regardless.

GPL enforcement: waiting for the Monsoon

Posted Sep 26, 2007 18:51 UTC (Wed) by vmole (guest, #111) [Link] (6 responses)

From the outside, this case does not have the look of a deliberate attempt to ignore the GPL. Instead, it looks like a small company which found free software useful in the creation of its product and which put the GPL-compliance part of the job - if it really even understood its obligations in that regard - on the back burner.

I call BS on this. It's not 1991. Developers know when they're using GPL code. They might not be up on the fine legal points, but the source distribution requirements are fairly clear and widely discussed. The whole "Yes, we're using Linux but you're not allowed to look at it" argument is hardly an innocent mistake. If the immediate response had been "Oops, sorry, it'll be on our FTP site in the morning", I might buy "it was a mistake" argument. Ignoring e-mails from the developers until the lawsuit was filed pretty much rules that out.

I used to work for a small company (5 people, 3 technical). Our main product was proprietary, but we shipped some adjunct tools that were under GPL and other copyleft licenses. Putting the (yes, modified) source for those on the CD was just part of the build procedure. It's simply not that hard or time consuming.

GPL enforcement: waiting for the Monsoon

Posted Sep 26, 2007 19:33 UTC (Wed) by ajross (subscriber, #4563) [Link] (5 responses)

It's not 1991. Developers know when they're using GPL code

Yes, but their bosses don't. Or their bosses don't understand the issue. I find it eminently plausible that the tech folks were in meetings on a regular basis saying things like "You know, we need to do a source release for the busybox stuff." and were being ignored.

GPL enforcement: waiting for the Monsoon

Posted Sep 26, 2007 21:00 UTC (Wed) by vmole (guest, #111) [Link] (4 responses)

I don't. They made a conscious decision to use Linux and Busybox. While "Busybox" may not have rung any bells to any non-techies, I can't believe that "Linux" didn't.

Or rather, I can believe that certain people in Monsoon's management ignored the tech folks. I simply can't believe they did it through ignorance.

GPL enforcement: waiting for the Monsoon

Posted Sep 27, 2007 4:38 UTC (Thu) by felixfix (subscriber, #242) [Link] (3 responses)

It is eminently plausible and indeed probable. Maybe you have always worked with pretty smart clueful people, but there are quite a few people out there, successful businessmen and developers, who are so clueless that they wouldn't realize how important the GPL is to whatever code they are using. Maybe they heard of Linux being free software that thousands contribute to, but the strange concept that this freely (beer) available software has weird strings attached requiring them to publish their own changes .... well, that is just not a concept that has ever entered their heads. It is in fact so alien to hem that even if they read the GPL, it will not sink in. Their brains are not prepared for such an inside out concept. I have friends who know something of free software but are not developers, and they have trouble understanding this sharing. It is by no means intuitive in today's society full of DRM and lawyers.

GPL enforcement: waiting for the Monsoon

Posted Sep 27, 2007 8:21 UTC (Thu) by hingo (guest, #14792) [Link] (1 responses)

Yup, I have to +1 this. This is quite normal, happens every day and there is nothing to be surprised of.

At the same time, I think going for the lawsuit is the right thing to do, it is the only way to wake up these types. Unfortunately.

+2

Posted Sep 27, 2007 18:48 UTC (Thu) by man_ls (guest, #15091) [Link]

Sure, the previous quote from a MM representative shows the kind of mentality you two are talking about:
Seems to me that some of you have just come out blatantly admitting you are reverse engineering the firmware - or trying to. How should we handle this?
And true also, the lawsuit might be the only way to go. It is something that clueful developers can show their clueless bosses in the future. They might not understand "it is about sharing code", but they will surely understand "we just might get sued if we don't".

GPL enforcement: waiting for the Monsoon

Posted Sep 27, 2007 16:47 UTC (Thu) by amikins (guest, #451) [Link]

I also have to support this sentiment. Most business managerial types in my experience, even in small businesses that might rely more heavily on the input of their tech folks than average, are simply not prepared to comprehend the notion of copyleft. For many, the idea that they're /required/ to release the source code -- still seen as a secret recipe for software -- is baffling. Additionally, some who bother to realize that is a legal requirement would balk at using such software in the first place.

GPL enforcement: waiting for the Monsoon

Posted Sep 26, 2007 18:55 UTC (Wed) by pbardet (guest, #22762) [Link] (6 responses)

"From the outside, this case does not have the look of a deliberate attempt to ignore the GPL. Instead, it looks like a small company which found free software useful in the creation of its product and which put the GPL-compliance part of the job - if it really even understood its obligations in that regard - on the back burner."

It's really nice of you to try to help them in their defence, but if they had the time to write an EULA to prevent people from looking at their code, they should have taken the time to read and understand the license of the product they were using...

GPL enforcement: waiting for the Monsoon

Posted Sep 26, 2007 18:59 UTC (Wed) by corbet (editor, #1) [Link] (5 responses)

I agree they should have been on top of things. If the article appears to say anything else then I have written it poorly and apologize. All I'm trying to say is that it looks like a screwup rather than a deliberate effort to avoid the obligations that come with distributing GPL-licensed code.

GPL enforcement: waiting for the Monsoon

Posted Sep 26, 2007 19:28 UTC (Wed) by pbardet (guest, #22762) [Link] (4 responses)

I think your article is well balanced and explains the situation by taking into account both sides of the story. I was just referring to a smalll part.

But based on how the story is evolving (seems like the SFLC would not drop the case even if Monsoon would become GPL compliant), I'm not sure anymore who's right and who's wrong.

What is sure, is that I never heard about Monsoon before and that after hearing about the story, I checked their web site and their product seems very good. Almost sounds like free advertising to me that the BusyBox team is doing for them.

Let 'em sue

Posted Sep 26, 2007 20:27 UTC (Wed) by ncm (guest, #165) [Link] (3 responses)

If the company is deriving financial benefits by stalling negotiations, that seems like a good enough reason to ask for an injunction.

I also don't agree that it looks like an innocent mistake. It looks more like "let 'em sue". I don't see any of the markers that suggest innocence. The "no-reverse-engineering" EULA, in fact, is hard evidence to the contrary -- especially considering they actually referred to it in e-mail on the subject of compliance.

The Busybox developers should get their injunction, and then as a condition of lifting it extract a percentage of the gross sale price of each box sold, and make sure everybody knows they got it. People need to see teeth in the GPL.

Let 'em sue

Posted Sep 27, 2007 2:30 UTC (Thu) by rickmoen (subscriber, #6943) [Link] (2 responses)

I agree: Let 'em sue, as what I've been known to call "reality therapy". That having been said:

ncm wrote:

The "no-reverse-engineering" EULA, in fact, is hard evidence to the contrary -- especially considering they actually referred to it in e-mail on the subject of compliance.

I can envision that as a spur-of-the-moment attempt to finesse yet another complaint from yet another random Internet poster: The unlucky helldesk worker stuck with looking after the support forum sees someone's implied legal threat about copyright violation, and attempts to one-up it by dreaming up a counter-threat about contract violation. I doubt it's high-level policy; I think it seems more like one tired forum-janitor's off-the-cuff invention.

Probably, they're like most companies in not (institutionally) taking e-mailed or forum-posted legal claims seriously, thinking that anything actually real would come in a demand letter sent certified mail from a law firm. It might be worth noting, for similar cases in the future, that such a letter might be the most pragmatic way to telegraph to the right people that this is a serious matter. (In USA, DMCA takedowns under 17 U.S.C. 512(c)(3) will usually get someone's attention, too. In this case, that would be to Intermedia.net, Inc. of Sunnyvale, CA, whose IP netblock www.monsoonmultimedia.com is in.)

In other respects the "reverse engineering" claim is a red herring: If a company asserts that those exposing its copyright infringements are violating contract, one's correct response is "If so, so what?" That is, if the company seriously alleges intent sue its accusors, and to try to convince a judge that their noticing use of busybox/Linux violates a contract requirement, that'd be interesting (if unlikely), but is completely irrelevant to the copyright violation.

Rick Moen
rick@linuxmafia.com

The SFLC *sent* a registered mail letter, and it was ignored.

Posted Sep 27, 2007 6:31 UTC (Thu) by JesseW (subscriber, #41816) [Link] (1 responses)

Per this comment by Rob Landley, the SFLC did send a letter by registered mail(well, signature required FedEx, technically) telling Monsoon they were violating copyright, and the letter was ignored.

It's hard to engage company principals when the company won't take your calls. (Or your emails. And signs for a fedex containing your complaint and your contact info, but haven't replied at all a week later.

(The comment was originally made on Groklaw, which is down ATM, but happily someone has already copied the comment to LWN, so I linked to that instead.)

The SFLC *sent* a registered mail letter, and it was ignored.

Posted Sep 27, 2007 9:18 UTC (Thu) by rickmoen (subscriber, #6943) [Link]

You know, now that you mention it, I did see Rob's comment to that effect on Groklaw, but had forgotten -- perhaps because it boggles the mind that an allegedly serious company was that oblivious (and I hope they are indeed reading this). I guess they're just insisting on being Darwin's clients, then.

(I know Rob Landley, by the way, and he's an eminently reasonable guy.)

Rick Moen
rick@linuxmafia.com

Wallace vs. FSF Re: GPL enforcement: waiting for the Monsoon

Posted Sep 26, 2007 19:28 UTC (Wed) by atai (subscriber, #10977) [Link]

While it is not a GPL violation case, this seems to be a first US court judgment which clearly gives judicial opinions on the GPL...

http://www.fsf.org/news/wallace-vs-fsf

GPL enforcement: waiting for the Monsoon

Posted Sep 26, 2007 19:41 UTC (Wed) by arjan (subscriber, #36785) [Link] (7 responses)

I assume their correction will put the source of all GPL'd components (and all their derived works and aggregates etc) up, not just busybox.

I also assume they'll fix their EULA, since.. well it sounds like they're putting "additional restrictions" on things :)

GPL enforcement: waiting for the Monsoon

Posted Sep 26, 2007 21:10 UTC (Wed) by nix (subscriber, #2304) [Link] (6 responses)

Why would they need to put up the aggregates? `Mere aggregation... does
not bring the other work under the scope of this License' (not that the
law would let it: aggregation is surely not derivation).

Aggregation

Posted Sep 26, 2007 21:39 UTC (Wed) by ncm (guest, #165) [Link] (5 responses)

"Aggregation" means putting it on a CD. An integrated product is not "mere aggregation".

Aggregation

Posted Sep 26, 2007 23:36 UTC (Wed) by sepreece (guest, #19270) [Link] (1 responses)

Aggregation means the works are not intermingled and simply sharing a distribution medium (which could be a device rather than a disk). They have no obligation to share source that simply makes use of GPLed components or is simply in the same device as the GPLed components, unless it is intimately entangled with the internals of the GPLed components. [Over-simplification - there are lots of specific situations with different implications.]

Aggregation

Posted Sep 27, 2007 11:34 UTC (Thu) by drag (guest, #31333) [Link]

Well in the GPl license is specificly states that aggregations are except.

> These requirements apply to the modified work as a whole. If
> identifiable sections of that work are not derived from the Program,
> and can be reasonably considered independent and separate works in
> themselves, then this License, and its terms, do not apply to those
> sections when you distribute them as separate works. But when you
> distribute the same sections as part of a whole which is a work based
> on the Program, the distribution of the whole must be on the terms of
> this License, whose permissions for other licensees extend to the
> entire whole, and thus to each and every part regardless of who wrote it.

> Thus, it is not the intent of this section to claim rights or contest
> your rights to work written entirely by you; rather, the intent is to
> exercise the right to control the distribution of derivative or
> collective works based on the Program.

> In addition, mere aggregation of another work not based on the Program
> with the Program (or with a work based on the Program) on a volume of
> a storage or distribution medium does not bring the other work under
> the scope of this License.

What this ultimately means is decided by the copyright code of a paticular country.

That is, being a copyright license, the GPL has no effect over anything that is not copyrighted/copyrightable or is not a derived work. I don't think the GPL could have any effect on a aggregated work even if it said it did.

Not-a-Lawyer.

Aggregation

Posted Sep 27, 2007 14:20 UTC (Thu) by cortana (subscriber, #24596) [Link] (2 responses)

I wonder... at what point does aggregation end and creationg of a derivative work begin?

* Including two works on an ISO 9660 filesystem
* Including two works in a tar archive
* Including two works in an ar archive
* Including two works in an ar archive the name of which ends in '.a'
* Including two works in an ELF file

Aggregation

Posted Sep 27, 2007 19:18 UTC (Thu) by ncm (guest, #165) [Link] (1 responses)

It's not so hard, if you move away from the minutiae of file and media formats.

The root question is, must the code you wrote be released under the GPL? The answer is usually simple: does some part of what it does depend on GPL code? I.e., can you run it without also running GPL code, or does some part of it depend on the GPL code to function? If the former, it's just aggregation. If the latter, it's derived.

The Linux kernel is released under a special exception: user-level code that makes system calls is not a derived work, period. The LGPL presents a similar exception: if you release your product in such a way that the user can plug in their own version of the LGPL code, your code isn't a derived work. Linux offers another special exception: a driver that depends only on explicitly exported internal kernel interfaces isn't derived.

Busybox is implementing a standard interface defined by POSIX. A program may depend on Busybox to do its work without becoming a derived work, providing it doesn't depend on non-POSIX features of Busybox.

(Not a lawyer.)

Aggregation

Posted Oct 4, 2007 6:38 UTC (Thu) by kzm (guest, #47358) [Link]

> The root question is, must the code you wrote be released under the GPL?
> The answer is usually simple: does some part of what it does depend on GPL
> code? I.e., can you run it without also running GPL code,

So for a hardware device, you would argue that any device which runs a Linux kernel must be GPL'ed in its entirety? Including all software, firmware, and for that matter, hardware?

> The Linux kernel is released under a special exception: user-level code
> that makes system calls is not a derived work, period.

I always thought of that (and the binary modules issues) as Linus' interpretation (which at least in my jurisdiction carries considerable weight, especially when the licence is given without compensation), rather than a variation of the GPL.

At any rate, I think this interpretation is a good one: standard and available interfaces is what separates different works, messing directly with the implementation is what makes a derived work.

-k

GPL enforcement: waiting for the Monsoon

Posted Sep 26, 2007 19:45 UTC (Wed) by pmilne (guest, #34533) [Link]

The issue is not GPL enforcement but enforcement action when copyright is breached. It is the person making use of GPL'd works who relies on the GPL as a defence to a copyright breach claim. All the accuser needs to do is claim that copyright is breached, and possibly elaborate on this by explaining that the breach complained of does not meet one or more terms of the GPL.

It is then over to the defendant to argue why his or her use falls in terms of the GPL. As Eben Moglen says, it is over to the defendant to wave [around] the GPL to defend a claimed copyright breach. It is rather difficult to try and do this by arguing that the GPL is unlawful, unconstitutional, not tested in court, anti-American, fattening etc.

The GPL is of international applicability - a defendant in any Berne Convention country can wave around the GPL to defend a copyright breach claim. The GPL is not just a USA thing.

This is why a hearing directly aimed at the validity of the GPL will not be coming to a courthouse near you (or anywhere in the world) any time soon.

GPL enforcement: waiting for the Monsoon

Posted Sep 26, 2007 19:49 UTC (Wed) by dwheeler (guest, #1216) [Link] (6 responses)

The reason there are few "potential GPL violators out there with enough confidence to try to challenge the GPL in court" has been clear for years, as Eben Moglen's essay "Enforcing the GPL" has made clear. In particular, "The GPL only obliges you if you distribute software made from GPL'd code, and only needs to be accepted when redistribution occurs. And because no one can ever [legally] redistribute without a license, we can safely presume that anyone redistributing GPL'd software intended to accept the GPL."

GPL enforcement: waiting for the Monsoon

Posted Sep 27, 2007 6:02 UTC (Thu) by oak (guest, #2786) [Link]

Some questions enlightening this to product vendors:

Q: May I copy your product and all of its copyrighted source code freely?

A: NO!

Q: May you copy copyrighted GPL code into your product freely?

A: Er... Yes?

Q: Why?

<metafora representation>a lightbulb</metafora representation>

GPL enforcement: waiting for the Monsoon

Posted Sep 27, 2007 21:54 UTC (Thu) by giraffedata (guest, #1954) [Link] (4 responses)

And because no one can ever [legally] redistribute without a license, we can safely presume that anyone redistributing GPL'd software intended to accept the GPL.

While the logic is sound, I don't think it helps at all to eliminate court challenges. The dispute would be: what is this "GPL" that was accepted? There is plenty of room for dispute over what the conditions of the GPL are. What degree of linking to closed-source software is allowed before the conditions cease to be met?

And then there's the question of whether a copyright license was even required. If a loadable kernel module is a derived work of the Linux kernel, then we can safely presume the distributor intended to accept the GPL. If it isn't, the distributor didn't need any license and accepting GPL is meaningless.

Finally, I'd just like to state here that I hate Moglen's terminology "accept" for the license. It makes it sound like a contract, wherein there must be acceptance or there is no contract. As a license exists whether it is accepted or not, I'm sure what he means is that the distributor intended to rely on the GPL.

GPL enforcement: waiting for the Monsoon

Posted Sep 28, 2007 0:33 UTC (Fri) by rickmoen (subscriber, #6943) [Link] (3 responses)

giraffedata wrote:

There is plenty of room for dispute over what the conditions of the GPL are. What degree of linking to closed-source software is allowed before the conditions cease to be met?

You're advised not to hold your breath waiting for SFLC to change either the USA's or any other country's copyright law to render relevant criteria like "derivative work" and "non-literal copying" intuitively easy for software engineers to understand and apply to their coding regimes. Said concepts (as implemented in USA jurisdictions, at least) are not actually very difficult as legal distinctions go, but it's advisable to read a couple of the leading court decisions, plus remove prevailing nonsense on that subject about "linking" from your mind, if present.

Or, if you'd rather not study copyright court decisions, you can just avoid using substantial numbers of copyright-eligible (expressive, creative) elements of other people's works in yours, and thereby avoid encumbrance by the licensing terms (if any) of those other people's works. (When in doubt, don't.)

While the logic is sound, I don't think it helps at all to eliminate court challenges. The dispute would be: what is this "GPL" that was accepted?

Judges can read. So can you. ;-)

Rick Moen
rick@linuxmafia.com

GPL enforcement: waiting for the Monsoon

Posted Sep 29, 2007 6:38 UTC (Sat) by giraffedata (guest, #1954) [Link] (2 responses)

Those are some valid points about copyright, but I can't see how they have anything to do with the text they quote:

There is plenty of room for dispute over what the conditions of the GPL are. What degree of linking to closed-source software is allowed before the conditions cease to be met?

In particular, there is not a reference to derivative works here.

While the logic is sound, I don't think it helps at all to eliminate court challenges. The dispute would be: what is this "GPL" that was accepted?

Judges can read. So can you. ;-)

And yet, judges host thousands of hours every year of argument over what perfectly legible documents just like this mean, in the context of a specific case and myriad other sources of law. There would have to be something special about GPL to believe that there's nothing disputable about it.

GPL enforcement: waiting for the Monsoon

Posted Sep 29, 2007 9:39 UTC (Sat) by rickmoen (subscriber, #6943) [Link] (1 responses)

giraffedata wrote:

In particular, there is not a reference to derivative works here.

Nonetheless, that is a key legal concept whose boundaries determine precisely whether a GPLed (e.g.) work's copyright encumbrance is even relevant to whether some "degree of linking to closed-source software is allowed before the conditions cease to be met" (your phrase). That is, you asked a question that presumed that a "degree of linking" was a relevant concern. I countered, in part (spelling out my point here, more fully), that your question strongly suggests that you should review foundational concepts of copyright law, which study would reveal to you that you were asking the wrong question in the first place. (A literalist's answer to your question would have been "Mu". I was attempting to be a bit more helpful than that.)

And yet, judges host thousands of hours every year of argument over what perfectly legible documents just like this mean, in the context of a specific case and myriad other sources of law. There would have to be something special about GPL to believe that there's nothing disputable about it.

This would have been a wonderful objection, had I claimed there being "nothing disputable" in any potential future litigation citing the GNU General Public License. What I was saying was that your question of "What is this GPL that was accepted?" is rather silly in context: It is a conditional rights grant (now available in two exciting popular flavours) that, regardless of whether adjudicated under copyright law, contract law, or both, and regardless of applicable jurisdiction, is quite clear in its general outline and effect. Chicken-Little-ism over there being any reasonable prospect for substantive legal questions is a waste of your time and ours: There simply isn't.

Rick Moen
rick@linuxmafia.com

GPL enforcement: waiting for the Monsoon

Posted Sep 29, 2007 22:06 UTC (Sat) by giraffedata (guest, #1954) [Link]

I forgot about the derivative works angle on linking. I was thinking of more basic issue: you combine some closed source and GPL code; is it a "mere aggregation" or a "work based on the work" in GPL terms? There are various ways to combine, some of them typically called linking.

That is an eminantly litigatable question, and one I can definitely see arising, even among expert copyright lawyers.

This would have been a wonderful objection, had I claimed there being "nothing disputable" in any potential future litigation citing the GNU General Public License.

...

Chicken-Little-ism over there being any reasonable prospect for substantive legal questions is a waste of your time and ours: There simply isn't.

"There simply isn't any reasonable prospect for substantive legal questions" sounds identical to "there is nothing disputable" to me, especially in this context (debating whether GPL is likely to end up in court).

Regardless of the wording, I think you're saying you reach that conclusion because the GPL "is quite clear in its general outline and effect." Even if it is, that doesn't stop similarly clear documents from being litigated all the time. The details matter to people. I don't see what about the GPL makes it immune from substantive legal questions.

What should they have done?

Posted Sep 28, 2007 4:50 UTC (Fri) by apollock (guest, #14629) [Link] (5 responses)

I'm curious, in the case of BusyBox, what should Monsoon have done in order to have done the right thing? BusyBox isn't something you link against (at least as far as I understand it) so would they just have to have provided BusyBox source code (+ any modifications they made, I guess)?

But assuming they made no changes to BusyBox at all, would they just have had to provide the BusyBox source code they built from?

What should they have done?

Posted Sep 28, 2007 5:55 UTC (Fri) by sepreece (guest, #19270) [Link]

"But assuming they made no changes to BusyBox at all, would they just have had to provide the BusyBox source code they built from?"

Yes.

I gather they also shipped Linux, so they would also have to provide the source code for that.

What should they have done?

Posted Sep 28, 2007 22:50 UTC (Fri) by landley (guest, #6789) [Link] (3 responses)

When I haven't been forced into court, all I personally care about is
identifying the exact version of each GPL package and either confirming
there were no changes to that base version, or else obtaining said patches
(and preferably the .config file when there is one) under the same license
terms as the rest of the project. I usually just want to reproduce what
people did with the code I wrote. (Unlike RMS, I'm way too lazy to try to
force anybody to mirror something that's already publicly available, at
least not without a darn good reason.)

Claiming busybox users were violating the EULA for investigating this is
not a move designed to make the developers _less_ interested. That move
works explicitly _against_ what I want:

Q: So your device contains vanilla 1.1.1 plus these two patches from the
mailing list, so we already have all this code and can reproduce what
you've done?
A: We're not saying and trying to find out violates the EULA!
Q: OK, lawyers come out now...

If you _really_ want to escalate, you follow that sort of thing up by
ignoring the lawyers who try to contact you outside of court to talk about
it. That's really not a recipe for staying out of court.

And once lawyers enter into it, the letter of the license becomes more
important than just the spirit, and of course there's legal fees to
recover, and it just escalates. (The current settlement is entirely in
the hands of the lawyers.)

But when it's just developers, before the lawyers get involved? Show me
the code. If you're shipping vanilla BusyBox 1.00 with no patches, then
_SAY_ that. Explicitly. Either "It's $VERSION and we did not modify it"
or "It's $VERSION and here's a patch that applies against $VERSION". If
you want to be a legal stickler, give a URL to where we can download that
source from busybox.net, and offer to email a copy of that source as a
file attachment upon request.

Probably what confuses some companies is "it's publicly available version
$X, we got it from $URL, and we did not modify it" seems too obvious to
say, but _we_ don't know whether or not they modified it unless they tell
us. So they never actually explicitly say it, but then when we ask about
it they get confused...

What should they have done?

Posted Sep 29, 2007 9:47 UTC (Sat) by rickmoen (subscriber, #6943) [Link] (2 responses)

Rob --

I'll repeat the advice you received when you recently commented in that identical helpful, explanatory spirit on Groklaw: Follow the IBM nazguls' example in the SCO case, by saying nothing in public for the period of your litigation except as specifically advised by your lead counsel.

Rick Moen
rick@linuxmafia.com

What should they have done?

Posted Sep 30, 2007 8:01 UTC (Sun) by grouch (guest, #27289) [Link]

I'd like to 2nd (or is that now 3rd?) the advisement to say nothing about the case unless your attorney authorizes it. As much as I'd love to read every detail of the exchanges and have a day by day update of the situation, I would hate to see things unravel (as in get side-tracked and delayed) because the BusyBox developers generated some code in public that they are not familiar with. Lawyers use (almost) the same language as the rest of us, except it's code where they work.

See SCO Uses the "Core" Word - Asks for Stay to be Enforced in Arbitration for an example of this. It ain't about a core dump. Such an innocent word, but it is sure to have some lawyers up in arms. Did Rob break any syntax rules or create any infinite loops above? I don't know the code.

Mr. Landley should ignore all of us who are gnawing on every news article about the complaint. There will be theories, speculation and just plain WAG running the spectrum from dead-on to bizarre fantasy. Leave us to suffer in our ignorance. Leave it to your lawyers to display any output from their coding.

What should they have done?

Posted Sep 30, 2007 20:35 UTC (Sun) by landley (guest, #6789) [Link]

I'm aware of this, and have been taking it into consideration. The
biggest line I've been drawing is "I won't talk about anything that's
happened since the suit was filed", and I do stop and think when talking
about stuff from before the filing. I've _mostly_ been quiet on the
subject.

That said, the question asked wasn't really specific to this lawsuit.
It's "what do I actually need to do to comply with the spirit of the
GPL", and that's an important question. Staying silent on how other
companies can _avoid_ such suits in future strikes me as both
disingenuous and counterproductive. I'm not trying to lure anybody else
into getting sued; quite the opposite. I'd rather _not_ have to be
involved in future lawsuits if there's an easy way to avoid it.

Yes, I pondered staying silent about this topic to make the lawyers
comfortable, but if I would have said exactly this if I wasn't a party to
the suit (and in fact I might have already and it could already be dug
out of the busybox mailing list archives by the opposing side), why _not_
say it now? The point of the suit isn't to change the way _I_ work. Nor
is it to make GPL compliance harder in the cases where it's easy _not_ to
get sued when you take the right steps before lawyers get involved.

I'm also not the only party to the suit, so saying what would have
satisfied me once upon a time when thresholds were lower doesn't
guarantee it would have satisifed Erik, and or that it would be
sufficient now lawyers are deployed. (I thought I made that clear.)

I should probably just write a brief "complying with GPLv2" HOWTO and
post it somewhere. Most of the tricksy edge cases only kick in when
you're trying to weasel out of it, not when you just want to discharge
your obligations and are new enough at it you may not be entirely certain
what they actually are...

GPL enforcement: waiting for the Monsoon

Posted Oct 4, 2007 12:07 UTC (Thu) by keestux (guest, #48036) [Link]

This subject interests me a lot. A few years ago I bought a harddisk recorder from KiSS (now owned by Linksys), a DP-558. It's a device that uses uClinux, and busybox (amongst other software). As soon as I had this device I started to look at the firmware. At the time KiSS published a GPL.zip, but after brief examination I knew that the latest firmware could not have been built with that GPL.zip. Then I started writing emails to KiSS, which were never answered in a satisfactory manner. Even after Linksys bought them the situation has not improved. In fact it got worse. The KiSS download URL disappeared and Linksys published an older GPL.zip than what KiSS had. I wrote them about this, but they never acted nor answered.

What I learned from this is that a company, such as KiSS, can easily get away with being unfriendly to GPL (to put it mildly). They simply act as dumb as possible, and preferably do not answer emails about it. Sometimes they publish a new GPL.zip, but mostly that is way too late, or incomplete. And to pretend everything is alright with them, they fill their website with GPL friendly notes, as if what they publish is sufficient.

For a software engineer, like myself, that is not enough. But hey, I'm not a copyright holder of uClinux nor busybox, what can I do? I just tried, in a friendly manner, to ask for up-to-date GPL source code. But they never answered to my request. So, speaking from experience I'd say that yes, some companies will only begin to understand by the time they get sued. And by that time it comes in handy that they acted dumb, so they can pretend they never knew.


Copyright © 2007, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds