Re: GPLv3 suggestion to solve KDE/QT problem and others
On Sun, Feb 20, 2000 at 08:04:10PM -0500, Raul Miller wrote:
> 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".]
Aren't the restrictions transitive as well? IANAL...
> > > ...
> > >
> > > > 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.]
Hmm. Reusing code between different licenses is not the issue... There
are many compatibility problems between licenses. But not even to be
able to reuse code between software that use the same license seems
problematic to me. You are right *hit forhead with palm*, the QPL is
not a Free license because it does not allow code reuse. It is strange
that DFSG does not mention code reuse anywhere. This should be after
"Derived Works":
Code Reuse
The license must allow combining different works or parts
of works distributed under the same license, and must allow
them to be distributed under the same terms as the license
of the original works.
Then WHY did the FSF approve the QPL? Harmony was already on its
way...
>
> > > 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...
I was responding to what I thought was the most likely meaning of what
you said, which was that DFSG allowed proprietary licenses.
> > 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.
When looking at things from this angle... The problem of GPL
incompatibility with other licenses (not necessarily the QPL) results
from the GPL's definition of Freedom being different from that of the
DFSG (or the FSF or whatever). Were the definitions identical there
would be no "Free but GPL-incompatible" licenses listed on the FSF's
license page. Is this the case? If so, would you say the GPL is too
strict or the FSF too relaxed?
> > 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.
If the QPL (or any other non-GPL license) is considered a Free
license, this shouldn't be a problem. The way I see it the original
authors already gave the FSF a permission to do such things when they
gave users a permission to use any later version of the GPL with their
software.
Strengthening the GPL would not have any effect as users would always
be able to use the older, weaker versions. The mechanism in which
newer versions of the GPL can be used with software copyrighted before
the license upgrade therefore is only useful when weakening the
restrictions, and this is why I assume that was the original intent.
It might be interesting to strengthen some aspects of it and weaken
others so that users would have to choose which rights they have but I
don't know how it might be useful to the problem at hand.
> > > 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).
Are there any examples of this? I'd say the final terms by which
software may be distributed are the ones that should be compared
against the DFSG, whether it's a single license, a union or whatever.
> --
> Raul
- Adi Stav
Reply to: