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
