Re: [gentoo-project] [RFC] GLEP 76: Copyright Policy

[Aaron Bauman]

So, ugh, let's not do anything and let the courts do their job then if they have too?  

You basically just said,

"Let's do some busy work that is utter shit and it's cool"

On June 16, 2018 9:39:49 PM EDT, Rich Freeman <rich0@g.o> wrote:
>On Sat, Jun 16, 2018 at 9:03 PM Kent Fredric <kentnl@g.o> wrote:
>>
>> This idea to me is just asking for trouble, given the aformentioned
>> factors.
>>
>
>What kind of, "trouble?"
>
>> Reliably handling contribution factors however seems difficult, given
>> the stock output given by "git blame" is routinely wrong due to how
>or
>> workflow operates.
>
>Why does this have to be reliable?
>
>> So given that, as it stands, automating this is either:
>>
>> a) hard
>> b) impossible
>>
>> And subsequently, manually doing it will tend towards those entries
>> quickly becoming wrong.
>
>How is that a problem?  Also, this assumes that the main copyright
>holder on something we distribute actually changes often.
>
>There really isn't any negative consequence to the person listed on a
>copyright notice being "wrong" as far as I can tell.  I use quotes
>because as long as the person listed contributed SOMETHING to the file
>the statement is still accurate, even if non-ideal.  I doubt a court
>is going to decide a case differently because the person listed on the
>copyright notice wrote 20% of a file vs somebody else who wrote 40%.
>As far as I'm aware the name listed on a copyright notice isn't
>binding at all on a court - the court is free to determine who
>actually owns the copyright based on the facts of the situation.  The
>notice simply serves to inform the recipient of a work that it IS
>copyrighted, so that they can't claim innocent infringement.  The work
>remains copyrighted all the same if the notice is not present, and
>future infringement after receiving notice would not be innocent
>regardless.
>
>> And to add insult to injury, changing these entries via either
>> mechanism produces source of commit churn and conflicts
>
>Only if you try to constantly adjust things.
>
>If you just wait until somebody points out an inaccuracy (which is all
>the policy requires), then these commits will be rare.
>
>> And around about here you ask "what's the point?". A lot of work, for
>> negligible benefit.
>
>The policy doesn't require much work.  The parts that suggested that
>it needed to be maintained in realtime were removed, for exactly the
>reasons you have elaborated on.
>
>The intent here is not to have devs constantly checking the copyright
>notices on every commit.  It simply states what they are intended to
>contain.
>
>>
>> The nature of the proposed changes seems strongly in conflict with
>the
>> technology we have to use, and will produce no benefit, at the
>expense
>> of real problems.
>>
>
>Well, one of the main benefits is that people won't feel like they
>have to replace all the copyright notices with ones that reference
>Gentoo when they put these files on Gentoo infra (such as what
>happened with eudev).
>
>As far as real problems go, just don't touch the copyright lines
>except to add "and others" and there won't be many issues.
>
>If somebody makes a huge rewrite they can always add themselves to the
>notice as the main contributor if they wish.
>
>I definitely don't think automating the notices is a good idea.  For
>example, in the eudev repository the file src/scsi_id/scsi_id.c has
>IBM/SUSE copyright notices on it, and that isn't what your git log
>command would output.  That was just the first random file in that
>repository I checked.
>
>Overall the intent of the policy (after the various rewrites) was to
>try to give reasonable instructions as to how the notice should be
>written, but not to suggest that developers need to put a great deal
>of effort into making it precise.
>
>--
>Rich

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.