Re: two semantics of fclose()

[Jim Meyering]

Bruno Haible wrote:
> Hi Eric,
>
>> > What is the semantic of fclose() that you want to test?
>> > Basically, you have two possible behaviours of fclose(), one is probably
>> > stricter POSIX compliant than the other.
>>
>> 1. fclose alone - guarantee that fdopen(sockfd) can be fclose'd
>> 2. fclose + fflush - guarantee that fclose(stdin) properly positions the
>> file on seekable input
>
> OK, that's how it's documented now, now that the dependency from fflush to
> fclose is dropped.
>
>> if we just relicense fflush to be LGPLv2+, then
>> fclose can depend on fflush to begin with, and always solve both
>> problems at once, at which point I don't see the need for an fflush-strict.
>
> Yes, this would be very reasonable. Few users would want only the
> halfway fixed fclose().
>
> Can we relax the license of 'fflush' and its dependency 'fpurge' from LGPLv3+
> to LGPLv2+?
>
>   lib/fflush.c - needs the permission of you, me, and Jim.
>   lib/fpurge.c - needs the permission of you and me.
>
> I agree to relax these two modules to LGPLv2+.

Relaxing fflush.c to LGPLv2+ is fine with me.