Paul Eggert wrote:
> > The practical drawback would be that the --symlink option, in the
> > coreutils situation, will copy more files and symlink less files.
> 
> That's a serious drawback, at least for the way I work.  When I
> develop, I commonly edit the gnulib copies and expect coreutils to
> track the changes.

Understood.

> Another possibility is to have two copies of the file in gnulib, one
> GPL'ed and one LGPL'ed.  We could automatically generate one copy from
> the other.

I wouldn't do that: Redundant copies do eventually get out of sync. They
cause perpetual occasional trouble.

Since you want to work directly on symlinks to gnulib files: how about
two other options?

  a) Add another option to gnulib that avoids the license changes altogether.
     You would use this option; Jim when making release tarballs would not.
     Drawback: Jim needs a special directory for making release tarballs.

  b) Push back the license substitution moment to "make dist". I.e. You
     work on symlinks to gnulib files that carry mixed GPL/LGPL notices,
     but "make dist" creates a tarball with only GPL notices.

Bruno
     


Reply via email to