Relicensing Has Begun
Wednesday September 19th, 2001
Gervase Markham writes: "Today we are checking in the first set of license changes into the Mozilla source tree, in our effort to get all mozilla.org-hosted code licensed in a way which addresses concerns about potential incompatibilities between the MPL and the GPL and LGPL. Our ultimate goal is to relicense all the mozilla.org-hosted Mozilla code under an MPL/GPL/LGPL tri-license (except for a few contributed files which will remain under their current BSD-style licenses). For more information on this ongoing effort see the Mozilla Relicensing FAQ. Please read that before asking questions in the comments." Click the Full Article link to find out more about the relicensing.
may take a few minutes to be pushed to the webserver. Patience :-)
#2 What has really changed?
Wednesday September 19th, 2001 1:46 PM
What will the legal impact on my contributions be? I mean; what will be "legal" to do now that wasn't before?
I'd like some more explanation on this and how it affects us contributors.
#3 Re: What has really changed?
Wednesday September 19th, 2001 1:47 PM
Oops. Didn't notice the FAQ link. Ignore me. :)
Why are the NPL'd files not being changed to MPL while we're at it? I thought that it was policy that the NPL was obsolete and would be replaced by the MPL over time.
Thanks in advance for any info, Stuart.
#5 Re: Why *N*PL/GPL/LGPL?
Wednesday September 19th, 2001 2:53 PM
It's in the FAQ: <http://www.mozilla.org/MP…icensing-faq.html#why-npl> ... In short, "Because we don't yet have all the necessary permissions from AOL Time Warner that we would need in order to do so."
Any bets being taken on when we'll see a fork? I'll put my money on february 21.
I doubt it. The M/NPL has always been forkable - *proprietary* forkable - and nobody tried to fork it. Perl has been dual-licensed between the GPL and artistic licenses for donkey's years and never license-forked. OpenOffice is GPL/SISSL. NSPR and spidermonkey have been dual MPL/GPL for ages too.
Oh, and on <http://www.gnu.org/philosophy/license-list.html> , rms urges perl programmers to dual-license all perl code they write, to "promote uniformity". He also made a statement shortly after the dual-licensing of NSPR and spidermonkey was announced, urging people to respect the spirit of the dual license and not restrict their contributions to GPL only (sorry, I don't have a reference to this, some searching might pull it up).
If anybody does fork, they'll have no serious support from anywhere, and will fall behind the official project almost immediately.
#9 Re: when do we fork?
Wednesday September 19th, 2001 3:49 PM
This is just my opinion (and doesn't necessarily reflect reality or the opinions of mozilla.org) bug as I understand it, lot's of forking has already happened. Active state forked a long time ago when they started working on Komodo. OEone's operating environment was a fork from one of our branches and they will probably return to fork the next one of our stable branches. I believe lot's of others, maybe Galeon, have done the same thing. Not everyone working on Mozilla based projects does it in cvs.mozilla.org. The same thing happens with Bugzilla. RedHat's Bugzilla is a fork. They aren't participating in the mainline Bugzilla development as far as I know. I'm sure that scores of others have forked Bugzilla too. I don't see a lot of checkins to Bugzilla from NASA or the US Army or Apache. The license requires that people make their changes to MPL and NPL filed publically available. It says nothing about participating in mozilla.org hosted development. IANAL so my reading of the license may be way off base. I don't claim any expertise in this area but concern about forking seems silly to me.
#10 Re: Re: when do we fork?
by david_ascher <DavidA@ActiveState.com>
Wednesday September 19th, 2001 4:10 PM
Just to follow-up to one of Asa's points -- we (ActiveState) have _not_ forked Mozilla. We have made some patches to Mozilla for use in Komodo, but publish those patches with each release (see <http://aspn.activestate.c…SPN/Downloads/Komodo/More>, under "Built on Mozilla").
This is not a fork (<http://www.tuxedo.org/~es…rgon/html/entry/fork.html>), since we don't do parallel development. Finally, all of our changes to Mozilla are either "branding" changes (e.g. the splashscreen) or bugs for which we submit bugs in Mozilla's bugzilla when we have a general fix. We are not interested in maintaining a fork of Mozilla -- that is why we contribute numerous patches to Mozilla and have placed the PyXPCOM bindings in the Mozilla source tree.
While we have made some modifications to bugzilla (bugs.activestate.com), those aren't modifications to a code base we distribute. My understanding of the MPL clause 3.2 is that the modifications to the source code must only be made if you actually distribute the executable. In the case of Bugzilla, most of the changes are cosmetic or irrelevant to the larger public (and have to do with integration with ActiveState IT systems), with minor feature enhancements which we'll share with anyone interested in adding them to the mainline.
To finish, I agree w/ Asa -- the threat of forking is pretty low from where I'm standing.
-- David Ascher Director, Programming Tools ActiveState
#11 Re: Re: Re: when do we fork?
Wednesday September 19th, 2001 4:25 PM
David, (others), I didn't mean to suggest that ActiveState wasn't offering changes back to Mozilla (I know better, I've seen some of those patches sitting in Bugzilla for way too long). ActiveState does more than make the changes public, they go to the trouble of bringing them to our front door gift wrapped.
I only meant that people grab the code and go do other things with it. Not everyone wants to be a part of the Mozilla browser project. If these other projects which take the code and make different things out of it aren't forks then I don't have the proper vocabulary. I hope I haven't stepped on any toes.
To rephrase my comments, I believe that there have been and are going to be a lot of people doing very cool stuff with Mozilla technologies that are not the Mozilla browser project and not hoseted by mozilla.org. I think this is great. I don't think this is something we should be worried about.
#13 Already happened or won't happen
by abraham <email@example.com>
Thursday September 20th, 2001 11:09 AM
If you mean "fork" like Linux, with multiple distributions which all define themselves compared to a single "autoritative" kernel, that has already happened.
If you mean "fork" like *BSD, with five basically equal and indpendent trees, I doubt that will happen as long as AOL back the project. There is simply too much to lose by diverging too far from the AOL backed tree.
If you believe that license issues will promote a fork, I can't see any reason to think that will happened. It didn't happen to Perl. X11 and BSD did fork, but all the forks either kept the original lisence or went proprietary. There have been no forks that switched to another free license, like the GPL, even though the (new) BSDL and MIT X11 licenses would allow that.
The license fanatics in the GPL camp tend to be Linux lusers without a clue, and no ability to code. There are some pretty competent coders among the pro-BSDL anti-GPL fanatics, but the new license would not allow switching the the BSDL.
As I understand it, the reason netBSD and freeBSD are under parallel development is that there is something fundamentally different somewhere between the two operating systems - they made a different decision about something big a ways back and now, because of that, they would have great difficulty using each other's code (although they are obviously legally allowed to, being truely free and all).
But how could this work with Mozilla? That's a question which begs the question - what is Mozilla? Is it XPCOM? NGLayout? Which components would you have to take away to make Mozilla no longer Mozilla?
If you were to fork based on one feature then, because of the modulised nature of mozilla, you could still share certain other components with the main Mozilla codebase. Kmeleon, for example, doesn't maintain its own rendering engine, fixing bugs and improving the code they already released, they just use the newer rendering engine from mozilla.org when they want to update their browser. I'm no programmer, but because of the modulised nature of Mozilla, I really can't see how it would be possible to fork and stay forked in the way you mean. The Mozilla organisation forks the codebase regularly, but they don't maintain the forkedness for more than a week or so - every milestone is a fork from the "main" codebase. And Netscape and OEone and Kmeleon release things forked from particular milestones, but the developpment of a particular fork is always shortlived.
Question: does this solve the licensing issues with libart? If so, does that mean SVG could finally be folded into the main branch?
What are the licensing issues with libart? :-)
mozilla.org will continue to not allow LGPL or GPL-only code into the tree, because not all of our customers/distributors can use it.
I'd been told that one of the reasons SVG hasn't been folded into the main branch yet was because of some licensing issue or other with libart, on which SVG depends (the other reason was that it needed a code review).
Was I mistaken or something?
#22 What is bug 93480 about then?
Saturday September 22nd, 2001 5:09 PM
* new top-level directory in CVS for code/data under other licenses <http://bugzilla.mozilla.org/show_bug.cgi?id=93480>
I thought this would be the main thing holding up libart checkin (which is bug 79312, the one blocked by the new-directory bug).
There doesn't seem to be much progress, though. :-(
If you'd like a version of Mozilla 0.9.4 with app icons (i.e. different taskbar icons for mail/news, address book and composer - like in Netscape 6.1) then download the MathML enabled build which also includes the app icons: <http://ftp.mozilla.org/pu…la-win32-0.9.4-MathML.zip>
Although if you can live without app icons and have no interest in MathML please use a talkback build instead.
(actually if you copy the icons directory from the chrome dir in the MathML build into the chrome dir of a 0.9.4 talkback build or nightly then the app icons will work with that build)
#18 Comment dates not being displayed
Saturday September 22nd, 2001 9:40 AM
Is it just me or are the posting dates not appearing next to the comments in MozillaZine Talkbacks?
#19 Re: Comment dates not being displayed
Saturday September 22nd, 2001 11:43 AM
Maybe they used single quotation marks instead of double quotation marks for the preprocessor and omitted a function or symbol that turns those letters into date / time formats.
#20 Re: Comment dates not being displayed
Saturday September 22nd, 2001 1:46 PM
Working on it. Love how stuff breaks when i go offline a few days...
#25 Hurray, it's fixed! (n/t)
Wednesday September 26th, 2001 1:32 PM
This space left intentionally blank.
Wednesday September 26th, 2001 11:46 AM