On 4/23/19 7:15 PM, Ingo Schwarze wrote:
>>> At the top of the file, a Copyright notice and license is missing.
>>> Please conisder using /usr/share/misc/license.template with the
>>> comment markers changed to .\" .
> 
>> I intentionally skipped on adding the copyright notice and license
>> because I felt it would be presumptuous -- I wanted to keep open
>> the option of a copyright assignment to an OpenBSD contributor open
>> in case the OpenBSD project wished for it, just in case.
> 
> If you weren't a lawyer, i would feel tempted to suspect that you
> misunderstood how Copyright works in general.  As things stand, i
> may be misunderstanding what you intend to say here.  Either way,
> i suspect you misunderstand how ownership of intellectual property
> works in OpenBSD in particular.

For the sake of correctness I must state that I'm not a lawyer;
however, I do have a law degree from a Swiss university (master of law).

> By international law (Berne Convention), you cannot give away Copyright.
> Copyright always resides with the natural person who is the original
> creator of a Work.  It is inalienable.  The "Copyright" line is merely
> a statement of fact.
> 
> Is it correct that you wrote all the text in the file?
> If so, your name needs to be there.

It is indeed correct that I wrote all the text in the file (except, by
definition, your suggestions).

> According to the Berne Convention, even though you cannot give away
> the moral rights that constitute the core of Copyright, you can give
> away the economic rights arising from a Work.  Some publishers of
> software (for example the FSF) ask for that.  But in OpenBSD, we
> strongly encourage original authors to retain all economic rights
> arising from their Works, and simply grant a standardized license
> themselves, such that OpenBSD can distribute the Works.

Thank you for clarifying.

Since I wasn't aware how documentation (and code) from outsiders
contributing to OpenBSD would be treated, I figured I should err on the
side of caution and not grant any license in the initial publication.
Requests with regards to assignment of rights could have been possible,
after all.
Granting the economic rights becomes somewhat meaningless if there is a
pre-existing liberal license and you had wished that the rights had been
granted exclusively to a single entity.

> The OpenBSD
> project doesn't own any rights and isn't even a legal entity.

