[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sunset clauses



On Wed, May 15, 2002 at 01:30:34PM -0700, Mark Rafn wrote:
> Agreed.
> 
> However, the derivative work of X software linked to Y software may not be
> free even if X and Y are both free.  This is true regardless of the sunset
> clause, and is the entire GPL/OpenSSL problem.  It still exists unless the
> exemption is perpetual.

...or until the licenses or X and/or Y are changed to resolve the
incompatibility.  As the author of apt's sunset clause, I can frankly
tell you that the motivation was not to be bitchy to Corel, but:
  1) to get Corel legally in the clear so that their Debian-derived product
     wouldn't have PR or legal problems from a tussle with Debian (who
     could be expected to stand behind Jason's rights as author);
  2) to bring the Qt/GPL problem to Corel's attention so that they would
     be motivated to talk to TrollTech about it.  After getting clueless
     advice from Joseph Carter, who represented himself as coming from
     Debian, and suffering the backlash from us when the license turned
     out to not solve the problem, TrollTech stopped listening to us.

I can't tell you for sure what Jason's motivations were, all I know is
that appeared satisfied with the sunset clause as written.  A few folks
from this list helped me write it.

> Imagine software that is GPL, and has a time-limited additional right 
> to distribute when linked with OpenSSL.

Yes, and in fact I would advocate just such an action.

> The software itself is free.  No question.  It would be free under pure
> GPL, so it's free both before and after the sunset.

Yes.

> The derivative work that is the software linked with OpenSSL is not free
> IMO.  It has a license that expires.  It's free before sunset, unlawful to
> distrubute after the exception expires.

But this is only due to factors outside that software's control.  People
shouldn't write GPL'ed applications that use GPL-incompatible code in
the first place.  Debian has no license to distribute it when they do;
that's why we didn't ship KDE.  A sunset clause such as the one I'm
talking about *does* make it possible for Debian and anyone else to
distribute such a piece of software freely.

> This makes sunset clauses where the post-expiry license is not a pure
> superset of the pre-expiry license quite problematic.  It's certainly
> free, but only as long as the conditions of both licenses are followed.
> 
> Unless I misunderstand how the sunset clause is expected to work, I don't 
> see how it benefits anyone.

By motivating people with silly licenses to change them.

Say I have written an application called "fruitbat" that links against
libssl.  If I license it ONLY under the GNU GPL, Debian can't distribute
it because of the stack of advertising clauses in the libssl license.
So I dual-license the software with a sunset clause granting permission
to link against libssl.

There are 4 possible outcomes:

1) The Free Software Foundation changes the GPL to permit the addition
of advertising clauses.  I once would have thought this laughably
unlikely; after reading http://www.gnu.org/copyleft/fdl.html I no longer
feel secure in that assumption.

2) The copyright holders of OpenSSL remove the stack of advertising
clauses.

3) I extend the term of my sunset and renew my hope that 1) or 2) happens.

4) I get disgusted with either the FSF or OpenSSL and tell people they'd
better quit distributing binaries linked against libssl once the sun
sets.

Because our Social Contract dedicates us to our users *as well as* Free
Software, it may be that as a matter of Policy we decide not to let
things into main that don't run a risk of making themselves
undistributable by us in the future, even if that risk is fundamentally
due only to the actions of third parties.  This is because it might
gravely inconvenience our users to have software effectively and
suddenly disappear from our distribution.  If I understand the
motivations behind your post, this is what you're worried about and I
sympathize.  In fact, I'd probably agree with not letting such softare
into Debian.  Debian reserves the right to not distribute any particular
piece of software, or not distribute it in main even though it meets the
DFSG.  The reason we reserve that right is for strange cases like this.

However, your concern is inapplicable when software with GPL linking
problems is *already* in main.  Under such circumstances, I would say
that it benefits our users more to lobby the upstream author for a
permanent or temporary license change so that we can continue to
distribute it.  If the upstream author elects to go the sunset clause
route, we'd probably want to warn our users that circumstances beyond
our control may force us to remove the software from Debian at a future
date.  Such things are never completely avoidable.  The U.S. Congress
could pass a bill that renders cryptographic software illegal, and
things would have to change in Debian.

This scenario didn't crop up with apt because Corel's package manager
was not, at the time, part of our distribution.  Apt itself was never in
any sort of difficulty.  The sunset clause on apt's license therefore
did not have any impact on our users.  I don't know if Corel's package
manager is in our distribution today, and if so, what version of libqt
it links against.

-- 
G. Branden Robinson                |    The first thing the communists do
Debian GNU/Linux                   |    when they take over a country is to
branden@debian.org                 |    outlaw cockfighting.
http://people.debian.org/~branden/ |    -- Oklahoma State Senator John Monks

Attachment: pgp71ajTj9Ine.pgp
Description: PGP signature


Reply to: