Re: gnulib/poll.c license

[Eric Blake]

On 10/25/2012 08:15 AM, Thomas Martitz wrote:
>> This has been asked before on this list, and the answer has always been
>> that it is more work than worth the effort, and that gnulib-tool is the
>> preferred way to use gnulib source code.
>>
> 
> I cannot really understand your reasoning as it makes it hard to
> discover that less restrictive license terms are also possible. I
> wouldn't have found that LGPLv2+ is no problem if I didn't go through
> the "hassle" of writing mails and subscribing to this mailing list.

You don't have to subscribe to bug-gnulib to post here.  List policy
here (as on many other GNU lists) is to allow anyone to post, and to use
reply-to-all so that non-subscribers still stay part of the thread.

Picking and choosing just a .c file is too likely to go wrong - most of
gnulib depends on also picking up .m4 files, replacement .h files to
work around broken system headers, and module dependencies.  To really
use a module, you have to use the full information under the modules/
directory - and gnulib-tool really is the easiest way to use this full
information, including licensing terms.

> Perhaps it could be made more prominent on the gnulib website, at least.

What page would you suggest enhancing to more prominently call out the
fact that we recommend gnulib-tool as the way for using gnulib files?

> 
> Additionally it means extra work when merging upstream fixes harder,
> which is unfortunate.

On the contrary, I find gnulib-tool quite easy to use; much easier than
the counterpart of trying to hand-pick multiple files to copy into place.

> 
> But if you have determined that this approach works better for you I'm
> not going to question it any further.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature