Slashdot Mirror

mozilla.org says M22 is the final one

Mozilla rules. Even in Milestones (M16,M17), it's extremely stable. I suggest that you give it a try. Mozilla. Of course, there's always Lynx. IMO, most important information can still be transferred by plain text. There's absolutely no reason to use Flash animations to get messages across to people and indeed, web sites that do this sort of thing....well...you have to wonder? Is this content really useful information, or is it more a "Fun Thing"? I'm not so sure anymore. Anyway, even on the GFX side, there's always Mozilla - it's coming along very nicely, IMO.

Both of these systems allow a bug to be assigned, prioritized, and tracked. I know of many closed source companies (most of whom prefer to remain nameless) who use these systems as they are robust, reasonably mature, and don't cost a dime! Highly recommended. :)

--- Brent Rockwood, Senior Software Developer

Mozilla does run on Be.

http://www.mozilla.org/ports/beos/

Ok, fine, Maybe Opera isn't based on IE, but Mozilla is based on Netscape 5.0. Go to there website at www.mozilla.org. They say "Mozilla is based on a very early version of Netscape Communicator 5.0 with all of the code that Netscape is unable to release due to license or export restrictions"

An accurate statement would be 'Netscape6 will incorporate the Mozilla browser'. Netscape will basically be putting their logo and name on it when they distribute it.

And anyone who says Mozilla sucks obviously has not used it in a long while. The Milestone releases suck, yes, but this project is still in development. If you try a nightly build you will be impressed with the improvements in stability and speed.

This post was made from Mozilla BuildID:2000083111 for Linux.

Mozilla has a problem with this too, and it's in danger of being cast aside because not enough people care about it.

Go cast your vote for bug 28327!

--

Actually, I'm pretty much amazed. I expected all hell to break lose. In fact, not only my browser correctly displayed the Chinese characters in the post, but when I clicked on the link it opened a nice little window saying "www..com could not be found. Please check the name and try again." With the Chinese characters correctly displayed, even in the error message!

