Re: [gentoo-project] RFC: Re-evaluate GLEP-0076 and copyright policy

[Rich Freeman]

On Wed, May 19, 2021 at 1:03 AM Joonas Niilola <juippis@g.o> wrote:
>
> This causes few misunderstandings with the requirements. Is the legal
> name sign-off required from the *committer*, or from the *contributor*?

So, you are probably referring to case 4, where a contributor makes a
certification to the committer.  I think it is a fair point that the
policy doesn't state whether the contributor has to also provide a
sign-off using their real name, or if some other way of providing this
certification is acceptable.

> What about a contribution where the author just adds a patch from
> upstream, how much is covered by the Gentoo copyright policies?

Well, I'd think that most of these are going to fall under case #3
("The contribution is based upon previous work that, to the best of my
knowledge, is covered under an appropriate free software license..."),
unless we're talking about patches to non-FOSS code.  That seems
pretty unlikely to come up, but has it?

> We've turned down many contributions in the past because the contributor
> did not wish to share their real name. Too many. We've also merged
> contributions from Github accounts with no history, and absolutely no
> way for us to determine whether the affiliated name is real.

This is a fair point - we basically assume that if upstream accepts it
then we can accept it, but I don't think anything else is practical.
If upstream distributes a tarball under an FOSS license, and we mirror
it, we can't really go auditing every upstream to ensure every one of
them actually has the rights to their code.  I think the concept is
that we weigh the actions of projects above the actions of random
individuals.

> Heck, you can't even tell if the name I use is real.

This has been discussed a fair bit already I believe.  The policy is
intended to cover Gentoo with a reasonable amount of due diligence,
and also generally create a professional atmosphere not full of random
pseudonyms.  However, we didn't want to get into a situation where
we're harvesting a lot of sensitive private info like identity docs,
especially since validating these requires some expertise and probably
isn't practical online.

Ultimately the policy was intended to find a balance.  No doubt you
could make it slightly more strict or slightly less strict and the
argument could be made that either is acceptable.

Much of it was based on what the Linux Kernel and other projects do.
That doesn't make it automatically correct, and the kernel doesn't
redistribute random stuff from random other projects, so we can't
conform completely to it.

> Therefore I suggest we update the GLEP to *clearly* state that *only*
> committer's sign-off is required.

Well, either way it probably is reasonable to make it explicit whether
a real-name sign-off by the contributor is necessary in case #3, and
whether that needs to make its way into the commit itself as an
additional signed-off-by line.

> (And I feel like even that is
> debatable, but at least a start for now)

It certainly was debated when the policy was enacted.  I'm not sure
that rehashing the debate is going to change much - the arguments
haven't changed, and I don't think the Council has changed all that
much either.  However, they could speak for themselves...

> Then a small note about ebuild's copyright header. The GLEP states:
> "All copyrightable files included in Gentoo projects must contain
> appropriate copyright and license notices"
>
> but do ebuilds, at least most of the ebuilds, contain copyrightable
> innovative work? Most ebuilds are just following the basic skeleton form
> and calling functions from eclasses and EAPI. Therefore I suggest the
> copyright headers in ebuilds shouldn't be mandatory, but opt-in, if the
> author feels like it contains innovative work.

So, only a court can make this determination, and courts in different
jurisdictions could make the determination differently.  IMO it is a
MUCH simpler solution to just leave the line there for everything than
to have debates and escalations over just how much content it takes to
make an ebuild copyrightable, especially when you start throwing
eclasses and so on into the mix, where setting a variable changes the
behavior of the ebuild.

There is little harm to have the additional copyright line, but not
including it could limit our rights.  Also, in the case where the
ebuild at some point in history was part of somebody else's repository
(perhaps in an earlier revision the maintainer isn't aware of
offhand), removing the copyright notice might provoke offense.

I'd strongly recommend keeping the current policy if only to keep it
simple.  Really the only inconvenience is updating the year.

> And why couldn't we use the ./header.txt to indicate this copyright for
> every ebuild, why must it be replicated to each .ebuild file?

Including it in every file is generally considered a best practice -
you can google that in policies from various reputable sources.  Not
giving sufficient notice can limit rights under copyright law in some
jurisdictions.  Just about every FOSS project does it this way.

> We also have the metadata/AUTHORS file whose purpose I still don't know.

You can find a lot of debate on this on the list archives.  Basically
it exists for a few reasons:

1. Some contributors work for employers who have a requirement to list
their name in copyright notices.
2. Some files were sourced in a way that they contain non-Gentoo
copyright notices already. (Eudev had a bit of a delicate situation
resulting from this.)
3. Some developers wanted to have their own names in the copyright
notices for their contributions.

In these situations the options are to accumulate copyright notices
(adding Gentoo plus others), or have the AUTHORS file where we can put
all that in one place and keep the per-file details simple.  The full
history is found in git regardless, but the topic of copyright notice
is sensitive to some.  IMO it isn't intended to be a "credit" for work
done, but some feel otherwise, and this policy was a way to keep the
files simple and keep everybody happy.  It basically requires nobody
to do anything but tolerate a small file in the repository, but those
who wish to be listed can ask.

--
Rich