bug-gnulib
[Top][All Lists]
Advanced

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

Re: gplv3 files and updates


From: Brett Smith
Subject: Re: gplv3 files and updates
Date: Wed, 17 Oct 2007 12:57:43 -0400
User-agent: Mutt/1.5.11

On Tue, Oct 16, 2007 at 09:44:37AM -0700, Paul Eggert wrote:
> > 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 think I confused this thread by bringing up two issues that were only
tangentially related at the beginning.  I apologize for that; I didn't
realize they were quite so tangential at the time.

I agree with you 100% about how users should treat the licensing of gnulib
files they get through consumer projects like coreutils: they should rely
on the information in the header, and it'd be a lot of trouble to try to
advertise the alternative licensing options to them.  I have no problem
with maintainers of projects that use gnulib sticking with the standard
GPL/LGPL notices on the files as appropriate.

And I know you can't be responsible for the various ways that different
projects use gnulib, so I'm not asking you to police them and make sure
they do it the right way, or somehow enforce rules on them.

The only thing I'm concerned about at this point is the licensing
information within gnulib itself.  Right now, if I grab gnulib from git,
the header on the argp source will tell me that the code is GPLed, but the
documentation in the modules directory will tell me it's LGPLed.  I think
it would be very helpful for both of those sources of information to say
the same thing: that the code is LGPLed.  I'm primarily concerned with
consistency, so that when people look at the gnulib source (as it exists in
its own git repository, not consumer projects), it's unambiguously clear to
developers that they can use the code under the LGPL.  Helping them find
out that the code exists in the first place is a separate problem that can
be addressed better through channels other than license headers, and is at
most a secondary concern of mine.

But, like I said in my last e-mail, I want to see this information made
consistent without making your maintainership jobs harder, which is why
I've been asking so many pesky questions about how you all use gnulib in
your own projects these days.

>From what I understand, there's a historical reason why the file headers
say the code is GPLed, even though the documentation says it's LGPLed.
That's because most projects using gnulib were GPLed, and wanted to use the
files under the GPL, and were typically copying them directly into their
own source repositories.  So having the file headers say "this is GPLed"
was a straightforward way to satisfy the common use case.

However, I then got the impression that gnulib-tool is now the standard way
to get gnulib files into your project's source repository.  If that's the
case, then I think there's an easy way to make the licensing information
consistent without making your jobs harder: simply put the standard LGPL
license header notice on the files that are LGPLed, and give gnulib-tool a
--gpl switch to convert the files' headers to a GPL license notice on
request.  Or if you don't want to change gnulib-tool's interface, have it
assume that it should change the license headers to GPL by default, and
have the existing --lgpl flag keep the LGPL license header that would
already be on the files.

So, as long as everyone's using gnulib-tool, I think that's the preferable
way to go, because then we don't have to write any new text for the license
headers.  So that's why I'm asking the question: is it true that you all
are using gnulib-tool?  Again, I understand that there may be other
developers out there who aren't, but they can fend for themselves.  I'm
just concerned about you all as core GNU maintainers.

If I've misunderstood something, and not everyone's using gnulib-tool, then
we can proceed with the work on some sort of change to the license notice
on the LGPLed files.  But I'd like to know if there's some reason why the
above won't work first.

Thanks again,

-- 
Brett Smith
Licensing Compliance Engineer, Free Software Foundation




reply via email to

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