And it passes the Unicode test better than I thought it did: in fact, only the Sanskrit bit was incorrect (and only slightly so: the ligatures weren't made). This is because I have the GNU Unifont installed, but Mozilla definitely rocks.

This was posted on mozillazine.org 3 days ago.

Anyways, I tested it with a nightly build and it brought my whole x down. I think they should make a version check and give you an error message if you try to run it with the wrong build.
You might also want to check out the latest mozilla nighlty which has now the new modern 2.0 skin, which i, amongst many others think is looks cool. This has also been posted before, but just in case you dont know...

You know something? I can't find any music on 8 track, and it's amost impossible to find a convenience store that sells leaded gas. The next thing I'll find out is that my parachute pants from junior high school don't fit anymore. What's this world coming to?

Why don't you try using a real browser? Internet Explorer is AWESOME if you use Windows, but even if you don't, there are several options such as Netscape, Opera, and Mozilla, (or derivatives).

</RANT>

--

I thought that Gecko was one of the bits also available under gpl, but after further investigation that doesn't seem to be currently true.
There is quite a bit that is dual licensed though and I'd guess that Gecko is one of things they'd concentrate on GPLing first as it is rather central to the whole thing.

I thought that Gecko was one of the bits also available under gpl, but after further investigation that doesn't seem to be currently true.
There is quite a bit that is dual licensed though and I'd guess that Gecko is one of things they'd concentrate on GPLing first as it is rather central to the whole thing.

I think the post is kind of misleading. The link to the pictures for the next Mario Kart game I believe are for the Gameboy Advance...

GameCube: like I said a couple of days ago in another post. Why is it everything has to have a cube name in it now?

Talk about name ripping: A GameCube that uses a PowerPC. That sounds similar to this. It's so appropriately named Gekko. Hmm...

A 56k modem and a proprietary storage system? (meaning: no DVD).

Forget it.

Do you really have to use bloody JavaScript for these applications? come on, I want a decent language

Then use one.
I think the point of this whole thing is to capture people who really use HTML, Javascript and XML (see mozilla developers) for most of their functionality. Don't assume that everyone wants to learn C (or whatever you consider to be a decent language).

Can I say that on /.?




Never attribute to malice that which can be adequately explained by stupidity.

of course those icons on web pages sure don't get any more legible.

Isn't it about time more browsers had this? Are there any plans for Mozilla to include this functionality?

With difference between the top end and bottom end of display technology, and the tendancy of (less skilled?) web designers to create "best viewed in NxN" sites, html viewing software neads to be deisgned to cope with these differences.

Thad

--

This is a response to Galeon?

Saying it is "also" light and unbloated?

Too bad Galeon requires me to install all of GNOME as well. Not exactly unbloated if you don't use GNOME, is it? It even requires you to use the GNOME control panel to set such things as your mailer, and to have GNOME programs beyond the base GNOME libs, such as GTM (Gnome Transfer Manager, for downloads).

I'm sorry, but Galeon doesn't quite cut it for me. Too bad there aren't many binding for embedding Mozilla yet, only the gtk bindings. Of course, you could just use the embedding interface interface of Mozilla itself and build your own wrapper. Judging by gtkmozembed, it'd only take around 70kbyes of code.

You'd also, of course, have to understand the very confusing embedding docs, and while the gtkmozembed code might help a bit, it's very Gtk specific.

Perhaps someone will start developing some other bindings so that you don't need to implement 5 different objects to interface with the embedding objects. Oh, and create the associated IDL files, whatever those are, I haven't figured them out yet.

One of Mozilla's major claims to fame is its embeddability. Too bad it's not very embeddable yet.

Wow, I went just a bit off my train of thought.. well. Galeon requires GNOME, K-Meleon requires Windows.. I guess that evens it out a bit. I'd really like to see a Gtk-only Mozilla-based webbrowser, though; no GNOME, no KDE, just Gtk, Mozilla code, Linux, and X.
---

This is a response to Galeon?

Saying it is "also" light and unbloated?

Too bad Galeon requires me to install all of GNOME as well. Not exactly unbloated if you don't use GNOME, is it? It even requires you to use the GNOME control panel to set such things as your mailer, and to have GNOME programs beyond the base GNOME libs, such as GTM (Gnome Transfer Manager, for downloads).

I'm sorry, but Galeon doesn't quite cut it for me. Too bad there aren't many binding for embedding Mozilla yet, only the gtk bindings. Of course, you could just use the embedding interface interface of Mozilla itself and build your own wrapper. Judging by gtkmozembed, it'd only take around 70kbyes of code.

You'd also, of course, have to understand the very confusing embedding docs, and while the gtkmozembed code might help a bit, it's very Gtk specific.

Perhaps someone will start developing some other bindings so that you don't need to implement 5 different objects to interface with the embedding objects. Oh, and create the associated IDL files, whatever those are, I haven't figured them out yet.

One of Mozilla's major claims to fame is its embeddability. Too bad it's not very embeddable yet.

Wow, I went just a bit off my train of thought.. well. Galeon requires GNOME, K-Meleon requires Windows.. I guess that evens it out a bit. I'd really like to see a Gtk-only Mozilla-based webbrowser, though; no GNOME, no KDE, just Gtk, Mozilla code, Linux, and X.
---

When java finally hits Mozilla, I'll wipe Netscape from my disk drive.

As of July 31, there were 150,000 downloads of Stephen King's new work, of which 116,000 paid the $1 fee. He's made these $116,000 just because of his high reputation, but, he spent more than that just to market that book.

For a multi-million-seller like a platinum album or Harry Potter book, the "please donate a dollar" scheme just isn't going to work. On the other hand, if you look at the recent furor over the Harry Potter book, and all the pre-sales, and so forth, you can easily see that it would have been very easy to ask people to pay upfront, and very lucrative.

Also, I hate to say this, but most of the music being produced for free is worth every penny---i.e., it's just not that great. (Especially in the classical genres. The MP3 artists in the classical genres completely suck. I'm sorry to say that, but it's true.) At some point, certain artists are going to become more popular than the others, and are going to be allowed to demand more.

If your next song gets you $400,000, rather than $400, then I know you'll start thinking to yourself, "Hmm, now that I've got a reputation for quality...."

A lot of people confuse my opinion that "prepay is inevitable" with the fact that I think "prepay is good". I don't think anything is good or bad. I download free things all the time. I started using linux in '94, when 0.99 was made official, and my experience with the 'net goes back way before then. I know all about free. I was a regular user of Gutenberg even before there was such a thing as the Web; and more recently, you could say I made a major contribution to the HTTP logs of the free book section of ebooks.barnesandnoble.com,due to my clever use of curl. :-)

But I'm also a grown-up, and I know all about the world works, and how bills need to get paid. My opinion is that prepayment is inevitable, not that it's good or bad, and that once an artist becomes famous and/or popular, they will start thinking "do I devote myself to this full time, or not? Do I get paid for it, or not?", and at that time, they will decide to convert from a donation-only model to a prepayment model.

I think that only time will tell, but I'm pretty confident that prepayment will arrive, one day or another.

P.S. Microsoft killed Netscape because they are a zillion-dollar company, and can afford to put out IE as a "loss leader". Also, because they were able to develop IE5 while Netscape spent their money on plastic dinosaurs and Corporate Headquarters With Waterfalls. There are lots of little software companies, but there's only one M$, and it's the M$s of the world who will demand the prepayment.

People think that artists like Van Gogh were "starving artists" who never sold their art. That's pure baloney. Van Gogh was the son of a rich industrialist, and had a brother who supported him. The "starving artist" is a myth. There isn't a one on the planet, and there never was.

Finally, unlike Mozilla, the various forms of artwork like music, art and literature absolutely do not lend themselves to open-source collaborative development. You can't "fix a bug" in a Picasso or "add a feature" to a Nirvana tune. It still takes unique people with unique visions, and some of those visions are going to be worth more than others.

If you put up a form saying "Prepay a required $1 for the next release of Metallica when it comes out", or "Pay a volutary $1 for Anonymous Artist to download their new music", I think Metallica will get plenty of $1 payments, regardless of the extreme vocal opinions on the subject at places like slashdot.

But hey, let's not argue. Let's test the theory. We're all scientists, right? Let's see if we can get a high-profile artist to try it. I really think people will be surprised.
--
Orlando, Paladin of Charlemagne

I think that your analysis of the licensing problems is quite right. The two responses that are usually given are also usually countered with the following arguments:

1. When you compile KDE, you also include some code from the Qt header files (macros, types, etc.) so a part of the KDE binaries is derived from Qt. This code is not compatible with the GPL, which implies that you are not allowed to re-distribute it in a GPL'ed package.
2. Indeed, you could assume that the "Qt exception" (a suggested addition to the KDE license in order to make it compatible with Qt) is implicitely included in the code that was written specifically for KDE, because it is obvious that the authors of this code intended to have it distributed with KDE and together with Qt. However, a (very) small part of the KDE code was borrowed from other projects for which you cannot make this assumption. Thus the license for the whole package is a problem.

But there is hope, especially about the second point... As reported on Wednesday, Mozilla is going to be dual licensed. In order to change the license, they will get in touch will all contributors in order to be sure that they agree with the re-licensing. More precisely, as explained in their relicensing FAQ, they will make a reasonable attempt to contact and obtain consent from each of the contributors (it may not be possible to contact all of them, so the law only requires them to be able to prove that they made a reasonable effort).

If the Mozilla team can do it, then the KDE team should not be scared to do it. Maybe there is still hope for KDE2 to be released with the "Qt exception" in all source files. This would put an end to this licensing controversy, and this would benefit KDE (a lot!).

This would probably not end the GNOME vs. KDE flamewars, but at least they would have to consider some more technical arguments instead of flaming KDE for its licensing problems.

It does not even work on glibc 2.0 even if you hand compile it. Trust me.

If you were following Mozilla development, you might have noticed this bug which tells you that glibc 2.0 is broken with regards to Mozilla. Don't do it. Upgrade to glibc 2.1.

And if you were really serious about compiling from source, you might have taken a look at the Mozilla Detailed Unix Build Instructions. This page even gives you a link to a patch that makes glibc 2.0.7 behave so that you can compile with Mozilla.

Somehow people have no problem with upgrading their system with security fixes, but ask them to upgrade system stuff that's broken to fix a bug and they go all to pieces.

-Nathan

It does not even work on glibc 2.0 even if you hand compile it. Trust me.

If you were following Mozilla development, you might have noticed this bug which tells you that glibc 2.0 is broken with regards to Mozilla. Don't do it. Upgrade to glibc 2.1.

And if you were really serious about compiling from source, you might have taken a look at the Mozilla Detailed Unix Build Instructions. This page even gives you a link to a patch that makes glibc 2.0.7 behave so that you can compile with Mozilla.

Somehow people have no problem with upgrading their system with security fixes, but ask them to upgrade system stuff that's broken to fix a bug and they go all to pieces.

-Nathan

It does not even work on glibc 2.0 even if you hand compile it. Trust me.

If you were following Mozilla development, you might have noticed this bug which tells you that glibc 2.0 is broken with regards to Mozilla. Don't do it. Upgrade to glibc 2.1.

And if you were really serious about compiling from source, you might have taken a look at the Mozilla Detailed Unix Build Instructions. This page even gives you a link to a patch that makes glibc 2.0.7 behave so that you can compile with Mozilla.

Somehow people have no problem with upgrading their system with security fixes, but ask them to upgrade system stuff that's broken to fix a bug and they go all to pieces.

-Nathan

• Object
• • Person
  • place
  • Thing
  • file
  • stream
  • device

WHY? well the advantages are obvious aren't they? In this age of always(we wish)on networking it would make sense to represent the most commonly dealt with domain objects as clearly as possible. Bruce Tognazzini made the suggestion that people ought to be first class elements of any net oriented UI. And of course if you have people they have places to go things to do people they do them with, things they need to do them, places where they can work undisturbed, places where they can choose things or make things, places to meet other people, etc, etc. until you reach a place that... well you don't really want to go there now do you?

The neat thing is that it's possible to do almost all of the messy parts in the XML layer, for which there are numerous commodity tools and libraries. It should (in theory) be crossplatform (assuming platforms are compatible to standard).
My major worry right now is whether most of the SVG clients are going to support in-picture-links as that would be the way to implement most of the method calls on objects. Greatest possible thing would be to be able to write the methods in scheme ;-)

