Re: .TH 4th field (Was: [PATCH 1/2] system_data_types.7: srcfix)

[Alejandro Colomar <alx.manpages@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 5308 bytes --]

Hi Ingo,

On 8/24/22 19:12, Ingo Schwarze wrote:
> Hi Alejandro,
> 
> Alejandro Colomar wrote on Wed, Aug 24, 2022 at 05:04:57PM +0200:
>> On 8/24/22 15:22, Ingo Schwarze wrote:
>>> Alejandro Colomar wrote on Sat, Aug 20, 2022 at 02:40:58PM +0200:
> 
>>>> Should I keep the static part of the COLOPHON in a REPORTING BUGS section?
> 
>>> I do not think a manual page should include *any* boilerplate text.
>>> Text that is the same everywhere is nothing but a distraction
>>> and a waste of screen real estate.
> 
>> Agree.  I was hesitant of removing that, which mtk added a long time
>> ago, since he claimed an important improvement in awareness of the
>> existence of the project.  But I prefer using reportbug(1) and dpkg(1)
>> or apt(8) (or equivalent in other distros) to find out how to report bugs.
> 
> Hum.  Interesting aspect.  Maybe Micheal had a point that advertising
> the Linux man-pages project - even in such an aggressive way - had some
> value in the early days.  I'm not an expert in Linux history, but i
> believe use of manual pages was initially much less common in Linux-
> based operating systems compared to AT&T UNIX, other commercial UNIX
> systems, and BSD.  Also, due to the fragmentation of Linux-based
> operating systems into Linux (the kernel), GNU (the most important
> parts of userland), and software from many third-party sources,
> a single, uniform corpus of manual pages was slower to develop for
> Linux than, for example, in BSD.
> 
> But nowadays, i would no longer subscribe to such a theory, it seems
> to me that times have changed in this respect.  Debian has fostered
> some progress in writing missing manual pages.  Web sites like
> manpages.debian.org and even man.archlinux.org now provide more
> comprehensive collections of manual pages than even BSDs do.
> And such sites usually clearly identify package names, much reducing
> the effects of the conceptual fragmentation.  So i expect many more
> Linux users are now aware of the man-pages project than used to be,
> and even those who aren't yet are likely to find out once they need to.

Removed: 
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=8c3052b0322580eba62de91f04ba657f7dfe360e>

this time it seems your name and email are correct :)

> 
>> Greg KH expressed concern about the copyright of the example programs
>> some time ago.  He asked what license applies to them, and how should a
>> user know, that is, is a user allowed to create derived programs from
>> those examples?  Should we state their license in a C comment within the
>> example program?  Or just assume that it's a meaningless program and
>> that anyone can just copy it indiscriminately because, who cares about
>> such a tiny insignificant piece of code?
> 
> That is an interesting question, too.  I believe it never occurred
> to me because EXAMPLES in OpenBSD manual pages are typically kept so
> short and simple that they only demonstrate well-established aspects
> of prior art and do not really involve any creative act by the author
> of the manual pages, hence obviously being in in the public domain
> in the first place.
> 
> But in the Linux man-pages project, you have many long and complex
> programs below EXAMPLES, some of which certainly pass the test of
> originality, hence being protected by Copyright law.
> 
> Now obviously, unless otherwise stated, such examples are covered
> by the SPDX-License-Identifier: at the top of the file.  For pages
> licensed under the BSD or MIT licenses, everything is obviously
> fine, anyone can use such example code in any project.  For pages
> under GPL licenses, the situation is also tolerable: while BSD
> projects cannot use these example, at least GPL projects can, which
> feels like the main purpose of a Linux project.  I sense a real
> problem with EXAMPLES in Linux-man-pages-copyleft pages though:
> Those can *neither* be used in BSD projects *nor* in GPL projects
> as far as i can see.
> 
> Maybe it would be worth finding the authors of significant examples
> in Linux-man-pages-copyleft pages and getting their permission
> to add a line like
> 
>    /* This example code is released into the public domain. */
> 
> at the top of such examples, maybe together with a roff(7) comment
> like
> 
>    .\" This example code was written by Alice and Bob in 2015.
> 
> Anything more complicated, like refering to GPL-2+ would seem like
> overkill to me.

I'll do that (PD) with all of my examples, and will also request a 
comment stating either PD or a specific license for contributions to 
EXAMPLES.  For existing examples, since most come from Michael, I'll 
wait until he comes back some day, if he does...  Otherwise, I'll just 
do nothing until someone asks for a license for a specific piece of 
code, and then ask the specific author.

> 
>>>> AUTHORS,

[...]

> I think it's a case-by-case decision: is there clear enough and
> significant enough authorship of the initial version, or was it
> a cast of many right from the start?

For now, since mtk was against that section, I'll keep that trend.

Cheers,

Alex

> 
> Yours,
>    Ingo

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]