Question about section 1.7 "Larger Work"

[Benoit Jacob]

Hi,

This section:

1.7. "Larger Work"
means a work that combines Covered Software with code in a separate
file or files not governed by the terms of this License.

Seems unclear to me.

First question: how to parse it grammatically?

Possibility #1:
means a work that combines Covered Software with code in a separate
file (or files) not governed by the terms of this License.
Possibility #2:
means a work that combines Covered Software with code in a separate
file (or files not governed by the terms of this License).

Second question: Is this referring to files in the Source form or
Executable form? I'm asking because of the term "separate" used in this
clause. If my application links *statically* to a MPL2-licensed library,
then that library is not a separate file from the library, in Executable
form. Is it still a "Larger Work" according to 1.7?

Thanks,
Benoit

[Gervase Markham]

Hi Benoit,

Good questions :-)

On 16/11/11 18:04, Benoit Jacob wrote:
> Possibility #1:
> means a work that combines Covered Software with code in a separate
> file (or files) not governed by the terms of this License.
> Possibility #2:
> means a work that combines Covered Software with code in a separate
> file (or files not governed by the terms of this License).

The answer is Possibility #1. We could perhaps fix this by adding the
brackets, as in your clarifying example. Or commas.

> Second question: Is this referring to files in the Source form or
> Executable form? I'm asking because of the term "separate" used in this
> clause. If my application links *statically* to a MPL2-licensed library,
> then that library is not a separate file from the library, in Executable
> form. Is it still a "Larger Work" according to 1.7?

The answer is that the code referred to is in Source Form, but it's OK
for the "combining" process to put them into the same file.

We could perhaps clarify this by replacing "code in" with "source code
from" (not capitalized as it's not a defined term).

Gerv

[Benoit Jacob]

On 16/11/11 01:11 PM, Gervase Markham wrote:
>> Second question: Is this referring to files in the Source form or
>> Executable form? I'm asking because of the term "separate" used in this
>> clause. If my application links *statically* to a MPL2-licensed library,
>> then that library is not a separate file from the library, in Executable
>> form. Is it still a "Larger Work" according to 1.7?
>

> The answer is that the code referred to is in Source Form, but it's OK
> for the "combining" process to put them into the same file.
>
> We could perhaps clarify this by replacing "code in" with "source code
> from" (not capitalized as it's not a defined term).

Please do clarify it in the license: this seems very important to me. In
addition, it would be useful to add a FAQ entry about this, and how in
particular static linking is fine.

Benoit

>
> Gerv
>
> _______________________________________________
> governance-mpl-update mailing list
> governance...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance-mpl-update

[Benoit Jacob]

On 16/11/11 01:11 PM, Gervase Markham wrote:

>> Second question: Is this referring to files in the Source form or
>> Executable form? I'm asking because of the term "separate" used in this
>> clause. If my application links *statically* to a MPL2-licensed library,
>> then that library is not a separate file from the library, in Executable
>> form. Is it still a "Larger Work" according to 1.7?
>

> The answer is that the code referred to is in Source Form, but it's OK
> for the "combining" process to put them into the same file.
>
> We could perhaps clarify this by replacing "code in" with "source code
> from" (not capitalized as it's not a defined term).

Actually, this seems very important to me so why would one not use "a
defined term" here?

What matters to me is that it's made clear that the requirements on
files being separate applies to the Source form, not to the Executable form.

Benoit

[Benoit Jacob]

Ping. I believe that this is quite important. The phrasing in section
1.7 has been misunderstood by reasonable people as meaning that the MPL
doesn't allow static linking to libraries.

Cheers
Benoit

On 16/11/11 01:43 PM, Benoit Jacob wrote:
> On 16/11/11 01:11 PM, Gervase Markham wrote:

>>> Second question: Is this referring to files in the Source form or
>>> Executable form? I'm asking because of the term "separate" used in this
>>> clause. If my application links *statically* to a MPL2-licensed library,
>>> then that library is not a separate file from the library, in Executable
>>> form. Is it still a "Larger Work" according to 1.7?
>>

[Luis Villa]

I am discussing it with Gerv. :)

On Sat, Nov 19, 2011 at 3:12 PM, Benoit Jacob <bja...@mozilla.com> wrote:
> Ping. I believe that this is quite important. The phrasing in section 1.7
> has been misunderstood by reasonable people as meaning that the MPL doesn't
> allow static linking to libraries.
>
> Cheers
> Benoit
>
> On 16/11/11 01:43 PM, Benoit Jacob wrote:
>>
>> On 16/11/11 01:11 PM, Gervase Markham wrote:
>>>>

