Re: gplv3 files and updates

[Brett Smith]

On Mon, Oct 15, 2007 at 09:52:01AM -0700, Paul Eggert wrote:
> The gnulib README file says the following.  If this isn't clear enough,
> perhaps you or your correspondent could suggest a clearer wording?

There's nothing wrong with the README in isolation.  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?  If you're familiar with the gnulib project, you know
to follow the README and related documentation, of course.  But I don't
think that's clear to newbies.  In fact, it's possible that they won't see
the licensing information in the README at all, and think the files are
just GPLed.  That doesn't create any serious trouble for anybody, but it
does generate questions, and it possibly means that developers don't make
use of perfectly good code because they don't realize it's LGPLed.  I would
like to find a way to get both sources of information -- the file headers
and the README -- consistent in what they say.

I don't want to make your all's work as GNU maintainers harder.  As far as
I'm concerned, it's my job to make the software licensing serve you -- and
if I suggest some kind of licensing clean-up that makes more permanent work
for you, I've failed at that.

During the first round of this thread back in July, I thought we found a
solution that wasn't going to interrupt anybody's workflow.  I believed
that everyone was using (or supposed to be using) gnulib-tool, and so we
could put LGPL headers on the LGPLed files, and give gnulib-tool a switch
that would convert the headers to GPL on request for GPLed projects.  This
would make all the licensing information consistent by putting the most
accurate headers on files in the gnulib source, and I didn't think it would
make any more work when you maintain projects that use gnulib: you would
just have to make one tweak to your gnulib-tool call to make it do whatever
you needed, and then forget about it.

>From what Jim and Bruno wrote yesterday, I'm starting to think I
misunderstood the situation, and some projects are still using gnulib files
directly without gnulib-tool.  If that's the case, we'd need to find
another solution to stay out of your hair.  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 way, the license headers would clearly signal to everyone that the
README and such were authoritative, instead of staying silent on the
subject as they do now.

So, if someone could let me know which situation we're in -- whether all
individual projects should be using gnulib-tool or not -- I'd appreciate
it.  From there, I'm hopeful we can find a way to address this issue that's
both legally clean and equally easy for you all to work with.

Thank you very much,

-- 
Brett Smith
Licensing Compliance Engineer, Free Software Foundation