decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

To read comments to this article, go here
The Latest on the Firefox EULA Matter - Update: Progress!
Wednesday, September 17 2008 @ 07:48 AM EDT

Mitchell Baker has posted on her blog a notice that Mozilla will let us know today what solution they've come up with for the Firefox EULA dispute:
Firefox without EULAs — Update

We’re still working on this. There’s been a bunch of helpful feedback. We appreciate this. We think we’ve integrated the feedback into something that’s a good solution; different from out last version in both its essence and its presentation and content.

We’ve come to understand that anything EULA-like is disturbing, even if the content is FLOSS based. So we’re eliminating that. We still feel that something about the web services integrated into the browser is needed; these services can be turned off and not interrupt the flow of using the browser. We also want to tell people about the FLOSS license — as a notice, not as as EULA or use restriction. Again, this won’t block the flow or provide the unwelcoming feeling that one comment to my previous post described so eloquently.

We expect to have the materials that show this plan posted tomorrow morning.

So that sounds promising. I don't think the EULA content was FLOSS based, actually, and I'll show you why I don't think so. I hope it will be a positive contribution to the general discussion.

It isn't just that the community isn't accustomed to EULAs. And it isn't just that Linux has no use restrictions, in that the GPL doesn't restrict use, only distribution. The Open Source Initiative's definition of "Open Source" includes this clause, explained in the annotated version:

7. Distribution of License

The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

Rationale: This clause is intended to forbid closing up software by indirect means such as requiring a non-disclosure agreement.

Now, originally, the Mozilla EULA for Firefox did require clicking "I agree" or you couldn't use the software:

A source code version of certain Firefox Browser functionality that you may use, modify and distribute is available to you free-of-charge from under the Mozilla Public License and other open source software licenses.

The accompanying executable code version of Mozilla Firefox and related documentation (the "Product") is made available to you under the terms of this Mozilla Firefox End-User Software License Agreement (the "Agreement"). By clicking the "Accept" button, or by installing or using the Mozilla Firefox Browser, you are consenting to be bound by the Agreement. If you do not agree to the terms and conditions of this Agreement, do not click the "Accept" button, and do not install or use any part of the Mozilla Firefox Browser.

Is that a conflict? Ask your lawyer. But it is the right question. It's bad enough to be unable to call your product free software; if you can't even call it open source, then exactly what is it? It's a fair question.

And I do think it's fair to ask Mozilla and Canonical: what were you thinking? How did this get this far, this wrong? Is there maybe a need to dig a bit deeper into community values and norms? Why, I wonder, didn't anyone think to ask the Software Freedom Law Center for an opinion on how to protect Mozilla's legal interests in a way that would not violate community values? That's what it's there for, after all, to prevent community members from making legal mistakes. I think this dustup could easily have been avoided, and yes, I think it would have been better if it had been. There is an entity in place. It simply makes sense to use the resources that we have available as a community.

When earlier there was a draft of the new Firefox "EULA for Linux", there was this mea culpa:

We’ve been working for a while to fix some objections to both the presentation of a EULA and the content of the EULA in certain Linux distributions. The issue came to light because of a change in settings in the 3.0 builds, that turned on the EULA display at installation, similar to the Windows environment. This caused two big problems. One, it put a EULA in front of a set of end-users who are not accustomed to seeing such agreements. Second, the license grant itself was inconsistent with the values of many of the users in the Linux communities and our own. They viewed the EULA as improperly imposing restrictions on the use of Firefox. Red Hat and Fedora were staunch advocates for making a change, and helped us understand the problem and potential fixes.

Upon review, they were right.

So much for all those who thought it was a few extreme zealots making a big fuss over nothing. It was not nothing. They were right. And now Mozilla has acknowledged it, to their credit.

You know why Red Hat and Fedora always seem to be the ones taking the lead legally and getting things right? I think it's because they distribute under the GPL, and once you understand that license, it frames your expectations. There are no use restrictions on GPL code. There can't be. It's what makes it shine. The Mozilla Public License is not the GPL, and it is a license that makes it easier to get things wrong, as happened here, in part because of that attitudinal difference. Now, you can use it if you like it, but it's good to at least understand it precisely and clearly. Here's a problem, as I see it, with the Mozilla Public License:

You may distribute the Executable version of Covered Code or ownership rights under a license of Your choice, which may contain terms different from this License, provided that You are in compliance with the terms of this License and that the license for the Executable version does not attempt to limit or alter the recipient's rights in the Source Code version from the rights set forth in this License. If You distribute the Executable version under a different license You must make it absolutely clear that any terms which differ from this License are offered by You alone, not by the Initial Developer or any Contributor. You hereby agree to indemnify the Initial Developer and every Contributor for any liability incurred by the Initial Developer or such Contributor as a result of any such terms You offer.

In other words, anyone can take MPL code and release it under another license. The GPL, in contrast, requires that GPL code stay that way forever. It's a huge difference. Now, maybe you like the MPL precisely because it doesn't include that requirement, so to you it's a feature, not a bug. Some vendors likely would pick the MPL over the GPL, all things being equal, particularly if they are used to proprietary software.

