From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 939B2138334 for ; Sun, 17 Jun 2018 02:17:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 09A3FE0874; Sun, 17 Jun 2018 02:17:49 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AC316E0835 for ; Sun, 17 Jun 2018 02:17:48 +0000 (UTC) Received: from [192.168.1.151] (pool-71-163-21-11.washdc.fios.verizon.net [71.163.21.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: bman) by smtp.gentoo.org (Postfix) with ESMTPSA id 1726A335C7F for ; Sun, 17 Jun 2018 02:17:47 +0000 (UTC) Date: Sat, 16 Jun 2018 22:17:44 -0400 User-Agent: K-9 Mail for Android In-Reply-To: References: <23325.35685.793702.267278@a1i15.kph.uni-mainz.de> <20180617123737.122ef070@katipo2.lan> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----RR04KGMYUY4WBE6FK5I3DPR6GSKEEI" Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-project] [RFC] GLEP 76: Copyright Policy To: gentoo-project@lists.gentoo.org From: Aaron Bauman Message-ID: X-Archives-Salt: 8262e6cf-b171-42c6-98bc-baa156e3be0b X-Archives-Hash: 853a52a10f157ee6534eb112228f26f0 ------RR04KGMYUY4WBE6FK5I3DPR6GSKEEI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So, ugh, let's not do anything and let the courts do their job then if they= have too? =20 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 wrote: >On Sat, Jun 16, 2018 at 9:03 PM Kent Fredric wrote: >> >> This idea to me is just asking for trouble, given the aformentioned >> factors=2E >> > >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=2E > >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=2E > >How is that a problem? Also, this assumes that the main copyright >holder on something we distribute actually changes often=2E > >There really isn't any negative consequence to the person listed on a >copyright notice being "wrong" as far as I can tell=2E I use quotes >because as long as the person listed contributed SOMETHING to the file >the statement is still accurate, even if non-ideal=2E 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%=2E >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=2E The >notice simply serves to inform the recipient of a work that it IS >copyrighted, so that they can't claim innocent infringement=2E The work >remains copyrighted all the same if the notice is not present, and >future infringement after receiving notice would not be innocent >regardless=2E > >> 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=2E > >If you just wait until somebody points out an inaccuracy (which is all >the policy requires), then these commits will be rare=2E > >> And around about here you ask "what's the point?"=2E A lot of work, for >> negligible benefit=2E > >The policy doesn't require much work=2E The parts that suggested that >it needed to be maintained in realtime were removed, for exactly the >reasons you have elaborated on=2E > >The intent here is not to have devs constantly checking the copyright >notices on every commit=2E It simply states what they are intended to >contain=2E > >> >> 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=2E >> > >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)=2E > >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=2E > >If somebody makes a huge rewrite they can always add themselves to the >notice as the main contributor if they wish=2E > >I definitely don't think automating the notices is a good idea=2E For >example, in the eudev repository the file src/scsi_id/scsi_id=2Ec has >IBM/SUSE copyright notices on it, and that isn't what your git log >command would output=2E That was just the first random file in that >repository I checked=2E > >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=2E > >--=20 >Rich --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------RR04KGMYUY4WBE6FK5I3DPR6GSKEEI Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable So, ugh, let's not do anything and let the cou= rts 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&quo= t;

On June 16, 2018 9:39:49 PM EDT, Rich = Freeman <rich0@gentoo=2Eorg> wrote:
On Sat, Jun 16, 2018 at 9:03 PM Kent Fredric <ken=
tnl@gentoo=2Eorg> wrote:

 This idea to me is just asking for trouble, given the aformention=
ed
 factors=2E


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=2E

Why does this have to be reliable?

 So given that, as it stands, automating this is =
either:

 a) hard
 b) impossible

 And subsequently, manuall=
y doing it will tend towards those entries
 quickly becoming wrong=2E

How is that a problem?  Also, this assumes that the main =
copyright
holder on something we distribute actually changes often=2E
There really isn't any negative consequence to the person listed on a<=
br>copyright notice being "wrong" as far as I can tell=2E  I use quotes
=
because as long as the person listed contributed SOMETHING to the file
t=
he statement is still accurate, even if non-ideal=2E  I doubt a court
is=
 going to decide a case differently because the person listed on the
cop=
yright notice wrote 20% of a file vs somebody else who wrote 40%=2E
As f=
ar as I'm aware the name listed on a copyright notice isn't
binding at a=
ll on a court - the court is free to determine who
actually owns the cop=
yright based on the facts of the situation=2E  The
notice simply serves =
to inform the recipient of a work that it IS
copyrighted, so that they c=
an't claim innocent infringement=2E  The work
remains copyrighted all th=
e same if the notice is not present, and
future infringement after recei=
ving notice would not be innocent
regardless=2E

 And to add insult to injury, changing thes=
e entries via either
 mechanism produces source of commit churn and conf=
licts

Only if you try to constantly adjust things=2E
If you just wait until somebody points out an inaccuracy (which is all=

the policy requires), then these commits will be rare=2E

 And around about here you ask "w=
hat's the point?"=2E A lot of work, for
 negligible benefit=2E

The policy doesn't require much work=2E  The parts that suggeste=
d that
it needed to be maintained in realtime were removed, for exactly =
the
reasons you have elaborated on=2E

The intent here is not to h=
ave devs constantly checking the copyright
notices on every commit=2E  I=
t simply states what they are intended to
contain=2E


 The nature of the proposed change=
s seems strongly in conflict with the
 technology we have to use, and wi=
ll produce no benefit, at the expense
 of real problems=2E
<=
br>
Well, one of the main benefits is that people won't feel like theyhave to replace all the copyright notices with ones that reference
Gen=
too when they put these files on Gentoo infra (such as what
happened wit=
h eudev)=2E

As far as real problems go, just don't touch the copyrig=
ht lines
except to add "and others" and there won't be many issues=2E
If somebody makes a huge rewrite they can always add themselves to the=

notice as the main contributor if they wish=2E

I definitely don'=
t think automating the notices is a good idea=2E  For
example, in the eu=
dev repository the file src/scsi_id/scsi_id=2Ec has
IBM/SUSE copyright n=
otices on it, and that isn't what your git log
command would output=2E  =
That was just the first random file in that
repository I checked=2E
<=
br>Overall the intent of the policy (after the various rewrites) was to
=
try to give reasonable instructions as to how the notice should be
writt=
en, but not to suggest that developers need to put a great deal
of effor=
t into making it precise=2E

--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------RR04KGMYUY4WBE6FK5I3DPR6GSKEEI--