Ben Bucksch wrote:
Gervase Markham wrote:
When I said the codebase, I meant as a whole. They can't do nasty
proprietary things with it as there are too man
...y contributors involved, I assume.
...y MPLed files in the tree is actually where I was going. Hmm.
Editor widget woes, I
Emlyn wrote:
Things like NSPR and XPCOM are extremely cool technlogies which would be
of great use to other free software projects, who would not have to
re-implement the portable-runtime and cross-platform component model wheels.
Speaking of which, because XPCOM is so very useful, are
AOL has exactly the same rights (effectively) to the codebase that you
do.
As we saw in the very last days, this is untrue, if the code is under
the NPL (or even MPL).
Sorry, are you complaining that AOL is using its rights to work towards levelling the
playing field.
When I said the
The below is a cool example Ben :-), but it isn't a fair comparison. If you change
the house numbers to be the same, then _that_ is an equivalent example.
Simon
On 21/09/2001 at 09:49 Ben Bucksch wrote:
Simon P. Lucy wrote:
No dual licence where the language of both licences is in the same
Simon P. Lucy wrote:
Also if I have to licence using the GPL then I may be locked out of future
derivations of my own work.
Unlikely.
If it's a smaller change, that project would have to maintain the change
as a patch, and maintaining patches is hell, as we experienced.
If it is something
Simon P. Lucy wrote:
I know, this I don't understand, i don't see how Galeon and Nautilus can go on, yet
there's a need to further allow GPL licencing.
The only reason why they still exist is that nobody sued them yet (to my
understanding; dunno if they fixed the license in the meantime).
Simon P. Lucy wrote:
I have said that the only way to use the source is to remove the GPL/LGPL language.
But its not the binary that matters, you have to make sure for all uses. This
effectively still means that I'm estopped from contributing back because I can't
licence using the GPL.
Why
Simon P. Lucy wrote:
Mozilla runs on Linux, no user that uses Linux is really going to care about the
source licencing.
They do care, but the MPL is acceptable to most.
Developers that wish to combine code from GPL may be affected but I've never quite
seen the problem like that.
Galeon.
Simon P. Lucy wrote:
Actually, having read the FAQ, even if I hadn't thought that Mozilla, for me, was a
dead project it certainly is now. Forcing developers to licence their own work under
the GPL simply means that developers such as myself can never contribute back because
of the risk of
Simon P. Lucy wrote:
I fail to see how contributions will be made back to the tree by those that insist on
using the GPL.
Not at all.
In which case why bother?
Because Mozilla can't be used by GPL projects otherwise. Note: *used*,
i.e. compiled and distributed. Development should (!= must)
*** REPLY SEPARATOR ***
On 21/09/2001 at 14:34 Ben Bucksch wrote:
Simon P. Lucy wrote:
I have said that the only way to use the source is to remove the GPL/LGPL
language. But its not the binary that matters, you have to make sure for
all uses. This effectively still means
Things like NSPR and XPCOM are extremely cool technlogies which would be
of great use to other free software projects, who would not have to
re-implement the portable-runtime and cross-platform component model wheels.
Speaking of which, because XPCOM is so very useful, are there any
plans
On 20/09/2001 at 14:55 Gervase Markham wrote:
You have the wrong end of the stick. It's not that way round, it's the
other way round - developers who want to combine our code with GPLed
apps. We still aren't letting GPLed code into the tree. For one example
of a group who want to use our code
On 20/09/2001 at 15:00 Gervase Markham wrote:
This is not the case. Let's do a thought experiment:
You have a file of code. You make three copies and put one of the
license header from the MPL, LGPL and GPL on each one. Whenever you make
changes to the file, you update all three copies. If
Simon P. Lucy wrote:
However this is not the case, there are not three files but one.
Think of it like Breathsavers mints; every Mozilla file is 3 files in one. When
you license your code out you can pick which of the 3 you want to use, or you
can relicense it as all 3. And, being the copyright
license
header from the MPL, LGPL and GPL on each one. Whenever you make
changes to the file, you update all three copies. If someone wants to
use the file, he picks which copy to use. If you are, for example,
Netscape,
However this is not the case, there are not three files but one.
On 20/09/2001 at 21:45 jesus X wrote:
Simon P. Lucy wrote:
However this is not the case, there are not three files but one.
Think of it like Breathsavers mints; every Mozilla file is 3 files in one.
No it isn't, there is only one file. Legally its a single entity. This idea of it
being
On 20/09/2001 at 19:04 Gervase Markham wrote:
license
header from the MPL, LGPL and GPL on each one. Whenever you make
changes to the file, you update all three copies. If someone wants to
use the file, he picks which copy to use. If you are, for example,
Netscape,
However this is not
This is not the case. Let's do a thought experiment:
You have a file of code. You make three copies and put one of the
license header from the MPL, LGPL and GPL on each one. Whenever you make
changes to the file, you update all three copies. If someone wants to
use the file, he picks which
Daniel Veditz wrote:
Note that there are at least two folks--Simon Lucy and myself--who
object to specifics in the current proposal for dual licensing (though
not the concept itself) on the same grounds that GPL zealots dislike
non-GPL licenses. It would allow people to turn the code
Mitchell Baker wrote:
The additional language was added so that recipients who receive a file
can be sure they can use it under either license. This may sound silly,
but a lot of those who might use Mozilla, especially companies with due
diligence and risk analysis requirements, look for
There are two discussions here. One regards the MPL itself, and its use
by the mozilla project. The other regards the proposed dual/tri licensing
with the LGPL and or GPL. The former is an interesting discussion which
we should continue. But it should not stop us from proceeding with the
On 13/09/2001 at 09:31 Mitchell Baker wrote:
There are two discussions here. One regards the MPL itself, and its use
by the mozilla project. The other regards the proposed dual/tri licensing
with the LGPL and or GPL. The former is an interesting discussion which
we should continue. But it
Simon P. Lucy wrote:
the GPL effectively removes the original
copyright (insofar as original copyright holders have rights to any
derivable product) and gives it away to all and sundry.
The MPL, and a few other licences avoids this imposition.
Does the MPL give the original copyright holder
On 13 Sep 2001, Ben Bucksch wrote:
Ian Hickson wrote:
The only case that would be a problem is distributing the proprietary
plugin with the GPLed Mozilla with the intent of using the whole as a
Flash renderer. In practice, I see no one doing that.
Why not? Nokia does distribute Mozilla
On 14/09/2001 at 00:56 Ben Bucksch wrote:
Simon P. Lucy wrote:
the GPL effectively removes the original
copyright (insofar as original copyright holders have rights to any
derivable product) and gives it away to all and sundry.
The MPL, and a few other licences avoids this imposition.
Does
On Thu, 13 Sep 2001, Daniel Veditz wrote:
Ian Hickson wrote:
On 13 Sep 2001, Ben Bucksch wrote:
Incidentally, the Flash issue seems to me to be a red herring. If, as an
end user, I obtain a copy of a GPLed version of Mozilla, and a copy of the
proprietary Flash plugin, then the GPL does
Ian Hickson wrote:
You mis-read what I wrote. Nokia do not intend their product to be used as
a Flash Renderer, they intend it to be used as a web browser. The point is
that the plugins are not deriative works (they in fact can be created,
compiled and used totally independently of the
Ian Hickson wrote:
In practice, though, our ability to be used in proprietary projects has
not really affected our market share relative to the market share obtained
through the Netscape brand release. Therefore if Netscape switched to the
GPL, we could switch to the GPL without this affecting
On Wed, 12 Sep 2001, Daniel Veditz wrote:
Ian Hickson wrote:
For that matter, why do we want to promote _any_ non-strong-copyleft
projects, other than Mozilla itself?
We want Mozilla to be used as widely as possible, by any project using any
license (including proprietary) that agrees
Ben Bucksch wrote:
Ian Hickson wrote:
The term (as used by the FSF) is extremely well defined. The GPL is a
license that ensures two things:
a. Code covered by the GPL will be free.
b. Code covered by the GPL won't be used with code that is not free.
Not exactly. Code covered under
Gervase Markham wrote:
AOL needs the COOL code closed because it doesn't want people writing
clients it can't control to access its service.
AOL doesn't even trust Netscape with the source to the COOL components, we
get binary drops.
Anyway, I think it's safe to say that a switch to
Ian Hickson wrote:
On Wed, 12 Sep 2001, Daniel Veditz wrote:
I'm lost, what's important to you?
On the long run, that everyone be allowed to do whatever they like with
all their programs, including modifying them, etc. (Emphasis on everyone and
all.
Everything, except combine it with
Ian Hickson wrote:
On Wed, 12 Sep 2001, Frank Hecker wrote:
Ian Hickson wrote:
And before anyone suggests it, licensing MPL/LGPL would be pointless,
since the MPL allows everything the LGPL allows and more
But IMO the MPL does not allow including Mozilla code in an LGPLed
library and
Ian Hickson wrote:
Why do we care about LGPL projects and not, say, projects using the
original BSD license, the Apache license, the Zope license, the IBM public
license, the Qt public license, the Sun Industry Standards Source License,
etc, etc, etc?
Because nobody has ever claimed that the
Frank Hecker wrote:
IMO Section 3 was intended for a specific case, a case explicitly
addressed in Section 3: This option [i.e., changing the license
notices] is useful when you wish to copy part of the code of the Library
into a program that is not a library. But IMO it's not a
On Thu, 13 Sep 2001, Ben Bucksch wrote:
Ian Hickson wrote:
The LGPL would also prevent anyone from building Mozilla using MSVC++,
since the MSVC++ redistributables license disallows reverse
engineering, and the LGPL requires that that be allowed.
There're tons of (L)GPLed projects using
On Thu, 13 Sep 2001, Ben Bucksch wrote:
Ian Hickson wrote:
On Thu, 13 Sep 2001, Ben Bucksch wrote:
Ian Hickson wrote:
Is there a need (real or perceived) for Mozilla code to be
distributable as an LGPL library?
Yes, for the same reason as to use it under GPL terms: In order to use
it
On Wed, 12 Sep 2001, Frank Hecker wrote:
Actually I should have said, the LGPL does not allow The MPL
clearly allows MPLed code to be combined with other code and the product
as a whole distributed under non-MPL terms.
This is different than relicensing the code. Both the MPL and the
Ben Bucksch wrote:
My personal opinion is that the GPL was poorly designed, because I think
that this very discussion should never have to happen. The GPL is, IMO,
not as free as other licenses.
Ssshh! The zealots might hear you!
Using the word free in conjunction with the GPL is sure
Ian Hickson wrote:
On Wed, 12 Sep 2001, Frank Hecker wrote:
Ian Hickson wrote:
Why do we care about LGPL projects and not, say, projects using the
original BSD license, the Apache license, the Zope license, the IBM public
license, the Qt public license, the Sun Industry Standards Source
Ian Hickson wrote:
On Wed, 12 Sep 2001, Frank Hecker wrote:
On the other hand, the GPL cannot be merged with any code other than GPL
code (except for OS and compiler libraries).
Not true, the GPL is compatible with code under quite a number of licenses
that the FSF enumerates.
The
Ian Hickson wrote:
must allow _their_ end users to reverse engineer their
program,
Does their peogram include linked libraries?
which at this stage includes the MSVC++ code, which the end user
is not allwed to reverse engineer.
Who says that? In Europe, reverse engineering is allowed for
Did the thread started in .general? Can you give a short summary?
Gervase Markham wrote:
I think Hixie's saying that if you want to combine with GPL code, you
have to change all the notices, as section 3 requires, before you can
do so. This is inconvenient (and may make returning changes
Ian Hickson wrote:
For example, consider the case when you take the source code for a
GPLed application and the source code for an LGPLed library used by
the application. You compile all the code, link it together (let's say
statically for the sake of argument), and distribute the resulting
work
Ian Hickson wrote:
The LGPL would also prevent anyone from building Mozilla using MSVC++,
since the MSVC++ redistributables license disallows reverse engineering,
and the LGPL requires that that be allowed.
There're tons of (L)GPLed projects using MSVC++.
The only case where I can see a
On Wed, 12 Sep 2001, Frank Hecker wrote:
I know what Section 3 says. My point is, is it _required_ as a
condition of the GPL or LGPL that when code under the LGPL is combined
with code under the GPL to create a work to be shipped under GPL terms,
that the LGPL license notices must first
I personally don't see any reason one could not combine code under the
GPL with code under the LGPL, leaving all license notices intact, and
then distribute the resulting work as a whole under GPL terms. To claim
otherwise would seem to imply that doing this violates the terms of
either
Ian Hickson wrote:
On the other hand, the GPL cannot be merged with any code other than GPL
code (except for OS and compiler libraries).
BTW: That exception might apply to the reverse engineering (in LGPL
license) as well.
On Wed, 12 Sep 2001, Frank Hecker wrote:
For the record, I don't believe that this is the case. I think that this
case is covered under Section 6 of the LGPL: [...]
Ooh, you may have a point there. Ok, I take my comments regarding the
requirements on GPL users for linking with LGPL code
On Thu, 13 Sep 2001, Ben Bucksch wrote:
Ian Hickson wrote:
Is there a need (real or perceived) for Mozilla code to be
distributable as an LGPL library?
Yes, for the same reason as to use it under GPL terms: In order to use
it in LGPL projects.
Why do we care about LGPL projects and
For example, consider the case when you take the source code for a GPLed
application and the source code for an LGPLed library used by the
application. You compile all the code, link it together (let's say
statically for the sake of argument),
I don't know if this makes a difference,
Gervase Markham wrote:
I personally don't see any reason one could not combine code under the
GPL with code under the LGPL, leaving all license notices intact, and
then distribute the resulting work as a whole under GPL terms. To
claim otherwise would seem to imply that doing this
Ian Hickson wrote:
Both the MPL and the LGPL
allow code covered by them to be linked with other code under other
licenses.
Yes, but the MPL allows this in more contexts than the LGPL. The
exception granted in the LGPL is for an application that calls the
LGPLed code in the form of a
On Wed, 12 Sep 2001, Frank Hecker wrote:
Ian Hickson wrote:
And before anyone suggests it, licensing MPL/LGPL would be pointless,
since the MPL allows everything the LGPL allows and more
But IMO the MPL does not allow including Mozilla code in an LGPLed
library and distributing the
55 matches
Mail list logo
