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 <raph@acm.org>" 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?

Adding the libart author to the cc.

Accepting bug (may reassign later if need be).

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.

adding cc

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.

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.

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?

> 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.

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).

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.

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.

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.

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?

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.

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.

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...