Sergey Yanovich | 4 Jul 13:09 2008
Picon

Re: Using new jemalloc features in our code

Cross-posting and redirecting follow-ups to m.legal

Gervase Markham wrote:
> Sergey Yanovich wrote:
>> I've always been curious, how well patching MS CRT for jemalloc fares
>> with GPLv2, namely with Article 2 Part b):
> 
> What is the current situation w.r.t. Firefox on Windows? Do we bundle
> any binary modules, e.g. the MS CRT? If not, we should consider whether
> that's a boundary we want to cross.

Firefox 3.0 on Windows already ships jemalloc patched MS CRT.

> As to what happens if you tried to distribute a GPLed Mozilla-based
> browser with a jemalloc-patched MSCRT which was therefore not a System
> Library, I'd suspect that you'd be in trouble. But I'd have to check
> carefully.

Basically, you said what I said. The described product ain't GPLed. 
Careful checking applies mostly to consequences.

> As we try hard to make our code equally usable under whichever licence a
> licensee chooses, this would be a good reason *not* to make having to
> match the MS CRT with jemalloc compulsory to build the codebase.

Absolutely!

--

-- 
Sergey Yanovich
(Continue reading)

Gervase Markham | 7 Jul 11:52 2008
Picon

Re: Using new jemalloc features in our code

Sergey Yanovich wrote:
> Firefox 3.0 on Windows already ships jemalloc patched MS CRT.

Ah.

Is it possible to build Firefox without this, or is it required?

Gerv
Sergey Yanovich | 7 Jul 16:29 2008
Picon

Re: Using new jemalloc features in our code

Gervase Markham wrote:
> Sergey Yanovich wrote:
>> Firefox 3.0 on Windows already ships jemalloc patched MS CRT.
> 
> Is it possible to build Firefox without this, or is it required?

It is right now (with --disable-jemalloc). However, Benjamin wrote in 
the proposal at the root of this thread in m.d.platform:

> My proposed solution to this problem is as follows:
> 
> * Always build jemalloc. Mozilla code should not use malloc()/free(), but mozilla-specific symbol
names such as NS_Alloc() or JE_malloc()
> 
> * where possible, hook jemalloc into the CRT so that it allocates all malloc()ed memory and there is a
unified heap

This seems to imply making --disable-jemalloc obsolete, which is why I 
am raising the legal issue under discussion.

--

-- 
Sergey Yanovich
Gervase Markham | 7 Jul 16:36 2008
Picon

Re: Using new jemalloc features in our code

Sergey Yanovich wrote:
> It is right now (with --disable-jemalloc). However, Benjamin wrote in
> the proposal at the root of this thread in m.d.platform:
> 
>> My proposed solution to this problem is as follows:
>>
>> * Always build jemalloc. Mozilla code should not use malloc()/free(),
>> but mozilla-specific symbol names such as NS_Alloc() or JE_malloc()
>>
>> * where possible, hook jemalloc into the CRT so that it allocates all
>> malloc()ed memory and there is a unified heap
> 
> This seems to imply making --disable-jemalloc obsolete, which is why I
> am raising the legal issue under discussion.

The GPL-compatibility problem only arises if we put distributors in a
position where they must modify and distribute the MSCRT. It is not
envisaged that such modification would be _required_.

bsmedberg just told me:

"The original proposal I posted was fairly clear that we can't require a
modified MSCRT for no other reason than it would require people to buy
MSVC professional. So as far as I know there's no issue."

Does that solve the problem?

Gerv
Benjamin Smedberg | 7 Jul 17:00 2008
Picon

Re: Using new jemalloc features in our code

Sergey Yanovich wrote:

> It is right now (with --disable-jemalloc). However, Benjamin wrote in 
> the proposal at the root of this thread in m.d.platform:
> 
>> My proposed solution to this problem is as follows:
>>
>> * Always build jemalloc. Mozilla code should not use malloc()/free(), 
>> but mozilla-specific symbol names such as NS_Alloc() or JE_malloc()
>>
>> * where possible, hook jemalloc into the CRT so that it allocates all 
>> malloc()ed memory and there is a unified heap
> 
> This seems to imply making --disable-jemalloc obsolete, which is why I 
> am raising the legal issue under discussion.

I think you misunderstood the proposal. It requires that we always build 
jemalloc. It does *not* require that we always build jemalloc *into the 
CRT*. For those without MSVC professional, or who are bound by the GPL, 
jemalloc would be a mozilla library, e.g. libmozjemalloc.so or somesuch.