From AOL's page (http://www.mozilla.org/MPL/FAQ.html):

"16. Why don't you just release the source under both the NPL and the GPL right from the start?

The NPL and GPL are incompatible, as we explain in the question about using code covered by the GPL with code covered by the NPL. If we were to take this tack, we would cause an immediate and irreparable split in development on the Mozilla code base. This split would greatly minimize the benefit that Netscape would see from free source development, and because of this, the company is not able to consider releasing its code under the GPL."

From AOL's page (http://www.mozilla.org/MPL/FAQ.html):

"There are a number of reasons for this. The first three points speak to the necessity for the NPL, and the fourth addresses the question of why we didn't just release the code under the NPL and the GPL.

4. Netscape is interested in encouraging the use and development of the Communicator source code by other commercial developers. Netscape was concerned that these other companies would hesitate to engage in this development if the code were regulated by a license as strict as the GPL, requiring that all related software also be released as free source. At the very least, every other commercial developer would have to look very closely at the legal ramifications of embarking on free source development. This initial hurdle alone might be enough to keep them from starting at all, so it was decided to remove the hurdle by using a somewhat less restrictive license."

I've always thought that was a bullshit response, and now we see that they could have done it all along, and just chose not to.

the link in the article wasn't very descriptive, neither was the FAQ. It is instructive to compare the MPL with the GPL directly.

