--- Begin Message ---
|
Subject: |
failure notice |
|
Date: |
7 Jul 2007 09:23:57 -0000 |
Hi. This is the qmail-send program at toaster1.peak.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<address@hidden>:
AUTORESPOND: Junk mail received.
--- Below this line is a copy of the message.
Return-Path: <address@hidden>
Received: (qmail 8209 invoked by uid 89); 7 Jul 2007 09:23:57 -0000
Delivered-To: address@hidden
Received: (qmail 8204 invoked by uid 89); 7 Jul 2007 09:23:56 -0000
Received: from unknown (HELO lists.gnu.org) (199.232.76.165)
by toaster1.peak.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 7 Jul 2007
09:23:56 -0000
Received-SPF: pass (toaster1.peak.org: SPF record at gnu.org designates
199.232.76.165 as permitted sender)
Received: from localhost ([127.0.0.1] helo=lists.gnu.org)
by lists.gnu.org with esmtp (Exim 4.43)
id 1I76WA-0007OQ-5M
for address@hidden; Sat, 07 Jul 2007 05:23:54 -0400
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
id 1I6zzN-0005Bd-RC
for address@hidden; Fri, 06 Jul 2007 22:25:37 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
id 1I6zzM-0005BR-Dn
for address@hidden; Fri, 06 Jul 2007 22:25:36 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
by lists.gnu.org with esmtp (Exim 4.43) id 1I6zzM-0005BO-8V
for address@hidden; Fri, 06 Jul 2007 22:25:36 -0400
Received: from fencepost.gnu.org ([140.186.70.10])
by monty-python.gnu.org with esmtp (Exim 4.60)
(envelope-from <address@hidden>) id 1I6zzL-0002Bk-Ue
for address@hidden; Fri, 06 Jul 2007 22:25:36 -0400
Received: from brett by fencepost.gnu.org with local (Exim 4.60)
(envelope-from <address@hidden>)
id 1I6zzN-0000jF-Sm; Fri, 06 Jul 2007 22:25:37 -0400
Date: Fri, 6 Jul 2007 22:25:37 -0400
From: Brett Smith <address@hidden>
To: Karl Berry <address@hidden>
Message-ID: <address@hidden>
References: <address@hidden>
<address@hidden>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <address@hidden>
User-Agent: Mutt/1.5.11
X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4)
X-Mailman-Approved-At: Sat, 07 Jul 2007 05:23:15 -0400
Cc: address@hidden, address@hidden, address@hidden
Subject: Re: gplv3 files and updates
X-BeenThere: address@hidden
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Gnulib discussion list <bug-gnulib.gnu.org>
List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/bug-gnulib>,
<mailto:address@hidden>
List-Archive: <http://lists.gnu.org/pipermail/bug-gnulib>
List-Post: <mailto:address@hidden>
List-Help: <mailto:address@hidden>
List-Subscribe: <http://lists.gnu.org/mailman/listinfo/bug-gnulib>,
<mailto:address@hidden>
Sender: address@hidden
Errors-To: address@hidden
On Fri, Jul 06, 2007 at 07:39:45PM -0500, Karl Berry wrote:
> I hope Brett will comment.
I'll admit up-front that I'm still not entirely sure I understand the
situation at hand, which is why I was holding off. But perhaps if I
describe the issues as I see them, hopefully that will be helpful.
Speaking generally, there are two main ways that the FSF, GNU, and
associated projects can really mess up licensing:
1. We can release something under more permissive terms than we intended --
e.g., LGPLing something we wanted to GPL.
2. We can fail to communicate to the user what the license is and what
their rights and obligations are.
I think everything else is a pretty easy bug to fix -- it might be
embarrassing, but it would all work out in the end.
The main goal here, as I understand it, is to make gnulib files readily
available under both the GPL and LGPL, with the appropriate headers. I
haven't heard anybody say that that's the wrong goal, and on my first
review, it seems pretty clear that the files in question should be LGPLed.
So I don't think we're facing problem number 1.
So it seems to me that we're having a discussion about whether or not we're
facing problem number 2. I'll lay all my cards on the table and say
up front that I'm personally a big fan of having license notices be as
visible, clear, and consistent as possible. They can help make sure that
everybody understands what's going on even after code has passed through
many different hands, and they can help enforce the license (something I
think about a lot ;) ).
I don't think this needs to be a matter of what's legal, or what's not
legal, or what a court case said or anything like that. A court's not
going to punish us if our license notices are confusing. Instead, a user
is going to decide they can't make heads or tails of it, and will just
refuse to use the code. So we should make sure it's as clear as possible
to that user. This is more about reasonable policy than law.
I understand Karl's concern about the current situation. Given
documentation that says the code has one license, and header comments that
say the code has another license, it can be difficult for a user to discern
which one is true. Even if there's documentation that says "The
documentation is authoritative," how can you be sure that's trustworthy?
Perhaps you have your own ideas about how much documentation of a license
should be good enough, but I would ask that you please respect that other
users may have different thresholds to reach before they're comfortable. I
think we should do what we can to make sure everyone's as comfortable as
possible.
With all that said, I also understand that gnulib is in a pretty unique
licensing situation, and so it may be difficult to get this to fit the
standard licensing policies that suffice for most other projects. But I
think it'd be worthwhile to spend a little time to see how close we can
get.
In that vein, Bruno, let me ask you a couple of questions. First: why does
gnulib want to make these files readily available under *both* licenses,
rather than just the LGPL? There are plenty of good answers to this
question -- heck, even just plain old developer convenience will suffice
for me -- I just want to know which ones are actually at play here.
Second: is there a particular reason why the automatic conversion goes from
GPL to LGPL, rather than the other way around? I ask because, under the
LGPL, *everybody* has permission to relicense the work under the GPL. So
if the headers that shipped with gnulib advertised the LGPL, and then
gnulib-tool offered to convert them to the GPL, it would be cleaner for a
couple of reasons. First, it would make the code headers consistent with
the documentation. Second, it would very obviously be legally
unquestionable, because the user running gnulib-tool would merely be
exercising this right that the LGPL grants them. So I'd like to know if
there's a particular reason not to do it that way.
Of course, if I'm misunderstanding anything more fundamental, or if there's
anything else you think that would be helpful to add, please don't hesitate
to let me know. And if anybody has any of their own questions about this,
I'd be happy to answer those.
Thanks everyone,
--
Brett Smith
Licensing Compliance Engineer, Free Software Foundation
--- End Message ---