Closed Bug 93480 Opened 23 years ago Closed 23 years ago

Create new top-level directory in CVS for code/data under other licenses

Categories

(mozilla.org :: Miscellaneous, task)

Product:
mozilla.org
Component:
Miscellaneous
Platform:
x86
Windows 98
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: hecker, Assigned: endico)

References

(
URL
)

Details

This is a request to create a new directory under the mozilla.org CVSROOT 
directory in order to contain Mozilla-related code and data that is under 
licenses different than those normally used for Mozilla code and data 
distributed by mozilla.org. I'm assigning it to Dawn, but, Dawn, feel free to 
reassign to someone else as necessary.

(Also note that full implementation of this scheme would also require changes to 
be made to the instructions and scripts for building Mozilla; I'll let someone 
else file those bugs, as I don't know all the places where changes would be 
required. Presumably lxr.mozilla.org would have to be changed as well to allow 
source browsing of this separate directory.)

This new directory would be in the same CVS repository as the existing Mozilla 
tree, and would be parallel to the current top-level "mozilla" directory. The 
name of the directory is still up for grabs, and should be discussed a bit in 
the bug. One proposal is to give it a name like "other", "mozilla-other", or 
"othermozilla" in order to distinguish its content from content in the main 
Mozilla source tree.

Some more background and thoughts on this issue:

Recently people have on separate occasions proposed including in the Mozilla 
source tree code and data under licenses that are different from those normally 
used for Mozilla material distributed by mozilla.org. In particular, it's been 
proposed that Mozilla distribute mathematical fonts (for use by MathML) under 
special font licenses, and that a copy of the LGPLed libart library (for use by 
SVG) be checked into the Mozilla CVS repository.

In at least a couple of instances (e.g., the JPEG library) code under different 
licenses has already been checked into the main Mozilla tree. However there is 
growing consensus that material under different licenses should not be part of 
the main Mozilla source tree, especially when those licenses have notification 
requirements and other conditions that go beyond those in the MPL and NPL. (This 
would be true for both the mathematical font licenses and for the libart 
license.) The feel is that licensees who check out the main Mozilla source 
directory should have a reasonable expectation that the code and data in that 
directory should be under a single licensing scheme, or at least under a very 
restricted set of licensing schemes (basically MPL, NPL, MPL/GPL, or NPL/GPL).

If code and data under different licenses should not be in the main Mozilla 
tree, where should it be? Suggestions have included having somebody else (other 
than mozilla.org) host the code and data, putting it in a new and different 
mozilla.org CVS repository, and putting it into a different top-level directory 
in the current mozilla.org CVS repository. At the mozilla.org meeting on July 27 
in San Diego CA (at the O'Reilly Open Source Conference) there seemed to be 
consensus on putting differently-licensed code and data in a separate top-level 
directory in the current repository. This would remove the need to establish a 
separate repository. It would require that developers do a second checkout 
operation to get the additional code and data, but this was deemed an acceptable 
trade-off.

No agreement was reached at the meeting on a name for this separate top-level 
directory. Proposals included "third-party", "different-license", etc. My 
personal preference is for a short name like "other"; however, to emphasize that 
this directory is Mozilla-related, we could also use a name like "mozilla-other" 
or "othermozilla". (Another possibility is to call the directory something like 
"nonmpl" or "mozilla-nonmpl" to emphasize the difference in licensing terms; 
this implies that all code in the main tree is under the MPL, which is not 
strictly speaking true, but it does make for a simpler name.)

As a final note, I propose that this separate directory be internally organized 
in a manner similar to that of the main Mozilla tree. In other words, if a 
particular group of files would have gone into, say, the directory 
mozilla/extensions/foo if they were under the standard Mozilla licensing scheme, 
then they would go into other/extensions/foo if they were under a different 
license. This would help people figure out where the files went, would allow 
people to create a single source directory by overlaying the "other" directory 
on top of the "mozilla" directory, and might simplify making the needed changes 
to build scripts.
Blocks: 79312
In your proposed organization, this means that the licenses could change at an
arbitrary directory depth, right?  Seems like this could be confusing.
Organization of files within the "other" directory tree is really a judgement
call; I don't feel strongly either way. I'm definitely *not* in favor of having
arbitrary files in the Mozilla source tree have different licenses. The idea is
rather that there are specific groups of source files (like the libart library
source) that might be under a different license.

...And having written that, I realize that it arguably would be better to have
such groups of files just put in subdirectories directly under the top-level
"other" directory, one group per subdirectory. So, for example, there might be a
directory "other/libart", "other/mtextra", and so on. Given that having files
under a different license is supposed to be an exceptional things, we shouldn't
have too many such subdirectories.

Bottom line: Scratch my suggestion about having the structure of the "other"
directory mirror the structure of the existing "mozilla" directory.
personally i like the 'nonmpl' suggestion.  other might be nice but you're loading it w/ a meaning that can not be easily discerned.
OK, I think "nonmpl" is the favored suggestion so far. Another possibility would
be to call it "mozilla-nonmpl", to emphasize that the code is intended as part
of Mozilla. Any thoughts on this, pro or con?

Any takers for "non-mpl", with added hyphen for readability?
I personally don't care greatly whether it's "non-mpl" or "nonmpl". However I
agree that "non-mpl" is slightly more readable.

So now that's settled, how about it?  :)

this has my vote (except it won't allow me to vote on it)
This would make merging the svg branch easier (libart is LGPL), since we could
modify the build scripts to pull from this directory. We also wouldn't have to
wait for the mac changes to be integrated into the official sources.
I brought this up with Brendan and he thinks that 'non-mpl' is too specific.
In the future, our concept of 'differently licenced' may change and 'non-mpl'
may not describe that. Also, in the present, our favored license is the tri-
license. Does that mean that mpl-only is 'different' and that such code
belongs in the new directory? If so, then non-mpl is wrong. 

Remind me why differently licenced stuff has to be a sibling of
cvsroot/mozilla and not a child?

It just occured to me that this could piss off lxr users. In order to make
lxr index everything pulled in a mozilla build, the root needs to be the
parent of the mozilla directory. Currently used urls like
lxr.mozilla.org/mozilla/source/client.mk will need to change to something like
lxr.mozilla.org/mozilla/source/mozilla/client.mk
This would break everyone's collections of lxr bookmarks, links in web
pages, urls in code, and books. doublplusungood.

How bad is it to not include the 'differently licensed' code in normal
lxr searches? Maybe not so bad since stuff in that directory will be
standalone libraries, right? LXR doesn't index all libraries used by
mozilla anyway. (e.g. gtk) If its not important then i could just put that 
stuff in its own lxr tree and everything will be fine.

I think for similar reasons this would also make building mozilla and making
mozilla tarballs awkward.

Someone pulling the tree in their home directory will likely assume that
everything will go under the mozilla directory and they'll be surprised to
find another directory mysteriously show up (in their home directory?) 
as a sibling of mozilla. To minimize people's surprise it would be nice if
the 'differently licenced' directory began with 'mozilla'. e.g. 
'mozilla-funny-license'.

I guess i prefer 'mozilla-third-party'. 'mozilla' for the reason above,
and 'third-party' because people know what it means and I think that will be
a good description of the parentage of stuff that ends up there. Its not clear 
that this is differently licenced stuff but that shouldn't be too hard to
guess.
We could massage the build scripts which pull this stuff to do it under mozilla
(it won't be pulled by default, anyway), and we could have lxr index under a
separate subdirectory (similar to how the mozclassic stuff works).

Yes, this is yuck :)

What about mozilla/third-party/ with a README saying "these are under different
licenses"? These wouldn't be part of SeaMonkeyAll directly, but would be pulled
as appropriate depending on build options.
the problem is that if we want lxr to be useful then the main queries need to 
catch this stuff (and of course we really don't want to break old lxr urls).
 
Would it be sufficient to amke mozilla/<foo>/LICENSE specify license for that 
directory tree. mozilla/<foo> could be in seamonkey or it could be outside of 
seamonkey. lxr could be easily adapted to remind people of the license based on 
that location.

Build scripts could easily notify people whenever they pull directories whos 
LICENSE doesn't match the main license. and a bit of voodoo could be practiced 
to carp if a file has a license which doesn't match say 
mozilla/<foo>/LICENSES/<acceptable-license-headers>

we could also name tags FOO_NPL BAR_LGPL so that when people pull these special 
directories they're constantly reminded of the license it's under.
I don't pretend to have good suggestions for exactly how to resolve the LXR- and
build-related issues. However I did want to make some general comments.

First, Mitchell's position (which I agree with) is that in the ideal case people
getting Mozilla code "in the usual way" should get only code licensed under a
single standard Mozilla license. (Hopefully in the future that single standard
license will be the MPL/GPL/LGPL tri-license, or at worst we'll have at most two
licenses, i.e., the pair of MPL/GPL/LGPL and NPL/GPL/LGPL tri-licenses.) This
limits the potential confusion of licensees as to what rights they have in the
Mozilla code, and makes it easier for them to comply with license requirements.

If we have to have code under "non-standard" licenses (and I think this will be
unavoidable in some cases), then we want to clearly isolate that code from the
main body of Mozilla code. In particular, that means the following:

1. The standard Mozilla source tarball distributions should contain only code
under the standard license(s). Code under non-standard licenses should be under
a different tarball.

2. Someone checking out Mozilla code "in the usual way" (i.e., using standard
recommended commands or scripts, with no special options) should get only code
under the standard license(s), and should have to do a separate checkout
operation to get the code under non-standard licenses.

3. Ideally a Mozilla build done "in the usual way" (i.e., without any special
options) should not build features which incorporate code under a non-standard
license. (Thus, for example, SVG should not be built by default, since it
results in the LGPLed libart being incorporated into the resulting Mozilla
binaries.) Where this is not possible (e.g., because the differently-licensed
code is required by critical core Mozilla functions) then the build output
should prominently identify where and when differently-licensed code was used.

(Again, this is in the ideal case -- we may have to bend these guidelines a bit
in some special cases.)

The idea of a "differently-licensed" directory is to collect all the
differently-licensed code into one place, and not have multiple directories
scattered around the tree as we do now; I believe that having a single such
directory is essential as we move forward. I care less about whether such a
directory is a sibling of the mozilla directory in the CVS repository, or a
subdirectory of the mozilla directory, as long as we meet the goals 1-3 above,
and especially goal 2, that the differently-licensed code doesn't get checked
out with other Mozilla code by default.

Some other comments:

On the directory name, I understand Brendan's concerns about the name "non-mpl".
Note that Mitchell didn't like the name "third-party" because it didn't clearly
indicate that the code was isolated due to licensing concerns. I therefore
propose one of the names "mozilla-nonstd-license", "moz-nonstd-license", or
plain "nonstd-license". Yes, these are longer and a bit inconvenient to type,
but we can accept some inconvenience -- part of the goal here is to encourage
people to use the standard license scheme, and to discourage them from using
different licenses.

On LXR, I agree that existing URLs should still work. However I don't
necessarily see it as mandatory that the distinction between code under standard
and non-standard licenses be "invisible" to LXR. For example, maybe people would
have to do two separate LXR searchs or browse operations if they want to search
or browse both code under the standard license(s) and code under non-standard
licenses.

Anyway, those are my thoughts, for what they're worth.








under we want the differently-licensed files in a different place because we want 
Hecker: thats fine, except for one point:

libart can be a system library, exactly as gtk is. If this subdir is created,
then the build process will offer to use the system libart instead (just like we
do for libpng, libgif, zlib, etc) This would only work on unix systems, since
mac/windows are unlikely to have libart installed.


The main reason for wanting somewhere inside cvs.m.o for this is that we can
then build (and work) on the mac. Requiring the tinderboxes to be upgraded every
time we make a change isn't really an option. The SVG branch currently requires
an up to date libart version to be installed. Note that this would not be a
fork; raph is just a bit slow in having patches accepted.

Also, libart added some functions which we use without upping the soname, so the
runtime linker gives up on earlier versions, like those shipped with every
current linux distribution.

libart is only linked to dynamically, of course.
What about "other-license" instead of "nonstd-license"?

Frank, please clarify:

> In particular, it's been proposed that Mozilla distribute mathematical fonts
> (for use by MathML) under special font licenses,

> 3. Ideally a Mozilla build done "in the usual way" (i.e., without any special
> options) should not build features which incorporate code under a non-standard
> license. (Thus, for example, SVG should not be built by default, since it
> results in the LGPLed libart being incorporated into the resulting Mozilla
> binaries.)

Does this imply that mozilla nightlies and milestones shouldn't have MathML,
i.e. bug 15391 "MathML not enabled in nightly builds" will be WONTFIX?

I thought one of the main points for this was to make way for things like MathML
fonts so that MathML support could finally be enabled by default. Now you seem
to say that this bug is the worst enemy of MathML...

Re MAthML, as I said "ideally" the standard Mozilla builds should not require
the inclusion of material under other licenses. But that's in the ideal case; in
practice we can certainly make exceptions if and when it makes sense.

Re the comments on libart, I'm unsure exactly what you're asking for. I _think_
you're saying that you want libart to be in a subdirectory of the mozilla
directory, in order to build properly on the Mac -- that if the libart code were
in a directory that is a sibling of the mozilla directory then it would cause
major problems for Mac builds. Do I have that right?

Re the name, I personally don't care whether it's "nonstd-license" or
"other-license". I just think that the name should have the word "license" in
it, in order to make it clear that the directory exists because of licensing issues.

It needs to be somewhere where we can:

a) make local changesb) convince the build scripts to pull it when svg is enabled

I don't know how the maccvs automation works - I suspect that somewhere under
mozilla/ would be easiest, but its probably not essential.
Since alex is on vacation, this may not happen til he gets back.
the pull/build scripts for the client can just as easily pull/build something
that *isn't* under mozilla/ (remember, mozilla is not the cvs repository root),
fwiw.

I don't have a work-free resolution for the LXR issue, but i did do something
like this for the netscape commercial tree, where i created a new directory
(seamonkey) that housed the parallel ns and mozilla trees, so that both were
indexed, and the root url was seamonkey (in place of mozilla).

Before we redesign the source tree to address non-MPL license issues we should
re-examine our non-compliance with *MPL* license requirements. The issues are
similar (knowing what code is licensed by whom) and perhaps a mechanism that
addresses the MPL problem solve the other issues as well.

The MPL problem is that it is impossible to follow section 3.3 of the license,
which requires a "prominent statement" listing the Original Code and Initial
Developer in the source and executable. We have no such notice in the
executable, and have it in the source only if you count the file-by-file Exhibit
A headers which may or may not be sufficient.

You might attempt to argue that only applies to "Modifications" and that
mozilla.org distributes the reference version, but since the mozilla.org
codebase is a mixture of different "Original Code" the binary must be a
derivative of each of them.

How are mozilla.org, Netscape, Beonex and other distributors ever going to be
able to comply with this requirement? We need a map file that describes which
files were created by which Initial Developer, and the build scripts should
incorporate this file into the about: page.

If we have this map mechanism, couldn't it be used to describe non-MPL licenses
just as easily, with no need to move files around?
[An alternative way to MPL compliance would be to change section 3.3 of the MPL
itself, removing the impractical advertising-clause-like requirement of
publishing the Initial Developer name in the executable. Of course we'd still be
out of compliance with section 3.6--we don't say that the source is available
nor "how and where" to get it--but that's an entirely different issue.]
The original issue "Create new top-level directory in CVS for code/data under
other licenses" is fixed, see the lxr url in the URL field of this bug.

dveditz: I suggest you open a new bug to "re-examine our non-compliance with
*MPL* license requirements", if you are still interested.

Marking FIXED.
URL: http://lxr.mozilla.org/mozilla/source...
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.