This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus on MT-, AS- and AC-Safety docs.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Torvald Riegel <triegel at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Rich Felker <dalias at aerifal dot cx>
- Date: Mon, 02 Dec 2013 16:38:17 -0500
- Subject: Re: Consensus on MT-, AS- and AC-Safety docs.
- Authentication-results: sourceware.org; auth=none
- References: <528A7C8F dot 8060805 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1311182312130 dot 8831 at digraph dot polyomino dot org dot uk> <orob5fv8nl dot fsf at livre dot home> <Pine dot LNX dot 4 dot 64 dot 1311201555320 dot 28804 at digraph dot polyomino dot org dot uk> <orli0itbm5 dot fsf at livre dot home> <Pine dot LNX dot 4 dot 64 dot 1311211322040 dot 14539 at digraph dot polyomino dot org dot uk> <or4n75t4b7 dot fsf at livre dot home> <Pine dot LNX dot 4 dot 64 dot 1311221324200 dot 5029 at digraph dot polyomino dot org dot uk> <orob5csdvx dot fsf at livre dot home> <52985836 dot 4050700 at redhat dot com> <orli05k7sd dot fsf at livre dot home>
On 11/30/2013 02:29 PM, Alexandre Oliva wrote:
> On Nov 29, 2013, Florian Weimer <fweimer@redhat.com> wrote:
>
>> Hmm. Could we make this data available in machine-parsable form,
>> under a free software license (which the GFDL isn't)?
>
> The @safety notes are always right after the corresponding
> @deftypefu?nx? lines, and the transition to macros for all keywords
> should make this even more parseable than it was. I'm sure we can
> contribute the code with an additional permission for the information to
> be extracted and transformed under some other license.
>
> Do you have any specific license in mind? It doesn't seem critical for
> the purpose above that it be a software license. After all, this is
> just data, that a program would read in, perhaps transform and output in
> another form, for visualization, storage or further transformation. For
> this purpose alone, even GNU SFDL would do, and that would be pretty
> easy to accomplish with a simple addional permission; heck, we could
> even have the build machinery extract the info and attach the intended
> license to the result. (Worst case, we could do it the other way round,
> maintain the info separately and insert it as part of the build process,
> but that would be a lot more inconvenient to maintain, I think)
This is certainly a very good point. It would be nice to have this
information in a license form that would allow it to appear without
say needing the front-matter to be present (impossible in a tooltip
display while hovering over a function) as is required by GFDL IIRC.
The reason most people like free software licenses is that they work
well with documentation that is embedded in code and extracted. We
have discussed embedding this information into function definitions
and then extracting it for the build process.
Cheers,
Carlos.