This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Add missing copyrights
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, OndÅej BÃlka <neleai at seznam dot cz>, libc-alpha at sourceware dot org
- Date: Tue, 11 Jun 2013 18:57:31 -0400
- Subject: Re: [RFC] Add missing copyrights
- References: <20130611133800 dot GA4128 at domone dot kolej dot mff dot cuni dot cz> <Pine dot LNX dot 4 dot 64 dot 1306111928100 dot 897 at digraph dot polyomino dot org dot uk> <20130611200107 dot 34B552C058 at topped-with-meat dot com> <51B78716 dot 9090701 at redhat dot com> <20130611210407 dot 25B9F2C09D at topped-with-meat dot com> <51B79607 dot 4050002 at redhat dot com> <20130611213518 dot 5D9C82C09F at topped-with-meat dot com> <51B7A361 dot 5030904 at redhat dot com> <20130611224559 dot A79852C045 at topped-with-meat dot com>
On 06/11/2013 06:45 PM, Roland McGrath wrote:
>> On 06/11/2013 05:35 PM, Roland McGrath wrote:
>>>> Do we have a file that contains no license but needs a license that
>>>> is not the boiler plate for the project?
>>>
>>> If a file that's empty except for comments needs any license at all,
>>> then sysdeps/init_array/crt[in].S are such files.
>>
>> Do we expect many more of these files to be present in glibc?
>
> You mean, new ones to be added? There will be a new start.[cS] (crt1.o)
> for every new port. For any new ports that don't use sysdeps/init_array,
> there will be new crt[in].S files. There may well be new libc_nonshared
> cases in the future.
>
>> That would have been a real inconvenience for downstream, but is such
>> a scenario a real problem for the project? It seems like a fail safe
>> scenario under which our licensing is too restrictive and requires us
>> to back off from a position of safety?
>
> As long as the ownership is clearly FSF, then there is never a "real
> problem for the project". We can always change the terms in future
> versions, whether to be more permissive or to be more restrictive.
> But if we start out with restrictive conditions on files that get
> linked into user binaries, it is a problem for our users.
Thanks for talking this out. I'm sufficiently convinced that you're
probably right, but I'm still worried about missing license headers.
The only solution appears to be good old fashioned human review.
Cheers,
Carlos.