79312 - need permission to check libart into the tree

Status: RESOLVED FIXED

(mozilla.org :: Miscellaneous, task)

Description

[Bradley Baetz]

Alex Fritze's SVG code uses libart (see URL). This code is licensed under the
LGPL, and is being used for the rendering/compositing/path stuff.

Alex has done a windows build, and I have a unix one. To fit it into the mozilla
build system, I've replaced the automake makefiles with a Makefile.in, and the
configure-generated config.h (which just did endianness tests) has been replaced
with defines based on prcpucfg.h. I've also deleted the configure stuff, and
added a README.mozilla file outlining the changes I've made.

The unix build is linked dynamically, and Alex says that the windows build is
also done dynamically.

Since mac and windows aren't likely to have libart installed, and the version on
my redhat7.1 machine isn't recent enough, this needs to be checked into the
tree.

Also, there are some known bugs in libart that we are likely to have to fix, so
the actual source may end up being modified, and these patches would then
presumably have to be LGPL'd.

As well as a COPYING file containing the LGPL (marked as version 2, June 1991),
the CVS source (in the gnome CVS repository) comes with a README.CVS file which
contains the following:

"Welcome to the libart source tree!

This code is being developed in a "free software for sale"
model. Thus, it's available under a free software license (LGPL for
this module), but I'm also requesting that for all changes to the code
the copyright gets assigned back to me.

So if you want to contribute, please do, but contact me about getting
the copyright assigned. Otherwise, I will have to back your changes
out.

Thanks!

Raph Levien <[e-mail]>"

The unix builds already link to gtk, and theres a copy of glib checked into the
tree already.

Frank Hecker volunteered (on npm.svg) to "raise the issue with mozilla.org
staff"

Assuming that there is no problem, and that I get the permission, which,
according to the CVS contributor form I signed, I need in writing in order to
check in non-MPL/NPL code (for both the initial checkin and for any changes we
make to libart), I'll check this in on behalf of Alex, who doesn't have a CVS
account. (once we follow the usual process to check in the other SVG code along
with it)

So can we please get a lawyer to look at this?

Comment 1

[Bradley Baetz]

Adding the libart author to the cc.

Comment 2

[Frank Hecker]

Accepting bug (may reassign later if need be).

Comment 3

[Frank Hecker]

First, a disclaimer: I am not a lawyer, and my comments are not intended as 
legal advice. This is really not a legal question per se, but rather a policy 
issue for mozilla.org re checking source for an LGPLed library into the 
mozilla.org source tree. Here is the situation as I understand it from my 
correspondence with Alex Fritze and the previous comments in the bug:

The Mozilla SVG code (in progress) calls libart code as a dynamically linked 
library.  The libart shared library is licensed under the LGPL. The libart code 
does not call any Mozilla code or other NPLed or MPLed code.  The libart library 
is not already installed on systems, so it must be distributed and installed 
with Mozilla or distributed and installed separately.  Also, the version used by 
Mozilla SVG may have Mozilla-specific bug fixes.  So the question at hand is: Is 
it OK to check a copy of the libart source code into the Mozilla source tree, so 
that the libart shared library can be built as part of building SVG-enabled 
Mozilla and distributed as part of SVG-enabled Mozilla binaries.

My opinion: If mozilla.org were to allow LGPLed code into the Mozilla source 
tree, this is probably the most straightforward case: The code is in the form of 
a self-contained dynamically linked shared libary. In theory distributing such 
an LGPLed library with a Mozilla binary distribution should not cause license 
compatibility issues. However there may be other implications of having the 
LGPLed libart code as part of the mozilla.org tree; for example, it could 
increase the complexity of the license-related notifications that Mozilla 
distributors are required to do.

Given the circumstances, it's not possible for me to give unilateral approval to 
checking this code in.  I'm copying Mitchell Baker on this, and soliciting her 
comments on this topic.  Mitchell, note that I'm not proposing that we adopt a 
general policy of allowing LGPL-only code in the tree; I'm simply asking for 
your opinion on allowing code for this particular LGPLed library in the tree.

If we don't want to do this (for whatever reason), then I see two main 
alternatives: 1) Require Mozilla distributors to independently obtain and build 
a copy of the libart library, and distribute that libart library separately from 
Mozilla itself; or 2) Try to get permission to check the libart code into the 
mozilla.org tree under an MPL/LGPL dual license.  A third alternative is of 
course not to use the libart libart, but that's not much of an option IMO.