>>>> Second question: Is this referring to files in the Source form or
>>>> Executable form? I'm asking because of the term "separate" used in this
>>>> clause. If my application links *statically* to a MPL2-licensed library,
>>>> then that library is not a separate file from the library, in Executable
>>>> form. Is it still a "Larger Work" according to 1.7?
>>>

>>> The answer is that the code referred to is in Source Form, but it's OK
>>> for the "combining" process to put them into the same file.
>>>
>>> We could perhaps clarify this by replacing "code in" with "source code
>>> from" (not capitalized as it's not a defined term).
>>
>> Actually, this seems very important to me so why would one not use "a
>> defined term" here?
>>
>> What matters to me is that it's made clear that the requirements on
>> files being separate applies to the Source form, not to the Executable
>> form.
>>
>> Benoit
>

[Gervase Markham]

On 16/11/11 18:04, Benoit Jacob wrote:

> Second question: Is this referring to files in the Source form or
> Executable form? I'm asking because of the term "separate" used in this
> clause. If my application links *statically* to a MPL2-licensed library,
> then that library is not a separate file from the library, in Executable
> form. Is it still a "Larger Work" according to 1.7?

Hi Benoit,

The more we think about this, the more we realise it's a good question :-)

Luis and I have discussed this, and we now think the answer is the
following:

"Combination" does not necessarily mean "compilation", and it doesn't
necessarily mean "putting in the same file". It means "making to work
together as a whole". So if you have an MPLed .js file working with a
non-MPLed .js file to achieve an effect, that is a Larger Work. If you
compile MPLed files and non-MPLed files into a static binary, that is a
Larger Work. If you compile MPLed files into one dynamic lib and link it
to a non-MPLed app, that is a Larger Work as well.

To put it another way: the definition of Modifications defines what code
falls under the MPL. If your code doesn't meet that definition, it's not
under the MPL. A Larger Work is any thing which combines MPLed and
non-MPLed code in a way which does not make the non-MPLed code a
Modification. This definition of a Larger Work doesn't define the scope
of the MPL, it just creates a name for such a combination.

Does that help?

Gerv

[Benoit Jacob]

Sorry to be sending this so late. I actually sent this last week, but my
Thunderbird isn't configured for Newsgroups and dropped the newsgroup
field. I didn't realize that that meant that it wouldn't be sent at all
to the list.

On 22/11/11 04:46 AM, Gervase Markham wrote:
> On 16/11/11 18:04, Benoit Jacob wrote:

>> Second question: Is this referring to files in the Source form or
>> Executable form? I'm asking because of the term "separate" used in this
>> clause. If my application links *statically* to a MPL2-licensed library,
>> then that library is not a separate file from the library, in Executable
>> form. Is it still a "Larger Work" according to 1.7?
>

> Hi Benoit,
>
> The more we think about this, the more we realise it's a good question
>

> Luis and I have discussed this, and we now think the answer is the
> following:
>
> "Combination" does not necessarily mean "compilation", and it doesn't
> necessarily mean "putting in the same file". It means "making to work
> together as a whole". So if you have an MPLed .js file working with a
> non-MPLed .js file to achieve an effect, that is a Larger Work. If you
> compile MPLed files and non-MPLed files into a static binary, that is a
> Larger Work. If you compile MPLed files into one dynamic lib and link it
> to a non-MPLed app, that is a Larger Work as well.
>
> To put it another way: the definition of Modifications defines what code
> falls under the MPL. If your code doesn't meet that definition, it's not
> under the MPL. A Larger Work is any thing which combines MPLed and
> non-MPLed code in a way which does not make the non-MPLed code a
> Modification. This definition of a Larger Work doesn't define the scope
> of the MPL, it just creates a name for such a combination.
>
> Does that help?

It does, thanks. But while it does clarify the intention of the MPL in
this area, I am still worried if the MPL is going to ship as-is without
updated text, as I consider the current text to be ambiguous.

Specifically, when the MPL says:

> 1.7. "Larger Work"
> means a work that combines Covered Software with code in a separate
> file or files not governed by the terms of this License.

The word "separate" here only has a precise meaning with respect to a
particular Form of the software. If I understand correctly your
explanation, the intent is that the Source Code Form is meant here, so
that in the above sentence, "separate file" specifically means:

"a file that is separate from the files in the Source Code Form of the
Covered Work"

I still believe that it is very important to clarify this: in the
current state of the text, I think that the word "separate" is ambiguous.

Thanks,
Benoit