bug-gnulib
[Top][All Lists]
Advanced

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

Re: gplv3 files and updates


From: Paul Eggert
Subject: Re: gplv3 files and updates
Date: Tue, 16 Oct 2007 09:44:37 -0700
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

Brett Smith <address@hidden> writes:

> The confusion comes up because the headers in the individual files
> say something else: they say it's GPLed, period.  Given this
> discrepancy, which source of information should users believe?

They should believe the license information on the files that they
have.  If it says GPL, then it's GPL.  If it says it's LGPL, then it's
LGPL.  The retrieval method for getting files from gnulib generates
files that use either wording, so it's up to the guy who retrieves the
files to get it right.

> I don't think that's clear to newbies.

No matter _what_ we do, it won't be clear to newbies.  The GPL/LGPL
licensing rules are complicated.  Newbies cannot understand them at a
glance.

> That doesn't create any serious trouble for anybody

Yes, and that's the point.  We have a situation where there is a real
hassle for developers dealing with these files, which can cause real
trouble during development.  We need to trade this off with the
confusion by people who get files from gnulib with licenses that are
more restrictive than they want.

> I'm starting to think I misunderstood the situation, and some
> projects are still using gnulib files directly without gnulib-tool.

There is always cut-and-paste.  People will always do that, regardless
of gnulib-tool.

> Perhaps the best thing would be
> to simply add an informational notice to the headers of LGPLed files;
> something like:
>
>    This file may be available under other licenses, such as the GNU LGPL.
>    See the gnulib documentation for details.

That sort of thing sounds reasonable, but it has to be a proper notice,
and not be so handwavy.  How about this wording instead?

   This file contains free software: you can redistribute it and/or
   modify it under the terms of the GNU General Public License as
   published by the Free Software Foundation; either version 3 of the
   License, or (at your option) any later version.  Alternatively, you
   can redistribute this file's contents and/or modify the contents
   under the terms of the GNU Lesser General Public License as
   published by the Free Software Foundation; either version 3 of the
   License, or (at your option) any later version.

   This file's contents are distributed in the hope that it will be
   useful, but WITHOUT ANY WARRANTY; without even the implied warranty
   of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   General Public License and the GNU Lesser General Public License for
   more details.

   You should have received a copy of the GNU General Public License or
   the GNU Lesser General Public License along with this file.  If not,
   see <http://www.gnu.org/licenses/>.

This wording would appear in the master copy, and in all copies
distributed in GPL or LGPL packages, without any changes.  This will
simplify gnulib-tool and will simplify the process of generating and
applying patches.

A downside of this wording is that it will publicize the existence of
the LGPL even in GPL-only packages.  So the proposal would have to run
by RMS.  That is why I changed the phrase "This program" to "This
file's contents" in the proposed wording above -- to emphasize the fact
that the permissions notice applies only to this particular source code
file, and not to the whole package in which it appears.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]