--BDS
Jean-Marc Desperrier | 7 Jul 17:08 2008

Re: Using new jemalloc features in our code

Benjamin Smedberg wrote:
>> [...]
>
> I think you misunderstood the proposal. It requires that we always build
> jemalloc. It does *not* require that we always build jemalloc *into the
> CRT*. For those without MSVC professional, or who are bound by the GPL,
> jemalloc would be a mozilla library, e.g. libmozjemalloc.so or somesuch.

And what about enabling those people to use the Wine CRT source ?
Do you see a problem that I miss that makes it difficult ?
Also do you see a technical reason that will make the MSFT source the 
preferred default choice, even after the Wine source is usable ?

Redirecting this to dev.platform
Sergey Yanovich | 7 Jul 18:43 2008
Picon

Re: Using new jemalloc features in our code

Gervase Markham wrote:
> Sergey Yanovich wrote:
>> It is right now (with --disable-jemalloc). However, Benjamin wrote in
>> the proposal at the root of this thread in m.d.platform:
>>
>>> My proposed solution to this problem is as follows:
>>>
>>> * Always build jemalloc. Mozilla code should not use malloc()/free(),
>>> but mozilla-specific symbol names such as NS_Alloc() or JE_malloc()
>>>
>>> * where possible, hook jemalloc into the CRT so that it allocates all
>>> malloc()ed memory and there is a unified heap
>> This seems to imply making --disable-jemalloc obsolete, which is why I
>> am raising the legal issue under discussion.
> 
> The GPL-compatibility problem only arises if we put distributors in a
> position where they must modify and distribute the MSCRT. It is not
> envisaged that such modification would be _required_.
> 
> bsmedberg just told me:
> 
> "The original proposal I posted was fairly clear that we can't require a
> modified MSCRT for no other reason than it would require people to buy
> MSVC professional. So as far as I know there's no issue."
> 
> Does that solve the problem?

Yes, sure. The latest comment by bsmedberg is clear and unambiguous.

However, let's don't pretend the original proposal was equally so. If 
(Continue reading)

Benjamin Smedberg | 7 Jul 20:07 2008
Picon

Re: Using new jemalloc features in our code

Sergey Yanovich wrote:

> However, let's don't pretend the original proposal was equally so. If 
> all Mozilla code uses NS_Alloc/Free, this and system malloc/free 
> constitute *at least* two allocator/deallocator pair. To avoid crashes 
> caused by wrong deallocator, I see to fast track solutions:
> 
> 1) carefully match every alloc/dealloc call pairs and equally tests 
> versions with both patched CRT and double heap.
> 
> 2) drop support for the non-patched version.
> 
> Everyone would agree that #2 is times easier, if not the only doable 
> solution. I am still having doubts #1 is feasible. All major developers 
> work with patched CRT. After certain period of time, hard-to-detect 

* This discussion is off-topic for mozilla.legal.
* Most of our hackers use the express version of MSVC and therefore do not 
use the patched CRT. Claiming "All major developers..." is just nonsense.

--BDS
johnsonlau | 13 Jul 12:55 2008
Picon

What work should be done on distributing to make my application working only in MPL?

I know MPL gives me a choice on tri-licenses.
But I don't understand whether the choice is covering on codes only
intruduced with a GPL license,
or all the codes to be intruduced as a GPL licensed product.

If I want my application to be distributed only in MPL, not GPL nor
LGPL,
and I ensure that my work doesn't envolve any GPL / LGPL codes,
how do I include licensing information in my product?
Can I just simply remove "Alternatively, ..." in section "EXHIBIT A"?

Thanks.
Frank Hecker | 13 Jul 13:09 2008

Re: What work should be done on distributing to make my application working only in MPL?

johnsonlau wrote:
> If I want my application to be distributed only in MPL, not GPL nor
> LGPL,
> and I ensure that my work doesn't envolve any GPL / LGPL codes,
> how do I include licensing information in my product?
> Can I just simply remove "Alternatively, ..." in section "EXHIBIT A"?

Yes. As Section 13 of the MPL states, "Initial Developer *may* designate 
portions of the Covered Code as 'Multiple-Licensed'." (emphasis added). 
Using multiple licensing is an option, not a mandatory practice. The 
example in Exhibit A shows how to indicate the use of multiple 
licensing, if you want to use it. If you don't want to use multiple 
licensing then you can simply leave off the "Alternatively, ..." 
paragraph when putting the MPL license notice in your own files.

Frank

--

-- 
Frank Hecker
hecker <at> mozillafoundation.org

Gmane