Comment 4

[Alex Fritze]

Attachment: mozilla/modules/libart zip

Comment 5

[Alex Fritze]

Attachment: libart makefile diffs

Comment 6

[Steve]

adding cc

Comment 7

[Frank Hecker]

We discussed the libart issue in the last meeting of mozilla.org staff; here are 
my conclusions based on those discussions:

A number of people in the meeting expressed concern about checking LGPLed code 
into the main Mozilla tree. There are now several licenses used for Mozilla code 
(NPL, MPL, NPL/GPL, MPL/GPL, some BSD-style licenses, and perhaps others) and 
there were several comments to the effect that mozilla.org should be trying to 
reduce the number of licenses used, not expanding it. There was also concern 
that the LGPL has license requirements that go well beyond those of the 
BSD-style licenses already used for some "foreign" code in the tree, and that 
this would increase the burden on Mozilla distributors in terms of keeping track 
of licenses and ensuring their compliance with them.

Thus IMO it will be difficult to get mozilla.org approval for the original plan 
of just checking the libart code in as usual, and I suggest consideration of 
other options. Here are two:

The first possibility, which was discussed in the staff meeting, is to put the 
libart code somewhere other than the main Mozilla CVS tree. For example, 
mozilla.org could designate a special "third-party" area for code under other 
licenses; this area could be in the form of a new top-level directory in the 
current Mozilla CVS repository, or even in a separate CVS repository. The build 
process would get the libart code from this "third-party" area if SVG support is 
enabled as part of the build. Since SVG support would not be turned on by 
default in the standard build process, this means that Mozilla distributors 
would not be including the LGPLed code unless they explicitly meant to. (Some 
people referred to this as an "opt-in" process: you have to explicitly ask for 
code under different licenses to be included.)

The second possibility is to attempt to secure permission from Raph Levien to 
put a copy of the libart source code into the main Mozilla tree with all the 
license notices changed to use the MPL (or some other "approved" license). (As I 
understand it, Raph Levien is the sole copyright holder for the libart code, 
hence the only person whose permission would be needed for this.) The original 
libart code would still be available under the LGPL from the standard place, but 
the copy included with Mozilla would be under the MPL.

(This would not be exactly the same as a dual license as current used in the 
Mozilla code, but the practical effects would be the same: Someone wanting to 
use libart code under LGPL terms would pull the code from the current location, 
while someone wanting to use libart under MPL terms would pull the code from the 
Mozilla tree. Their rights as licensees would be somewhat different if they used 
the MPL and not the LGPL.)

Putting the libart code into a separate "third-party" area would require no 
changes to the current libart, but would need formal approval from mozilla.org; 
someone would also need to create the separate directory or repository. (Someone 
in the meeting proposed storing the code on an independent CVS repository 
entirely out of the mozilla.org domain; however for simplicity I suggest trying 
to get approval for having the area just be a separate top-level directory in 
the current mozilla.org repository.)

Checking in a copy of libart relicensed under the MPL would require no 
mozilla.org approval, at least relating to licensing. (You'd still need to go 
through the normal code review processes, of course.) However this would require 
special permission from Raph Levien.

Those are my current thoughts; let me know how you'd like to proceed. In 
particular, if you want to try the "third-party" area idea I'll formally propose 
that to mozilla.org. 

Comment 8

[Henri Sivonen (:hsivonen)]

Are these assumptions correct?
* Forking libart would be bad.
* After an initial phase, fixes to libart required for Mozilla would be 
  infrequent.
* Changes to libart required for Mozilla would be of general interest and 
  acceptable for inclusion in the Gnome version on libart.

If the above assumpions are correct, could "third-party" CVS repository just be
cvs.gnome.org? That is, changes to libart would go directly to the main libart
source. Libart could be build separately from Mozilla and mozilla.org could make
binaries of libart available as separate downloadables.

Comment 9

[Bradley Baetz]

Henri - thats basically what I've just (a couple of hours ago) suggested to
Alex.

Frank - would mozilla.org have problems with hosting compiled libart
binaries/sources for the various platforms?

Comment 10

[Frank Hecker]

> Frank - would mozilla.org have problems with hosting compiled libart
> binaries/sources for the various platforms?

I think it's worth proposing. One idea would be to handle libart like people 
have proposed handling NSPR and other components: have them be built and 
released independently of Mozilla and then linked into Mozilla as binaries. 
(IIRC this never happened for NSPR, but mainly because Mozilla uses a separate 
"client branch" version of Mozilla. In the case of libart I agree that it would 
be better to have any Mozilla-specific changes folded back into the "official" 
version.)

