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)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: hecker, Assigned: endico)
References
()
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.
Comment 1•23 years ago
|
||
In your proposed organization, this means that the licenses could change at an arbitrary directory depth, right? Seems like this could be confusing.
Reporter | ||
Comment 2•23 years ago
|
||
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.
Reporter | ||
Comment 4•23 years ago
|
||
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?
Comment 5•23 years ago
|
||
Any takers for "non-mpl", with added hyphen for readability?
Reporter | ||
Comment 6•23 years ago
|
||
I personally don't care greatly whether it's "non-mpl" or "nonmpl". However I agree that "non-mpl" is slightly more readable.
Comment 7•23 years ago
|
||
So now that's settled, how about it? :)
Comment 8•23 years ago
|
||
this has my vote (except it won't allow me to vote on it)
Comment 9•23 years ago
|
||
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.
Assignee | ||
Comment 10•23 years ago
|
||
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.
Comment 11•23 years ago
|
||
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.
Comment 12•23 years ago
|
||
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.
Reporter | ||
Comment 13•23 years ago
|
||
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
Comment 14•23 years ago
|
||
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.
Comment 15•23 years ago
|
||
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...
Reporter | ||
Comment 16•23 years ago
|
||
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.
Comment 17•23 years ago
|
||
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.
Comment 18•23 years ago
|
||
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).
Comment 19•23 years ago
|
||
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.]
Comment 20•23 years ago
|
||
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.
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.
Description
•