Bug 414946 fixes jemalloc on mac, but needs to include code copied from an apple header, which uses the Apple Public Source License (http://www.opensource.apple.com/license/apsl/). I can't find another time we use the APSL (existing Apple entries in about:license are the more straightforward BSD style), so I've done the legwork below. The APSL is approved by the OSI (see http://www.opensource.org/licenses/alphabetical), so it's proper open source, and it seems we can use it. A quick summary of the license: Section 1: definitions Section 2: The important bit, our redistribution rights and responsibilities. See below. Section 3: We grant rights to other parties on the modified code. Not important, since our modification comes to about 25 characters. Section 4: we can use the apple code in a larger work Section 5: Apple doesn't grant us patent licenses. Section 6: We can add additional terms; we can't pretend Apple requires them. Section 7: We can use later version of the APSL. Section 8: No warrantee from apple. Section 9: Ass covering, limiting liability. section 10: Apple doesn't grant us use of their trademarks. Section 11: We own our modification, apple owns theirs. Section 12: The agreement terminates if we break it, OR IF WE SUE APPLE FOR PATENT INFRINGEMENT (unless they started it), or if courts make it illegal. Section 13: This doesn't create a partnership with apple; this doesn't stop apple copying our product; Apple don't waive this just because they dont enforce it; Disputes are in Northern District in California; US and California law applies. Section 2 has all the important bits: Section 2.1: Unmodified code; we include modified code. Section 2.2: Modified code: - (a) we must satisfy Section 2.1: - 2.1 (a, DONE) We need to keep apples legal notices in the code. - 2.1 (b, TODO) We must include a copy of the APSL - (b, DONE) - Must copy the notice from Exhibit A of the APSL into our modifications. This is already done, as the code we copy includes Exhibit A. - We need to add "prominent notices stating that You changed the files and the date of any change". I'm about to add this to bug 414946. - (c, DONE) We must make our changes available Can someone confirm that we can use this license, especially in the presence of Section 12, which says we can't sue Apple for patent infringement, and Section 13, which says any lawsuit happens in Northern District in California? (Both of these are of course insanely unlikely, but lawyers worry, and I wouldn't like to worry them).

The APSL is incompatible with the GPL: http://www.gnu.org/philosophy/apsl.html so is not suitable :-( If Apple tends to use BSD, is there a newer version of the file you copied from under the BSD licence? Ideas: Could this code be reimplemented? Or given that it's structs, can we claim it's an expression of fact rather than something copyrightable and creative? Is it shipped with their SDKs, so we could make it a build dependency? Luis: I confess the System Library Exception of the GPL confuses me a bit. How can we use that here, if at all? Gerv

A few options, in order of niceness: - We could ask chromium, as they've done the same thing (http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/base/process_util_mac.mm&q=_malloc_zone_t&exact_package=chromium&sa=N&cd=3&ct=rc). Perhaps they dont have the same GPL worries as us though. - We could redo the structs to just use different members of the same size, without docs, comments, etc. Basically just: struct sl_zone_struct { void* m1; // member 1, etc void* m2; size_t (*m3)(); void* (*m4)(); void* (*m5)(); void* (*m6)(); void* (*m7)(); void* (*m8)(); void* (*m9)(); const chat* m10; unsigned (*m11)(); void (*m12); void* m13; unsigned m14; void* (*m15)(); void* (*m16)(); } - We only use the size of the struct in our code, we could calculate it's size on our platforms (probably 10.5 and 10.6 on each of PPC, i386 and x86-64, possibly leave out PPC).

Paul: pinching code from that Chromium file would be absolutely fine, as it's BSD-licensed. But if you think they have just copied and pasted from the APSL file, that would be bad. Is that what you suspect they have done, or have they independently derived the information in some way? Would all options, including your initial proposal, require updating the code if the structure changed again? Gerv

(In reply to comment #3) > Paul: pinching code from that Chromium file would be absolutely fine, as it's > BSD-licensed. But if you think they have just copied and pasted from the APSL > file, that would be bad. Is that what you suspect they have done, or have they > independently derived the information in some way? They have certainly taken the code directly from the APSL code, and put it in a BSD file. The comment before the struct mentions it, and they use the same member names in the struct, and the same parameter names in the signatures within the function pointers. I'm emailing the chromium-dev list now to ask. > Would all options, including your initial proposal, require updating the code > if the structure changed again? Yes, they all would, including the initial proposal. The third proposal (use only the size) would also require changes if the architecture changed, and it would be a difficult and nasty bug to track down too.

(In reply to comment #4) > They have certainly taken the code directly from the APSL code, and put it in a > BSD file. The comment before the struct mentions it, and they use the same > member names in the struct, and the same parameter names in the signatures > within the function pointers. I'm emailing the chromium-dev list now to ask. Let me rephrase that: the code _appears_ to have been taken from the APSL code, and I'll ask them to confirm its source.

chromium-dev thread: http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/62db4de8a7edd011#

Hi Paul, Unless you get a better-licensed source for the code from the Chromium guys, can you please use your solution 2, struct sl_zone_struct? Thanks, Gerv

(In reply to comment #7) > Unless you get a better-licensed source for the code from the Chromium guys, > can you please use your solution 2, struct sl_zone_struct? Agreed, that's the best plan.

(In reply to comment #2) > struct sl_zone_struct > { > void* m1; // member 1, etc > void* m2; > size_t (*m3)(); > void* (*m4)(); > void* (*m5)(); > void* (*m6)(); > void* (*m7)(); > void* (*m8)(); > void* (*m9)(); > const chat* m10; > unsigned (*m11)(); > void (*m12); > > void* m13; > unsigned m14; > void* (*m15)(); > void* (*m16)(); > } My mistake: we need the member names or else the code this supports becomes unreadable. How important is that? We don't need the absolute correct types though, we can make do with just void*, void(*)() and unsigned. If not... Really, there is only one struct that can be used to support the API or ABI, so that certainly leans towards a statement of facts, but I'm reaching the end of my understanding of the legalities there. In the Chromium thread, they've referred it to DannyB, who is the Google open source lawyer. We can wait to see what they're doing with it, but the time frame for that is really quite bad to get this into Firefox 4.0.

(In reply to comment #9) > My mistake: we need the member names or else the code this supports becomes > unreadable. How important is that? We don't need the absolute correct types > though, we can make do with just void*, void(*)() and unsigned. Actually, we don't _need_ the member names, the code would just be ugly without. This could be remedied by detailed comments. So if we can't use the member names, I guess this is the best solution.

This is a cut-down version of the patch for bug 414946, which shows only the code related to the structs. The structs are in osx_zone_types.h, and the rest shows how the code is used. The structs are like the apple structs in that they are the same size and have the same number of members, with each member being the same size, but it shares no code, not even the types or names of its members. Instead, it's just a struct which is the same size as the apple structs. So even without using the apple structs, we're able to have pretty clean code for this. Assuming approval, this is what I intend to use for bug 414946.

FYI, Google fixed their code to properly abide by the APSL, so we don't have a BSD source for the Apple code.

Comment on attachment 484659 [details] [diff] [review] Relevant parts of proposed solution Looks good to me. Thanks for taking the time to do this right :-) Gerv

Paul: did you check this in? If so, please can you put a changeset URL here? Thanks, Gerv

(In reply to comment #14) > Paul: did you check this in? If so, please can you put a changeset URL here? No, I closed it because there's no code here, and it's all being handled in bug 414946. Perhaps I did that wrong; what should I have done?

Oh, right. I guess that's fine :-) Gerv

Gerv, would it be acceptable to link to the relevant Apple source code from our source?

:jlebar: you mean, would it be legal to put a URL in our comments, to allow people to read the other code for greater enlightenment? Of course. One might want to add a clarificatory note that (for the avoidance of doubt) our code was not copied from theirs. Gerv