(That's why I said "to an OpenBSD contributor", not "to the OpenBSD
project" in my previous e-mail, actually.)

Some nitpicks in the diff follow.

> Index: Makefile
> ===================================================================
> RCS file: /cvs/src/usr.bin/rcs/Makefile,v
> retrieving revision 1.40
> diff -u -p -r1.40 Makefile
> --- Makefile  15 Oct 2010 08:44:12 -0000      1.40
> +++ Makefile  23 Apr 2019 17:04:55 -0000
> @@ -1,7 +1,9 @@
>  #    $OpenBSD: Makefile,v 1.40 2010/10/15 08:44:12 tobias Exp $
>  
>  PROG=        rcs
> -MAN= ci.1 co.1 ident.1 merge.1 rcs.1 rcsclean.1 rcsdiff.1 rcsmerge.1 rlog.1
> +MAN= ci.1 co.1 ident.1 merge.1 \
> +     rcs.1 rcsclean.1 rcsdiff.1 rcsmerge.1 rlog.1 \
> +     rcsfile.5
>  
>  SRCS=        ci.c co.c ident.c merge.c rcsclean.c rcsdiff.c rcsmerge.c 
> rcsparse.c \
>       rcsprog.c rlog.c rcsutil.c buf.c date.y diff.c diff3.c rcs.c rcsnum.c \
> Index: rcsfile.5
> ===================================================================
> RCS file: rcsfile.5
> diff -N rcsfile.5
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ rcsfile.5 23 Apr 2019 17:04:55 -0000
> @@ -0,0 +1,154 @@
> +.\" $OpenBSD$
> +.\"
> +.\" Copyright (c) 2019 Fabio Scotoni <[email protected]>
> +.\"
> +.\" Permission to use, copy, modify, and distribute this software for any
> +.\" purpose with or without fee is hereby granted, provided that the above
> +.\" copyright notice and this permission notice appear in all copies.
> +.\"
> +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> +.\"

Nitpick: The other man pages in the usr.bin/rcs/ tree do not have a
trailing .\" -- except for rcs(1).
You may wish to make this consistent this one way or another,
likely in a separate commit.

> +.Dd $Mdocdate$
> +.Dt RCSFILE 5
> +.Os
> +.Sh NAME
> +.Nm rcsfile
> +.Nd format of an RCS file
> +.Sh DESCRIPTION
> +An RCS file is a text file.
> +It consists of four sections, each separated by two empty lines.
> +RCS files should not be edited by hand;
> +the
> +.Xr rcs 1
> +programs should be used instead.
> +.Ss Administrative data
> +The RCS file begins with admin data.
> +Each entry in this section consists of either one or multiple values.
> +Entries that take one value are specified on one line:
> +The keyword and its corresponding value are separated by
> +a tab character.
> +Entries that take multiple values begin with a keyword on one line;
> +the values are specified on subsequent lines, one per line and
> +prefixed with a tab character.
> +If the list is empty, the semicolon immediately follows the keyword.
> +Entries are terminated with a semicolon.
> +The entries are:
> +.Bl -tag -width Ds
> +.It Ic head Ar rev
> +Highest revision number.
> +.It Ic branch Ar rev
> +Revision number that specifies the default branch (optional).
> +.It Ic access
> +List of users that are allowed to check in new revisions with
> +.Xr ci 1 .
> +This keyword is not followed by a tab;
> +instead, the list of users is specified with one username per line.
> +The list is terminated by a single semicolon.
> +.It Ic symbols
> +List of symbolic names used as aliases for specific revisions.
> +Each entry consists of a symbolic name followed by a colon and
> +the revision.
> +.It Ic locks
> +List of locked revisions.
> +Each entry consists of a username followed by a colon and
> +the locked revision.
> +.It Ic strict
> +Indicates that locks are strict;
> +if missing, locks are not strict.
> +This entry takes no value and immediately follows the list of locks
> +without a newline.
> +.It Ic comment Pf @ Ar leader Ns @
> +Contains the comment leader surrounded by at signs.
> +.It Ic expand Pf @ Ar mode Ns @
> +Indicates the keyword substitution mode.
> +See
> +.Xr rcs 1
> +for the possible keyword substitution modes.
> +If this entry is not given in the admin section,
> +.Ar kv
> +must be assumed.
> +.El
> +.Ss List of deltas
> +The RCS file continues with a list of deltas.
> +Deltas are separated by empty lines.
> +The list begins with the head and ends with the initial revision.
> +Each entry begins with the revision number, followed by a newline.
> +After that, the structure follows the admin section.
> +.Bl -tag -width Ds
> +.It Ic date Ar YYYY . Ar mm . Ar dd . Ar HH . Ar MM . Ar SS

Are you sure you want to do this without Pf/Ns?
You may have inadvertently introduced spaces here and
the spaces are meaningful:
date    2019.04.23.19.41.22;
does not parse the same as
date    2019 . 04 . 23 . 19 . 41 . 22;

nitpick on my own text:
Maybe this should be [YY]YY because two-digit years do exist.

> +Indicates the date and UTC time the revision was checked in.
> +The date consists of the year, the month,
> +the day of month, the hour, the minute and the second,
> +each separated by dots.
> +The year is specified in either two or four digits.
> +The other values are specified in two digits each.
> +.It Ic author Ar username
> +Author's username.
> +This entry immediately follows the
> +.Ic date
> +without a newline.
> +.It Ic state Ar value
> +Contains the state of this delta,
> +which is an arbitrary string.
> +This entry immediately follows the
> +.Ic author
> +without a newline.
> +.It Ic branches
> +List of revision numbers that are branches stemming from this delta.
> +.It Ic next Ar rev
> +Next revision.
> +Chronologically, this is the
> +.Em previous
> +revision.
> +For the initial check-in,
> +.Ar rev
> +is empty,
> +but the tab character that acts as separator is nonetheless present.
> +.El
> +.Ss Description
> +The RCS file continues with the description.
> +It consists of the string
> +.Ic desc
> +followed by a newline and then an at sign.
> +The description is an arbitrary string that can span multiple lines.
> +A single at sign on a line terminates the description.
> +At signs anywhere in the description itself
> +are escaped by prefixing them with another at sign.
> +.Ss List of deltatexts
> +Finally, the RCS file contains the deltatexts.
> +The list of deltatexts is ordered the same as the list of deltas.
> +Deltatexts are separated by two lines.
> +Each entry begins with the revision number, followed by a newline.
> +The text
> +.Dq Ic log
> +follows on its own line.
> +The log message follows on another new line;
> +it consists of an at sign, the log message itself (which may span
> +multiple lines), and finally an at sign on its own line.
> +Then the text
> +.Dq Ic text
> +follows on its own line.
> +The format is the same as for the description and log message.
> +As with the description,
> +at signs anywhere in the log message or in the deltatext itself
> +are escaped by prefixing them with another at sign.
> +The deltatext of the head consists of the full file contents.
> +All subsequent deltatexts contain the differences to the previous
> +deltatext in the format of
> +.Xr diff 1
> +.Fl n .
> +.Sh SEE ALSO
> +.Xr ci 1 ,
> +.Xr co 1 ,
> +.Xr cvs 1 ,
> +.Xr ident 1 ,
> +.Xr rcs 1 ,
> +.Xr rcsclean 1 ,
> +.Xr rcsdiff 1 ,
> +.Xr rcsmerge 

Reply via email to