MPL Alpha 1 Draft Released
Luis Villa
please follow up to that list, not governance@ or legal@. Apologies for
not sending it here promptly; in the future I will announce Alphas/Betas
to governance@ and legal@, but if you want all the intermediate
discussion as well, please subscribe to governance-mpl-update@.]
Hello, all-
Last week the Mozilla community had quite a few releases, and the MPL
team, not wanting to be left out, is excited to announce the first Alpha
draft of the next version of the Mozilla Public License.
The text is available here:
http://mpl.mozilla.org/wp-content/uploads/2010/07/MPL-2-alpha-one.pdf
and an annotated version, including commentary and links to previous
discussions of most of the included changes, is available here:
[An easier link for all the Alpha information is
http://mpl.mozilla.org/participate/alpha ]
We should stress that, like most Mozilla alphas, while this draft
includes a substantial number of changes, it is not feature complete- we
continue to consider significant revisions to some areas of the text. It
is also not something that should be used to release software under-
please wait until the final release for that! Finally, no decisions in
this draft are 'final'- we remain open to persuasion on both small
issues (formatting, specific word choice) and large issues (policy
choices that may be reflected in these changes.)
As usual, we welcome general questions and feedback through the
governance-mpl-update, and specific comments through mpl.co-ment.com.
Past iterations with this group have proved useful, and some suggestions
that came in through comment are reflected in the text.
We would like to ask that this community, and other users of the MPL,
carefully inspect the sections that have changed- while we've been
careful in making changes, and generally believe the changes make the
license easier to understand, we want to ensure that there are no
unintended side-effects, so the more eyeballs (particularly fresh ones)
on the license the better.
Thanks- look forward to discussing the new text with you-
Luis, on behalf of the rest of the MPL team
--
Luis Villa, Mozilla Legal
work email:lvi...@mozilla.com (preferred)
work phone: 650-903-0800 x327
personal:http://tieguy.org/about/
Nelson Bolyard
And make no mistake, it's a rewrite.
Now, looking down the road, I expect that, just as in the past when
Mozilla switched from the dual license to the tri-license, there will
be a whole lotta letters and/or emails sent out asking past contributors
to agree to relicense past contributions under the new license.
What's the plan for when past contributors of substantial portions
do not agree, either because they have some specific objection
or simply because they no longer exist (e.g. corporations, or
deceased persons) or (in at least one case) are corporations that
have been acquired since they made their past contributions, and
their new owners are not open source friendly (to say the least)?
Then what?
Rip out the old software and look for a replacement? (Good luck!)
Asa Dotzler
My understanding is that Mozilla "the project" does not require a
re-licensing like it did for the tri-licensing effort. If the MPL is
updated, then the Mozilla project will have to decide, like any other
project using the MPL, whether or not to update to the latest version.
Doing so won't require that every copyright holder assent like it did
when adopting the additional license a few years ago. This is not a
re-licensing like it was for the LGPL and GPL additions.
- A
Robert Kaiser
> So, Mozilla lawyers have rewritten the MPL, forming an alpha of MPL 2.
> And make no mistake, it's a rewrite.
It's not just Mozilla lawyers sitting in some backyard dark room, it's
all happening and being discussed in the public, see
mozilla.governance.mpl-update and https://mpl.co-ment.com/
> Now, looking down the road, I expect that, just as in the past when
> Mozilla switched from the dual license to the tri-license, there will
> be a whole lotta letters and/or emails sent out asking past contributors
> to agree to relicense past contributions under the new license.
As far as I know, the MPL v1.1 contains an "or later" rule that allows
any code licensed under it to be reused under any newer version of the
MPL, so no permission letters are needed for that.
IANAL, though, you better read up in the mpl-update group and ask the
actual lawyers dealing with this.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
Luis Villa
> Nelson Bolyard schrieb:
>> So, Mozilla lawyers have rewritten the MPL, forming an alpha of MPL 2.
>> And make no mistake, it's a rewrite.
'revision', 'update', etc., but I'll stress again that it is primarily a
revision and fine-tuning rather than a substantial policy change, at
least so far.
> It's not just Mozilla lawyers sitting in some backyard dark room, it's
> all happening and being discussed in the public, see
> mozilla.governance.mpl-update and https://mpl.co-ment.com/
>> Now, looking down the road, I expect that, just as in the past when
>> Mozilla switched from the dual license to the tri-license, there will
>> be a whole lotta letters and/or emails sent out asking past contributors
>> to agree to relicense past contributions under the new license.
>
> As far as I know, the MPL v1.1 contains an "or later" rule that allows
> any code licensed under it to be reused under any newer version of the
> MPL, so no permission letters are needed for that.
Luis
Ben Bucksch
origin (copyright) of the MPL code is described in executable versions
and documentation. I do think it's a moral obligation to give credit to
the Mozilla authors, and MPL 1.1 made it explicit, and I want this
requirement to stay.
I think the least we can expect for our work on Mozilla is to be
credited and thanked for it.
Ben Bucksch
the same medium (DVD, USB stick) as the Executable, or downloadable
("available ... via an accepted Electronic Distribution Mechanism"). The
new section 3.2 and 3.3 a) makes no restrictions at all apart from
"reasonable" and "nominal charge".
I realize that the GPL has language similar to the new wording, however
I considered MPL to be better. Why shouldn't you make the source
available per download? In fact, I'd mandate that it must be available
freely to everybody (not just recipients of the executable) for free per
Internet HTTP. You received free, you shall give free.
Ben
Luis Villa
> The old MPL 1.1 section 3.2 demanded that the Source Code is either
> on the same medium (DVD, USB stick) as the Executable, or downloadable
> ("available ... via an accepted Electronic Distribution Mechanism").
> The new section 3.2 and 3.3 a) makes no restrictions at all apart from
> "reasonable" and "nominal charge".
>
> I realize that the GPL has language similar to the new wording,
> however I considered MPL to be better.
could now rely on two things: (1) there is now a pretty broad
understanding of what 'reasonable' distribution is for free/open
software, which is pretty much in line with what we were already
requiring (2) we could include in a FAQ some examples of what we mean by
'reasonable' distribution, allowing it to be more flexible than actually
including it in the body of the license itself. This has the bonus of
being future-proof; we were already seeing some creakiness around the
old language and modern development practices and I think we expected
that would only get worse.
> Why shouldn't you make the source available per download?
But you can imagine situations where it might be hard to include source
through the available technology (e.g., some application stores); we'd
like to encourage people to be creative there rather than set out strict
definitions in the license itself.
> In fact, I'd mandate that it must be available freely to everybody
> (not just recipients of the executable) for free per Internet HTTP.
> You received free, you shall give free.
speaking even GPL only creates obligations to people whom you've
distributed executables to, rather than to the entire world. We can look
at it, though; honestly it just wasn't something we ever considered.
Let me know if this didn't answer your questions, Ben-
Luis
Luis Villa
You mean "You must include a prominent statement that the Modification
is derived, directly or indirectly, from Original Code provided by the
Initial Developer and including the name of the Initial Developer in (a)
the Source Code, and (b) in any notice in an Executable version or
related documentation in which You describe the origin or ownership of
the Covered Code." ?
I think we meant this general situation to be covered by the new 3.4:
"You may not remove or alter any valid copyright or patent notices
contained within the Source Code form of the Covered Software, or any
valid notices of licensing."
This still 'gives credit', though not as explicit as part (b) of the
language you cited (notice in executable versions or documentation.)
My personal experience is that virtually no one reads documentation, so
that any requirements pertaining to documentation don't actually do much
to help give credit. But you're right that the removal of 'notice in an
Executable version' makes the new language less forceful, and you're not
the first to mention this (it came up in the co-ment tool as well.)
Do others here have thoughts/comments/concerns about this area? We'll
take a harder look, but if others have thoughts about it, that would be
great to hear as well. Thanks.
Luis
Ben Bucksch
On 19.08.2010 20:16, Luis Villa wrote:
> On 8/16/10 10:36 AM, Ben Bucksch wrote:
>> I am missing the old section 3.3, second part
>>
>> I think the least we can expect for our work on Mozilla is to be
>> credited and thanked for it.
> You mean "You must include a prominent statement that the Modification
> is derived, directly or indirectly, from Original Code provided by the
> Initial Developer and including the name of the Initial Developer in
> (a) the Source Code, and (b) in any notice in an Executable version or
> related documentation in which You describe the origin or ownership of
> the Covered Code." ?
>
Yes.
> I think we meant this general situation to be covered by the new 3.4:
> "You may not remove or alter any valid copyright or patent notices
> contained within the Source Code form of the Covered Software, or any
> valid notices of licensing."
I know, but that's not enough.
If I wrote the whole network library, I still wouldn't appear in the
Help | About box.
Similarly, if I take Gecko and build my own browser UI around it, I
don't remove any noticed and don't have to credit anything.
> This still 'gives credit'
Unfortunately, it does not.
The above mentioned problems didn't exist in the old wording, it was
much clearer, and had no loopholes.
Ben Bucksch
> there is now a pretty broad understanding of what 'reasonable'
> distribution is for free/open software
I recently found that I don't even agree with other Mozilla people what
"open source project" means (they say license only ala Oracle, I say
open for contribution), so I don't think you can assume a shared
understanding of "reasonable", esp. with a hostile party, at a court.
> Why shouldn't you make the source available per download?
> Generally, you should; that is 'reasonable' modern open source
> practice. But you can imagine situations where it might be hard to
> include source through the available technology (e.g., some
> application stores);
You can always offer a download on your own server and cite the URL in
the app. All you need to do is guarantee that it stays live (the old MPL
even specced how long).
> we'd like to encourage people to be creative there
Frankly, I'd rather have people not be "creative" when it comes to
fulfilling open source license requirements. Companies have been way too
creative in this area.
(Sorry for picking on your word, could not resist :) )
>> In fact, I'd mandate that it must be available freely to everybody
>> (not just recipients of the executable) for free per Internet HTTP.
>> You received free, you shall give free.
> That would be broader than any other open source license
MPL 1.1 was very close to that.
> generally speaking even GPL only creates obligations to people whom
> you've distributed executables to, rather than to the entire world.
Frankly, I don't see why, given that these receivers can then freely
redistribute, so there's little point.
Internal use is not covered anyways, so that's irrelevant.
I don't know what would happen if a company sold commercial software
based on Gecko, and in the license for the software mandated that the
MPL source is not re-distributed. The customer could then get the
source, and the MPL would allow them to give it to me, but the other
contract would forbid it. Essentially close-sourcing the MPL changes. I
don't think we want that.
So, I don't see a point of this loophole "source for customers only".
Luis Villa
covered the Initial Developer and not later contributors. But I see your
general point.
Anyone else have thoughts/opinions on this issue?
Luis
Ben Bucksch
> On 8/19/10 5:10 PM, Ben Bucksch wrote:
>> The above mentioned problems didn't exist in the old wording, it was
>> much clearer, and had no loopholes.
> It actually had a pretty big loophole in practice, which is that it
> only covered the Initial Developer and not later contributors.
I know. But if you made substantial contributions, chances are very good
that you at some point created a new source file, in which case you are
Initial Developer (hopefully you are alert enough to put yourself in the
field). So, that wasn't too bad actually, in practice crediting major
contributors.
Justin Dolske
> My personal experience is that virtually no one reads documentation, so
> that any requirements pertaining to documentation don't actually do much
> to help give credit.
I pretty strongly agree with this. No one reads docs. And for a
project/software of any size, having license-required credits can easily
result in a wall of text, who wants to read that? Credits feel like an
issue orthogonal to core FOSS principles.
Justin
Luis Villa
time I got in one, so I wouldn't discount it altogether. It is too easy
for those of us who are lucky enough to do this full time to forget the
impact of this kind of thing on volunteers.
It may be most productive to discuss what the outcome should be when a
healthy project (with presumably good contributor recognition practices)
is forked by a third party without a community connection. Think of the
license as a mandatory minimum, designed to cover that case, while the
best practices of healthy projects would go beyond that, but not be
mandated by the license.
Luis Villa
should first highlight a general point. There is a tension between a
couple of different potential goals:
* Making exploitation hard for hostile, sophisticated license users.
* Making understanding and compliance easy for well-intentioned license
users.
* Reducing the damage caused by unsophisticated and/or unintentional
license violators.
In particular, the first two points can be in obvious tension: making
things ironclad against hostile exploiters can make the license harder
to understand and/or less flexible for well-intentioned users. Of
course, go too far towards making it easy, and you leave yourself with
no tools to use against unsophisticated violators.
Two data points have informed my (personal) thinking about where to
strike the balance:
* As far as we're aware, sophisticated exploiters appear to have been
rare; violations have instead mainly been very amateurish, making very
obvious mistakes like not putting up any source anywhere. I think the
GPL and CC folks have mostly found the same thing to be true. This
suggests to me that it is most important to cover the common amateurish
cases; the rare sophisticated exploiter should not be ignored but
shouldn't be given undue weight.
* Detailed requirements have proven hard for well-intentioned users to
understand, and easy for them to violate even when acting in good faith.
This suggests to me that we should generally avoid overly-specific
requirements unless there is a very good reason.
Obviously each time we look at language, we do a case-by-case balancing
of the issues, and so what you're telling us is valuable, Ben. I just
thought it might be worthwhile to spell out the background that I'm
operating against.
Luis
On 8/19/10 5:22 PM, Ben Bucksch wrote:
> On 19.08.2010 20:09, Luis Villa wrote:
>> there is now a pretty broad understanding of what 'reasonable'
>> distribution is for free/open software
>
> I recently found that I don't even agree with other Mozilla people
> what "open source project" means (they say license only ala Oracle, I
> say open for contribution), so I don't think you can assume a shared
> understanding of "reasonable", esp. with a hostile party, at a court.
>
>> Why shouldn't you make the source available per download?
>> Generally, you should; that is 'reasonable' modern open source
>> practice. But you can imagine situations where it might be hard to
>> include source through the available technology (e.g., some
>> application stores);
>
> You can always offer a download on your own server and cite the URL in
> the app. All you need to do is guarantee that it stays live (the old
> MPL even specced how long).
>
>> we'd like to encourage people to be creative there
>
> Frankly, I'd rather have people not be "creative" when it comes to
> fulfilling open source license requirements. Companies have been way
> too creative in this area.
> (Sorry for picking on your word, could not resist :) )
>
>>> In fact, I'd mandate that it must be available freely to everybody
>>> (not just recipients of the executable) for free per Internet HTTP.
>>> You received free, you shall give free.
>> That would be broader than any other open source license
>
> MPL 1.1 was very close to that.
>
>> generally speaking even GPL only creates obligations to people whom
>> you've distributed executables to, rather than to the entire world.
>
> Frankly, I don't see why, given that these receivers can then freely
> redistribute, so there's little point.
>
> Internal use is not covered anyways, so that's irrelevant.
>
> I don't know what would happen if a company sold commercial software
> based on Gecko, and in the license for the software mandated that the
> MPL source is not re-distributed. The customer could then get the
> source, and the MPL would allow them to give it to me, but the other
> contract would forbid it. Essentially close-sourcing the MPL changes.
> I don't think we want that.
>
> So, I don't see a point of this loophole "source for customers only".
Ben Bucksch
> I was going to reply in great detail (and may yet) but I think I
> should first highlight a general point. There is a tension between a
> couple of different potential goals:
>
> * Making exploitation hard for hostile, sophisticated license users.
> * Making understanding and compliance easy for well-intentioned
> license users.
From my experience, the distinction is not so clear. Speaking of
companies, there are often different people or fractions involved (often
development dev against laywers), and they might fight with each other.
Being a contractor helping all kinds of companies with using Mozilla
(XUL, Gecko etc.) in their products, I have very often been in these
situations, arguing for source publishing, but having a hard stance,
because the company has no inherent interest in it. In such situations,
the license is the only "weapon" for the "good guys". In fact, in almost
any company I worked for, I had to argue with "the license requires us
to do this, at that time, we have no choice, we *have* to do it", and
that argument was usually working, and the *only* argument that really
worked. I can't say this, if I know the license has loopholes. So,
having clear, loophole-free requirements for me is very important. It
also shows that there's no clear distinction between "bad guys" and
"good guys" when looking at companies.
Also, there are typically time pressures to get a release out, and
fulfilling source code requirements is very low on the priority list (no
direct benefit for company nor ordinary users), and after the release,
people tend to slack a bit and/or move on to the next version, and
forget about such things.
> In particular, the first two points can be in obvious tension: making
> things ironclad against hostile exploiters can make the license harder
> to understand and/or less flexible for well-intentioned users. Of
> course, go too far towards making it easy, and you leave yourself with
> no tools to use against unsophisticated violators.
I don't see the tension as far as understanding goes.
"You have to publish the source via a very widely established protocol
(such as HTTP), accessible to anyone on the Internet, and mention the
location (e.g. URL or hyperlink) in the product, where the product
license is displayed or cited (e.g. About dialog). The source code must
be accessible at this location at the same time when the product is
available to the public, and for 6 months until this product version is
replaced by a newer version, or for 12 month after the product is
discontinued.",
or something like that, is not hard to understand. The time scale
matches MPL 1.1, the "for anyone" is distributing the source
theoretically wider than MPL1.1, but that at the same time makes the
license language easier to understand.
> Two data points have informed my (personal) thinking about where to
> strike the balance:
I hope my first-hand experience as a contractor, as written above, gives
some more data.
Ben Bucksch
> I still remember showing my grandmother that 'wall of text' the first
> time I got in one, so I wouldn't discount it altogether. It is too
> easy for those of us who are lucky enough to do this full time to
> forget the impact of this kind of thing on volunteers.
Indeed.
> It may be most productive to discuss what the outcome should be when a
> healthy project (with presumably good contributor recognition
> practices) is forked by a third party without a community connection.
If I create a new UI around Gecko, the 95% majority of my product is
still Gecko, so I think Mozilla contributors have to be credited fully.
Same for Seamonkey, Camino, KMeleon etc.pp..
I agree about the documentation (as in: end user manual), it's pointless
and technically hard to put the credits there.
Ben
timeless
<ben.buck...@beonex.com> wrote:
> I know. But if you made substantial contributions, chances are very good
> that you at some point created a new source file, in which case you are
> Initial Developer (hopefully you are alert enough to put yourself in the
> field).
FWIW, I looked once, and afaict, I am one of the rare devs who hadn't
created a file that was credited anywhere.
It's possible that this is because:
* I don't like leaving my name in files.
* I merely cannibalized existing files (nsDeque is mine but the file
name existed before me).
* I've had an employer for most of my 10 years I just haven't created
files that weren't my employer's.
> So, that wasn't too bad actually, in practice crediting major contributors.
Other than shorting me, I don't think it's very bad.
timeless
> I still remember showing my grandmother that 'wall of text' the first time I
> got in one, so I wouldn't discount it altogether.
I do like that, I seem to recall occasionally having relatives mention
seeing me in credits in places. It is a nice feeling.
> It is too easy for those
> of us who are lucky enough to do this full time to forget the impact of this
> kind of thing on volunteers.
> It may be most productive to discuss what the outcome should be when a
> healthy project (with presumably good contributor recognition practices) is
> forked by a third party without a community connection.
This is actually an interesting part, one of my happiest bits is that
I'm in credits for Apple's products because Hyatt copied a pair of
files from mozilla to webkit and I had touched them.
Benjamin Smedberg
> This still 'gives credit', though not as explicit as part (b) of the
> language you cited (notice in executable versions or documentation.)
>
> My personal experience is that virtually no one reads documentation, so that
> any requirements pertaining to documentation don't actually do much to help
> give credit. But you're right that the removal of 'notice in an Executable
> version' makes the new language less forceful, and you're not the first to
> mention this (it came up in the co-ment tool as well.)
>
> Do others here have thoughts/comments/concerns about this area? We'll take a
> harder look, but if others have thoughts about it, that would be great to
> hear as well. Thanks.
This whole discussion has focused on "giving credit", which I think is
misguided.
I understand that people who create software really want to be acknowledged:
it feels good to know that your code is part of products, and it looks good
to family, friends, and potential employers. But the associated costs are
that people who do release software have to either have to maintain drastic
change-control practices in order to keep the MPL credits list up to date,
or risk accidentally violating the license terms while forgetting somebody.
I don't think that is a price we should be enforcing at the license level.
There are other issues, of course: the license could require that you credit
all *copyright holders*, but then most of our core contributors would not be
given individual credit, because they work for Mozilla or other entities
which own their copyright.
I think the more interesting question here is whether we should be able to
identify all the copyright holders for a particular piece of code. As far as
I can tell, that was the original reason for listing "Contributors" in the
MPL 1.1 header, so that you could go back later and know exactly who has a
copyright interest in that code. I think it's much more important for the
MPL 1.2 effort to decide whether this is an important goal or not.
Leave "credit" to the community, who can choose to credit individuals or
copyright owners (or not, as long as the license makes the source code
available), and can also choose to credit important non-code contributors. A
license is a poor tool for trying to demand and control credit, which is
primarily a social issue.
--BDS
Luis Villa
>
> I think the more interesting question here is whether we should be
> able to identify all the copyright holders for a particular piece of
> code. As far as I can tell, that was the original reason for listing
> "Contributors" in the MPL 1.1 header, so that you could go back later
> and know exactly who has a copyright interest in that code. I think
> it's much more important for the MPL 1.2 effort to decide whether this
> is an important goal or not.
some consensus that:
1) This language in the MPL 1.1 did not achieve the goal of identifying
all the copyright holders for a given piece of code; we have hard data
showing that a large number of small-c contributors ended up never
listed as Contributors. (I believe I sent links to that effect to the
list; please poke if you need me to resend.)
2) Modern development practices (better revision control systems,
contributor agreements, and source code search tools, primarily) do a
better job of this now, making it less important to have in the license.
Ben Bucksch
> I understand that people who create software really want to be
> acknowledged: it feels good to know that your code is part of
> products, and it looks good to family, friends, and potential employers.
> But the associated costs are that people who do release software have
> to either have to maintain drastic change-control practices in order
> to keep the MPL credits list up to date
I've done it myself, when I released Beonex. You just need to gather the
Initial Developer and Contributor lines, and basically run sort|uniq on
them. You'll get a few dups with " Inc" vs. ", Inc" etc., but that's
easily fixed in script or source. It can be automated. I created and ran
a few scripts myself.
> Leave "credit" to the community
Unfortunately, community failed. For example, although I work for and on
and around Mozilla full-time since over 10 years, and am an Initial
Developer, e.g. of netwerk/ code, and there's a long list of people
scrolled by in Firefox About, I am not among them. Now, you may argue I
should not be in the list. Community can fail.
I do not want to rely on the project owner de jour to decide whether he
thinks my authorship is relevant or his own contributions are more
important. I think that's an understandable concern.
In general, I think the authors of the code must be prominently credited
towards end-users, no matter who creates the UI or binary, be it Firefox
or Google Chrome based on Gecko - that's why most open-source licenses
*do* have a credits clause.
I am happy with the MPL 1.1 clause, I think it was very well formulated
as-is, and I don't see why I should give up my guaranteed rights.
Ben
timeless
> (I believe I sent links to that effect to the list; please
> poke if you need me to resend.)
You did, under:
hard data on when committers list themselves as Contributors [was Re:
What "notification" means to me]
Luis Villa
http://turingmachine.org/~dmg/papers/dmg2009_wcreAuthors.pdf
for a better link.
Gervase Markham
> Unfortunately, community failed. For example, although I work for and on
> and around Mozilla full-time since over 10 years, and am an Initial
> Developer, e.g. of netwerk/ code, and there's a long list of people
> scrolled by in Firefox About, I am not among them. Now, you may argue I
> should not be in the list. Community can fail.
That list is not supposed to be a list of everyone who has ever worked
on Mozilla code. It's a list of people who have made a significant
contribution to that particular release and, as such, people get added
to it and removed from it at the end of each product cycle.
about:credits _is_ that list of everyone, and you are on it - and have
been since Tue May 2 19:13:48 2000 PDT, over 10 years ago. A link to
that page is the first thing you see when you click "Credits" in the
About box of Firefox 4.
> In general, I think the authors of the code must be prominently credited
> towards end-users, no matter who creates the UI or binary, be it Firefox
> or Google Chrome based on Gecko - that's why most open-source licenses
> *do* have a credits clause.
Depending on exactly what you mean by "a credits clause", I don't think
that's true.
The GPL3 requires the publication of appropriate copyright notices on
the code (section 4). Apache requires their preservation (section 4.3).
BSD requires their preservation, and placement in documentation. MIT
requires their preservation in "the Software". The MPL 2.0 requires
their preservation (section 3.4) and allows their addition (section 11).
No-one has a "you have to put my name in the About box" clause. The
closest is Apache 2 section 4.4, but even that allows the NOTICE file to
be a text file on disk, unreferenced in the UI.
Gerv
Gervase Markham
> If I wrote the whole network library, I still wouldn't appear in the
> Help | About box.
If the network library were under the MPL 1.1, you couldn't require this
either.
Gerv
Gervase Markham
> You can always offer a download on your own server and cite the URL in
> the app. All you need to do is guarantee that it stays live (the old MPL
> even specced how long).
And that was one of its most annoying provisions. When you are doing
daily builds on 3 platforms in 75 languages, do you have any idea how
much disk space it requires to keep source available for 6 months?
>> generally speaking even GPL only creates obligations to people whom
>> you've distributed executables to, rather than to the entire world.
>
> Frankly, I don't see why, given that these receivers can then freely
> redistribute, so there's little point.
The point is that you don't place unnecessary burdens on the
redistributor. Limiting it to the number of copies of the binary
distributed bases an upper bound on e.g. the amount of money you need to
spend on bandwidth and your FTP server. Mandating you make it available
to the whole world opens you up to unlimited costs. That's unreasonable,
IMO.
> I don't know what would happen if a company sold commercial software
> based on Gecko, and in the license for the software mandated that the
> MPL source is not re-distributed. The customer could then get the
> source, and the MPL would allow them to give it to me, but the other
> contract would forbid it. Essentially close-sourcing the MPL changes. I
> don't think we want that.
That's not possible, either under the MPL 1.1 or 2.0. Quoting from 2.0:
3.3.b): "You may distribute such Executable form under the terms of this
License or under different terms, provided that the license for the
Executable form does not attempt to limit or alter the recipient’s
rights in the Source Code form under this License."
Gerv
Gervase Markham
> I know. But if you made substantial contributions, chances are very good
> that you at some point created a new source file, in which case you are
> Initial Developer (hopefully you are alert enough to put yourself in the
> field). So, that wasn't too bad actually, in practice crediting major
> contributors.
Actually, it wasn't that good. When I first created the list of IDs for
about:license, in order to bring us (for the first time, some 5-7 years
after the code release) into compliance with the letter of this
particular part of the MPL, I got several complaints from long-term
contributors that they weren't "credited". I had to explain that this
list was about license compliance, not credit.
Gerv
Gervase Markham
> I think the more interesting question here is whether we should be able
> to identify all the copyright holders for a particular piece of code. As
> far as I can tell, that was the original reason for listing
> "Contributors" in the MPL 1.1 header, so that you could go back later
> and know exactly who has a copyright interest in that code. I think it's
> much more important for the MPL 1.2 effort to decide whether this is an
> important goal or not.
I think it's pretty clear that, when considered as a method of keeping
track of who has a copyright interest in a file, the Original Developer
/ Contributors mechanism is an abject failure. I suspect that, of those
files in the Mozilla codebase which have been significantly changed by
more than (say) 5 people, the number for which all those with a
copyright interest will be listed in the Contributors section would be tiny.
> Leave "credit" to the community, who can choose to credit individuals or
> copyright owners (or not, as long as the license makes the source code
> available), and can also choose to credit important non-code
> contributors. A license is a poor tool for trying to demand and control
> credit, which is primarily a social issue.
As someone who has been managing both credit and licensing for the
Mozilla project for many, many years, I wholeheartedly agree.
If and when the Mozilla project switches to MPL 2.0, I would anticipate
(and note, this is off the top of my head, not an official position, and
I reserve the right to change it):
1) Keeping a non-license-header list of contributors in each file, made
up of the ID and Contributors lists from the MPL headers, to which
anyone who made a change could add their name (even if they were not a
copyright holder, e.g. because they worked for a company - a much better
situation than now)
2) Removing the list of IDs from about:licence (no-one reads it)
IMO, the scope for gaining recognition of your work would be basically
the same - or better, if you work for a company.
Gerv
Asa Dotzler
> On 20/08/10 01:22, Ben Bucksch wrote:
>> You can always offer a download on your own server and cite the URL in
>> the app. All you need to do is guarantee that it stays live (the old MPL
>> even specced how long).
>
> And that was one of its most annoying provisions. When you are doing
> daily builds on 3 platforms in 75 languages, do you have any idea how
> much disk space it requires to keep source available for 6 months?
It's not just three platforms either. It's at least ten including 64-bit
and mobile platforms. But it's even worse than that. Add in another 5 or
6 dozen tinderbox and tryserver builds across about 7 platforms per day
and then it really does start to take up a few bytes of disk.
- A
Ben Bucksch
> On 20/08/10 01:22, Ben Bucksch wrote:
>> You can always offer a download on your own server and cite the URL in
>> the app.
>
> daily builds on 3 platforms in 75 languages, do you have any idea how
> much disk space it requires to keep source available for 6 months?
Yes. None.
<http://hg.mozilla.org/mozilla-central/archive/4958e6add3c9.tar.bz2> is
fine. (Plus a similar link to the locale source.)
> The point is that you don't place unnecessary burdens on the
> redistributor. Limiting it to the number of copies of the binary
> distributed bases an upper bound on e.g. the amount of money you need
> to spend on bandwidth and your FTP server. Mandating you make it
> available to the whole world opens you up to unlimited costs. That's
> unreasonable, IMO.
I've done it. Even in year 2000, when bandwidth was 1000 times more
expansive than now, the FTP traffic costs were not significant.
Fact is: if you need to write a paper letter to the company and wait for
it being answers, as some companies have demanded for GPL, *that* is an
"unreasonable burden" on the part of the open-source developer /
customer who is just curious what they did with the Mozilla source. A
burden that is so high that I am unlikely to do it, unless in
exceptional circumstances.
Sorry, but source code provision is at the very core of open-source. It
must be loophole-free.
Ben