Re: GPLv3 suggestion to solve KDE/QT problem and others
On Mon, Feb 21, 2000 at 02:45:15AM +0200, Adi Stav wrote:
> I was only using what I perceived to be the most common way to mean "a
> license restriction that requires all code linked to or from a certain
> program to be licensed under the same license as the program". In THAT
> sense most proprietary licenses are not viral as they don't care what
> you link to them, as long as you don't distribute the program itself.
>
> I agree that this term does have some negative overtones but I feel
> that "strong copyleft" is not exactly the same thing. I didn't mean it
> negatively, anyhow.
I think you're referring to the GPL property I think of as transitive
rights. [As in "transitive closure", not "transitive verb".]
> > ...
> >
> > > If this change is made, Free Software will still have the advantage
> > > over proprietary software, as it would still be illegal for
> > > proprietary software to link to GPLd libraries.
> >
> > QPL is a proprietary license. Clause 3b makes it so.
>
> Clause 3b?
b. When modifications to the Software are released under this
license, a non-exclusive royalty-free right is granted to the
initial developer of the Software to distribute your modification
in future versions of the Software provided such versions remain
available under these terms in addition to any other license(s) of
the initial developer.
> I fail to see why this would make it non-free. If the modifier did
> not choose to release their modifications as Free Software, the
> initial developer still has the right to force this by releasing those
> modifications under the QPL. Definetely not copyleft, but not worse
> than BSDL. And you're allowed to make unpublished modifications, as
> the clause is only activated "When modifications to the Software are
> released".
Unpublished modifications are irrelevant. And, the BSD license lets
you use whatever additional license you choose on modified works --
as long as you retain the original.
The QPL *requires* that you allow the original author to re-release it
under any other license that the original author chooses. This can be as
proprietary or restrictive as the original author chooses.
Needless to say, if you don't have the authority to grant this kind
of copyright you can't incorporate someone else's code into a QPL mod.
[And this is the biggest conflict between the QPL and the GPL.]
> > DFSG allows proprietary licenses. GPL does not.
>
> I'm not sure what you mean by that... Of course DFSG doesn't allow
> proprietary licenses.
I don't know why you bother saying that you don't know what I mean
at the same time you contradict me. You should at least explain
what you mean...
> Its very goal is to define what's Free and what's proprietary (unless
> you're using a different definition of "free"). The QPL is considered
> Free by all of DFSG, OSD (irrelevant here) and the FSF. I can't think
> of any other important Free Licenses definitions.
Each Free License is itself a Free License definition of sorts (based
on what other licenses can be combined in a work). The BSD license
defines a very relaxed sort of freedom which just means that the author
gets credit for their work. The GPL defines a much more specific sort
of freedom which guarantees that developers can continue to work on
whatever forks they choose. Etc.
> Please clarify? :)
>
> > Perhaps you're thinking of authoring a GPL-like license which allows
> > any DFSG software to be combined?
>
> That could indeed be useful but is not what I had in mind. I did mean
> upgrading the GPL.
I hope you understand that I think of what you're suggesting as
downgrading the GPL.
If you were really thinking of taking a license and adding more guarantees
of freedom you'd be talking about the LGPL -- or, if its protections aren't
strong enough for you, you'd be talking about upgrading it so that those
protections are stronger.
Instead you're talking about weakening the GPL so that it can be legally
used in conjunction with QPLed software without getting proper permission
from the original authors.
> > DFSG doesn't even require that licenses not contradict each other.
>
> Hmm... Why would it need to require that? If a product has
> contradicting licenses, it would be illegal to distribute by
> definition, and its Free license would be already contradicted.
That's the case when the GPL is involved. In other cases the result may
be more ambiguous (perhaps granting only the rights of the union of the
respective licenses, or perhaps not -- I doubt there's a general rule
for the general case of this sort of thing).
--
Raul
Reply to: