Source code via download -- MPL Alpha 1 Draft Released

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Source code via download -- MPL Alpha 1 Draft Released

Ben Bucksch
  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. 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
_______________________________________________
legal mailing list
[hidden email]
https://lists.mozilla.org/listinfo/legal
Reply | Threaded
Open this post in threaded view
|

Re: Source code via download -- MPL Alpha 1 Draft Released

Luis Villa-5
  On 8/16/10 10:41 AM, Ben Bucksch wrote:
>  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.
Our thinking was that when we encouraged 'reasonable' distribution, we
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?
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); 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.
That would be broader than any other open source license; generally
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, Mozilla Legal
work email: [hidden email] (preferred)
work phone: 650-903-0800 x327
personal: http://tieguy.org/about/

_______________________________________________
legal mailing list
[hidden email]
https://lists.mozilla.org/listinfo/legal
Reply | Threaded
Open this post in threaded view
|

Re: Source code via download -- MPL Alpha 1 Draft Released

Ben Bucksch
  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".
_______________________________________________
legal mailing list
[hidden email]
https://lists.mozilla.org/listinfo/legal
Reply | Threaded
Open this post in threaded view
|

Re: Source code via download -- MPL Alpha 1 Draft Released

Luis Villa-5
  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.
* 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".


--
Luis Villa, Mozilla Legal
work email: [hidden email] (preferred)
work phone: 650-903-0800 x327
personal: http://tieguy.org/about/

_______________________________________________
legal mailing list
[hidden email]
https://lists.mozilla.org/listinfo/legal
Reply | Threaded
Open this post in threaded view
|

Re: Source code via download -- MPL Alpha 1 Draft Released

Ben Bucksch
In reply to this post by Ben Bucksch
  On 20.08.2010 20:20, Luis Villa wrote:
>  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.
_______________________________________________
legal mailing list
[hidden email]
https://lists.mozilla.org/listinfo/legal
Reply | Threaded
Open this post in threaded view
|

Re: Source code via download -- MPL Alpha 1 Draft Released

Gervase Markham
In reply to this post by Luis Villa-5
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?

>> 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
_______________________________________________
legal mailing list
[hidden email]
https://lists.mozilla.org/listinfo/legal
Reply | Threaded
Open this post in threaded view
|

Re: Source code via download -- MPL Alpha 1 Draft Released

Asa Dotzler-2
On 9/7/2010 8:42 AM, Gervase Markham wrote:
> 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
_______________________________________________
legal mailing list
[hidden email]
https://lists.mozilla.org/listinfo/legal
Reply | Threaded
Open this post in threaded view
|

Re: Source code via download -- MPL Alpha 1 Draft Released

Ben Bucksch
In reply to this post by Gervase Markham
  On 07.09.2010 17:42, Gervase Markham wrote:
> 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.
>
> 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?

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
_______________________________________________
legal mailing list
[hidden email]
https://lists.mozilla.org/listinfo/legal