Re: Standards References

[Michael Kerrisk <mtk dot manpages at gmail dot com>]

On Tue, Oct 25, 2016 at 3:50 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 10/14/2016 05:33 AM, Rical Jasan wrote:
>> On 10/13/2016 11:32 PM, Carlos O'Donell wrote:
>>> On 10/14/2016 01:22 AM, Rical Jasan wrote:
>> To start fleshing out 1b below, would you want to use those names, or
>> names from feature_test_macros(7), or both?  I think I would lean
>> towards correlating the two, so rendered names might be more friendly
>> like standards(7), but were connected to the names in
>> feature_test_macros(7), allowing us to eventually say things like, "foo
>> is standardized by Nicely Formatted Standard Name, and made available
>> whenever _NFSN is defined.", or however we agree on the rendering.
>
> I would also lean towards correlating the two.

Yes, if we could have some consistency between the two projects, that
would be great.

> It also does us a big disservice if we deviate from the linux man pages
> project in this regard, and we should endeavour to harmonize what we can
> between the glibc manual and that project.

Agreed.

> I routinely get things committed to linux man pages and Michael is a very
> quick reviewer (unlike myself :-}).

Sometimes, I am quick. Sometimes I'm much worse than Carlos.

[...]

>>> A final note about copyright and licensing. The manual is GFDL and the
>>> source code is GPLv2, so you cannot copy any legally significant text
>>> from one to the other without relicensing permission by the FSF.
>>
>> When I do cull my knowledge from the sources, I don't copy/paste
>> anything.  If I can't restate it in a meaningful way from my own
>> understanding, I don't think I should writing the documentation for it
>> anyway.  But thank you for making that explicit, as I wouldn't have been
>> aware otherwise.
>
> Thank you for your consideration.
>
>> Should I avoid reading man pages for functions that aren't documented in
>> the glibc manual but that I intend on documenting because they are
>> present in the source, but absent from the manual?
>
> IANAL.
>
> Avoid reading what you can and write what you know.
>
>> What about other forms of documentation, like tutorials or forums?
>
> Worse. At least Michael has documentation about who contributed the material
> and under what license, so in the event of a conflict we might rewrite it or
> ask the original author to dual license.
>
> Alex and I dual licensed the safety notes, once for glibc and once for the
> man pages.

I don't have a glibc CLA (and don't plan to get one), but I'll help
out with relicensing as I can. Also, would try help with review. (but
please do explicitly CC me.)

Cheers,

Michael