Closed
Bug 533671
Opened 16 years ago
Closed 16 years ago
Need to add js/ctypes/libffi/ and js/ctypes/libffi_msvc/ to about:license
Categories
(Core :: General, defect)
Core
General
Tracking
()
RESOLVED
FIXED
mozilla1.9.2
| Tracking | Status | |
|---|---|---|
| blocking2.0 | --- | alpha1+ |
| status1.9.2 | --- | beta5-fixed |
People
(Reporter: reed, Assigned: gerv)
References
Details
Attachments
(1 file)
|
3.44 KB,
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
I just discovered by way of bug 520704 that we had libffi in the tree without any license acknowledgement in about:license.
Looks like there's two different licenses that need to be added to about:license:
* http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/LICENSE
* http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi_msvc/LICENSE
The libffi one also mentions "See source files for details.", so should go through the code to make sure there's not some other license hiding somewhere.
Flags: blocking1.9.2?
| Reporter | ||
Comment 1•16 years ago
|
||
(In reply to comment #0)
> The libffi one also mentions "See source files for details.", so should go
> through the code to make sure there's not some other license hiding somewhere.
Yep, I already see at least one different license in a file.
Comment 2•16 years ago
|
||
Gerv: can you whip up a patch, here?
blocking2.0: ? → alpha1
Flags: blocking1.9.2? → blocking1.9.2+
Updated•16 years ago
|
Whiteboard: [needs patch]
Comment 3•16 years ago
|
||
Since libffi_msvc was forked from libffi in 2004, it should have a set of licenses that are a subset of those in libffi, with the exception of copyright dates being different. Does that qualify it for a separate entry in about:license?
I am assuming that we do not need to call out lists of original contributors and such, or lists of copyright years and holders, from each source file. For instance, a snippet from http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/ltcf-gcj.sh:
6 # Originally by Gordon Matzigkeit <gord@gnu.ai.mit.edu>, 1996
7 #
8 # Original GCJ support by:
9 # Alexandre Oliva <oliva@lsd.ic.unicamp.br>
Do we just list the license, with a blank ______ space for author and year? Same for BSD licenses?
From looking through libffi, the following files contain unique licenses. Most of libffi is BSD, with a smattering of GPLv2, GPLv3 (!) and public domain:
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/LICENSE
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/configure (?)
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/texinfo.tex
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/ltcf-gcj.sh
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/aclocal.m4
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/mkinstalldirs
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/src/dlmalloc.c
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/include/Makefile.in
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/install-sh
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/testsuite/lib/target-libpath.exp (GPLv3)
And libffi_msvc has the following:
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi_msvc/LICENSE
(same as libffi's LICENSE except for copyright years)
If someone can give a rough guideline for how this should be presented in about:config, I can attempt a patch, but Gerv may be far more efficient at this stuff. ;)
| Assignee | ||
Comment 4•16 years ago
|
||
Do we ship any of the following files, or code derived from them?
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/texinfo.tex
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/install-sh
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/testsuite/lib/target-libpath.exp
?
If not, then all is well. I have a patch ready to go.
Gerv
Comment 5•16 years ago
|
||
Not in our binaries, no. They are used during the libffi build process, but don't contain code that ends up in a binary that we ship.
Is the GPLv3 bit not a problem in that case? I was going to go email the maintainer and ask him if he can relicense it, but if all's well, then great. ;)
| Assignee | ||
Comment 6•16 years ago
|
||
Hmm. "Used during the build process" sounds like "I have to do work to figure out if our binaries are a derivative work of that code or not". :-/
It would avoid a lot of doubt and effort, and make the licensing of libffi much clearer and more consistent, if he were to relicense. So emailing him is still a good idea :-) I am happy to do it if you like.
Gerv
Comment 7•16 years ago
|
||
Well, let's be more specific:
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/texinfo.tex - certainly not relevant to the built binary. (GPLv2 license .)
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/testsuite/lib/target-libpath.exp - likewise. (GPLv3 license.)
What's the issue with texinfo.tex, btw? It looks like GPLv2 to me.
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/install-sh - this script file is required to exist in order for libffi to build, but it is not actually executed in our configuration. This is BSD or something similar, no? Isn't that OK?
If I'm going to ask him to relicense, what should I say? Obviously the GPLv3 bits aren't great, but should I be asking him to relicense those other bits too?
| Assignee | ||
Comment 8•16 years ago
|
||
(In reply to comment #7)
> http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/texinfo.tex -
> certainly not relevant to the built binary. (GPLv2 license .)
I thought that was the case - just wanted to check.
> http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/testsuite/lib/target-libpath.exp
> - likewise. (GPLv3 license.)
So it's _not_ used during the build process?
> What's the issue with texinfo.tex, btw? It looks like GPLv2 to me.
I don't quite understand your question. Mozilla can't use code which is GPL-only. The GPL alone is incompatible with the MPL.
> http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/install-sh -
> this script file is required to exist in order for libffi to build, but it is
> not actually executed in our configuration. This is BSD or something similar,
> no? Isn't that OK?
It's OK; I wanted to know whether I needed to add the text to about:licence. If we aren't distributing it, then we don't.
> If I'm going to ask him to relicense, what should I say? Obviously the GPLv3
> bits aren't great, but should I be asking him to relicense those other bits
> too?
If the code actually is used in our build process, and isn't part of the test suite (as the directory name seems to suggest), then something like:
Dear Mr. X,
My name's Dan Witte; I work for the Mozilla project. We've recently started using the libffi library in our JavaScript engine (used in Firefox, Thunderbird and our other software). Most of libffi is under a BSD-like licence, but one file you contributed is GPLv3. Mozilla projects can't use GPL-only code because it's incompatible with the Mozilla Public License (MPL), one of the licences we use.
For the avoidance of doubt, would you consider relicensing that file to be consistent with the rest of the license of libffi?
Thank you for your time,
Dan
| Assignee | ||
Comment 9•16 years ago
|
||
Here is a patch.
Gerv
Assignee: nobody → gerv
Status: NEW → ASSIGNED
Comment 10•16 years ago
|
||
(In reply to comment #8)
> > http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/testsuite/lib/target-libpath.exp
> > - likewise. (GPLv3 license.)
>
> So it's _not_ used during the build process?
Correct.
> > What's the issue with texinfo.tex, btw? It looks like GPLv2 to me.
>
> I don't quite understand your question. Mozilla can't use code which is
> GPL-only. The GPL alone is incompatible with the MPL.
Oh. I did not understand this. There is a bunch more GPLv2 code, other than the files you mentioned above, in libffi. However, it's all configure and install scripts, which doesn't end up in the binary. I don't know if that constitutes a 'derived work' or not.
> If the code actually is used in our build process, and isn't part of the test
> suite (as the directory name seems to suggest), then something like:
You took me a bit literally when I asked what to write, but OK. ;) I guess the most relevant point is to ask for relicensing of the configure and install scripts, since we actually execute them. The GPLv3 testsuite bits are far less relevant, but I'll point them out, since it's somewhat conspicuous.
Thanks Gerv!
| Assignee | ||
Comment 11•16 years ago
|
||
Hang on :-)
Configure and install scripts usually have an exception attached E.g.
http://mxr.mozilla.org/mozilla-central/source/js/ctypes/libffi/ltcf-gcj.sh
says:
25 # As a special exception to the GNU General Public License, if you
26 # distribute this file as part of a program that contains a
27 # configuration script generated by Autoconf, you may include it under
28 # the same distribution terms that you use for the rest of that program.
So if that exception is present, we don't have a problem.
If you are going to ask for files to be relicensed, please run a list past me first :-)
Gerv
Comment 12•16 years ago
|
||
Will do!
Updated•16 years ago
|
Whiteboard: [needs patch]
Comment 13•16 years ago
|
||
Who can review this patch? This is becoming one of the last release blockers!
Comment 14•16 years ago
|
||
r=me if it counts!
Updated•16 years ago
|
Attachment #417823 -
Flags: review+
| Assignee | ||
Comment 15•16 years ago
|
||
I'm waiting for the tree to be green...
Gerv
Updated•16 years ago
|
Keywords: checkin-needed
Whiteboard: [needs 1.9.2 landing]
| Assignee | ||
Comment 16•16 years ago
|
||
On the case.
Gerv
| Assignee | ||
Comment 17•16 years ago
|
||
Fixed on trunk:
http://hg.mozilla.org/mozilla-central/rev/9cadbf318098
and branch:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c9fd0a41f44f
Gerv
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
status1.9.2:
--- → beta5-fixed
Resolution: --- → FIXED
| Reporter | ||
Updated•16 years ago
|
Keywords: checkin-needed
Whiteboard: [needs 1.9.2 landing]
You need to log in
before you can comment on or make changes to this bug.
Description
•