Re: [gentoo-project] rfc: copyright attribution clarifications

[Rich Freeman]

On Wed, Nov 14, 2018 at 4:00 PM Patrick McLean <chutzpah@g.o> wrote:
>
> I don't object to adding the copyright notice to the commit message
> rather than the ebuild, the only caveat is that the copyright should be
> propigated to the rsync tree as well (since most users use rsync rather
> than git). Perhaps the "fattening" step could do it, even just a
> top-level file listing packages and copyright owners, should not be
> overly hard to generate, maybe with a post-push hook that updates it
> when a copyright tag is detected in the push.

IMO documenting copyright data in git would be a value-add, and could
potentially be assisted by repoman just as signed-off-by tags are.

Whether it gets propagated to rsync I'll leave to others who care
more.  Personally I don't get why we propagate anything other than the
ebuilds to rsync, but if rsync users want to punish themselves who am
I to argue with them?  :)

>
> IANAL nor do I pretend to be one. A lawyer did instruct me to add the
> copyright notices to ebuilds that I work on during work hours.

In my experience corporate lawyers have a lot of incentive to do this
sort of thing.

First, it costs them nothing to direct people to do this.  It doesn't
really cost the company much either, so there won't be push-back
internally.

It is also easy to explain a policy like this to a pointy-haired boss
type.  It gets seen as "doing something" to protect the company as
well.  Whether it actually is making a difference is another matter,
but it isn't like anybody is going to ever look into that.  It isn't
adding any risk.

At work I've seen far more costly policies than this established by
lawyers that are of dubious value to the company, but since the lawyer
doesn't get paid less if the policy is expensive, but they might lose
their job if anything bad happens, they have a lot of incentive to
enact every possible rule so that they can be seen as being innocent
if anything goes wrong.

I think a lot of it just happens without any malicious intent.  Lawyer
is asked for opinion, lawyer gives opinion.  Everybody is happy.  :)

>
> AFAIK no one on this list/thread is a lawyer, so much if this is not
> particularly valuable.

Well, if somebody who is a lawyer wants to add perspective I'm all
ears, but this is a community-based FOSS projects and decisions are
generally made based on arguments debated in public, and not "a friend
of a friend talked to a lawyer and got some free advice so we better
follow it."  A lot of pros and cons have been presented for this
change, and those in charge can weigh them, but I've never really been
a fan of arguments that deference must be made to arguments that
aren't even presented simply due to somebody holding a credential.

> Personally, I don't see why there is a strong objection to a practice that is quite common in open source code.

I suspect that some of this is due to the nature of ebuilds themselves
and our workflow.

If you have some file full of 2000 lines of source code, you're going
to spend all your time buried in whatever function you're refactoring
and you're not really looking at the boilerplate at the start of the
file.  You might spend days looking at the file and your editor
remembers where you left off.  You never even look at the copyright
notices and a few more lines isn't a big deal.  You don't even look at
the other functions in the file you're editing but trust them to honor
their APIs.

On the other hand Gentoo ebuilds might only be 10-20 lines long, and a
lot of the stuff that people are often looking at (keywords, iuse,
my_foo, etc) are right at the top.  Often this stuff is "above the
fold" as they say.  Sticking another half a dozen lines of cruft at
the top means that you're hunting more to find the stuff you care
about, and the copyright boilerplate could become half the file
contents in a file that is mostly boilerplate already.

Maybe a compromise would be to stick all the copyright cruft at the
end of the file, but IMO it is better stored in git, preferably in
some standardized format that could be parsed by tools.

-- 
Rich