Bugzilla

Assignee

Comment 1

•

17 years ago

mkaply: Ben is concerned about the choice-of-law provisions; if there's ever litigation involving the code, he doesn't want to be dragged over to the US.

At the moment, the US choice of law is removed and replaced with German law. However, he would be willing to "remove the replacement" - i.e. to make the license of these files a strict subset of the MPL terms. That is, the MPL but without clause 14 (choice of law).

His point is that this could be no worse than the code having a license, such as the BSD licence (used for lots of code in our codebase) which doesn't specify choice-of-law either.

Would that be an acceptable solution?

Gerv

Comment 2

•

17 years ago

Concretely, I propose:

 * The "License" shall be the Mozilla Public License Version 1.1, except
 * Sections 6.2 and 11, but with the addition of the below defined Section 14.
 * You may obtain a copy of the Mozilla Public License Version 1.1 at
 * <http://www.mozilla.org/MPL/>. The contents of this file are subject to the
 * License; you may not use this file except in compliance with the License.
 * 
 * Section 14: MISCELLANEOUS.
 * This License represents the complete agreement concerning subject matter
 * hereof. If any provision of this License is held to be unenforceable, such
 * provision shall be reformed only to the extent necessary to make it
 * enforceable.
 * 
 * Once Covered Code has been published under a particular version of the
 * License, You may always continue to use it under the terms of that version.
 * (End of Section 14)

I.e. the "provision of law" and "update of licenses" clauses are removed without replacement. The license will not say anything about it, falling back to standard law. It is the same as BSD in these questions. So, no new concern for lawyers, it adheres to the Mozilla policy of "any license which is MPL or a direct subset of it".

Reporter

Comment 3

•

17 years ago

What is the difference between this file and other files you were the initial developer of like everything in extensions/sroaming?

Why are these files singled out for license change?

Are you worried there will be litigation over these files?

Comment 4

•

17 years ago

mkaply, there are a number of reasons, but essentially I want to ensure Mozilla is used in the original Open-Source idea/spirit. A single core file is sufficient as angle. For other contributions, I was either not Initial Contributor, I did not care (in case of sroaming) or there were other reasons. In any case, I already discussed the reasoning with Gerv.

Benjamin Smedberg

Comment 5

•

17 years ago

Making up your own license is a blatant violation of the CVS contributor agreement and a betrayal of our community. Unless BenB is willing to license his code under the standard tri-license I propose his CVS access should be revoked and we should remove or replace this code immediately.

Comment 6

•

17 years ago

huch? Slow. This personal attack is not warranted at all.

A) This code and license is there since 1999.
B) I did not check it in myself (I had no CVS account back then), but a former Netscape employee. It was reviewed.
C) Furthermore, mozilla.org is and was aware of it since a long time.
D) There is a bigger number of licenses already in the tree, as you probably know, see <about:credits>.
D) I claim the license is in compliance with the Mozilla policy of "MPL or a subset of it".

The change proposed in comment 2 definitely complies, it is specifically designed to be a subset of MPL.

Mitchell Baker

Comment 7

•

17 years ago

Well, if someone checked in this in 1999 it was a mistake then and it is a mistake now.    

I share bsmedberg's sense of shock.  Changles to the MPL cannot be made by any one of us, whatever the assertions about the affects of that change.  And in fact, neither change is as simple as it seems.

The choice of law provision affects compatibility in ways that are only now starting to be figured out -- FSF has done some work here, Creative 
Commons has done some work, OSI has been trying to look at this,  and coincidnetly I started talking to the CC folks about what they have learned a few weeks back.  The update of license change sets out how future versions of licenses are handled; this leads to complex compatibility issues as licenses are updated.  

This issue is more properly addressed in the governance newsgroup.  Here I will simply assert that it is UNACCEPTABLE for anyone to change the MPL and check code in under a different version of the MPL. 

What we do about this code isn't quite clear to me.  The update issue is the big one.  In the abstract I would like to get rid of this code altogether, but we live in a practical world.

It would help to know a couple of developers who are associated with the usefulness of this code.  BenB I'm assuming is one.

Comment 8

•

17 years ago

Mitchell, I have talked about this with Gerv and Frank Hecker, both during the relicensing and now triggered by mkaply a few weeks ago.

I have always said that I want to resolve this in a friendly way. I have specific concerns, and I would like to have them addressed, but I'm willing to give in and forget about my rights and change to standard MPL, if that's the only option.

Re "unacceptable": As pointed out, there are a number of licenses which are a subset of MPL in the tree already, and this is merely yet another.

Comment 9

•

17 years ago