But what about programmers? What I've learned from this event for FLOSS programmers to consider is that your code is not protected in a triple-licensed project like Firefox beyond whatever is the least protective license of the three. Here's Mozilla's license policy page, and here's the part about the triple license:

Acceptable Licenses

1. The following license (the "Mozilla tri-license") is acceptable in all circumstances except for those covered by point 4, below:

  • MPL/GPL/LGPL triple license, allowing use of the file under the terms of any one of:
    • The Mozilla Public License, version 1.1 or later (MPL)
    • The GNU General Public License, version 2 or later (GPL)
    • The GNU Lesser General Public License, version 2.1 or later (LGPL)
For new source files please use the boilerplate license notice appropriate for the type of file you are creating. Please don't copy boilerplate from existing files.

2. The following license is acceptable for trivial pieces of Support Code, such as testcases:

  • Creative Commons Public Domain Dedication, using the following boilerplate:
    Any copyright is dedicated to the Public Domain.
3. The following licenses are acceptable only for Support Code in directories whose files are already under the license in question, as outlined later in this policy:
  • The Mozilla Public License, version 1.1 or later (MPL) alone
  • The Netscape Public License, version 1.1 or later (NPL) alone
  • MPL/GPL dual license, allowing use of the file under the terms of either of:
    • The Mozilla Public License, version 1.1 or later (MPL)
    • The GNU General Public License, version 2 or later (GPL)
4. For Third Party Code, you should use the license pertaining to that code when modifying it or adding new files to it, and the tri-license when adding Mozilla-specific files such as build system files. See below for a list of directories this applies to.

5. All Product Code must be under either the tri-license or, for Third Party Product Code, a license compatible with all three sets of terms in the tri-license. The purpose of this rule is to make sure that users of our code can take and use the same code under any one of the three licenses; no group is disadvantaged.

6. If importing new Third Party Code, always inform They can then check whether the license is compatible - even simple-looking licenses can have twists in them - and make sure we are meeting the requirements.

I guess I never really thought deeply about the MPL before in the way this incident forced me to, and before I read paragraph 5 as meaning that no one could take the code and release it under a license that would conflict with the GPL. Of course it doesn't mean that. I should have known it doesn't, because the MPL itself gives you the option to not even use the MPL. So the wiggle room is built in from the starting gate. Paragraph 5, as I understand it now, is just saying that while you must contribute under the triple license, anyone can choose whatever license they want to use from the three for a distribution, and Mozilla chooses the MPL. So don't imagine that the GPL being one of the three fully protects your code in your contributions to Firefox the way the GPL normally would if Firefox were licensed under the GPL the way Linux is. It does protect your ability to take the code, minus the trademark, and do whatever you wish to do with it as per the GPL license requirements, and that's not nothing, as we saw in this incident, but it's not the same. You probably already knew this, but I hadn't thought it through before.

It's one thing for a proprietary company to restrict its own code. That bothers me not at all, since I can just avoid it if I wish to. But if you work and contribute labor or code free of charge to a project and then the code or the project forks away from the very values that motivated you to volunteer in the first place, and they can, why would you continue to support that project? And if the protections you feel are important are not found in the license, where will they be found? Some things are just obvious. If ever there was an incident that illustrates that just being able to see the source code is not enough or all there is to FOSS, this one was it.

I trust both Mozilla and Canonical now see that there is no way to pressure the FOSS community. They don't have to care about that, but it's simply true that there is no 'have to' with FOSS. The majority of the comments I saw on Launchpad were saying that folks were ready to drop both Firefox and Ubuntu in a heartbeat, if necessary. Me too, actually. Mozilla and Canonical can, of course, decide to drop the community. I am very glad, though, that it looks like there will be a happy ending, as we all want Firefox and Ubuntu to be successful. But not if they violate everything the community cares about. I may be more polite than some few comments were about it, because I believe in being polite and respectful -- and by the way I certainly also saw some very rude comments attacking those who cared about this issue -- but I am very glad the community made it clear that they feel that freedom and community values matter. Because they do. And the simple truth is that no one will represent the community's interests fully but the community itself.

Update: Progress! Not the final yet, but soooo much better. Take a look here. One relevant bit:

We’ve received a lot of feedback on the licensing proposal. The commentary overwhelmingly indicated the proposed approach wasn’t good enough (that would be an understatement). We looked at it again, incorporated suggestions from the community at large and from some of the Linux distributors. The new design addresses both presentation and content. We’re still tweaking the language a bit and working on the implementation, but directionally this is where we’re going.

Presentation: There’s no click-through, or license splashed in the users face on start-up (or at any point thereafter). We’ll either include some text on the first-run page or in an info box that links to a static page in the browser that contains a notice about your rights. We’re still working through which implementation works best - so this isn’t final. ...

Content: There is no EULA. There are no caps except where grammatically required. There is a notice page that points to the MPL, provides summary information on the rights that come with it, includes a statement about trademarks, and a statement about optional web services (like safe-browsing) that are not covered under the MPL. The notice includes a link to the terms related to the services.

  View Printable Version

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )