Hmm like this attitude, make eachother better by copying and innovating. The layout guys are working really hard on the Mozilla code to clean it up.

With Mozilla and Safari we have two great browsers at our disposal. To quote a big electronics company... Let's make things better :P

"I will eventually be implementing the rule tree in KHTML that I implemented in Gecko for reducing style footprint and speeding up style resolution (with a few extra goodies/cool capabilities that don't exist in Gecko's rule tree)."

Why not adding those "few extra goodies/cool capabilities" to Gecko, then you can take the code to Sarafi too? Then Gecko can legally use all your cool code.

It's a whole lot more fun to make the Mozillazine fanboys foam at the mouth about how Apple dares to use their holy code, though...

David Tenser:

At this point, I doubt Hyatt could add the code to Gecko. Chances are had to sign a noncompete agreement with Apple, and so the browser code he writes would have to go to Safari.

But this does raise the question: what about Phoenix?

Interesting... i was wondering if Apple was gonna capitalize on the work already done on gecko and add it to safari.

Brilliant move just as long as it doesn't end up cluttering things.

This is why i love open source. Creating a hybrid is brilliant and amazingly productive.

Scares me what M$ must be doing though.

To be honest we'd be a lot better as a society if all our technological advnacements were open source

"d", who are these "fanboys" you speak of? I've seen no such foaming on Mozillazine....

holy code would be closed source wich Mozilla isn't, care to elaborate on your remark d? Or is this one of those flames towards the Mozilla code, we have seen so much around here? (mind you in the comments section).

Both Mozilla and Safari can learn from eachother and that's exactly what they should do, so i hope that the licensing crap can be worked out.

Re moving Safari code back into Mozilla: The goal of the Mozilla tri-license scheme (MPL/GPL/LGPL) was only to make it easier for other projects to use Mozilla code, not to make it easier to move code from other projects into Mozilla. As it turns out, from a licensing point of view moving code freely between two projects (without getting explicit permission from the licensors) is impossible unless a) all the projects are using non-copyleft licenses (e.g., BSD, MIT), or b) all the projects are using the same copyleft license (e.g., all are using the GPL, or all are using the LGPL).

So, given that KTML is licensed under the LGPL: If Mozilla were licensed under the MPL/NPL only (i.e., the situation before the tri-license), then Safari would not be able to use Mozilla code or vice versa. If Mozilla were licensed under the GPL only, then Mozilla would be able to use KHTML code but Safari would not be able to use Mozilla code. Only if both Mozilla and KTML were under the LGPL (only) could code be freely mixed.

So the tri-license scheme made a bad situation better, but there was no way to address the problem completely.

Maybe this should be highlighted as the big problem with a company (eg Apple, Netscape) coming up thier own licences instead of using GPL or LGPL?

Seems to me to a rather dumb problem that occured because the corporate types put too much faith in thier lawyers and when they discover thier mistake can never fix it.

Seems to me that maybe Apple should learn something from this situation when they look at thier own "Open Source" licence.

It seems that this is too complicated and someone needs to step back and think about merging these license languages. What would be the reason to have different types of licenses within the opensource community? Does anyone have a comparison of the current licenses?

I second Jack, please a table with the comparison...

;-)

MaurOS X.

Michael, Jack, one thing that the MPL allows that the GPL or LGPL does not is that it allows Netscape to not reveal the source code for the parts of their browser that they add to Mozilla (aim integration, Netscape webmail integration, etc).

What should be created is probably something along the lines of "if you use this code under any of the licences we are able to pull back related and nonrelated improvements and rerelease it in all our licenses"

That would enable both Apple and Netscape to have closed parts while still allowing everybody to reap the benefits of the joint development of the open source parts.

However it would probably take a few years to design something like this :P

Stefan, such a clause would not be GPL or LGPL compatible.

Hello,

I think the best solution, and something that most people don't realize, is that free and opensource software developers that are interested in a particular type of program should consider licensing their patches in multiple licensing formats. For instance, if someone is working on khtml extensively, and they know that other opensource programs exist that may or may not be able to use the code, and you would like to make that option available to them, then license the code with some compatability clauses in it. Or license the code with as many licenses as you need to stay compatible.

I guess it all depends on the developer. If the people writing the patches want their code re-used in other projects, and they know of those projects, they should re-license their code when its posted in CVS. If they didn't add any other licenses other than the GPL to their patch, then you must assume they do not want their code used in any program that uses licenses other than the GPL. So either way, this is a non-issue. When developers choose a license for their code, they know where that code can and cannot be used. If they don't, maybe someone should try to raise their awareness to licensing issues such as this.

Why don't you fork an LGPL-only version of Gecko? It could still be linked to a proprietary Netscape, and it could share code with Safari, Khtml or any other LGPL-project.

He who has a thousand friends has not a friend to spare,And he who has one enemy will meet him everywhere.