Thus far there seem to be more people in favor of keeping libart outside the 
main Mozilla tree (as opposed to relicensing the source and putting it in the 
main Mozilla tree). I'll go back to mozilla.org with this idea, and see if we 
can get a consensus on what sort of "third party" area should be set up.

Comment 11

[Daniel (Leaf) Nunes]

there was a period of time where nspr was assumed to be installed on the system 
in order to build the unix version; this got a lot of complaints, and was 
eventually replaced with the pull-by-tag system we have now, because of the 
number of changes that go into the "stable" nspr product, eliciting numerous 
point releases to fix mozilla-specific nspr bugs.

Just because we include the source tree for libart on the mozilla.org cvs 
repository (say, in /cvsroot/third-party/libart) does not mean we are forking 
the tree... cvs has an "import" function which lets one project take a source 
drop as a release from another distribution. We can take periodic drops, and 
make the /cvsroot/third-party/libart partition in despot restricted, and force 
changes to go back to Raph when fixes are required. This slows things up a 
little, but keeps all development happening in one place.

If libart is going to be as unchangeing as suggested, then it makes more sense 
to use binary drops in some form. Either by requiring distributors to get or 
build binaries of libart to link against and ship with their distribution, or by 
 hosting binaries on ftp.mozilla.org and finagling the build system(s) into 
fetching them, unpacking them, and incorporating their contents into the build 
if one "opts-in" at build configure time (making it easier for distributors to 
distribute).

Comment 12

[Daniel (Leaf) Nunes]

Note, also, that even if we cvs import the libart code into 
/cvsroot/third-party/libart, the pulling and building of this source would still 
be opt-in.

Comment 13

[Bradley Baetz]

According to files in the cvs tree (see my initial comment), raph wants stuff
which is checked into the gnome cvs to have copyright assigned to him. This may,
I suspect, cause some problems in relying solely on the gnome tree.

However, I want to get these patches in ASAP, so until we actually end up
changing libart, can we just add configure.in foo (for unix), and require an up
to date version of libart to be installed? (This would require the tinderbox
which builds svg to be updated, but thats going to have to be done anyway)

This can then be revisited when those changes are required, which will probably
not be for a while.

Since all the code is in #ifdef MOZ_SVG, it can be checked in without problems,
as soon as I can find a mac person to verify that it builds (It needs a mac
person to make it run though). 600 odd Kb of diffs is too much to try to
coordinate things, especially since interdiff doesn't seem to like new files.
Thats really bug 80142 though.

Comment 14

[Alex Fritze]

To get libart to work with the latest code you need to add the lines 
  #include "art_bpath.h"
  #include "art_vpath_bpath.h"
to mozilla/modules/libart_lgpl/libart-incs.h and add art_bpath.h and 
art_vpath_bpath.h to the exports in the makefile.

Comment 15

[Alex Fritze]

Frank - what is the latest thinking on how to handle libart? Has a consensus 
been reached at mozilla.org about setting up some kind of third party area? It 
would be nice to get this sorted out before we start checking in any of the svg 
code. 
Personally I'd be in favour of cvs importing the libart source code into a 
third party area of the Mozilla cvs tree & communicating changes back to Raph. 
Is that still an option?

Comment 16

[James Turner]

A note for the curious, Mathieu Lacage and Raph Levin have produced some nice
documentation on libart; see http://www.gnome.org/~mathieu/libart/libart.html
for the info. The 'Introduction' page includes the statement 'Libart can also be
licensed under other licenses from XXX'; I don't know if this is a stock thing
or whether it indicates a readiness to dual-licence.

Comment 17

[Frank Hecker]

My apologies for the delay in commenting on this. I think we have an emerging 
consensus that the best way to handle libart and other code under "non-standard" 
licenses will be to create a new separate top-level directory in the existing 
Mozilla CVS repository; see bug 93480 for more information, and note that 
creating the directory itself will only be the first step to resolving this 
whole issue.

Marking this bug as now dependent on bug 93480.

Comment 18

[Bradley Baetz (:bbaetz)]

libart_lgpl has been checked in to mozilla/other-licenses/libart_lgpl/

a=brendan & other staff@m.o

This isn't yet part of the build scripts, even on teh svg branch, so even if you
do check it out, it won't do anything...