Licenses restrict your range of (legal) actions. GPL and APL are two sets of
restrictions. If you can choose either GPL or APL, and switch back and forth
at any time:
a. You can remove a GPL-only restriction that doesn't suit by saying APL
applies.
b. You can remove an APL-only restriction that doesn't suit by saying GPL
applies.
So therefore:
c. You are restricted only by that subset of conditions that is common to
both APL and GPL.
Or did I miss something?
Alan.
-Original Message-
From: Ceki Glc [mailto:[EMAIL PROTECTED]]
Sent: Friday, 23 February 2001 1:07 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Test Infrastructure Project Proposal
Peter,
Thanks for your reply. My question was really about the logical meaning of
dual licensing. For example, assume that the GPL has requirements G1, G2, Gn
and the APL has requirements A1, A2, ..., Am, does dual licensing mean:
1) All of G1, G2, .., Gn, A1, A2, ..., Am must be satisfied.
2) Either all of (G1, G2, ..., Gn) must be satisfied or all of (A1, A2, ...,
Am) must be satisfied but not both group of conditions.
Interpretation 1 is the worst of both worlds. As such I don't think it would
satisfy anybody, quite the contrary.
Interpretation 2 is probably correct. What happens to derivative work
licensed under GPL/APL? Must it be GPL/APL too? In particular, what happens
to fresh code that links to the original GPL/APLed code...
Doesn't dual licensing leave the door wide open for abuse? If tomcat were
dual licensed, then one could usurp the tomcat label (by invoking GPL terms)
and have code with a totally different license link with tomcat (by invoking
APL terms). This situation is not logically equivalent to 2 but who is going
to prove otherwise? Are you confused? I know I am. Ceki
At 12:38 23.02.2001 +1100, Peter Donald wrote:
At 02:32 23/2/01 +0100, Ceki Glc wrote:
Absolutely agree. However, a good portion of the world does not. We should
strive to accommodate both camps. Could anyone explain what dual GPL/APL
licensing really means? Thanks in advance, Ceki
In terms of Apache it means the value of the Apache name is devaluaed to a
degree. At the moment you can not fork off code but you can not use same
name as Apache project. So if you forket tomcat you could use the code but
would need to name it something else. As at the moment the Apache name is
largely synonymous with quality (with a few exceptions) this could be a
significant threat to some. The only way to get around this would be to use
trademark law (either common or registered trademarks) to protect names but
that is a lot more work/money. The other issue is that the APL requires
giving credit which is either good or bad depending on who you ask ;)
Cheers,
Pete
*-*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-*
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Ceki Glc Web: http://qos.ch
av. de Rumine 5 email: [EMAIL PROTECTED] (preferred)
CH-1005 Lausanne [EMAIL PROTECTED]
Switzerland Tel: ++41 21 351 23 15
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