A very useful link is the Annotated MPL which explains some of the jargon in IANAL terms, though Mozilla says that this document is "now somewhat dated, but are still here for historical purposes".

In drafting this license, we attempted to balance the needs of several different constituencies: the free software development community, commercial programmers, and Netscape itself. Our intent with this license is to promote a Communicator development community on the Net and to release the source code under a license that supports this community, yet still allows Netscape to meet its business goals going forward. We believe this license satisfies the Debian Free Software Guidelines, which provide a commonly accepted definition of ''free software,'' much like other free software licenses such as GPL or BSD. We felt that none of the existing licenses balanced the needs of the various developers in a way that is most appropriate for this source code. It is our intention that the Netscape Public License balances these three constituencies in such a way that will maximize development on this code base.

(emphasis added)

since IANAL and very few of us are, maybe an actual lawyer here can comment on these documents more thoroughly? Especially the parts about intellectual property in the MPL.

the link in the article wasn't very descriptive, neither was the FAQ. It is instructive to compare the MPL with the GPL directly.

A very useful link is the Annotated MPL which explains some of the jargon in IANAL terms, though Mozilla says that this document is "now somewhat dated, but are still here for historical purposes".

In drafting this license, we attempted to balance the needs of several different constituencies: the free software development community, commercial programmers, and Netscape itself. Our intent with this license is to promote a Communicator development community on the Net and to release the source code under a license that supports this community, yet still allows Netscape to meet its business goals going forward. We believe this license satisfies the Debian Free Software Guidelines, which provide a commonly accepted definition of ''free software,'' much like other free software licenses such as GPL or BSD. We felt that none of the existing licenses balanced the needs of the various developers in a way that is most appropriate for this source code. It is our intention that the Netscape Public License balances these three constituencies in such a way that will maximize development on this code base.

(emphasis added)

since IANAL and very few of us are, maybe an actual lawyer here can comment on these documents more thoroughly? Especially the parts about intellectual property in the MPL.

the link in the article wasn't very descriptive, neither was the FAQ. It is instructive to compare the MPL with the GPL directly.

A very useful link is the Annotated MPL which explains some of the jargon in IANAL terms, though Mozilla says that this document is "now somewhat dated, but are still here for historical purposes".

In drafting this license, we attempted to balance the needs of several different constituencies: the free software development community, commercial programmers, and Netscape itself. Our intent with this license is to promote a Communicator development community on the Net and to release the source code under a license that supports this community, yet still allows Netscape to meet its business goals going forward. We believe this license satisfies the Debian Free Software Guidelines, which provide a commonly accepted definition of ''free software,'' much like other free software licenses such as GPL or BSD. We felt that none of the existing licenses balanced the needs of the various developers in a way that is most appropriate for this source code. It is our intention that the Netscape Public License balances these three constituencies in such a way that will maximize development on this code base.

(emphasis added)

since IANAL and very few of us are, maybe an actual lawyer here can comment on these documents more thoroughly? Especially the parts about intellectual property in the MPL.

the link in the article wasn't very descriptive, neither was the FAQ. It is instructive to compare the MPL with the GPL directly.

A very useful link is the Annotated MPL which explains some of the jargon in IANAL terms, though Mozilla says that this document is "now somewhat dated, but are still here for historical purposes".

In drafting this license, we attempted to balance the needs of several different constituencies: the free software development community, commercial programmers, and Netscape itself. Our intent with this license is to promote a Communicator development community on the Net and to release the source code under a license that supports this community, yet still allows Netscape to meet its business goals going forward. We believe this license satisfies the Debian Free Software Guidelines, which provide a commonly accepted definition of ''free software,'' much like other free software licenses such as GPL or BSD. We felt that none of the existing licenses balanced the needs of the various developers in a way that is most appropriate for this source code. It is our intention that the Netscape Public License balances these three constituencies in such a way that will maximize development on this code base.

(emphasis added)

since IANAL and very few of us are, maybe an actual lawyer here can comment on these documents more thoroughly? Especially the parts about intellectual property in the MPL.

First, you can imagine that a dually-licensed source file is really two files: one that has the GPL at the top, and the other than has the MPL at the top. When you use the file -- distribute it, compile it into a binary and distribute that, combine it with other code -- you can choose which of those ``virtual files'' you're dealing with. So if you want to use nsMozFile.cpp with your GNOME app, you might choose to use it under the GPL. But when Netscape builds Netscape 6 from nsMozFile.cpp, they'll probably choose to mean the requirements of the MPL instead of the GPL.

