"Alfred M. Szmidt" <a...@gnu.org> writes: > doc/fdl.texi is removed below > > If I'm understanding correctly, removing fdl.texi seems wrong to > me. I'm supposing it's created dynamically from a copy in gnulib > or somewhere now? But the license can't be updated merely by > changing that file. The @copying block has to be updated also. In > fact, the @copying block now says 1.2, but (I'm guessing) fdl.texi > v1.3 is what gets pulled in. > > I think the right outcome is: > 1) change 1.2 to 1.3 in @copying in inetutils.texi. > > 2) keep a copy of fdl[-1.3].texi in the repo. > > 3) in the event that the fdl is updated, both things need to be > updated. I don't know of any plausible way to automate it, and > updates are so infrequent, it doesn't seem worth the effort. > > You raise good points and thank you for catching them, I am not sure > what we should do. coreutils for example doesn't include fdl.texi, > and coreutils is generally our guideline when it comes to these > things. > > Jim and co, what do you think?
After the patch I installed to inetutils [1], I think actually the only problem is that the gnulib 'fdl' module is a moving target. That doesn't really work, as Karl explained, since the main manual needs to be updated manually whenever there is a FDL version update in gnulib. So in gnulib, I propose we deprecated 'fdl' and ask maintainers to depend directly on 'fdl-1.3' or whatever version they need. Thoughts? I cc yet another list, bug-gnulib, to get this archived for the gnulib context as well, in case we end up modifying gnulib. Note that gnulib does not contain a 'gpl' or 'lgpl' module, only 'gpl-2.0', 'gpl-3.0', and 'lgpl-2.1'. (Although no lgpl-3.0..) So it seems the 'fdl' module is sub-optimal. /Simon [1] http://lists.gnu.org/archive/html/commit-inetutils/2009-05/msg00001.html
