--- Begin Message ---
|
Subject: |
Re: gplv3 files and updates |
|
Date: |
Fri, 6 Jul 2007 22:25:37 -0400 |
|
User-agent: |
Mutt/1.5.11 |
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 ---
--- Begin Message ---
|
Subject: |
confirm 307598579516f9399551670b8a18a250eb8cc76d |
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message. Do this if the message is
spam. If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list. The Approved: header can also appear in the first line
of the body of the reply.
--- End Message ---