My specific rationale and concerns are:
Update of license: It means that somebody else can just change the license under my feet, without me having any way to veto or object, although I'm the author. I don't think that's right. FWIW, I have consented (among all others) to the only change that ever happened, namely the GPL tri-licenses. Would Mozilla Foundation have chosen to just change the license, it would have saved Gerv a *lot* of work, but none of the contributors would have had a way to even have their voice heard.

Choice of law and jurisdiction: It basically means that the license is unenforceable for me in practice. US lawyers are extremely expensive ($500/h upwards), while German lawyer fees are regulated by law. US law is unpredictable due to 'case law". German and French law typically favors the small man. Finally, there's the massive geographic problem. Me choosing US law means that when I have a problem with a French company, I have to sue them in the US, which is completely insane from my perspective.

Vanilla BSD does not suit me, because the MPL gives special protections in many things like source publishing and credits that the BSD license does not give me. It may seem to be of theoretical nature, but many companies are outright ignorant, lazy or selfish when it comes to open-source and only adhere to basic principles of ethics when threatened with a lawsuit or the possibility of it. I have never sued anybody, but I have - in my role as Mozilla contractor and contributor - tried to convince many companies in adhering to the MPL, including source code publishing and credits.

I would like to know why the current license and esp. the compromise proposal in comment 2 are not acceptable. They adhere to the general principle of "subset of MPL". And they are nothing new in the codebase - the lack of choice of law and any possible interactions already exist due to the BSD code in there.

Reporter

Comment 10

•

17 years ago

I'm unclear how removing a section and adding a section can be called a "subset of MPL."

Comment 11

•

17 years ago

> I'm unclear how removing a section and adding a section can be
> called a "subset of MPL."

Because it's simply the MPL with 2 sentences less. The "added" paragraph parrots the removed paragraphs, minus the 2 sentences.

Comment 12

•

17 years ago

Correction: 6 sentences, but same thing.

Reporter

Comment 13

•

17 years ago

Sorry to harp on this, but where is this "subset of MPL" principal coming from?

If I take a license and remove a section, technically that is a subset. That doesn't make it a legal modification of the license.

Assignee

Comment 14

•

17 years ago

mkaply: I'm not sure what you mean by "a legal modification of the license". If I say "My code is under the Sun CDDL except for section 4.1", I don't need Sun's permission to do that. Similarly, as far as I can see, it's not _illegal_ per se for Ben to licence his code as he did. It may be something we don't like, and want to take action about, but it's not illegal.

The "subset of MPL" principle is Ben's summary of my explanation to him of something Mitchell told me once. (It therefore may not represent Mitchell's full view, which is something I've pointed out to Ben.) The principle is basically that we want to be able to say to people wanting to use Mozilla code "OK with the MPL? Then go right ahead" - i.e. everything in core Firefox or Thunderbird is under the MPL or some licence with a subset of its requirements.

Since we tri-licensed, that principle has been extended so that the sentence remains true if you replace "MPL" with "GPL" or "LGPL" - i.e. any licence we accept has to be a subset of the requirements of all three. The BSD-variant licences meet this requirement, as does the LGPL/MPL licence of Cairo (because LGPL can convert to GPL).

A licence which is the tri-license but with the MPL replaced with Ben's subset of the MPL could be said to meet this test. It depends on how you view the effect of the removal of the choice of venue clause. That's not to say that this is the only test we would apply to see if a licence was acceptable, of course.

Gerv

Assignee

Comment 15

•

17 years ago

Ben:(In reply to comment #9)
> Update of license: It means that somebody else can just change the license
> under my feet, without me having any way to veto or object, although I'm the
> author. 

This is not technically true - they can add additional possible sets of licence terms, but they can't stop the code being under the MPL 1.1. So the license terms don't "change", the options just increase. Your code can't be taken proprietary (any more than the MPL already allows).

That point aside, you are basically right. But I would note that this power over your code is a power the FSF has (due to its stewardship of the GPL and LGPL) and, recently, has chosen to exercise - your mozI?TXTToHTMLConv.* code can now be used under the GPLv3. It's also a power that the MoFo has over all of your other code submissions apart from this one. This was part of the conditions you agreed to when making all those other submissions - the MPL has the "or later" language in the licence, and the GPL and LGPL have it in the boilerplate we use.

> I don't think that's right. FWIW, I have consented (among all others)
> to the only change that ever happened, namely the GPL tri-licenses. Would
> Mozilla Foundation have chosen to just change the license, it would have saved
> Gerv a *lot* of work, but none of the contributors would have had a way to 
> even have their voice heard.

Indeed not. It's a process we never want to have to go through again (and I can't see any reason we ever would). But there's a difference between that situation and any MPL/GPL/LGPL version upgrades. People agree to licence version upgrades when they contribute; they had not agreed to the MPL to tri-license change, and so they had to be asked.

> Choice of law and jurisdiction: It basically means that the license is
> unenforceable for me in practice. 

I bow to the greater expertise of others, and I can't find a reference to something I think Simon Phipps once said on the subject, but it would be good to get confirmation that this clause actually has the effect you think it would.

Gerv

Reporter

Comment 16

•

17 years ago

(In reply to comment #14)
> mkaply: I'm not sure what you mean by "a legal modification of the license". If
> I say "My code is under the Sun CDDL except for section 4.1", I don't need
> Sun's permission to do that. Similarly, as far as I can see, it's not _illegal_
> per se for Ben to licence his code as he did. It may be something we don't
> like, and want to take action about, but it's not illegal.

Sorry, bad choice of words on my part. Let's say "proper modification of the license"

As far as your example, I can certainly say my code is under a license except for a section, but in the Sun scenario, I doubt Sun would take that code back. So what does it benefit me?

The mistake that was made here was the Netscape developer that allowed the code in originally.

The CVS Contributor agreement says "Code to be contributed to Mozilla.org or posted to the Mozilla.org CVS will be governed by the NPL or the MPL or another license acceptable to Mozilla.org."

This code is not governed by the MPL. It is governed by a modified MPL, and I have seen no documentation from mozilla.org saying this modification is acceptable.

Assignee

Comment 17

•

17 years ago

(In reply to comment #16)
> The mistake that was made here was the Netscape developer that allowed the 
> code in originally.

Indeed.

> The CVS Contributor agreement says "Code to be contributed to Mozilla.org or
> posted to the Mozilla.org CVS will be governed by the NPL or the MPL or 
> another license acceptable to Mozilla.org."

Right. And, assuming the Netscape developer ever signed one of those (back in 1999, I suspect we were a bit slack about that for Netscape people), then he broke it. But that's water under the bridge. Ben has since signed one, and as far as I am aware has kept to it to the letter. The agreement is not retrospective, AFAIK.

> This code is not governed by the MPL. It is governed by a modified MPL, and I
> have seen no documentation from mozilla.org saying this modification is
> acceptable.

Indeed; there is no such documentation. One possible resolution of this discussion (and the one Ben is requesting) is that we accept his modifications. Of course, there are several other possible resolutions.

Gerv

Mitchell Baker

Comment 18

•

17 years ago

There are a set of issues here.

One is the content of the MPL
Two is the changing of anything in the MPL and still calling it the MPL
Three is the policy for accepting code into our tree
Four is what we do about this particular code in the tree
Five is how we handle people who want to check code into our tree that is not governed by the MPL or another approved license
Six is what we mean by "another approved license"
Seven is whether what happened in 1999 should affect Ben's status now.

First, Ben thank you for your statements in Comment 8; they are very helpful.

Many of the topics above are best addressed in the governance newsgroup or (better yet) an updated license FAQ. I'll say something about them here though since they all come up above.

1. Content of the MPL is as it is written. The issues that Ben raises are not new, are not unknown and were chosen intentionally, and have been the topic of a bunch of discussion in licensing forums (not just the MPL, but these clauses in general).

2. The MPL allows people to make derivitive works of it BUT requires that the result be clearly named something different than the MPL. Deleting clauses requires changing the name so that it is immediately clear that this new set of lciensing terms is NOT the MPL. A subset of terms is not the MPL and -- as we see here -- can be confusingly similar at first glance. So the identification of these terms as the MPL is not permitted. This has also been the topic of a lot of discusison in licensing circles.

I don't plan to talk about the substance of the terms at issue here. As noted above these were conscious decisions, they are on the list to think about for a revision and a bunch of people have talked about them, both with me and among themselves. Ben if I can find any of the discussions in short form I'll send them to you. Many of them can be found in the OSI archives, but that is a giant amount of stuff to wade through; even the individual threads can be massive. If there's no good summary to point to then the newsgroup is probably the place.

Items 3 and 6 above -- these are much as Gerv described them. For example, we've included BSD code because if one does what the MPL requires, one has met the obligations of the other license. Whereever the term "subset" may have been used it was meant (at least by me, if I ever used the term) to convey this.

Item 5 above -- I thought we had this written out pretty clearly, but maybe that's not the case. If not, it's something that needs to get this done. I'm thinking it would help if I could spend some time on license issues in general, I'll look into whether I can do this.

Item 7 above -- I do think BenB or anyone else is entitled to this view going forward, but can't (a) use "Mozilla" or "MPL" to describe a different set of licensing terms; or (b) check code governed by a different set into the tree.

Item 4 above. I would hate to have to start rewriting code we've been relying on for this long. but the difference in terms is concerning.

mitchell

Comment 19

•

17 years ago

> we've included BSD code because if one does what the MPL requires,
> one has met the obligations of the other license.

The same is true for my license, both the current one, and even more so the one proposed in comment 2. That's why I still don't understand the problem with it.

I gather from your comment, however, that you would strongly prefer not to have this license in the tree.

I hereby grant the permission to change the files to standard MPL 1.1.
/netwerk/streamconv/converters/mozTXTToHTMLConv.h
/netwerk/streamconv/converters/mozTXTToHTMLConv.cpp
/netwerk/streamconv/public/mozITXTToHTMLConv.idl

Any new versions of the license shall not change change the spirit of the license. What happens in the unlikely event that I feel the need to sue anybody over infrigement, remains to be seen, maybe Mozilla Foundation/Corporation could help with reasonable lawyer costs.

Assignee

Comment 20

•

17 years ago

Ben: thank you very much for granting this permission. I am going to change the licence on the three files you name to straight MPL 1.1/GPL 2.0/LGPL 2.1 boilerplate, as given at http://www.mozilla.org/MPL/ .

I can't imagine a set of circumstances where you would need to sue over this code and yet the Mozilla Foundation would not be very interested in the situation too (as our copyrights would almost certainly have been violated as well). That's not a promise of help, just an observation.

Gerv

Assignee

Updated

•

17 years ago

Assignee: hecker → gerv

Component: Licensing → Networking

Product: mozilla.org → Core

Summary: Bad modifications to MPL in moz*TXTToHTMLConv files → Relicence moz*TXTToHTMLConv files

Version: other → Trunk

Assignee

Comment 21

•

17 years ago

Attached patch Patch v.1 — Details — Splinter Review

Here is a patch for the trunk. Requesting 1.9 approval, as the Tinderbox status requires.

This is a comment-only patch to relicense three files.

Gerv

Attachment #289917 - Flags: approval1.9?

Assignee

Comment 22

•

17 years ago

Comment on attachment 289917 [details] [diff] [review]
Patch v.1

Same patch applies perfectly to 1.8 branch; requesting approval for 1.8.1.11. This change has been requested by a Mozilla downstream distributor who uses the branch (IBM).

Gerv

Attachment #289917 - Flags: approval1.8.1.11?

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Updated

•

17 years ago

Attachment #289917 - Attachment description: Patch v.1 (for trunk) → Patch v.1

Updated

•

17 years ago

QA Contact: gerv → networking

Mike Beltzner [:beltzner, not reading bugmail]

Comment 23

•

17 years ago

Comment on attachment 289917 [details] [diff] [review]
Patch v.1

a=beltzner for drivers

Attachment #289917 - Flags: approval1.9? → approval1.9+

Daniel Veditz [:dveditz]

Comment 24

•

17 years ago

I'm a little late to the party having just found this from Gerv's status blog post, but it's worth noting that in 1999 the license was ultimately controlled by AOL and this worried a lot of contributors at the time who were not 100% sure AOL would honor the spirit of what Netscape had started.

I would hope Mozilla's track record since, and especially its transformation into an independent charitable organization, allays those initial fears.

Samuel Sidler (old account; do not CC)

Assignee

Comment 25

•

17 years ago

Checked in on trunk; leaving bug open for branch approvals.

Checking in netwerk/streamconv/converters/mozTXTToHTMLConv.h;
/cvsroot/mozilla/netwerk/streamconv/converters/mozTXTToHTMLConv.h,v  <--  mozTXTToHTMLConv.h
new revision: 1.21; previous revision: 1.20
done
Checking in netwerk/streamconv/converters/mozTXTToHTMLConv.cpp;
/cvsroot/mozilla/netwerk/streamconv/converters/mozTXTToHTMLConv.cpp,v  <--  mozTXTToHTMLConv.cpp
new revision: 1.86; previous revision: 1.85
done
Checking in netwerk/streamconv/public/mozITXTToHTMLConv.idl;
/cvsroot/mozilla/netwerk/streamconv/public/mozITXTToHTMLConv.idl,v  <--  mozITXTToHTMLConv.idl
new revision: 1.9; previous revision: 1.8
done

Gerv

Daniel Veditz [:dveditz]

Comment 26

•

17 years ago

fixed on trunk

Status: NEW → RESOLVED

Closed: 17 years ago

Resolution: --- → FIXED

Comment 27

•

17 years ago

Comment on attachment 289917 [details] [diff] [review]
Patch v.1

Approved for 1.8.1.12; a=ss for release-drivers. Please land as soon as possible.

Attachment #289917 - Flags: approval1.8.1.12? → approval1.8.1.12+