I'll restate that, because it's traditionally the sticking point: a dually-licensed file lets you choose which license you will honour. You have to meet the requirements of one of the licenses, at least, so mixing and matching requirements is obviously out. (Obviously. I'm embarrassed to even mention it.) You do not have to meet all the requirements of both licenses, and in fact it's impossible to do that, because the GPL forbids additional restrictions, and the MPL has several requirements that would fall under that category.

So what about changes? Well, now you've got three choices: you can create a derivative that is GPL-only, or a derivative that is MPL-only, or -- perhaps better still -- a derivative that is also dually-licensed. mozilla.org would certainly prefer that people keep things dually-licensed, for the same reasons that we want to dually-license it in the first place: it serves a larger community of contributors and consumers. Now, we can't require that your derivative be dually-licensed; that would violate the terms of both licenses, I suspect, but certainly the GPL. So all mozilla.org can do is exert control over its infrastructure, and insist that contributions which go into the cvs.mozilla.org tree be dually-licensed. It's still well within anyone's legal rights to create a GPL-only derivative of Mozilla, and fork the world. I think that would suck, a lot, and even RMS has in the past discouraged people from doing that. If nothing else, it would discourage other organizations from going the dual licensing route.

I hope that helps some. I'm really psyched about this; it's been a dream of mine (and others') since before Mozilla was even released, and the success of dually-licensing the JavaScript, NSPR and NSS/PSM code whet my appetite for more. Please join us in the mozilla-license forum for more discussion.

First, you can imagine that a dually-licensed source file is really two files: one that has the GPL at the top, and the other than has the MPL at the top. When you use the file -- distribute it, compile it into a binary and distribute that, combine it with other code -- you can choose which of those ``virtual files'' you're dealing with. So if you want to use nsMozFile.cpp with your GNOME app, you might choose to use it under the GPL. But when Netscape builds Netscape 6 from nsMozFile.cpp, they'll probably choose to mean the requirements of the MPL instead of the GPL.

I'll restate that, because it's traditionally the sticking point: a dually-licensed file lets you choose which license you will honour. You have to meet the requirements of one of the licenses, at least, so mixing and matching requirements is obviously out. (Obviously. I'm embarrassed to even mention it.) You do not have to meet all the requirements of both licenses, and in fact it's impossible to do that, because the GPL forbids additional restrictions, and the MPL has several requirements that would fall under that category.

So what about changes? Well, now you've got three choices: you can create a derivative that is GPL-only, or a derivative that is MPL-only, or -- perhaps better still -- a derivative that is also dually-licensed. mozilla.org would certainly prefer that people keep things dually-licensed, for the same reasons that we want to dually-license it in the first place: it serves a larger community of contributors and consumers. Now, we can't require that your derivative be dually-licensed; that would violate the terms of both licenses, I suspect, but certainly the GPL. So all mozilla.org can do is exert control over its infrastructure, and insist that contributions which go into the cvs.mozilla.org tree be dually-licensed. It's still well within anyone's legal rights to create a GPL-only derivative of Mozilla, and fork the world. I think that would suck, a lot, and even RMS has in the past discouraged people from doing that. If nothing else, it would discourage other organizations from going the dual licensing route.

I hope that helps some. I'm really psyched about this; it's been a dream of mine (and others') since before Mozilla was even released, and the success of dually-licensing the JavaScript, NSPR and NSS/PSM code whet my appetite for more. Please join us in the mozilla-license forum for more discussion.

First, you can imagine that a dually-licensed source file is really two files: one that has the GPL at the top, and the other than has the MPL at the top. When you use the file -- distribute it, compile it into a binary and distribute that, combine it with other code -- you can choose which of those ``virtual files'' you're dealing with. So if you want to use nsMozFile.cpp with your GNOME app, you might choose to use it under the GPL. But when Netscape builds Netscape 6 from nsMozFile.cpp, they'll probably choose to mean the requirements of the MPL instead of the GPL.

I'll restate that, because it's traditionally the sticking point: a dually-licensed file lets you choose which license you will honour. You have to meet the requirements of one of the licenses, at least, so mixing and matching requirements is obviously out. (Obviously. I'm embarrassed to even mention it.) You do not have to meet all the requirements of both licenses, and in fact it's impossible to do that, because the GPL forbids additional restrictions, and the MPL has several requirements that would fall under that category.

So what about changes? Well, now you've got three choices: you can create a derivative that is GPL-only, or a derivative that is MPL-only, or -- perhaps better still -- a derivative that is also dually-licensed. mozilla.org would certainly prefer that people keep things dually-licensed, for the same reasons that we want to dually-license it in the first place: it serves a larger community of contributors and consumers. Now, we can't require that your derivative be dually-licensed; that would violate the terms of both licenses, I suspect, but certainly the GPL. So all mozilla.org can do is exert control over its infrastructure, and insist that contributions which go into the cvs.mozilla.org tree be dually-licensed. It's still well within anyone's legal rights to create a GPL-only derivative of Mozilla, and fork the world. I think that would suck, a lot, and even RMS has in the past discouraged people from doing that. If nothing else, it would discourage other organizations from going the dual licensing route.

I hope that helps some. I'm really psyched about this; it's been a dream of mine (and others') since before Mozilla was even released, and the success of dually-licensing the JavaScript, NSPR and NSS/PSM code whet my appetite for more. Please join us in the mozilla-license forum for more discussion.

First, you can imagine that a dually-licensed source file is really two files: one that has the GPL at the top, and the other than has the MPL at the top. When you use the file -- distribute it, compile it into a binary and distribute that, combine it with other code -- you can choose which of those ``virtual files'' you're dealing with. So if you want to use nsMozFile.cpp with your GNOME app, you might choose to use it under the GPL. But when Netscape builds Netscape 6 from nsMozFile.cpp, they'll probably choose to mean the requirements of the MPL instead of the GPL.

I'll restate that, because it's traditionally the sticking point: a dually-licensed file lets you choose which license you will honour. You have to meet the requirements of one of the licenses, at least, so mixing and matching requirements is obviously out. (Obviously. I'm embarrassed to even mention it.) You do not have to meet all the requirements of both licenses, and in fact it's impossible to do that, because the GPL forbids additional restrictions, and the MPL has several requirements that would fall under that category.

So what about changes? Well, now you've got three choices: you can create a derivative that is GPL-only, or a derivative that is MPL-only, or -- perhaps better still -- a derivative that is also dually-licensed. mozilla.org would certainly prefer that people keep things dually-licensed, for the same reasons that we want to dually-license it in the first place: it serves a larger community of contributors and consumers. Now, we can't require that your derivative be dually-licensed; that would violate the terms of both licenses, I suspect, but certainly the GPL. So all mozilla.org can do is exert control over its infrastructure, and insist that contributions which go into the cvs.mozilla.org tree be dually-licensed. It's still well within anyone's legal rights to create a GPL-only derivative of Mozilla, and fork the world. I think that would suck, a lot, and even RMS has in the past discouraged people from doing that. If nothing else, it would discourage other organizations from going the dual licensing route.

I hope that helps some. I'm really psyched about this; it's been a dream of mine (and others') since before Mozilla was even released, and the success of dually-licensing the JavaScript, NSPR and NSS/PSM code whet my appetite for more. Please join us in the mozilla-license forum for more discussion.

First, you can imagine that a dually-licensed source file is really two files: one that has the GPL at the top, and the other than has the MPL at the top. When you use the file -- distribute it, compile it into a binary and distribute that, combine it with other code -- you can choose which of those ``virtual files'' you're dealing with. So if you want to use nsMozFile.cpp with your GNOME app, you might choose to use it under the GPL. But when Netscape builds Netscape 6 from nsMozFile.cpp, they'll probably choose to mean the requirements of the MPL instead of the GPL.

I'll restate that, because it's traditionally the sticking point: a dually-licensed file lets you choose which license you will honour. You have to meet the requirements of one of the licenses, at least, so mixing and matching requirements is obviously out. (Obviously. I'm embarrassed to even mention it.) You do not have to meet all the requirements of both licenses, and in fact it's impossible to do that, because the GPL forbids additional restrictions, and the MPL has several requirements that would fall under that category.

So what about changes? Well, now you've got three choices: you can create a derivative that is GPL-only, or a derivative that is MPL-only, or -- perhaps better still -- a derivative that is also dually-licensed. mozilla.org would certainly prefer that people keep things dually-licensed, for the same reasons that we want to dually-license it in the first place: it serves a larger community of contributors and consumers. Now, we can't require that your derivative be dually-licensed; that would violate the terms of both licenses, I suspect, but certainly the GPL. So all mozilla.org can do is exert control over its infrastructure, and insist that contributions which go into the cvs.mozilla.org tree be dually-licensed. It's still well within anyone's legal rights to create a GPL-only derivative of Mozilla, and fork the world. I think that would suck, a lot, and even RMS has in the past discouraged people from doing that. If nothing else, it would discourage other organizations from going the dual licensing route.

I hope that helps some. I'm really psyched about this; it's been a dream of mine (and others') since before Mozilla was even released, and the success of dually-licensing the JavaScript, NSPR and NSS/PSM code whet my appetite for more. Please join us in the mozilla-license forum for more discussion.

There has been a lot of performance work that has been conducted on the Linux builds lately so we're going to see an exciting future for Mozilla on the Linux platform. We just need a few more companies driving forward and making sure that we have a very fast and stable Linux mozilla (or mozilla based browser), and that it blows the Windows performance out of the window.

There has been a lot of performance work that has been conducted on the Linux builds lately so we're going to see an exciting future for Mozilla on the Linux platform. We just need a few more companies driving forward and making sure that we have a very fast and stable Linux mozilla (or mozilla based browser), and that it blows the Windows performance out of the window.

There has been a lot of performance work that has been conducted on the Linux builds lately so we're going to see an exciting future for Mozilla on the Linux platform. We just need a few more companies driving forward and making sure that we have a very fast and stable Linux mozilla (or mozilla based browser), and that it blows the Windows performance out of the window.

There has been a lot of performance work that has been conducted on the Linux builds lately so we're going to see an exciting future for Mozilla on the Linux platform. We just need a few more companies driving forward and making sure that we have a very fast and stable Linux mozilla (or mozilla based browser), and that it blows the Windows performance out of the window.

There has been a lot of performance work that has been conducted on the Linux builds lately so we're going to see an exciting future for Mozilla on the Linux platform. We just need a few more companies driving forward and making sure that we have a very fast and stable Linux mozilla (or mozilla based browser), and that it blows the Windows performance out of the window.

Now all they need to do is embed mozilla and we've got something.

That's what my signature says for a while now:

Spaghetti Code is Tasty Code!

For more funny signature, you can check http://bugzilla.mozilla.org/data/comments (When it becomes available again.)

dudle.

Domain names have several rules that must be followed.
And so I must wonder if this concern only projects under the GPL? What I fear most is a rise of partisanship in the handling of the assignment of domain names like theses ones, as well as some of the newly proposed extensions like .net, .jobs and the like.
My biggest interest is the handling of projects under GPL-Compatible lisences such as the MPL and the QPL.

I therefore propose not to allow the handling of new domain names, .cx or otherwise, be controlled by a single entity which might be subjected to pressure from interest groups like GNU, with all due respect that I hold for that organization.


--
Kiro

Ok you got me there! I've added a comment about it applying to heights to as per your comments and those in the bug 25612 (which shows this bug has been around for ages). Thanks!

I think that bug 39901 is what you are seeing (I submitted it a while ago). Yes it is valid bug and yes it is important. I'm very sorry that your bug was not being entered into bugzilla - you don't describe what was going wrong though. Do you have any bug numbers of bugs that have gone wrong? I haven't really heard of this happening before (but then again I'm not as active in moz as I used to be).

Bugzilla can be a pain to use and most of my bugs end up being duplicates but it's better to have duplicates than for a bug to go undiscovered. Maybe if you had tried the newsgroups or irc (/server irc.mozilla.org /join #mozillazine #mozilla) you would have found someone who would have helped you out...

This is a known bug.

http://bugzilla.mozilla.org/show_bug.cgi?id=37589

Mozilla has no Java by default (for the time being).

It has no IM.

You can choose not to install the Mail/News client.

Mozilla does not require you to register.

Sooo...that leaves slow (which is to be expected since it isn't even to beta--and it's actually pretty fast on my machine, though it does take a few seconds to load initially) and rendering stuff incorrectly which I can't believe is as bad as you say: 'a whole lot'? There are some major web sites which do not render properly, but they are by far a minority. Some of those are because of bad HTML coding. If you find some that should render correctly, check Bugzilla and submit the site as a problem if it hasn't been already!

Some ppl STILL don't seem to "get it". If you look at the following link...

Mozilla Milestones

...you will realize that M17 is the feature complete release. No attempt has been made to make it any more stable than the ability to complete a build without warnings. I am sure that PR2 is even less stable, as Netscape has added their own little "hacks". Anyone who has followed the project knows that the aim of everything after this date is stability, performance, and "polish".

I have seen people saying stuff like "Don't give me any of the Pre-Release garbage"...but this is exactly what this is about. I suggest trying some of the nightly builds from Tuesday evenings. These seem to be the most stable builds, because again, if you have been following Mozilla, you know that Tuesday is BugDay.

If you have never participated in a BugDay, I suggest that you do. But, before you do, download a M18 nightly...it seems to already be faster and more stable.

All I'm saying is, don't complain about Mozilla/Netscape not producting something and then complain when they do. It's not good form.

I am sure that since this does not seem to be a popular opinion, I will probably get modded down as a troll or flamebait or something like that, but I feal that I should still offer my feedback, as the guys working on the Mozilla project seem to be "unsung heros" right now. A good majority of the fixes are comming from Netscape Developers now. This is because they have begun work on Netscape 6 again (this was happening at the end of M17).