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

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 14975 bytes --]

Hello everybody,

Please find below the draft of a new copyright policy, which was in
the making since 2013 at least. After several iterations, we have come
up with a policy with the following key elements:

- Gentoo projects must release their work under GPL-compatible free
  software licenses, preferably under GPL-2 or later. CC-BY-SA-3.0
  (or 4.0) can be used for documentation.

- All commits to Gentoo repositories must be accompanied by a
  certificate of origin. Typically, this would be declared by adding
  a "Signed-off-by:" line (or several of them) to every commit.
  This model is very similar to the one used for development of the
  Linux kernel.

- The copyright notice, especially for ebuilds, will contain the
  name of the largest contributor, plus an "and others" clause when
  necessary. (So the "Copyright Gentoo Foundation" lines will be
  phased out.)

The original second part of the policy, namely to encourage developers
to license their contributions to the Gentoo Foundation (e.g., using
the FSFE's Fiduciary License Agreement), has been dropped, at least
for the time being.

We have chosen to publish this as GLEP 76, because we have a defined
workflow for GLEPs. However, the approval process will be somewhat
different, because both trustees and council are involved with it
(see combined trustees and council meeting on 2018-01-20 [1]).

The reStructuredText source of the GLEP can be found at [2] and its
rendered version is at [3]. For reference, the full text is also
included below.

Ulrich

[1] https://projects.gentoo.org/council/meeting-logs/20180120.txt
[2] ReST: https://gitweb.gentoo.org/data/glep.git/tree/glep-0076.rst
[3] HTML: https://www.gentoo.org/glep/glep-0076.html


---
GLEP: 76
Title: Copyright Policy
Author: Richard Freeman <rich0@gentoo.org>,
        Alice Ferrazzi <alicef@gentoo.org>,
        Ulrich Müller <ulm@gentoo.org>,
        Robin H. Johnson <robbat2@gentoo.org>,
        Michał Górny <mgorny@gentoo.org>
Type: Informational
Status: Draft
Version: 1
Created: 2013-04-23
Last-Modified: 2018-06-10
Post-History: 2018-06-10
Content-Type: text/x-rst
---


Status
======

The policies on this page have no effect!  These are draft policies up
for discussion, not final versions.


Abstract
========

This GLEP introduces a copyright and licensing policy for Gentoo
projects.  It requires all contributions of software or documentation
to be released under a free license, and to be accompanied by a
certificate of origin.


Motivation
==========

The copyright ownership of Gentoo materials is ambiguous due to
historical factors, and this GLEP attempts to improve the process
going forward.

In the beginning (2000 or earlier), the copyright header stated that
*Gentoo Technologies, Inc.* was the copyright holder, without any
formal paperwork.  The formal assignment document was however only
introduced in early 2004.  The assignment had many objectors (mostly
on the ``gentoo-core`` mailing list).  The developer recruiting
procedures attempted to require signing of the document as a condition
for becoming a developer, but it was not applied to pre-existing
developers, or those that objected.

Later, the *Gentoo Foundation* was established, and copyrights were
formally transferred (including nullifying original developer
assignments to *Gentoo Technologies, Inc.*), and the copyright header
was updated.  The formal assignment document text was updated in 2006,
but the formal assignment process had already been abandoned in
mid-2004.

Throughout this, the presence of copyright headers existed as a
policy, and continues to exist to this day.  Some files also still
contain or have in the past contained additional copyright headers,
attributing ownership to other parties.

The policy to have copyright notices ascribing copyright ownership to
the Gentoo Foundation caused an issue when Gentoo developers forked
another project and hosted the fork on Gentoo infrastructure.  To
comply with the previous policy the copyright notices were modified,
which caused concerns with the project the files were forked from.
Our previous policy completely neglected the possibility that Gentoo
might want to host files that were not created internally.

Finally, since the early days of Gentoo new ideas around copyright
licensing have become more popular, such as the FSFE's Fiduciary
License Agreement [#FLA]_, which takes a copyleft approach to
copyright licensing, while also better complying with copyright laws
in nations that have author's rights.

The goal here was to create a policy that was flexible enough to cover
forks and situations where Gentoo would not own the majority of the
copyright in a file.


Specification
=============

Purpose / Scope
---------------

This policy documents how Gentoo contributors comply and document
copyright for any contributions made to Gentoo.  Anyone committing
documentation or sources to any repository hosted on Gentoo
infrastructure or to any official Gentoo project (independently
of hosting) must comply with this policy.  Unofficial Gentoo projects
are also recommended to use this policy.

Questions regarding this policy should be directed to the trustees or
the -project list.  Any concerns over possible copyright violations
should be directed to the Trustees if they cannot be worked out to
anyone's satisfaction with the appropriate maintainer.


Licensing of Gentoo Projects
----------------------------

Every Gentoo project must abide by the Gentoo Social Contract
[#SOCIAL-CONTRACT]_ and release its work under one or more of the
following:

a) The GNU General Public License, version 2 or later (GPL-2+)
   [#GPL-2]_.

b) The Creative Commons Attribution-ShareAlike 3.0 License
   (CC-BY-SA-3.0, only for documentation) [#CC-BY-SA-3.0]_.
   *[Note: or version 4.0, to be decided]*

c) A license approved as GPL compatible by the Free Software
   Foundation [#GPL-COMPAT]_.

Exceptions for other free software licenses will be granted by the
Gentoo Foundation on a case by case basis.

For easy reference, the license for each project should be documented
on the wiki page at [#PROJECTS]_.


Certificate of Origin
---------------------

All commits to Gentoo project repositories shall be accompanied by a
certificate of origin.  The purpose of the certificate is to declare
that the contribution can be modified and redistributed in accordance
with the project's license.

For commits made using a VCS, the committer shall certify agreement
to the Gentoo DCO by adding ``Signed-off-by: Name <e-mail>`` to the
commit message as a separate line.  Committers must use their real
name, i.e., the name that would appear in an official document like
a passport.

The following is the current Gentoo DCO::

    Gentoo Developer's Certificate of Origin, revision 1

    By making a contribution to this project, I certify that:

    (1) The contribution was created in whole or in part by me, and I have
        the right to submit it under the free software license indicated
        in the file; or

    (2) The contribution is based upon previous work that, to the best
        of my knowledge, is covered under an appropriate free software
        license, and I have the right under that license to submit that
        work with modifications, whether created in whole or in part by
        me, under the same free software license (unless I am permitted
        to submit under a different license), as indicated in the file; or

    (3) The contribution is a license text (or a file of similar nature),
        and verbatim distribution is allowed; or

    (4) The contribution was provided directly to me by some other person
        who certified (1), (2), (3), or (4), and I have not modified it.

    I understand and agree that this project and the contribution are
    public and that a record of the contribution (including all personal
    information I submit with it, including my sign-off) is maintained
    indefinitely and may be redistributed consistent with this project or
    the free software license(s) involved.

The Gentoo DCO is licensed under a Creative Commons
Attribution-ShareAlike 3.0 Unported License [#CC-BY-SA-3.0]_.
It is based on the Linux Kernel DCO [#OSDL-DCO]_, released by Open
Source Development Labs, Inc. in 2005 under a CC-BY-SA-2.5 License.


Copyright Attribution
---------------------

All files included in Gentoo projects must contain an appropriate
copyright notice, as defined by this policy.

A proper copyright notice appears near the top of the file, and reads::

    Copyright YEARS LARGEST-CONTRIBUTOR [OTHER-CONTRIBUTORS] and others

The largest contributor is whatever entity owns copyright to some
portion of the largest number of lines in the file.  Additional
contributors can be listed, but this is neither required nor
recommended.  The "and others" text may be omitted if the explicitly
listed contributors hold copyright to the entire file.

Anyone finding a file out of compliance should file a bug against the
associated project/package providing as much information as possible.
Files that are not brought into compliance within 60 days or upon a
request for removal by a aggrieved copyright holder will be removed.
Any concerns not addressed by a maintainer can be appealed to the
Trustees.


Rationale
=========

Policy
------

This document aims to provide a single consistent copyright policy for
all Gentoo projects.  It is explicitly enforced for all official Gentoo
projects in order to protect the interests of Gentoo as a whole,
including its contributors, developers and users.  Additionally, it is
enforced for all other projects hosted on Gentoo infrastructure in order
to protect the Gentoo infrastructure owners and improve consistency.

The copyright model is built on the DCO model used by the Linux kernel
and requires all contributors to certify the legitimacy of their
contributions.  This also requires that they use their real name for
signing; an anonymous certification or one under a pseudonym would not
mean anything.

In the future, a second stage of this policy may use a combination of
the DCO model and an FLA model [#FLA]_ as it is used by different open
source projects.  Contributors would be able to freely choose whether
they sign the FLA document or not.


Licensing of Projects
---------------------

The Social Contract mentions GPL-2 and CC-BY-SA-2.0, both with the
option to use them in a later version ("at our discretion").  In order
to facilitate interchange of software between different projects, we
aim for uniformity of their licensing.  Therefore, items a) and b)
explicitly recommend the use of GPL-2+ and CC-BY-SA-3.0.  The latter
is restricted to be used for documentation, because Creative Commons
themselves recommend against using their licenses for software
[#CC-SOFTWARE]_.

Other GPL-compatible free software licenses that are not explicitly
listed are allowed by item c).  This covers cases where compatibility
to licenses used by upstream projects is necessary.  (For example,
the Gentoo BSD project may want to use the 2-clause or 3-clause BSD
license).

By default, GPL-incompatible licenses (e.g., the CDDL) are not
allowed, because their use would hinder interchange of code between
Gentoo projects.  However, the Foundation can grant exceptions to
this, as long as the license in question is a free software or open
source license.


DCO Changes
-----------

The Gentoo DCO rev. 1 has been based on Linux Kernel DCO 1.1
[#OSDL-DCO]_.  It features the following modifications from
the original:

1. The enumeration has been modified to use numeric points.

2. Additional point (3) has been inserted::

       (3) The contribution is a license text (or a file of similar nature),
       and verbatim distribution is allowed; or

3. The original point (c) has shifted to become point (4), and has been
   updated to account for the additional point (3).

4. The original point (d) has been transformed into a stand-alone
   paragraph following the enumeration.

5. The term "open source" has been replaced by "free software"
   throughout.

The new point was deemed necessary to allow committing license files
into the Gentoo repository, since those files usually do not permit
modification.  It has been established that adding a clear provision
for this case is better than excluding those commits from DCO
compliance.  Debian was facing a similar problem [#DEBIAN-LICENSE]_.

The update of point (c) was necessary to allow the new clause being
certified by the person providing the contribution.

The term "free software" is used for consistency with the language
of the Gentoo Social Contract [#SOCIAL-CONTRACT]_.

The remaining changes were merely editorial.  It has been established
that the last point is really separate from the other points, so it is
more appropriate to separate it from the enumeration by putting it
in a separate paragraph.


Acknowledgements
================

Many people have participated in invaluable discussions on this GLEP.
In particular, the authors would like to thank David Abbott,
Roy Bamford, Kristian Fiskerstrand, Andreas K. Hüttel, Matija Šuklje,
Matthew Thode, and Alec Warner for their input.


References
==========

.. [#SOCIAL-CONTRACT] Gentoo Social Contract,
   https://www.gentoo.org/get-started/philosophy/social-contract.html

.. [#GPL-2] GNU General Public License, version 2 or later,
   http://www.gnu.org/licenses/gpl-2.0.html

.. [#CC-BY-SA-3.0] Creative Commons Attribution-ShareAlike 3.0
   Unported License, http://creativecommons.org/licenses/by-sa/3.0/

.. [#GPL-COMPAT] GPL-compatible free software licenses,
   https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses

.. [#PROJECTS] Licensing of Gentoo projects,
   https://wiki.gentoo.org/wiki/Project:Licenses/Licensing_of_Gentoo_projects

.. [#OSDL-DCO] Developer's Certificate of Origin 1.1,
   https://web.archive.org/web/20060524185355/http://www.osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html

.. [#FLA] FSFE Legal: Fiduciary Licence Agreement (FLA),
   https://fsfe.org/activities/ftf/fla.en.html

.. [#CC-SOFTWARE] Can I apply a Creative Commons license to software?
   https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software

.. [#DEBIAN-LICENSE] [debian-legal] License of the GPL license,
   https://lists.debian.org/debian-legal/2018/04/msg00006.html


Copyright
=========

This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
Unported License.  To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/.

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Michał Górny]

W dniu nie, 10.06.2018 o godzinie 22∶34 +0200, użytkownik Ulrich Mueller
napisał:
> [1] https://projects.gentoo.org/council/meeting-logs/20180120.txt
> [2] ReST: https://gitweb.gentoo.org/data/glep.git/tree/glep-0076.rst
> [3] HTML: https://www.gentoo.org/glep/glep-0076.html
> 

I have also started writing an article focusing on more practical
aspects of this policy.  I'm publishing its draft in hope it would help
understanding the policy and the relevant discussion.  Since it's
a public preview, feedback would be appreciated as well.

HTML: https://dev.gentoo.org/~mgorny/articles/new-gentoo-copyright-policy-explained.html
ReST: https://dev.gentoo.org/~mgorny/articles/new-gentoo-copyright-policy-explained.rst



-- 
Best regards,
Michał Górny

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

[Brian Evans]

[-- Attachment #1.1: Type: text/plain, Size: 474 bytes --]

On 6/10/2018 4:34 PM, Ulrich Mueller wrote:
> - All commits to Gentoo repositories must be accompanied by a
>   certificate of origin. Typically, this would be declared by adding
>   a "Signed-off-by:" line (or several of them) to every commit.
>   This model is very similar to the one used for development of the
>   Linux kernel.
> 

If this does become ratified, please modify 'repoman commit/ci' to
easily allow a --signoff option for git commits.

Brian


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

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

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 1511 bytes --]

On 06/10/2018 04:34 PM, Ulrich Mueller wrote:

[...]

> Copyright Attribution
> ---------------------
> 
> All files included in Gentoo projects must contain an appropriate
> copyright notice, as defined by this policy.
> 
> A proper copyright notice appears near the top of the file, and reads::
> 
>     Copyright YEARS LARGEST-CONTRIBUTOR [OTHER-CONTRIBUTORS] and others
> 
> The largest contributor is whatever entity owns copyright to some
> portion of the largest number of lines in the file.  Additional
> contributors can be listed, but this is neither required nor
> recommended.  The "and others" text may be omitted if the explicitly
> listed contributors hold copyright to the entire file.

Why is this not recommended? Here are a couple of scenarios that came to
mind that lead to me to question how that would play out:
If developer A writes 51% of the lines of an ebuild and developer B
writes 49%, should B not be listed?
What if all the metadata lines defining variables consists of 75% of the
file and was written by A, but the core functionality of the ebuild (25%
by size) was written by B?
If A writes an ebuild, and B replaces a majority (>50%) of the ebuild,
should B remove A from attribution?
I think that specifying that substantial (though not necessarily
specific in defining this) contributions/contributors should included in
the copyright attribution and that substantial contribution attribution
*is* recommended.

[...]


-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Rich Freeman]

On Mon, Jun 11, 2018 at 12:25 PM NP-Hardass <NP-Hardass@gentoo.org> wrote:
>
> On 06/10/2018 04:34 PM, Ulrich Mueller wrote:
>
> > Copyright Attribution
> > ---------------------
> >
> > All files included in Gentoo projects must contain an appropriate
> > copyright notice, as defined by this policy.
> >
> > A proper copyright notice appears near the top of the file, and reads::
> >
> >     Copyright YEARS LARGEST-CONTRIBUTOR [OTHER-CONTRIBUTORS] and others
> >
> > The largest contributor is whatever entity owns copyright to some
> > portion of the largest number of lines in the file.  Additional
> > contributors can be listed, but this is neither required nor
> > recommended.  The "and others" text may be omitted if the explicitly
> > listed contributors hold copyright to the entire file.
>
> Why is this not recommended?

So, I came up with this to try to keep it as simple as possible.

My concern was basically analogous to the BSD advertising clause
problem.  If you start accumulating authors on this line then it gets
unwieldy.  How do you draw the line?

I suggested drawing the line at whoever touched the most lines, mainly
because it is simple.

IMO ANY solution is going to be imperfect, so simple trumps all.

But, it certainly isn't the only possible solution to this problem.

Keep in mind that notice is not the same as
authorship/copyright/credit/etc.  The "and others" is important.
Being #2 doesn't in any way diminish your rights under the law.  The
law simply requires a notice, so we need to come up with one.  It
shouldn't be viewed as "this is the only important contributor to this
file."  If we could not have any notice at all legally then that would
be simpler still.  Git already tracks who did what, and should always
be the place to go for this info.

> If developer A writes 51% of the lines of an ebuild and developer B
> writes 49%, should B not be listed?

Under the policy, no.

> What if all the metadata lines defining variables consists of 75% of the
> file and was written by A, but the core functionality of the ebuild (25%
> by size) was written by B?

Under the policy, "A and others" is listed.

> If A writes an ebuild, and B replaces a majority (>50%) of the ebuild,
> should B remove A from attribution?

Under the policy, yes, assuming this is noticed.  The policy does not
require checking on every commit, but only when the issue is
escalated.  That is actually a change from the wording which tried to
keep things more strict.

> I think that specifying that substantial (though not necessarily
> specific in defining this) contributions/contributors should included in
> the copyright attribution and that substantial contribution attribution
> *is* recommended.

So, the issue then becomes whether we have to define "substantial."
The goal is to have something actionable.  Anybody can run git blame
easily enough.  Figuring out what is "substantial" is harder.

But, the other change to the policy was to relax this and not worry
about keeping it as up to date.  So, in that spirit maybe we can be
more vague and let it be dealt with via escalation.

That seems to be the approach the Linux Foundation takes.  As far as I
can tell they have no policy regarding copyright notice - and the
contents of their files are all over the place.  Presumably committers
make their own judgement calls, and if somebody has a problem with it
they point it out to the Linux Foundation.

That said, the fact that this is basically happened with the eudev
copyright notices didn't prevent it from turning into a bit of a
tempest in a teapot with all kinds of accusations being tossed around.
It was dealt with upon escalation, but people tend to go crazy over
this stuff so some kind of policy that an ordinary dev can understand
wouldn't hurt, so that the issue is prevented.  That was the goal of
the policy.

A big goal here was to keep it simple and understandable but not too
vague.  It shouldn't need constant appeals to Trustees/Council/whoever
to apply to individual situations.

To the extent that the notice doesn't truly give credit to
contributors I'd call it a feature and not a bug.  I'd rather have the
notices viewed as useless for that purpose, because then people won't
constantly squabble about how does/doesn't get included on them.  The
ideal choices would be listing everybody or nobody, but everybody is
cumbersome, and nobody doesn't seem to be legally valid.  So, listing
one by name preserves the nonsensical nature of the notice while still
meeting the legal requirement.  Or something like that...

-- 
Rich

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]

>>>>> On Mon, 11 Jun 2018, NP-Hardass  wrote:

> On 06/10/2018 04:34 PM, Ulrich Mueller wrote:
> [...]

>> Copyright Attribution
>> ---------------------
>> 
>> All files included in Gentoo projects must contain an appropriate
>> copyright notice, as defined by this policy.
>> 
>> A proper copyright notice appears near the top of the file, and reads::
>> 
>> Copyright YEARS LARGEST-CONTRIBUTOR [OTHER-CONTRIBUTORS] and others
>> 
>> The largest contributor is whatever entity owns copyright to some
>> portion of the largest number of lines in the file.  Additional
>> contributors can be listed, but this is neither required nor
>> recommended.  The "and others" text may be omitted if the explicitly
>> listed contributors hold copyright to the entire file.

> Why is this not recommended? Here are a couple of scenarios that came to
> mind that lead to me to question how that would play out:
> If developer A writes 51% of the lines of an ebuild and developer B
> writes 49%, should B not be listed?

With the current policy neither of them is listed, so listing A would
be an improvement. The goal is to keep things simple, and listing only
the largest contributor looks like the simplest solution. For example,
listing the two largest contributors would lead to similar problems.
What should we do if A and B each write 34% and C writes 32%?

In a previous version of the draft, we had required a full list of
copyright holders to be listed somewhere in the file, and 60% of the
lines to be accounted for:
https://gitweb.gentoo.org/data/glep.git/commit/?id=bb756839bbd403059f6faeceaa114346d2a840d7

We changed that because neither tracing the number of lines nor
maintaining a list of authors in every ebuild seems feasible.

> What if all the metadata lines defining variables consists of 75% of the
> file and was written by A, but the core functionality of the ebuild (25%
> by size) was written by B?

That would get us into a discussion on which portions of an ebuild are
copyrightable and which are not. Again, we want simple rules there.

> If A writes an ebuild, and B replaces a majority (>50%) of the ebuild,
> should B remove A from attribution?
> I think that specifying that substantial (though not necessarily
> specific in defining this) contributions/contributors should included in
> the copyright attribution and that substantial contribution attribution
> *is* recommended.

See above. Explicitly listing only one copyright holder in the
copyright line looks like the simplest possible solution. Listing
nobody would be even simpler, but I think that you cannot have a
copyright line without at least one entity.

Also note that the exercise is _not_ about giving credit to authors
(and we currently don't do that with the Foundation copyright either).
The purpose of the copyright notice is to make a statement that the
work is copyrighted, in order to defeat a possible defense of
"innocent infringement".

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Michał Górny]

W dniu pon, 11.06.2018 o godzinie 12∶25 -0400, użytkownik NP-Hardass
napisał:
> On 06/10/2018 04:34 PM, Ulrich Mueller wrote:
> 
> [...]
> 
> > Copyright Attribution
> > ---------------------
> > 
> > All files included in Gentoo projects must contain an appropriate
> > copyright notice, as defined by this policy.
> > 
> > A proper copyright notice appears near the top of the file, and reads::
> > 
> >     Copyright YEARS LARGEST-CONTRIBUTOR [OTHER-CONTRIBUTORS] and others
> > 
> > The largest contributor is whatever entity owns copyright to some
> > portion of the largest number of lines in the file.  Additional
> > contributors can be listed, but this is neither required nor
> > recommended.  The "and others" text may be omitted if the explicitly
> > listed contributors hold copyright to the entire file.
> 
> Why is this not recommended? Here are a couple of scenarios that came to
> mind that lead to me to question how that would play out:
> If developer A writes 51% of the lines of an ebuild and developer B
> writes 49%, should B not be listed?
> What if all the metadata lines defining variables consists of 75% of the
> file and was written by A, but the core functionality of the ebuild (25%
> by size) was written by B?
> If A writes an ebuild, and B replaces a majority (>50%) of the ebuild,
> should B remove A from attribution?
> I think that specifying that substantial (though not necessarily
> specific in defining this) contributions/contributors should included in
> the copyright attribution and that substantial contribution attribution
> *is* recommended.
> 

Note that line attribution is not a very precise measure anyway.  For
example, you can easily update all lines in the ebuild without making
any substantial change to it.  Therefore, according to 'git blame' you'd
be 100% owner but at the same time the previous author would have far
more original contribution than you did.

-- 
Best regards,
Michał Górny

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

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 3491 bytes --]

On 06/11/2018 01:27 PM, Ulrich Mueller wrote:
>>>>>> On Mon, 11 Jun 2018, NP-Hardass  wrote:
> 
>> On 06/10/2018 04:34 PM, Ulrich Mueller wrote:
>> [...]
> 
>>> Copyright Attribution
>>> ---------------------
>>>
>>> All files included in Gentoo projects must contain an appropriate
>>> copyright notice, as defined by this policy.
>>>
>>> A proper copyright notice appears near the top of the file, and reads::
>>>
>>> Copyright YEARS LARGEST-CONTRIBUTOR [OTHER-CONTRIBUTORS] and others
>>>
>>> The largest contributor is whatever entity owns copyright to some
>>> portion of the largest number of lines in the file.  Additional
>>> contributors can be listed, but this is neither required nor
>>> recommended.  The "and others" text may be omitted if the explicitly
>>> listed contributors hold copyright to the entire file.
> 
>> Why is this not recommended? Here are a couple of scenarios that came to
>> mind that lead to me to question how that would play out:
>> If developer A writes 51% of the lines of an ebuild and developer B
>> writes 49%, should B not be listed?
> 
> With the current policy neither of them is listed, so listing A would
> be an improvement. The goal is to keep things simple, and listing only
> the largest contributor looks like the simplest solution. For example,
> listing the two largest contributors would lead to similar problems.
> What should we do if A and B each write 34% and C writes 32%?
> 
> In a previous version of the draft, we had required a full list of
> copyright holders to be listed somewhere in the file, and 60% of the
> lines to be accounted for:
> https://gitweb.gentoo.org/data/glep.git/commit/?id=bb756839bbd403059f6faeceaa114346d2a840d7
> 
> We changed that because neither tracing the number of lines nor
> maintaining a list of authors in every ebuild seems feasible.
> 
>> What if all the metadata lines defining variables consists of 75% of the
>> file and was written by A, but the core functionality of the ebuild (25%
>> by size) was written by B?
> 
> That would get us into a discussion on which portions of an ebuild are
> copyrightable and which are not. Again, we want simple rules there.
> 
>> If A writes an ebuild, and B replaces a majority (>50%) of the ebuild,
>> should B remove A from attribution?
>> I think that specifying that substantial (though not necessarily
>> specific in defining this) contributions/contributors should included in
>> the copyright attribution and that substantial contribution attribution
>> *is* recommended.
> 
> See above. Explicitly listing only one copyright holder in the
> copyright line looks like the simplest possible solution. Listing
> nobody would be even simpler, but I think that you cannot have a
> copyright line without at least one entity.
> 
> Also note that the exercise is _not_ about giving credit to authors
> (and we currently don't do that with the Foundation copyright either).
> The purpose of the copyright notice is to make a statement that the
> work is copyrighted, in order to defeat a possible defense of
> "innocent infringement".

Hence the "and others." Got it. I think that slipped my mind when I
typed up the email.  IANAL, so as long as "and others" would hold its
weight in copyright litigation, SGTM; my points are pretty much moot. I
guess I (wrongly) assumed it was partly a crediting thing.

Thanks for the clarification.

> 
> Ulrich
> 


-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 5206 bytes --]

On 06/11/2018 01:07 PM, Rich Freeman wrote:
> On Mon, Jun 11, 2018 at 12:25 PM NP-Hardass <NP-Hardass@gentoo.org> wrote:
>>
>> On 06/10/2018 04:34 PM, Ulrich Mueller wrote:
>>
>>> Copyright Attribution
>>> ---------------------
>>>
>>> All files included in Gentoo projects must contain an appropriate
>>> copyright notice, as defined by this policy.
>>>
>>> A proper copyright notice appears near the top of the file, and reads::
>>>
>>>     Copyright YEARS LARGEST-CONTRIBUTOR [OTHER-CONTRIBUTORS] and others
>>>
>>> The largest contributor is whatever entity owns copyright to some
>>> portion of the largest number of lines in the file.  Additional
>>> contributors can be listed, but this is neither required nor
>>> recommended.  The "and others" text may be omitted if the explicitly
>>> listed contributors hold copyright to the entire file.
>>
>> Why is this not recommended?
> 
> So, I came up with this to try to keep it as simple as possible.
> 
> My concern was basically analogous to the BSD advertising clause
> problem.  If you start accumulating authors on this line then it gets
> unwieldy.  How do you draw the line?
> 
> I suggested drawing the line at whoever touched the most lines, mainly
> because it is simple.
> 
> IMO ANY solution is going to be imperfect, so simple trumps all.
> 
> But, it certainly isn't the only possible solution to this problem.
> 
> Keep in mind that notice is not the same as
> authorship/copyright/credit/etc.  The "and others" is important.
> Being #2 doesn't in any way diminish your rights under the law.  The
> law simply requires a notice, so we need to come up with one.  It
> shouldn't be viewed as "this is the only important contributor to this
> file."  If we could not have any notice at all legally then that would
> be simpler still.  Git already tracks who did what, and should always
> be the place to go for this info.
> 
>> If developer A writes 51% of the lines of an ebuild and developer B
>> writes 49%, should B not be listed?
> 
> Under the policy, no.
> 
>> What if all the metadata lines defining variables consists of 75% of the
>> file and was written by A, but the core functionality of the ebuild (25%
>> by size) was written by B?
> 
> Under the policy, "A and others" is listed.
> 
>> If A writes an ebuild, and B replaces a majority (>50%) of the ebuild,
>> should B remove A from attribution?
> 
> Under the policy, yes, assuming this is noticed.  The policy does not
> require checking on every commit, but only when the issue is
> escalated.  That is actually a change from the wording which tried to
> keep things more strict.
> 
>> I think that specifying that substantial (though not necessarily
>> specific in defining this) contributions/contributors should included in
>> the copyright attribution and that substantial contribution attribution
>> *is* recommended.
> 
> So, the issue then becomes whether we have to define "substantial."
> The goal is to have something actionable.  Anybody can run git blame
> easily enough.  Figuring out what is "substantial" is harder.
> 
> But, the other change to the policy was to relax this and not worry
> about keeping it as up to date.  So, in that spirit maybe we can be
> more vague and let it be dealt with via escalation.
> 
> That seems to be the approach the Linux Foundation takes.  As far as I
> can tell they have no policy regarding copyright notice - and the
> contents of their files are all over the place.  Presumably committers
> make their own judgement calls, and if somebody has a problem with it
> they point it out to the Linux Foundation.
> 
> That said, the fact that this is basically happened with the eudev
> copyright notices didn't prevent it from turning into a bit of a
> tempest in a teapot with all kinds of accusations being tossed around.
> It was dealt with upon escalation, but people tend to go crazy over
> this stuff so some kind of policy that an ordinary dev can understand
> wouldn't hurt, so that the issue is prevented.  That was the goal of
> the policy.
> 
> A big goal here was to keep it simple and understandable but not too
> vague.  It shouldn't need constant appeals to Trustees/Council/whoever
> to apply to individual situations.
> 
> To the extent that the notice doesn't truly give credit to
> contributors I'd call it a feature and not a bug.  I'd rather have the
> notices viewed as useless for that purpose, because then people won't
> constantly squabble about how does/doesn't get included on them.  The
> ideal choices would be listing everybody or nobody, but everybody is
> cumbersome, and nobody doesn't seem to be legally valid.  So, listing
> one by name preserves the nonsensical nature of the notice while still
> meeting the legal requirement.  Or something like that...
> 

Keeping it simple is fine by me.  As mentioned in my other reply to Ulm,
I think I was conflating contribution attribution and copyright
assignment.  As long as "and others" (being unnamed) doesn't prevent
others from retaining their copyright (in practice as opposed to in
principle), SGTM.


-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Matt Turner]

On Mon, Jun 11, 2018 at 9:25 AM, NP-Hardass <NP-Hardass@gentoo.org> wrote:
> On 06/10/2018 04:34 PM, Ulrich Mueller wrote:
>
> [...]
>
>> Copyright Attribution
>> ---------------------
>>
>> All files included in Gentoo projects must contain an appropriate
>> copyright notice, as defined by this policy.
>>
>> A proper copyright notice appears near the top of the file, and reads::
>>
>>     Copyright YEARS LARGEST-CONTRIBUTOR [OTHER-CONTRIBUTORS] and others
>>
>> The largest contributor is whatever entity owns copyright to some
>> portion of the largest number of lines in the file.  Additional
>> contributors can be listed, but this is neither required nor
>> recommended.  The "and others" text may be omitted if the explicitly
>> listed contributors hold copyright to the entire file.
>
> Why is this not recommended? Here are a couple of scenarios that came to
> mind that lead to me to question how that would play out:
> If developer A writes 51% of the lines of an ebuild and developer B
> writes 49%, should B not be listed?
> What if all the metadata lines defining variables consists of 75% of the
> file and was written by A, but the core functionality of the ebuild (25%
> by size) was written by B?
> If A writes an ebuild, and B replaces a majority (>50%) of the ebuild,
> should B remove A from attribution?
> I think that specifying that substantial (though not necessarily
> specific in defining this) contributions/contributors should included in
> the copyright attribution and that substantial contribution attribution
> *is* recommended.

Don't think about the copyright line as attribution or credit. Some
projects I work on have Author: lines in files, which I've always
found irritating because they're often out of date and generally
useless -- if you want attribution just look at git log.

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

>>>>> On Mon, 11 Jun 2018, Ulrich Mueller wrote:

> [...] Explicitly listing only one copyright holder in the copyright
> line looks like the simplest possible solution. Listing nobody would
> be even simpler, but I think that you cannot have a copyright line
> without at least one entity.

Actually, the simplest solution would be not to have any copyright
notice at all. It it optional, and copyright protection still holds
without it.

> Also note that the exercise is _not_ about giving credit to authors
> (and we currently don't do that with the Foundation copyright
> either). The purpose of the copyright notice is to make a statement
> that the work is copyrighted, in order to defeat a possible defense
> of "innocent infringement".

The following was brought up by rich0 in #gentoo-council: Do we care
about the "innocent infringement" defense? That is, would we actually
sue anybody to obtain "statutory damages" for past infringements of
our copyright, or would our goal be to bring them into compliance in
the future?

If it is only the latter, we may well omit the copyright line from
ebuilds, and keep only the GPL-2 license notice. That would save us
all the hassle of keeping track of the main contributor. (Of course,
we would have to determine the main contributors when we were to
pursue an infringement. But presumably, we would have to verify the
accuracy of the copyright line in any case.)

Disclaimer: IANAL, TINLA.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

On Wed, Jun 13, 2018 at 10:35:00PM +0200, Ulrich Mueller wrote:
> >>>>> On Mon, 11 Jun 2018, Ulrich Mueller wrote:
> 
> > [...] Explicitly listing only one copyright holder in the copyright
> > line looks like the simplest possible solution. Listing nobody would
> > be even simpler, but I think that you cannot have a copyright line
> > without at least one entity.
> 
> Actually, the simplest solution would be not to have any copyright
> notice at all. It it optional, and copyright protection still holds
> without it.

I was checking into this yesterday, and yes this is true. I would
personally be fine with not requiring copyright notices.

> > Also note that the exercise is _not_ about giving credit to authors
> > (and we currently don't do that with the Foundation copyright
> > either). The purpose of the copyright notice is to make a statement
> > that the work is copyrighted, in order to defeat a possible defense
> > of "innocent infringement".
> 
> The following was brought up by rich0 in #gentoo-council: Do we care
> about the "innocent infringement" defense? That is, would we actually
> sue anybody to obtain "statutory damages" for past infringements of
> our copyright, or would our goal be to bring them into compliance in
> the future?
> 
> If it is only the latter, we may well omit the copyright line from
> ebuilds, and keep only the GPL-2 license notice. That would save us
> all the hassle of keeping track of the main contributor. (Of course,
> we would have to determine the main contributors when we were to
> pursue an infringement. But presumably, we would have to verify the
> accuracy of the copyright line in any case.)

The contributors can be found via "git log" or "git blame", so it isn't
that hard to determine who they are.

> 
> Disclaimer: IANAL, TINLA.
> 
> Ulrich

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 6909 bytes --]

On Sun, 10 Jun 2018 22:34:45 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> - Gentoo projects must release their work under GPL-compatible free
>   software licenses, preferably under GPL-2 or later. CC-BY-SA-3.0
>   (or 4.0) can be used for documentation.
> 
> - All commits to Gentoo repositories must be accompanied by a
>   certificate of origin. Typically, this would be declared by adding
>   a "Signed-off-by:" line (or several of them) to every commit.
>   This model is very similar to the one used for development of the
>   Linux kernel.

Using the Linux kernel as a reference point, while amicable, is somewhat a
dangerous line of reasoning here. Partly, because we have several
significant differences in practice from that project, and "we both use
Git" is insufficient.

- We don't have the hierarchy of Marshals who process their lowers
  contributions. The closest we have to this is Gentoo-Proxy-Maint, but
  besides that, we have a wild west free-for-all where commits are
  essentially unmonitored, there is no structural/procedural oversight
  where higher privileges vet the contributions of lower privileges.

- We cannot rely on copy/move detection in any reasonable fashion, as:
	1. File names are significant data which have source-time
	consequences.

	2. File contents are incredibly regular, having high similarity
	to huge volumes of the tree, making a statistical percentage
	similarity basis prone to misdetection.

	3. We routinely employ "copy the file to increment its version"
	logic, which is practically unseen outside Gentoo, partly,
	because the reliance on filenames as a versioning system is
	"you're too poor to have a real VCS", typically speaking, and
	we only really have it as a historical wart from how we
	evolved. Such an idea is typically nonsense if you can rely on
	a VCS to handle versioning for you.

These factors basically make our workflow, and the nature of the work
we do substantially different from the Kernel project, and most other
projects.

> - The copyright notice, especially for ebuilds, will contain the
>   name of the largest contributor, plus an "and others" clause when
>   necessary. (So the "Copyright Gentoo Foundation" lines will be
>   phased out.)

This idea to me is just asking for trouble, given the aformentioned
factors.

The need to update copyright year is already a minor burden, smoothed
over slightly by the fact repoman can reliably fix it on its own.

Reliably handling contribution factors however seems difficult, given
the stock output given by "git blame" is routinely wrong due to how or
workflow operates.

( For example, attribution for every virtual/perl-*/*.ebuild should
trace back to 56bd759df1d0c750a065b8c845e93d5dfa6b549d when robbat2
committed the first incarnation of those files, as there are many lines
that haven't changed since then, but my Git Fu doesn't know of a way to
reliably do this without manually implementing new tools that are
portage-semantics aware and do log processing, and I say that while
actively developing tools that scrape git fast-export to attempt to do
something remotely like this, but its quickly approaching the limits of
what can be done in a week, let alone regularly )

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.

And to add insult to injury, changing these entries via either
mechanism produces source of commit churn and conflicts ( which
themselves, will alter the statistical bias of attribution, potentially
necessitating subsequent commits )

And around about here you ask "what's the point?". A lot of work, for
negligible benefit.

If anything, I'd rather have a per-package attribution file, not a
per-ebuild attribution file.

1. Its out-of-band, so it doesn't lead to changes in the attributed content itself
2. Its not subject as much to accidents of copy/rename because it
anchors itself to the logical directory (one could argue, all files in
${cat}/${pn}/${pn}-${pv} are derivative versions of the same file, modulo ${pv})
3. As a result of #1 and #2, said file can be generated server side
while generating rsync trees, either by careful application of `git
shortlog -s -n`, or some clever system that generates all such files by
reading the output of `git fast-export --no-data`, avoiding commit
churn 

On its surface, what I've proposed for #3 looks like it could be done per-file,
but the trick is in order to do it per-file, one needs to create a much
smarter fast-export/short-log filter that can determine the "true
origin" of a given ebuild across renames, and the data is simply not
there to answer that question.

You can make assumptions like "-r1 is the parent of -r2", but that
often isn't the case.

With the "per-directory" approach, we can basically incorporate the
assumption that true ancestry is hard to determine in Gentoo, and not
lie to people about the accuracy of the data provided.

( It will also by nature encompass a greater number of copyright holders
  having influenced the file, even if its not clear which holders
  contributed which lines )

cf:

  git --no-pager shortlog -n -s virtual/perl-ExtUtils-MakeMaker/
    19	Kent Fredric
    13	Agostino Sarubbo
     3	Tobias Klausmann
     2	Andreas K. Hüttel
     2	Jeroen Roovers
     2	Markus Meier
     2	Michał Górny
     2	Mike Frysinger
     2	Robin H. Johnson
     1	Aaron Bauman
     1	Fabian Groffen
     1	Justin Lecher
     1	Michael Haubenwallner
     1	Michael Weber
     1	Mike Gilbert
     1	Sergei Trofimovich
     1	Thomas Deutschmann
     1	Ulrich Müller

vs:

  git blame -M1% -C1% --line-porcelain virtual/perl-ExtUtils-MakeMaker/perl-ExtUtils-MakeMaker-7.100.200_rc-r4.ebuild | grep -E '^(author |filename)' | sort -u

author Kent Fredric
filename virtual/perl-Archive-Tar/perl-Archive-Tar-2.40.100_rc.ebuild
filename virtual/perl-Archive-Tar/perl-Archive-Tar-2.40.100_rc-r5.ebuild


git blame -M1% -C1% --line-porcelain virtual/perl-ExtUtils-MakeMaker/perl-ExtUtils-MakeMaker-7.240.0.ebuild | grep -E '^(author |filename)' | sort -u
author Andreas K. Hüttel
author Kent Fredric
filename virtual/perl-ExtUtils-MakeMaker/perl-ExtUtils-MakeMaker-7.240.0.ebuild

These 2 latter results are simply wrong, as evidenced by the unchanged
lines shown in:

  git --no-pager diff -M1 -C1 -D 56bd759df1d0c750a065b8c845e93d5dfa6b549d  -- "virtual/perl-ExtUtils-MakeMaker/*.ebuild"

I attempted similar with --find-copies-harder, but lost patience when
it spent 5 minutes doing nothing.

IN SUMMARY:

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Rich Freeman]

On Sat, Jun 16, 2018 at 9:03 PM Kent Fredric <kentnl@gentoo.org> 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

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 2213 bytes --]

On Sat, 16 Jun 2018 21:39:49 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Sat, Jun 16, 2018 at 9:03 PM Kent Fredric <kentnl@gentoo.org> wrote:
> 
> 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.

Surely then, the most effective and usefully correct copyright notice
(for portage trees at least), would be:

"Copyright Gentoo Foundation and Contributors"

Or similar, instead of abandoning the Gentoo Foundation Copyright and using
a random persons name?

Otherwise most of the proposal in regards to portage trees, is mostly a
waste of time.

> (So the "Copyright Gentoo Foundation" lines will be
>  phased out.)

Because otherwise, the objective of putting a humans name there is
misleading at best, and serves no objective purpose.

If the objective is to simply denote the file has a copyright, that
format should do the job.

( Additionally, I have no opposition to generating a package-wide
file that notates contributors, such an approach is routinely
satisfactory for debian with regards to marking up which files have
which licenses without needing to inject the license in the file, and
has the benefit of exposing that metadata to consumers who only access
via rsync or tarballs, its just in-band in-git data that I find most
obnoxious due to being functionally redundant )


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 3995 bytes --]

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@gentoo.org> wrote:
>On Sat, Jun 16, 2018 at 9:03 PM Kent Fredric <kentnl@gentoo.org> 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.

[-- Attachment #2: Type: text/html, Size: 5114 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

On Wed, 13 Jun 2018 15:44:35 -0500
William Hubbs <williamh@gentoo.org> wrote:

> The contributors can be found via "git log" or "git blame", so it isn't
> that hard to determine who they are.

*caveat: git blame cannot be used usefully in the gentoo portage repo,
as it does not retain contributor data in any meaningful way.

git log and inferences made by analysing the log is the only way to
determine contributors, and then it is only a 90% solution.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Rich Freeman]

On Sat, Jun 16, 2018 at 10:14 PM Kent Fredric <kentnl@gentoo.org> wrote:
>
> Surely then, the most effective and usefully correct copyright notice
> (for portage trees at least), would be:
>
> "Copyright Gentoo Foundation and Contributors"
>
> Or similar, instead of abandoning the Gentoo Foundation Copyright and using
> a random persons name?

Sure, and that is what the policy proposes (except "and others"
instead of "and Contributors"), at least for existing stuff that has
the Foundation headers.  For new stuff it would be the name of the
main copyright holder.

> If the objective is to simply denote the file has a copyright, that
> format should do the job.

Sure.  It just isn't appropriate for things that the Foundation
doesn't hold copyright on, and it caused quite a stir when a large
number of notices were stripped from files and replaced with the
Foundation, hence the policy.

> ( Additionally, I have no opposition to generating a package-wide
> file that notates contributors, such an approach is routinely
> satisfactory for debian with regards to marking up which files have
> which licenses without needing to inject the license in the file, and
> has the benefit of exposing that metadata to consumers who only access
> via rsync or tarballs, its just in-band in-git data that I find most
> obnoxious due to being functionally redundant )

The original policy suggested something like this.  IMO git is a lot
simpler.  I don't see the point in duplicating git info just for the
benefit of people who can't be bothered to look at it.

-- 
Rich

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

[Rich Freeman]

On Sat, Jun 16, 2018 at 10:17 PM Aaron Bauman <bman@gentoo.org> wrote:
>
> 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"

You'll have to point out where I said that.

The policy was written in reaction to the problems that came about
when copyright notices were stripped from udev code, in order to
comply with what was perceived to be the Gentoo policy at the time.
That is clearly not a good policy, and this new policy was created to
fix that (and bikeshedded over the following few years).

The policy does not require anybody to do "busy work" - it just tells
you what to put in the copyright notice line when you're editing it.
You don't have to look at the notice when you're making random ebuild
changes.

Rich

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

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

You obviously didn't explicitly say that.  Forgive me for the lack of sarcasm tags.

Yes doing work that is inaccurate and lends to no good cause is busy work.  Yes, someone would have to do it.  No devs wouldn't be mandated too.

And years later we still have no problems with any copyright issues.

These lists are full of end of the world scenarios just like the council/trustee/foundation crap.

We have issues (like taxes) and then we bikeshed it until our fingers bleed all the while *one* guy tries to save it by doing actual work.

Another beautiful Gentoo day.  <--- Rich, this is sarcasm.

On June 16, 2018 10:39:51 PM EDT, Rich Freeman <rich0@gentoo.org> wrote:
>On Sat, Jun 16, 2018 at 10:17 PM Aaron Bauman <bman@gentoo.org> wrote:
>>
>> 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"
>
>You'll have to point out where I said that.
>
>The policy was written in reaction to the problems that came about
>when copyright notices were stripped from udev code, in order to
>comply with what was perceived to be the Gentoo policy at the time.
>That is clearly not a good policy, and this new policy was created to
>fix that (and bikeshedded over the following few years).
>
>The policy does not require anybody to do "busy work" - it just tells
>you what to put in the copyright notice line when you're editing it.
>You don't have to look at the notice when you're making random ebuild
>changes.
>
>Rich

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

[-- Attachment #2: Type: text/html, Size: 2120 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

On Sat, 16 Jun 2018 22:39:51 -0400
Rich Freeman <rich0@gentoo.org> wrote:
 
> The policy does not require anybody to do "busy work" - it just tells
> you what to put in the copyright notice line when you're editing it.
> You don't have to look at the notice when you're making random ebuild
> changes.
> 
> Rich
> 

On Sun, 10 Jun 2018 22:34:45 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> - The copyright notice, especially for ebuilds, will contain the
>   name of the largest contributor, plus an "and others" clause when
>   necessary. (So the "Copyright Gentoo Foundation" lines will be
>   phased out.)

- **ESPECIALLY** for ebuilds
- **WILL CONTAIN**
- So the "Copyright Gentoo Foundation" lines **WILL BE** phased out


So you can understand where this animosity comes from, esp as your
comments and Ulrich's seem to directly contradict each other.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 4737 bytes --]

>>>>> On Sun, 17 Jun 2018, Kent Fredric wrote:

> On Sun, 10 Jun 2018 22:34:45 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:

>> - Gentoo projects must release their work under GPL-compatible free
>> software licenses, preferably under GPL-2 or later. CC-BY-SA-3.0
>> (or 4.0) can be used for documentation.
>> 
>> - All commits to Gentoo repositories must be accompanied by a
>> certificate of origin. Typically, this would be declared by adding
>> a "Signed-off-by:" line (or several of them) to every commit.
>> This model is very similar to the one used for development of the
>> Linux kernel.

> Using the Linux kernel as a reference point, while amicable, is somewhat a
> dangerous line of reasoning here. Partly, because we have several
> significant differences in practice from that project, and "we both use
> Git" is insufficient.

> - We don't have the hierarchy of Marshals who process their lowers
>   contributions. The closest we have to this is Gentoo-Proxy-Maint, but
>   besides that, we have a wild west free-for-all where commits are
>   essentially unmonitored, there is no structural/procedural oversight
>   where higher privileges vet the contributions of lower privileges.

> - We cannot rely on copy/move detection in any reasonable fashion, as:
> 	1. File names are significant data which have source-time
> 	consequences.

> 	2. File contents are incredibly regular, having high similarity
> 	to huge volumes of the tree, making a statistical percentage
> 	similarity basis prone to misdetection.

> 	3. We routinely employ "copy the file to increment its version"
> 	logic, which is practically unseen outside Gentoo, partly,
> 	because the reliance on filenames as a versioning system is
> 	"you're too poor to have a real VCS", typically speaking, and
> 	we only really have it as a historical wart from how we
> 	evolved. Such an idea is typically nonsense if you can rely on
> 	a VCS to handle versioning for you.

> These factors basically make our workflow, and the nature of the work
> we do substantially different from the Kernel project, and most other
> projects.

I don't see how any of this would prevent a committer from adding a
Signed-off-by line.

>> - The copyright notice, especially for ebuilds, will contain the
>> name of the largest contributor, plus an "and others" clause when
>> necessary. (So the "Copyright Gentoo Foundation" lines will be
>> phased out.)

> This idea to me is just asking for trouble, given the aformentioned
> factors.

> The need to update copyright year is already a minor burden, smoothed
> over slightly by the fact repoman can reliably fix it on its own.

> Reliably handling contribution factors however seems difficult, given
> the stock output given by "git blame" is routinely wrong due to how or
> workflow operates.

We'll get rid of the line counting in the next iteration of the GLEP
(to be posted soon), and replace the wording by "the original author,
or the contributor holding copyright to the largest portion of the
file." So there will be no need to check the accuracy of the copyright
notice with every update of an ebuild, because it is a derived work of
its previous version. However, the copyright notice can be updated
when the ebuild is rewritten from scratch.

> ( For example, attribution for every virtual/perl-*/*.ebuild should
> trace back to 56bd759df1d0c750a065b8c845e93d5dfa6b549d when robbat2
> committed the first incarnation of those files, as there are many lines
> that haven't changed since then, but my Git Fu doesn't know of a way to
> reliably do this without manually implementing new tools that are
> portage-semantics aware and do log processing, and I say that while
> actively developing tools that scrape git fast-export to attempt to do
> something remotely like this, but its quickly approaching the limits of
> what can be done in a week, let alone regularly )

See above, we won't do line counting which is unreliable in any case.
For example, someone who adds or removes a "|| die" would get
accounted for that line.

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

> a) hard
> b) impossible

This is obvious, but it is not our aim to automate it.

> [...]

> IN SUMMARY:

> 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.

It is quite simple, we cannot put the Gentoo Foundation into copyright
notices, when no copyright assignment took place.

Even the requirement that every contributor must sign an FLA would not
help us there. IIUC we still wouldn't be allowed to use Foundation
copyright notices, because the FLA only grants a license but doesn't
assign copyright.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

>>>>> On Sun, 17 Jun 2018, Kent Fredric wrote:

> On Sat, 16 Jun 2018 22:39:51 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
 
>> The policy does not require anybody to do "busy work" - it just tells
>> you what to put in the copyright notice line when you're editing it.
>> You don't have to look at the notice when you're making random ebuild
>> changes.

> On Sun, 10 Jun 2018 22:34:45 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:

>> - The copyright notice, especially for ebuilds, will contain the
>> name of the largest contributor, plus an "and others" clause when
>> necessary. (So the "Copyright Gentoo Foundation" lines will be
>> phased out.)

> - **ESPECIALLY** for ebuilds
> - **WILL CONTAIN**
> - So the "Copyright Gentoo Foundation" lines **WILL BE** phased out

> So you can understand where this animosity comes from, esp as your
> comments and Ulrich's seem to directly contradict each other.

I don't see a contradiction there. You don't update the notice when
making a small ebuild change.

But of course, notices that are completely inaccurate (e.g., listing
an entity that hasn't been assigned copyright) should be replaced.
This needs to be done only once.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

On Sun, 17 Jun 2018 09:00:54 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> See above, we won't do line counting which is unreliable in any case.
> For example, someone who adds or removes a "|| die" would get
> accounted for that line.

Even if you abandon line counting, enumerating an "original author"
using git tools is non-trivial:

git --no-pager log --find-copies-harder --oneline --stat -M1 -C1 -D virtual/perl-ExtUtils-MakeMaker/perl-ExtUtils-MakeMaker-7.100.200_rc-r4.ebuild 
e1e494af471 (master) virtual/perl-*: -r1 bump all virtuals with new RDEPEND entries
 virtual/perl-ExtUtils-MakeMaker/perl-ExtUtils-MakeMaker-7.100.200_rc-r4.ebuild | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

.... neat.

Granted, this seems somewhat viable as long as we:

1. Do a one-time tree-wide assignment with a time-expensive git
   traversal ( possibly even digging into gentoo-history.git for the
   oldest author )
2. Then just assign it to $self every time you write a fresh ebuild,
   but leave it as-is when you're doing bumps/edits unless you're
   feeling extra-narcissitic.

( With a bit of luck, this will possibly aid future copy/rename
  detection )

It still seems like a big time waste to pander to some legal fantasy
world which will probably not even care for this data.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On Sun, 17 Jun 2018 09:00:54 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> I don't see how any of this would prevent a committer from adding a
> Signed-off-by line.

Here, it just seems like unnecessary fluff, given the committer and the
signed-off-by line should be identical.

It makes more sense in the kernel, where patches get formatted with
only author data, and the chain of custody from the border to its final
commit in kernel@ is not necessarily completely obvious.

Whereas in Gentoo, we don't really have any of those intermediate steps.

Its more a question what it seeks to achieve that can't be done with
existing data.

Especially considering anyone can trivially forge such a statement
and pretend they committed on somebody elses behalf after receiving a
patch.

And I somewhat find the "real names" policy somewhat obnoxious, for as
far as I'm aware, pseudonyms are just as legally binding as real names.

Requiring a legal name just excludes people, and well known pseudonymous
authors like "why_" would never participate in such a scheme.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

>>>>> On Sun, 17 Jun 2018, Kent Fredric wrote:

>> I don't see how any of this would prevent a committer from adding a
>> Signed-off-by line.

> Here, it just seems like unnecessary fluff, given the committer and the
> signed-off-by line should be identical.

The Signed-off-by line certifies agreement to the Gentoo DCO, whereas
the Commit line doesn't have any such meaning. Also the committer info
is somewhat transient and can change, e.g. when a branch gets rebased.
S-o-b lines won't get lost on a rebase.

> It makes more sense in the kernel, where patches get formatted with
> only author data, and the chain of custody from the border to its final
> commit in kernel@ is not necessarily completely obvious.

There are many commits in Linux that have only a single S-o-b line.

> Whereas in Gentoo, we don't really have any of those intermediate steps.

> Its more a question what it seeks to achieve that can't be done with
> existing data.

> Especially considering anyone can trivially forge such a statement
> and pretend they committed on somebody elses behalf after receiving a
> patch.

That's why we also require commits to be PGP signed.

> And I somewhat find the "real names" policy somewhat obnoxious, for as
> far as I'm aware, pseudonyms are just as legally binding as real names.

> Requiring a legal name just excludes people, and well known pseudonymous
> authors like "why_" would never participate in such a scheme.

The real name requirement is nothing new, but a policy that is in
effect since 2004 [1,2]:

| Real names must be provided for all developers, including
| infrastructure and documentation. Any exceptions to this for
| extenuating circumstances will be considered on a case-by-case
| basis. No exceptions will be made for people doing copyrightable
| work (ebuilds, software, scripts, documentation, etc.).

Ulrich

[1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/recruiters/index.xml?revision=1.15&view=markup
[2] https://wiki.gentoo.org/wiki/Project:Recruiters/Recruiting#What_does_the_recruitment_process_involve.3F

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 637 bytes --]

On 06/17/2018 10:45 AM, Ulrich Mueller wrote:
> Here, it just seems like unnecessary fluff, given the committer and the
> signed-off-by line should be identical.

Another example where you can end up with separate signed off by is a
patch contributed by external party or proxied commit, where you can
also end up with two separate signed off by lines (original author and
committer) or a committer different from the signed off by, depending on
the interpretation of the policy.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

>>>>> On Sun, 17 Jun 2018, Kristian Fiskerstrand wrote:

> On 06/17/2018 10:45 AM, Ulrich Mueller wrote:
>> Here, it just seems like unnecessary fluff, given the committer and the
>> signed-off-by line should be identical.

Sorry, but this wasn't written by me. It is from kentnl's message:
https://archives.gentoo.org/gentoo-project/message/abf87983601cbe4182be632c759b9402

> Another example where you can end up with separate signed off by is a
> patch contributed by external party or proxied commit, where you can
> also end up with two separate signed off by lines (original author and
> committer) or a committer different from the signed off by, depending on
> the interpretation of the policy.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 390 bytes --]

On 06/17/2018 10:37 PM, Ulrich Mueller wrote:
> Sorry, but this wasn't written by me. It is from kentnl's message:
> https://archives.gentoo.org/gentoo-project/message/abf87983601cbe4182be632c759b9402

Sorry for the mis-attributation :)

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

On Sun, 17 Jun 2018 22:41:50 +0200
Kristian Fiskerstrand <k_f@gentoo.org> wrote:

> On 06/17/2018 10:37 PM, Ulrich Mueller wrote:
> > Sorry, but this wasn't written by me. It is from kentnl's message:
> > https://archives.gentoo.org/gentoo-project/message/abf87983601cbe4182be632c759b9402  
> 
> Sorry for the mis-attributation :)

That'll learn me for not putting Signed-off-by: statements in my emails.

Signed-off-by: Kristian Fiskerstrand <k_f@gentoo.org>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 16081 bytes --]

>>>>> On Sun, 10 Jun 2018, Ulrich Mueller wrote:

> Please find below the draft of a new copyright policy, which was in
> the making since 2013 at least. After several iterations, we have
> come up with a policy with the following key elements:

> - Gentoo projects must release their work under GPL-compatible free
>   software licenses, preferably under GPL-2 or later. CC-BY-SA-3.0
>   (or 4.0) can be used for documentation.

> - All commits to Gentoo repositories must be accompanied by a
>   certificate of origin. Typically, this would be declared by adding
>   a "Signed-off-by:" line (or several of them) to every commit.
>   This model is very similar to the one used for development of the
>   Linux kernel.

> - The copyright notice, especially for ebuilds, will contain the
>   name of the largest contributor, plus an "and others" clause when
>   necessary. (So the "Copyright Gentoo Foundation" lines will be
>   phased out.)

Find an updated version below, taking input from IRC and mailing lists
into consideration. The main changes are:

- Take into account that some assets (like images) won't allow for
  a copyright notice in the file itself.
- Don't rely on line counting, but state that the main copyright
  holder must be listed.
- Allow for a simplified form of the copyright notice, attributing
  copyright to "The Gentoo Authors".

The source of the GLEP can be found at [1] (or included below);
the rendered version is at [2].

Ulrich

[1] ReST: https://gitweb.gentoo.org/data/glep.git/tree/glep-0076.rst
[2] HTML: https://www.gentoo.org/glep/glep-0076.html


---
GLEP: 76
Title: Copyright Policy
Author: Richard Freeman <rich0@gentoo.org>,
        Alice Ferrazzi <alicef@gentoo.org>,
        Ulrich Müller <ulm@gentoo.org>,
        Robin H. Johnson <robbat2@gentoo.org>,
        Michał Górny <mgorny@gentoo.org>
Type: Informational
Status: Draft
Version: 1
Created: 2013-04-23
Last-Modified: 2018-06-17
Post-History: 2018-06-10, 2018-06-19
Content-Type: text/x-rst
---


Status
======

The policies on this page have no effect!  These are draft policies up
for discussion, not final versions.


Abstract
========

This GLEP introduces a copyright and licensing policy for Gentoo
projects.  It requires all contributions of software or documentation
to be released under a free license, and to be accompanied by a
certificate of origin.


Motivation
==========

The copyright ownership of Gentoo materials is ambiguous due to
historical factors, and this GLEP attempts to improve the process
going forward.

In the beginning (2000 or earlier), the copyright header stated that
*Gentoo Technologies, Inc.* was the copyright holder, without any
formal paperwork.  The formal assignment document was however only
introduced in early 2004.  The assignment had many objectors (mostly
on the ``gentoo-core`` mailing list).  The developer recruiting
procedures attempted to require signing of the document as a condition
for becoming a developer, but it was not applied to pre-existing
developers, or those that objected.

Later, the *Gentoo Foundation* was established, and copyrights were
formally transferred (including nullifying original developer
assignments to *Gentoo Technologies, Inc.*), and the copyright header
was updated.  The formal assignment document text was updated in 2006,
but the formal assignment process had already been abandoned in
mid-2004.

Throughout this, the presence of copyright headers existed as a
policy, and continues to exist to this day.  Some files also still
contain or have in the past contained additional copyright headers,
attributing ownership to other parties.

The policy to have copyright notices ascribing copyright ownership to
the Gentoo Foundation caused an issue when Gentoo developers forked
another project and hosted the fork on Gentoo infrastructure.  To
comply with the previous policy the copyright notices were modified,
which caused concerns with the project the files were forked from.
Our previous policy completely neglected the possibility that Gentoo
might want to host files that were not created internally.

Finally, since the early days of Gentoo new ideas around copyright
licensing have become more popular, such as the FSFE's Fiduciary
License Agreement [#FLA]_, which takes a copyleft approach to
copyright licensing, while also better complying with copyright laws
in nations that have author's rights.

The goal here was to create a policy that was flexible enough to cover
forks and situations where Gentoo would not own the majority of the
copyright in a file.


Specification
=============

Purpose / Scope
---------------

This policy documents how Gentoo contributors comply and document
copyright for any contributions made to Gentoo.  Anyone committing
documentation or sources to any repository hosted on Gentoo
infrastructure or to any official Gentoo project (independently
of hosting) must comply with this policy.  Unofficial Gentoo projects
are also recommended to use this policy.

Questions regarding this policy should be directed to the trustees or
the -project list.  Any concerns over possible copyright violations
should be directed to the Trustees if they cannot be worked out to
anyone's satisfaction with the appropriate maintainer.


Licensing of Gentoo Projects
----------------------------

Every Gentoo project must abide by the Gentoo Social Contract
[#SOCIAL-CONTRACT]_ and release its work under one or more of the
following:

a) The GNU General Public License, version 2 or later (GPL-2+)
   [#GPL-2]_.

b) The Creative Commons Attribution-ShareAlike 3.0 License
   (CC-BY-SA-3.0, only for documentation) [#CC-BY-SA-3.0]_.
   *[Note: or version 4.0, to be decided]*

c) A license approved as GPL compatible by the Free Software
   Foundation [#GPL-COMPAT]_.

Exceptions for other free software licenses will be granted by the
Gentoo Foundation on a case by case basis.

For easy reference, the license for each project should be documented
on the wiki page at [#PROJECTS]_.


Certificate of Origin
---------------------

All commits to Gentoo project repositories shall be accompanied by a
certificate of origin.  The purpose of the certificate is to declare
that the contribution can be modified and redistributed in accordance
with the project's license.

For commits made using a VCS, the committer shall certify agreement
to the Gentoo DCO by adding ``Signed-off-by: Name <e-mail>`` to the
commit message as a separate line.  Committers must use their real
name, i.e., the name that would appear in an official document like
a passport.

The following is the current Gentoo DCO::

    Gentoo Developer's Certificate of Origin, revision 1

    By making a contribution to this project, I certify that:

    (1) The contribution was created in whole or in part by me, and I have
        the right to submit it under the free software license indicated
        in the file; or

    (2) The contribution is based upon previous work that, to the best
        of my knowledge, is covered under an appropriate free software
        license, and I have the right under that license to submit that
        work with modifications, whether created in whole or in part by
        me, under the same free software license (unless I am permitted
        to submit under a different license), as indicated in the file; or

    (3) The contribution is a license text (or a file of similar nature),
        and verbatim distribution is allowed; or

    (4) The contribution was provided directly to me by some other person
        who certified (1), (2), (3), or (4), and I have not modified it.

    I understand and agree that this project and the contribution are
    public and that a record of the contribution (including all personal
    information I submit with it, including my sign-off) is maintained
    indefinitely and may be redistributed consistent with this project or
    the free software license(s) involved.

The Gentoo DCO is licensed under a Creative Commons
Attribution-ShareAlike 3.0 Unported License [#CC-BY-SA-3.0]_.
It is based on the Linux Kernel DCO [#OSDL-DCO]_, released by Open
Source Development Labs, Inc. in 2005 under a CC-BY-SA-2.5 License.


Copyright Attribution
---------------------

All copyrightable files included in Gentoo projects must contain
appropriate copyright and license notices, as defined by this policy.
For files in textual format, these notices normally appear near the
top of the file.  When technical limitations do not allow for text
notices in the file itself (e.g., for binary image file formats),
copyright and license can be stated in an accompanying text file in
the same directory.

A proper copyright notice reads::

    Copyright YEARS MAIN-CONTRIBUTOR [OTHER-CONTRIBUTOR]... [and others]

It must list the main copyright holder, who is usually the original
author, or the contributor holding copyright to the largest portion
of the file.  Additional copyright holders can be listed, but this is
normally not required.  The "and others" text may be omitted if the
explicitly listed contributors hold copyright to the entire file.

Anyone finding a file out of compliance should file a bug against the
associated project/package providing as much information as possible.
Files that are not brought into compliance within 60 days or upon a
request for removal by a aggrieved copyright holder will be removed.
Any concerns not addressed by a maintainer can be appealed to the
Trustees.


Simplified Attribution
----------------------

Alternatively, projects are welcome to use a simplified form of the
copyright notice, which reads::

    Copyright YEARS The Gentoo Authors

Projects using this scheme must track authorship in a VCS, unless they
list all authors of copyrightable contributions in an ``AUTHORS`` file.


Rationale
=========

Policy
------

This document aims to provide a single consistent copyright policy for
all Gentoo projects.  It is explicitly enforced for all official Gentoo
projects in order to protect the interests of Gentoo as a whole,
including its contributors, developers and users.  Additionally, it is
enforced for all other projects hosted on Gentoo infrastructure in order
to protect the Gentoo infrastructure owners and improve consistency.

The copyright model is built on the DCO model used by the Linux kernel
and requires all contributors to certify the legitimacy of their
contributions.  This also requires that they use their real name for
signing; an anonymous certification or one under a pseudonym would not
mean anything.

In the future, a second stage of this policy may use a combination of
the DCO model and an FLA model [#FLA]_ as it is used by different open
source projects.  Contributors would be able to freely choose whether
they sign the FLA document or not.


Licensing of Projects
---------------------

The Social Contract mentions GPL-2 and CC-BY-SA-2.0, both with the
option to use them in a later version ("at our discretion").  In order
to facilitate interchange of software between different projects, we
aim for uniformity of their licensing.  Therefore, items a) and b)
explicitly recommend the use of GPL-2+ and CC-BY-SA-3.0.  The latter
is restricted to be used for documentation, because Creative Commons
themselves recommend against using their licenses for software
[#CC-SOFTWARE]_.

Other GPL-compatible free software licenses that are not explicitly
listed are allowed by item c).  This covers cases where compatibility
to licenses used by upstream projects is necessary.  (For example,
the Gentoo BSD project may want to use the 2-clause or 3-clause BSD
license).

By default, GPL-incompatible licenses (e.g., the CDDL) are not
allowed, because their use would hinder interchange of code between
Gentoo projects.  However, the Foundation can grant exceptions to
this, as long as the license in question is a free software or open
source license.


DCO Changes
-----------

The Gentoo DCO rev. 1 has been based on Linux Kernel DCO 1.1
[#OSDL-DCO]_.  It features the following modifications from
the original:

1. The enumeration has been modified to use numeric points.

2. Additional point (3) has been inserted::

       (3) The contribution is a license text (or a file of similar nature),
       and verbatim distribution is allowed; or

3. The original point (c) has shifted to become point (4), and has been
   updated to account for the additional point (3).

4. The original point (d) has been transformed into a stand-alone
   paragraph following the enumeration.

5. The term "open source" has been replaced by "free software"
   throughout.

The new point was deemed necessary to allow committing license files
into the Gentoo repository, since those files usually do not permit
modification.  It has been established that adding a clear provision
for this case is better than excluding those commits from DCO
compliance.  Debian was facing a similar problem [#DEBIAN-LICENSE]_.

The update of point (c) was necessary to allow the new clause being
certified by the person providing the contribution.

The term "free software" is used for consistency with the language
of the Gentoo Social Contract [#SOCIAL-CONTRACT]_.

The remaining changes were merely editorial.  It has been established
that the last point is really separate from the other points, so it is
more appropriate to separate it from the enumeration by putting it
in a separate paragraph.


Copyright Notice
----------------

Especially for ebuild repositories, constantly keeping track of the
main copyright holder of any file would be rather inconvenient and
tedious.  Therefore, projects are free to use either a traditional
copyright notice listing the individual author(s), or a simplified
notice with an attribution to "The Gentoo Authors".  The latter
resembles the scheme used by the Chromium project [#CHROMIUM]_.


Acknowledgements
================

Many people have participated in invaluable discussions on this GLEP.
In particular, the authors would like to thank David Abbott,
Roy Bamford, Kristian Fiskerstrand, Andreas K. Hüttel, Manuel Rüger,
Matija Šuklje, Matthew Thode, and Alec Warner for their input.


References
==========

.. [#SOCIAL-CONTRACT] Gentoo Social Contract,
   https://www.gentoo.org/get-started/philosophy/social-contract.html

.. [#GPL-2] GNU General Public License, version 2 or later,
   http://www.gnu.org/licenses/gpl-2.0.html

.. [#CC-BY-SA-3.0] Creative Commons Attribution-ShareAlike 3.0
   Unported License, http://creativecommons.org/licenses/by-sa/3.0/

.. [#GPL-COMPAT] GPL-compatible free software licenses,
   https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses

.. [#PROJECTS] Licensing of Gentoo projects,
   https://wiki.gentoo.org/wiki/Project:Licenses/Licensing_of_Gentoo_projects

.. [#OSDL-DCO] Developer's Certificate of Origin 1.1,
   https://web.archive.org/web/20060524185355/http://www.osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html

.. [#FLA] FSFE Legal: Fiduciary Licence Agreement (FLA),
   https://fsfe.org/activities/ftf/fla.en.html

.. [#CC-SOFTWARE] Can I apply a Creative Commons license to software?
   https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software

.. [#DEBIAN-LICENSE] [debian-legal] License of the GPL license,
   https://lists.debian.org/debian-legal/2018/04/msg00006.html

.. [#CHROMIUM] Chromium: Contributing Code,
   https://www.chromium.org/developers/contributing-code#TOC-Legal-stuff


Copyright
=========

This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
Unported License.  To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/.

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

Am Dienstag, 19. Juni 2018, 19:30:54 CEST schrieb Ulrich Mueller:
> >>>>> On Sun, 10 Jun 2018, Ulrich Mueller wrote:
> > Please find below the draft of a new copyright policy, which was in
> > the making since 2013 at least.

Looks good to me, no further comments. 

As discussed on IRC, regarding the CC license version "3.0 or later for 
existing projects, 4.0 or later for new projects" sounds like a good plan.

Cheers, 
Andreas

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 788 bytes --]

>>>>> On Sat, 23 Jun 2018, Andreas K Huettel wrote:

> As discussed on IRC, regarding the CC license version "3.0 or later for 
> existing projects, 4.0 or later for new projects" sounds like a good plan.

I've updated item b) in the Licensing section:

 a) The GNU General Public License, version 2 or later (GPL-2+)
    [#GPL-2]_.
 
-b) The Creative Commons Attribution-ShareAlike 3.0 License
-   (CC-BY-SA-3.0, only for documentation) [#CC-BY-SA-3.0]_.
-   *[Note: or version 4.0, to be decided]*
+b) The Creative Commons Attribution-ShareAlike 4.0 License
+   (CC-BY-SA-4.0, only for documentation) [#CC-BY-SA-4.0]_.
+   Existing projects may also stay with CC-BY-SA-3.0 [#CC-BY-SA-3.0]_.
 
 c) A license approved as GPL compatible by the Free Software
    Foundation [#GPL-COMPAT]_.

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 16530 bytes --]

Find another update of the copyright GLEP below. This takes further
input from mailing lists and IRC into consideration. Main changes are:

- The certificate of origin has been renamed from DCO to "Gentoo
  Certificate of Origin", because the original's conditions for
  modification require using a name that is not "confusingly similar".

- The Linux DCO 1.1 can be used as an alternative to certify commits,
  if it is applicable.

- The default documentation license for new projects is CC-BY-SA-4.0
  (existing projects can either stay with 3.0, or upgrade).

- The simplified form of the copyright notice now says "Gentoo Authors"
  (without the "The").

The source of the GLEP can be found at [1] (or included below); the
rendered version is at [2].

Ulrich

[1] ReST: https://gitweb.gentoo.org/data/glep.git/tree/glep-0076.rst
[2] HTML: https://www.gentoo.org/glep/glep-0076.html


---
GLEP: 76
Title: Copyright Policy
Author: Richard Freeman <rich0@gentoo.org>,
        Alice Ferrazzi <alicef@gentoo.org>,
        Ulrich Müller <ulm@gentoo.org>,
        Robin H. Johnson <robbat2@gentoo.org>,
        Michał Górny <mgorny@gentoo.org>
Type: Informational
Status: Draft
Version: 1
Created: 2013-04-23
Last-Modified: 2018-08-31
Post-History: 2018-06-10, 2018-06-19, 2018-08-31
Content-Type: text/x-rst
---


Status
======

The policies on this page have no effect!  These are draft policies up
for discussion, not final versions.


Abstract
========

This GLEP introduces a copyright and licensing policy for Gentoo
projects.  It requires all contributions of software or documentation
to be released under a free license, and to be accompanied by a
certificate of origin.


Motivation
==========

The copyright ownership of Gentoo materials is ambiguous due to
historical factors, and this GLEP attempts to improve the process
going forward.

In the beginning (2000 or earlier), the copyright header stated that
*Gentoo Technologies, Inc.* was the copyright holder, without any
formal paperwork.  The formal assignment document was however only
introduced in early 2004.  The assignment had many objectors (mostly
on the ``gentoo-core`` mailing list).  The developer recruiting
procedures attempted to require signing of the document as a condition
for becoming a developer, but it was not applied to pre-existing
developers, or those that objected.

Later, the *Gentoo Foundation* was established, and copyrights were
formally transferred (including nullifying original developer
assignments to *Gentoo Technologies, Inc.*), and the copyright header
was updated.  The formal assignment document text was updated in 2006,
but the formal assignment process had already been abandoned in
mid-2004.

Throughout this, the presence of copyright headers existed as a
policy, and continues to exist to this day.  Some files also still
contain or have in the past contained additional copyright headers,
attributing ownership to other parties.

The policy to have copyright notices ascribing copyright ownership to
the Gentoo Foundation caused an issue when Gentoo developers forked
another project and hosted the fork on Gentoo infrastructure.  To
comply with the previous policy the copyright notices were modified,
which caused concerns with the project the files were forked from.
Our previous policy completely neglected the possibility that Gentoo
might want to host files that were not created internally.

Finally, since the early days of Gentoo new ideas around copyright
licensing have become more popular, such as the FSFE's Fiduciary
License Agreement [#FLA]_, which takes a copyleft approach to
copyright licensing, while also better complying with copyright laws
in nations that have author's rights.

The goal here was to create a policy that was flexible enough to cover
forks and situations where Gentoo would not own the majority of the
copyright in a file.


Specification
=============

Purpose / Scope
---------------

This policy documents how Gentoo contributors comply and document
copyright for any contributions made to Gentoo.  Anyone committing
documentation or sources to any repository hosted on Gentoo
infrastructure or to any official Gentoo project (independently
of hosting) must comply with this policy.  Unofficial Gentoo projects
are also recommended to use this policy.

Questions regarding this policy should be directed to the Trustees
or the ``gentoo-project`` mailing list.  Any concerns over possible
copyright violations should be directed to the Trustees if they cannot
be worked out with the appropriate maintainer.


Licensing of Gentoo Projects
----------------------------

Every Gentoo project must abide by the Gentoo Social Contract
[#SOCIAL-CONTRACT]_ and release its work under one or more of the
following:

a) The GNU General Public License, version 2 or later (GPL-2+)
   [#GPL-2]_.

b) The Creative Commons Attribution-ShareAlike 4.0 License
   (CC-BY-SA-4.0, only for documentation) [#CC-BY-SA-4.0]_.
   Existing projects may also stay with CC-BY-SA-3.0 [#CC-BY-SA-3.0]_.

c) A license approved as GPL compatible by the Free Software
   Foundation [#GPL-COMPAT]_.

Exceptions for other free software licenses will be granted by the
Gentoo Foundation on a case by case basis.

For easy reference, the license for each project should be documented
on the wiki page at [#PROJECTS]_.


Certificate of Origin
---------------------

All commits to Gentoo project repositories shall be accompanied by a
certificate of origin.  The purpose of the certificate is to declare
that the contribution can be modified and redistributed in accordance
with the project's license.

For commits made using a VCS, the committer shall certify agreement to
the Certificate of Origin by adding ``Signed-off-by: Name <e-mail>``
to the commit message as a separate line.  Committers must use their
real name, i.e., the name that would appear in an official document
like a passport.

The following is the current Gentoo Certificate of Origin, revision 1:

    By making a contribution to this project, I certify that:

    1. The contribution was created in whole or in part by me, and I
       have the right to submit it under the free software license
       indicated in the file; or

    2. The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate free software
       license, and I have the right under that license to submit that
       work with modifications, whether created in whole or in part by
       me, under the same free software license (unless I am permitted
       to submit under a different license), as indicated in the file;
       or

    3. The contribution is a license text (or a file of similar nature),
       and verbatim distribution is allowed; or

    4. The contribution was provided directly to me by some other
       person who certified 1., 2., 3., or 4., and I have not modified
       it.

    I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the free software license(s) involved.

The Gentoo Certificate of Origin is licensed under a Creative Commons
Attribution-ShareAlike 3.0 Unported License [#CC-BY-SA-3.0]_.
It is based on the Linux Kernel DCO [#OSDL-DCO]_, released by Open
Source Development Labs, Inc. in 2005 under a CC-BY-SA-2.5 License.

Alternatively, and if it is applicable, committers are allowed to
certify their commits with the Linux Kernel DCO 1.1.  This shall be
clearly indicated by adding ``(Linux DCO 1.1)`` at the end of the
``Signed-off-by`` line.  Using the Gentoo Certificate of Origin is
strongly preferred, though.


Copyright Attribution
---------------------

All copyrightable files included in Gentoo projects must contain
appropriate copyright and license notices, as defined by this policy.
For files in textual format, these notices normally appear near the
top of the file.  When technical limitations do not allow for text
notices in the file itself (e.g., for binary image file formats),
copyright and license can be stated in an accompanying text file in
the same directory.

A proper copyright notice reads::

    Copyright YEARS MAIN-CONTRIBUTOR [OTHER-CONTRIBUTOR]... [and others]

It must list the main copyright holder, who is usually the original
author, or the contributor holding copyright to the largest portion
of the file.  Additional copyright holders can be listed, but this is
normally not required.  The "and others" text may be omitted if the
explicitly listed contributors hold copyright to the entire file.

Anyone finding a file out of compliance should file a bug against the
associated project/package providing as much information as possible.
Files that are not brought into compliance within 60 days or upon a
request for removal by a aggrieved copyright holder will be removed.
Any concerns not addressed by a maintainer can be appealed to the
Trustees.


Simplified Attribution
----------------------

Alternatively, projects are welcome to use a simplified form of the
copyright notice, which reads::

    Copyright YEARS Gentoo Authors

Projects using this scheme must track authorship in a VCS, unless they
list all authors of copyrightable contributions in an ``AUTHORS`` file.


Rationale
=========

Policy
------

This document aims to provide a single consistent copyright policy for
all Gentoo projects.  It is explicitly enforced for all official Gentoo
projects in order to protect the interests of Gentoo as a whole,
including its contributors, developers and users.  Additionally, it is
enforced for all other projects hosted on Gentoo infrastructure in order
to protect the Gentoo infrastructure owners and improve consistency.

The copyright model is built on the DCO model used by the Linux kernel
and requires all contributors to certify the legitimacy of their
contributions.  This also requires that they use their real name for
signing; an anonymous certification or one under a pseudonym would not
mean anything.

In the future, a second stage of this policy may use a combination of
the DCO model and an FLA model [#FLA]_ as it is used by different open
source projects.  Contributors would be able to freely choose whether
they sign the FLA document or not.


Licensing of Projects
---------------------

The Social Contract mentions GPL-2 and CC-BY-SA-2.0, both with the
option to use them in a later version ("at our discretion").  In order
to facilitate interchange of software between different projects, we
aim for uniformity of their licensing.  Therefore, items a) and b)
explicitly recommend the use of GPL-2+ and CC-BY-SA-4.0.  The latter
is restricted to be used for documentation, because Creative Commons
themselves recommend against using their licenses for software
[#CC-SOFTWARE]_.

Other GPL-compatible free software licenses that are not explicitly
listed are allowed by item c).  This covers cases where compatibility
to licenses used by upstream projects is necessary.  (For example,
the Gentoo BSD project may want to use the 2-clause or 3-clause BSD
license).

By default, GPL-incompatible licenses (e.g., the CDDL) are not
allowed, because their use would hinder interchange of code between
Gentoo projects.  However, the Foundation can grant exceptions to
this, as long as the license in question is a free software or open
source license.


Changes to the Certificate of Origin
------------------------------------

The Gentoo Certificate of Origin rev. 1 has been based on Linux Kernel
DCO 1.1 [#OSDL-DCO]_.  It features the following modifications from
the original:

i.   The enumeration has been modified to use numeric points.

ii.  Additional point 3. has been inserted:

         3. The contribution is a license text (or a file of similar
            nature), and verbatim distribution is allowed; or

iii. The original point (c) has shifted to become point 4., and has
     been updated to account for the additional point 3.

iv.  The original point (d) has been transformed into a stand-alone
     paragraph following the enumeration.

v.   The term "open source" has been replaced by "free software"
     throughout.

The new point was deemed necessary to allow committing license files
into the Gentoo repository, since those files usually do not permit
modification.  It has been established that adding a clear provision
for this case is better than excluding those commits from compliance
with the Certificate of Origin.  Debian was facing a similar problem
[#DEBIAN-LICENSE]_.

The update of point (c) was necessary to allow the new clause being
certified by the person providing the contribution.

The term "free software" is used for consistency with the language
of the Gentoo Social Contract [#SOCIAL-CONTRACT]_.

The remaining changes were merely editorial.  The original point (d)
is not part of the *or* statement joining the other points, so keeping
it in a paragraph separate from the enumeration is more appropriate.

Addition of another point for public domain material was also
considered.  However, it is preferred if all contributions carry
an explicit license notice that allows their certification under
point 1. or 2.  If necessary, license tools like Creative Commons
CC0 [#CC0-1.0]_ or Public Domain Mark [#CC-PDM-1.0]_ can be used.


Copyright Notice
----------------

Especially for ebuild repositories, constantly keeping track of the
main copyright holder of any file would be rather inconvenient and
tedious.  Therefore, projects are free to use either a traditional
copyright notice listing the individual author(s), or a simplified
notice with an attribution to the "Gentoo Authors".  The latter
resembles the scheme used by the Chromium project [#CHROMIUM]_.


Acknowledgements
================

Many people have participated in invaluable discussions on this GLEP.
In particular, the authors would like to thank David Abbott,
Roy Bamford, Kristian Fiskerstrand, Andreas K. Hüttel, Manuel Rüger,
Matija Šuklje, Matthew Thode, and Alec Warner for their input.


References
==========

.. [#SOCIAL-CONTRACT] Gentoo Social Contract,
   https://www.gentoo.org/get-started/philosophy/social-contract.html

.. [#GPL-2] GNU General Public License, version 2 or later,
   https://www.gnu.org/licenses/gpl-2.0.html

.. [#CC-BY-SA-4.0] Creative Commons Attribution-ShareAlike 4.0
   International License, https://creativecommons.org/licenses/by-sa/4.0/

.. [#CC-BY-SA-3.0] Creative Commons Attribution-ShareAlike 3.0
   Unported License, https://creativecommons.org/licenses/by-sa/3.0/

.. [#GPL-COMPAT] GPL-compatible free software licenses,
   https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses

.. [#PROJECTS] Licensing of Gentoo projects,
   https://wiki.gentoo.org/wiki/Project:Licenses/Licensing_of_Gentoo_projects

.. [#OSDL-DCO] Open Source Development Labs, Inc.,
   Developer's Certificate of Origin 1.1,
   https://web.archive.org/web/20060524185355/http://www.osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html

.. [#FLA] FSFE Legal: Fiduciary Licence Agreement (FLA),
   https://fsfe.org/activities/ftf/fla.en.html

.. [#CC-SOFTWARE] Can I apply a Creative Commons license to software?
   https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software

.. [#DEBIAN-LICENSE] [debian-legal] License of the GPL license,
   https://lists.debian.org/debian-legal/2018/04/msg00006.html

.. [#CC0-1.0] Creative Commons: CC0 1.0 Universal,
   https://creativecommons.org/publicdomain/zero/1.0/

.. [#CC-PDM-1.0] Creative Commons: Public Domain Mark 1.0,
   https://creativecommons.org/publicdomain/mark/1.0/

.. [#CHROMIUM] Chromium: Contributing Code,
   https://www.chromium.org/developers/contributing-code#TOC-Legal-stuff


Copyright
=========

This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
Unported License.  To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

>>>>> On Fri, 31 Aug 2018, Ulrich Mueller wrote:

> Find another update of the copyright GLEP below. This takes further
> input from mailing lists and IRC into consideration. Main changes are:

> - The certificate of origin has been renamed from DCO to "Gentoo
>   Certificate of Origin", because the original's conditions for
>   modification require using a name that is not "confusingly similar".

> - The Linux DCO 1.1 can be used as an alternative to certify commits,
>   if it is applicable.

> - The default documentation license for new projects is CC-BY-SA-4.0
>   (existing projects can either stay with 3.0, or upgrade).

> - The simplified form of the copyright notice now says "Gentoo Authors"
>   (without the "The").

> The source of the GLEP can be found at [1] (or included below); the
> rendered version is at [2].

Small update:
https://gitweb.gentoo.org/data/glep.git/commit/?h=glep-0076&id=c2869b90c4697a2aa9fec5567b51eef0da272e10

This slightly rewords the last paragraph in the "Certificate of Origin"
section (no change of meaning). It also adds a link to
developercertificate.org, to make clear to which version of the DCO it
refers.

Ulrich

> [1] ReST: https://gitweb.gentoo.org/data/glep.git/tree/glep-0076.rst
> [2] HTML: https://www.gentoo.org/glep/glep-0076.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

Hi!

On Mon, 03 Sep 2018 19:40:33 +0200 Ulrich Mueller wrote:
> Small update:
> https://gitweb.gentoo.org/data/glep.git/commit/?h=glep-0076&id=c2869b90c4697a2aa9fec5567b51eef0da272e10

> This also requires that they use their real name for signing; an
> anonymous certification or one under a pseudonym would not mean
> anything.

I don't like this. We have anonymous developers right now (at least
their names are not public even in LDAP). The cited requirement will
effectively kick them from the project. Moreover we have
contributors considering to become developers who prefer to keep
their anonymity.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]

>>>>> On Sat, 08 Sep 2018, Andrew Savchenko wrote:

>> This also requires that they use their real name for signing; an
>> anonymous certification or one under a pseudonym would not mean
>> anything.

Yes, that's the rationale. We can simply forget about the whole
copyright policy effort, if we don't require committers to certify
their contributions under their real name.

> I don't like this. We have anonymous developers right now (at least
> their names are not public even in LDAP). The cited requirement will
> effectively kick them from the project. Moreover we have contributors
> considering to become developers who prefer to keep their anonymity.

According to recruitment policy [1] (which is in place since 2004 [2]
at least), there cannot be any anonymous developers doing copyrightable
work:

# Real names must be provided for all developers, including
# infrastructure and documentation. Any exceptions to this for
# extenuating circumstances will be considered on a case-by-case
# basis. No exceptions will be made for people doing copyrightable
# work (ebuilds, software, scripts, documentation, etc.).

AFAICS, the GLEP will only confirm the existing policy there.

Ulrich

[1] https://wiki.gentoo.org/wiki/Project:Recruiters/Recruiting
[2] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/devrel/recruiters/index.xml?r1=1.14&r2=1.15

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Michael Orlitzky]

The Gentoo Certificate of origin says,

>  By making a contribution to this project, I certify that:
> 
>   1  The contribution was created in whole or in part by me...
> 
>   2  The contribution is based upon previous work that, to the best of 
>      my knowledge, is covered...
> 
>   3  The contribution is a license text (or a file of similar nature)...
> 
>   4  The contribution was provided directly to me by some other person 
>      who certified (1), (2), (3), or (4), and I have not modified it.

Do we really want to allow (4)s all the way down?

That issue aside, I have some doubts about the usefulness of asserting
(4), which to me sounds like the opposite of what is intended: "someone
gave it to me and he said it was fine" is a weird defense. Especially if
the name of the person doesn't appear in the sign-off.

I realize we might not be able to do much better in the case of e.g.
patches from outside contributors, but shouldn't we at least record the
person's name in that case? If there's ever a dispute, we might need to
track the guy down.

I also realize that (4) was taken directly from the DCO which presumably
has had actual lawyers look at it, so take this with a grain of salt.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

Dnia September 8, 2018 2:25:03 PM UTC, Michael Orlitzky <mjo@gentoo.org> napisał(a):
>The Gentoo Certificate of origin says,
>
>>  By making a contribution to this project, I certify that:
>> 
>>   1  The contribution was created in whole or in part by me...
>> 
>>   2  The contribution is based upon previous work that, to the best
>of 
>>      my knowledge, is covered...
>> 
>>   3  The contribution is a license text (or a file of similar
>nature)...
>> 
>>   4  The contribution was provided directly to me by some other
>person 
>>      who certified (1), (2), (3), or (4), and I have not modified it.
>
>Do we really want to allow (4)s all the way down?
>
>That issue aside, I have some doubts about the usefulness of asserting
>(4), which to me sounds like the opposite of what is intended: "someone
>gave it to me and he said it was fine" is a weird defense. Especially
>if
>the name of the person doesn't appear in the sign-off.
>
>I realize we might not be able to do much better in the case of e.g.
>patches from outside contributors, but shouldn't we at least record the
>person's name in that case? If there's ever a dispute, we might need to
>track the guy down.
>
>I also realize that (4) was taken directly from the DCO which
>presumably
>has had actual lawyers look at it, so take this with a grain of salt.

We require everyone certifying that to leave a signoff, so you'd have full backtrace.

--
Best regards, 
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]

>>>>> On Sat, 08 Sep 2018, Michael Orlitzky wrote:

> The Gentoo Certificate of origin says,
>> By making a contribution to this project, I certify that:
>> 
>> 1  The contribution was created in whole or in part by me...
>> 
>> 2  The contribution is based upon previous work that, to the best of 
>> my knowledge, is covered...
>> 
>> 3  The contribution is a license text (or a file of similar nature)...
>> 
>> 4  The contribution was provided directly to me by some other person 
>> who certified (1), (2), (3), or (4), and I have not modified it.

> Do we really want to allow (4)s all the way down?

> That issue aside, I have some doubts about the usefulness of asserting
> (4), which to me sounds like the opposite of what is intended: "someone
> gave it to me and he said it was fine" is a weird defense. Especially if
> the name of the person doesn't appear in the sign-off.

If you certify 4., the commit should already carry a Signed-off-by line
with that other person's name. If not, you must certify it with one of
the other clauses (presumably, 2.).

> I realize we might not be able to do much better in the case of e.g.
> patches from outside contributors, but shouldn't we at least record the
> person's name in that case?

Yes, the idea is that either there is a chain of Signed-off-by lines, or
(if not) that the committer has the responsibility that the contribution
is under a free software license.

Realistically, I won't expect our certification chains to have normally
more than two S-o-b lines (like proxied committer and proxy committer).

> If there's ever a dispute, we might need to track the guy down.

We can also see it more positively, the name should be there to give
credit to the right person. :)

> I also realize that (4) was taken directly from the DCO which presumably
> has had actual lawyers look at it, so take this with a grain of salt.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

On Sat, 08 Sep 2018 15:35:58 +0200 Ulrich Mueller wrote:
> >>>>> On Sat, 08 Sep 2018, Andrew Savchenko wrote:
> 
> >> This also requires that they use their real name for signing; an
> >> anonymous certification or one under a pseudonym would not mean
> >> anything.
> 
> Yes, that's the rationale. We can simply forget about the whole
> copyright policy effort, if we don't require committers to certify
> their contributions under their real name.
> 
> > I don't like this. We have anonymous developers right now (at least
> > their names are not public even in LDAP). The cited requirement will
> > effectively kick them from the project. Moreover we have contributors
> > considering to become developers who prefer to keep their anonymity.
> 
> According to recruitment policy [1] (which is in place since 2004 [2]
> at least), there cannot be any anonymous developers doing copyrightable
> work:
> 
> # Real names must be provided for all developers, including
> # infrastructure and documentation. Any exceptions to this for
> # extenuating circumstances will be considered on a case-by-case
> # basis. No exceptions will be made for people doing copyrightable
> # work (ebuilds, software, scripts, documentation, etc.).
> 
> AFAICS, the GLEP will only confirm the existing policy there.

Real names must be provided != must be publicly available. The
current status is that they are in LDAP, but not viewable outside
of recruiters (and maybe some other limited groups). What you are
proposing demands public availability, so it can be seen as an extra
requirement compared to GLEP.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

>>>>> On Sat, 08 Sep 2018, Andrew Savchenko wrote:

> On Sat, 08 Sep 2018 15:35:58 +0200 Ulrich Mueller wrote:
>> # Real names must be provided for all developers, including
>> # infrastructure and documentation. Any exceptions to this for
>> # extenuating circumstances will be considered on a case-by-case
>> # basis. No exceptions will be made for people doing copyrightable
>> # work (ebuilds, software, scripts, documentation, etc.).

> Real names must be provided != must be publicly available. The
> current status is that they are in LDAP, but not viewable outside
> of recruiters (and maybe some other limited groups).

The list of active developers at
https://www.gentoo.org/inside-gentoo/developers/ (which AFAIK is
generated from LDAP) doesn't suggest any such cases. I see one name
which seems to be a pseudonym (a name of a character from a comic),
but that person is not an ebuild developer.

Please correct me if I'm wrong.

> What you are proposing demands public availability, so it can be seen
> as an extra requirement compared to GLEP.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Justin Lecher]

[-- Attachment #1.1: Type: text/plain, Size: 584 bytes --]

On 08/09/2018 19:55, Ulrich Mueller wrote:
> 
> The list of active developers at
> https://www.gentoo.org/inside-gentoo/developers/ (which AFAIK is
> generated from LDAP) doesn't suggest any such cases. I see one name
> which seems to be a pseudonym (a name of a character from a comic),
> but that person is not an ebuild developer.
> 
At least in my time as recruiter we provided the real names to the
trustees and put into LDAP what ever the developer felt comfortable
with. I would ask the trustees for the full list as they should have the
best overview.

Justin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 989 bytes --]

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

On Sat, 08 Sep 2018 20:55:03 +0200 Ulrich Mueller wrote:
> >>>>> On Sat, 08 Sep 2018, Andrew Savchenko wrote:
> 
> > On Sat, 08 Sep 2018 15:35:58 +0200 Ulrich Mueller wrote:
> >> # Real names must be provided for all developers, including
> >> # infrastructure and documentation. Any exceptions to this for
> >> # extenuating circumstances will be considered on a case-by-case
> >> # basis. No exceptions will be made for people doing copyrightable
> >> # work (ebuilds, software, scripts, documentation, etc.).
> 
> > Real names must be provided != must be publicly available. The
> > current status is that they are in LDAP, but not viewable outside
> > of recruiters (and maybe some other limited groups).
> 
> The list of active developers at
> https://www.gentoo.org/inside-gentoo/developers/ (which AFAIK is
> generated from LDAP) doesn't suggest any such cases. I see one name
> which seems to be a pseudonym (a name of a character from a comic),
> but that person is not an ebuild developer.
> 
> Please correct me if I'm wrong.

https://wiki.gentoo.org/wiki/User:NP-Hardass

If this sounds like real name to you...
With git access of course.
 
> > What you are proposing demands public availability, so it can be seen
> > as an extra requirement compared to GLEP.
> 
> Ulrich


Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

>>>>> On Sun, 09 Sep 2018, Andrew Savchenko wrote:

> On Sat, 08 Sep 2018 20:55:03 +0200 Ulrich Mueller wrote:
>> The list of active developers at
>> https://www.gentoo.org/inside-gentoo/developers/ (which AFAIK is
>> generated from LDAP) doesn't suggest any such cases. I see one name
>> which seems to be a pseudonym (a name of a character from a comic),
>> but that person is not an ebuild developer.
>> 
>> Please correct me if I'm wrong.

> https://wiki.gentoo.org/wiki/User:NP-Hardass

> If this sounds like real name to you...
> With git access of course.

Yeah, sorry. I used the dev web of trust to initially clean up the list.
So either that name appears on a passport, or another dev has signed the
PGP key without verifying identity.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 19635 bytes --]

Here is another small update of the copyright GLEP, resulting from a
recent discussion on IRC. This is not a change of policy, but merely
a clarification of the real name requirement:

- The Signed-off-by line must contain the name of a natural person.

- A copyright holder can be a legal entity (e.g., a company) in some
  jurisdictions.

Below is a diff to the previous (approved) version, followed by the
GLEP's full text.

Ulrich


diff --git a/glep-0076.rst b/glep-0076.rst
index 4c0ffcb..4f9479b 100644
--- a/glep-0076.rst
+++ b/glep-0076.rst
@@ -10,7 +10,7 @@ Type: Informational
 Status: Accepted
 Version: 1
 Created: 2013-04-23
-Last-Modified: 2018-09-15
+Last-Modified: 2018-09-26
 Post-History: 2018-06-10, 2018-06-19, 2018-08-31
 Content-Type: text/x-rst
 ---
@@ -133,9 +133,9 @@ with the project's license.
 
 For commits made using a VCS, the committer shall certify agreement to
 the Certificate of Origin by adding ``Signed-off-by: Name <e-mail>``
-to the commit message as a separate line.  Committers must use their
-real name, i.e., the name that would appear in an official document
-like a passport.
+to the commit message as a separate line.  The sign-off must contain
+the committer's legal name as a natural person, i.e., the name that
+would appear in a government issued document.
 
 The following is the current Gentoo Certificate of Origin, revision 1:
 
@@ -197,6 +197,9 @@ author, or the contributor holding copyright to the largest portion
 of the file.  Additional copyright holders can be listed, but this is
 normally not required.  The "and others" text may be omitted if the
 explicitly listed contributors hold copyright to the entire file.
+In some jurisdictions, the copyright holder can also be a company or
+other legal entity, and therefore be different from the original
+author.
 
 Anyone finding a file out of compliance should file a bug against the
 associated project/package providing as much information as possible.
@@ -235,7 +238,8 @@ The copyright model is built on the DCO model used by the Linux kernel
 and requires all contributors to certify the legitimacy of their
 contributions.  This also requires that they use their real name for
 signing; an anonymous certification or one under a pseudonym would not
-mean anything.
+mean anything.  This policy is derived from the Linux project's policy
+[#SUBMITTING-PATCHES]_.
 
 In the future, a second stage of this policy may use a combination of
 the DCO model and an FLA model [#FLA]_ as it is used by different open
@@ -366,6 +370,11 @@ References
 .. [#FLA] FSFE Legal: Fiduciary Licence Agreement (FLA),
    https://fsfe.org/activities/ftf/fla.en.html
 
+.. [#SUBMITTING-PATCHES] Submitting patches: the essential guide to
+   getting your code into the kernel,
+   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v4.18#n460
+   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=af45f32d25cc1e374184675eadc9f740221d8392
+
 .. [#CC-SOFTWARE] Can I apply a Creative Commons license to software?
    https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software
 


---
GLEP: 76
Title: Copyright Policy
Author: Richard Freeman <rich0@gentoo.org>,
        Alice Ferrazzi <alicef@gentoo.org>,
        Ulrich Müller <ulm@gentoo.org>,
        Robin H. Johnson <robbat2@gentoo.org>,
        Michał Górny <mgorny@gentoo.org>
Type: Informational
Status: Accepted
Version: 1
Created: 2013-04-23
Last-Modified: 2018-09-26
Post-History: 2018-06-10, 2018-06-19, 2018-08-31
Content-Type: text/x-rst
---


Status
======

Accepted by the Gentoo Council on 2018-09-09 and approved by the
Gentoo Board of Trustees on 2018-09-15.  Implementation in tools
(e.g., repoman) is pending.


Abstract
========

This GLEP introduces a copyright and licensing policy for Gentoo
projects.  It requires all contributions of software or documentation
to be released under a free license, and to be accompanied by a
certificate of origin.


Motivation
==========

The copyright ownership of Gentoo materials is ambiguous due to
historical factors, and this GLEP attempts to improve the process
going forward.

In the beginning (2000 or earlier), the copyright header stated that
*Gentoo Technologies, Inc.* was the copyright holder, without any
formal paperwork.  The formal assignment document was however only
introduced in early 2004.  The assignment had many objectors (mostly
on the ``gentoo-core`` mailing list).  The developer recruiting
procedures attempted to require signing of the document as a condition
for becoming a developer, but it was not applied to pre-existing
developers, or those that objected.

Later, the *Gentoo Foundation* was established, and copyrights were
formally transferred (including nullifying original developer
assignments to *Gentoo Technologies, Inc.*), and the copyright header
was updated.  The formal assignment document text was updated in 2006,
but the formal assignment process had already been abandoned in
mid-2004.

Throughout this, the presence of copyright headers existed as a
policy, and continues to exist to this day.  Some files also still
contain or have in the past contained additional copyright headers,
attributing ownership to other parties.

The policy to have copyright notices ascribing copyright ownership to
the Gentoo Foundation caused an issue when Gentoo developers forked
another project and hosted the fork on Gentoo infrastructure.  To
comply with the previous policy the copyright notices were modified,
which caused concerns with the project the files were forked from.
Our previous policy completely neglected the possibility that Gentoo
might want to host files that were not created internally.

Finally, since the early days of Gentoo new ideas around copyright
licensing have become more popular, such as the FSFE's Fiduciary
License Agreement [#FLA]_, which takes a copyleft approach to
copyright licensing, while also better complying with copyright laws
in nations that have author's rights.

The goal here was to create a policy that was flexible enough to cover
forks and situations where Gentoo would not own the majority of the
copyright in a file.


Specification
=============

Purpose / Scope
---------------

This policy documents how Gentoo contributors comply and document
copyright for any contributions made to Gentoo.  Anyone committing
documentation or sources to any repository hosted on Gentoo
infrastructure or to any official Gentoo project (independently
of hosting) must comply with this policy.  Unofficial Gentoo projects
are also recommended to use this policy.

Questions regarding this policy should be directed to the Trustees
or the ``gentoo-project`` mailing list.  Any concerns over possible
copyright violations should be directed to the Trustees if they cannot
be worked out with the appropriate maintainer.


Licensing of Gentoo Projects
----------------------------

Every Gentoo project must abide by the Gentoo Social Contract
[#SOCIAL-CONTRACT]_ and release its work under one or more of the
following:

a) The GNU General Public License, version 2 or later (GPL-2+)
   [#GPL-2]_.

b) The Creative Commons Attribution-ShareAlike 4.0 License
   (CC-BY-SA-4.0, only for documentation) [#CC-BY-SA-4.0]_.
   Existing projects may also stay with CC-BY-SA-3.0 [#CC-BY-SA-3.0]_.

c) A license approved as GPL compatible by the Free Software
   Foundation [#GPL-COMPAT]_.

Exceptions for other free software licenses will be granted by the
Gentoo Foundation on a case by case basis.

For easy reference, the license for each project should be documented
on the wiki page at [#PROJECTS]_.


Certificate of Origin
---------------------

All commits to Gentoo project repositories shall be accompanied by a
certificate of origin.  The purpose of the certificate is to declare
that the contribution can be modified and redistributed in accordance
with the project's license.

For commits made using a VCS, the committer shall certify agreement to
the Certificate of Origin by adding ``Signed-off-by: Name <e-mail>``
to the commit message as a separate line.  The sign-off must contain
the committer's legal name as a natural person, i.e., the name that
would appear in a government issued document.

The following is the current Gentoo Certificate of Origin, revision 1:

    By making a contribution to this project, I certify that:

    1. The contribution was created in whole or in part by me, and I
       have the right to submit it under the free software license
       indicated in the file; or

    2. The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate free software
       license, and I have the right under that license to submit that
       work with modifications, whether created in whole or in part by
       me, under the same free software license (unless I am permitted
       to submit under a different license), as indicated in the file;
       or

    3. The contribution is a license text (or a file of similar nature),
       and verbatim distribution is allowed; or

    4. The contribution was provided directly to me by some other
       person who certified 1., 2., 3., or 4., and I have not modified
       it.

    I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the free software license(s) involved.

The Gentoo Certificate of Origin is licensed under a Creative Commons
Attribution-ShareAlike 3.0 Unported License [#CC-BY-SA-3.0]_.
It is based on the Linux Kernel DCO [#OSDL-DCO]_, released by Open
Source Development Labs, Inc. in 2005 under a CC-BY-SA-2.5 License.

Alternatively, and if it is applicable, committers can certify their
commits with the Linux Kernel DCO 1.1 [#DCO-1.1]_.  This shall be
indicated by adding ``(DCO-1.1)`` at the end of the ``Signed-off-by``
line.  Using the Gentoo Certificate of Origin is strongly preferred.


Copyright Attribution
---------------------

All copyrightable files included in Gentoo projects must contain
appropriate copyright and license notices, as defined by this policy.
For files in textual format, these notices normally appear near the
top of the file.  When technical limitations do not allow for text
notices in the file itself (e.g., for binary image file formats),
copyright and license can be stated in an accompanying text file in
the same directory.

A proper copyright notice reads::

    Copyright YEARS MAIN-CONTRIBUTOR [OTHER-CONTRIBUTOR]... [and others]

It must list the main copyright holder, who is usually the original
author, or the contributor holding copyright to the largest portion
of the file.  Additional copyright holders can be listed, but this is
normally not required.  The "and others" text may be omitted if the
explicitly listed contributors hold copyright to the entire file.
In some jurisdictions, the copyright holder can also be a company or
other legal entity, and therefore be different from the original
author.

Anyone finding a file out of compliance should file a bug against the
associated project/package providing as much information as possible.
Files that are not brought into compliance within 60 days or upon a
request for removal by a aggrieved copyright holder will be removed.
Any concerns not addressed by a maintainer can be appealed to the
Trustees.


Simplified Attribution
----------------------

Alternatively, projects are welcome to use a simplified form of the
copyright notice, which reads::

    Copyright YEARS Gentoo Authors

Projects using this scheme must track authorship in a VCS, unless they
list all authors of copyrightable contributions in an ``AUTHORS`` file.


Rationale
=========

Policy
------

This document aims to provide a single consistent copyright policy for
all Gentoo projects.  It is explicitly enforced for all official Gentoo
projects in order to protect the interests of Gentoo as a whole,
including its contributors, developers and users.  Additionally, it is
enforced for all other projects hosted on Gentoo infrastructure in order
to protect the Gentoo infrastructure owners and improve consistency.

The copyright model is built on the DCO model used by the Linux kernel
and requires all contributors to certify the legitimacy of their
contributions.  This also requires that they use their real name for
signing; an anonymous certification or one under a pseudonym would not
mean anything.  This policy is derived from the Linux project's policy
[#SUBMITTING-PATCHES]_.

In the future, a second stage of this policy may use a combination of
the DCO model and an FLA model [#FLA]_ as it is used by different open
source projects.  Contributors would be able to freely choose whether
they sign the FLA document or not.


Licensing of Projects
---------------------

The Social Contract mentions GPL-2 and CC-BY-SA-2.0, both with the
option to use them in a later version ("at our discretion").  In order
to facilitate interchange of software between different projects, we
aim for uniformity of their licensing.  Therefore, items a) and b)
explicitly recommend the use of GPL-2+ and CC-BY-SA-4.0.  The latter
is restricted to be used for documentation, because Creative Commons
themselves recommend against using their licenses for software
[#CC-SOFTWARE]_.

Other GPL-compatible free software licenses that are not explicitly
listed are allowed by item c).  This covers cases where compatibility
to licenses used by upstream projects is necessary.  (For example,
the Gentoo BSD project may want to use the 2-clause or 3-clause BSD
license).

By default, GPL-incompatible licenses (e.g., the CDDL) are not
allowed, because their use would hinder interchange of code between
Gentoo projects.  However, the Foundation can grant exceptions to
this, as long as the license in question is a free software or open
source license.


Changes to the Certificate of Origin
------------------------------------

The Gentoo Certificate of Origin rev. 1 has been based on Linux Kernel
DCO 1.1 [#OSDL-DCO]_.  It features the following modifications from
the original:

i.   The enumeration has been modified to use numeric points.

ii.  Additional point 3. has been inserted:

         3. The contribution is a license text (or a file of similar
            nature), and verbatim distribution is allowed; or

iii. The original point (c) has shifted to become point 4., and has
     been updated to account for the additional point 3.

iv.  The original point (d) has been transformed into a stand-alone
     paragraph following the enumeration.

v.   The term "open source" has been replaced by "free software"
     throughout.

The new point was deemed necessary to allow committing license files
into the Gentoo repository, since those files usually do not permit
modification.  It has been established that adding a clear provision
for this case is better than excluding those commits from compliance
with the Certificate of Origin.  Debian was facing a similar problem
[#DEBIAN-LICENSE]_.

The update of point (c) was necessary to allow the new clause being
certified by the person providing the contribution.

The term "free software" is used for consistency with the language
of the Gentoo Social Contract [#SOCIAL-CONTRACT]_.

The remaining changes were merely editorial.  The original point (d)
is not part of the *or* statement joining the other points, so keeping
it in a paragraph separate from the enumeration is more appropriate.

Addition of another point for public domain material was also
considered.  However, it is preferred if all contributions carry
an explicit license notice that allows their certification under
point 1. or 2.  If necessary, license tools like Creative Commons
CC0 [#CC0-1.0]_ or Public Domain Mark [#CC-PDM-1.0]_ can be used.


Copyright Notice
----------------

Especially for ebuild repositories, constantly keeping track of the
main copyright holder of any file would be rather inconvenient and
tedious.  Therefore, projects are free to use either a traditional
copyright notice listing the individual author(s), or a simplified
notice with an attribution to the "Gentoo Authors".  The latter
resembles the scheme used by the Chromium project [#CHROMIUM]_.


Acknowledgements
================

Many people have participated in invaluable discussions on this GLEP.
In particular, the authors would like to thank David Abbott,
Roy Bamford, Kristian Fiskerstrand, Andreas K. Hüttel, Manuel Rüger,
Matija Šuklje, Matthew Thode, and Alec Warner for their input.


References
==========

.. [#SOCIAL-CONTRACT] Gentoo Social Contract,
   https://www.gentoo.org/get-started/philosophy/social-contract.html

.. [#GPL-2] GNU General Public License, version 2 or later,
   https://www.gnu.org/licenses/gpl-2.0.html

.. [#CC-BY-SA-4.0] Creative Commons Attribution-ShareAlike 4.0
   International License, https://creativecommons.org/licenses/by-sa/4.0/

.. [#CC-BY-SA-3.0] Creative Commons Attribution-ShareAlike 3.0
   Unported License, https://creativecommons.org/licenses/by-sa/3.0/

.. [#GPL-COMPAT] GPL-compatible free software licenses,
   https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses

.. [#PROJECTS] Licensing of Gentoo projects,
   https://wiki.gentoo.org/wiki/Project:Licenses/Licensing_of_Gentoo_projects

.. [#OSDL-DCO] Open Source Development Labs, Inc.,
   Developer's Certificate of Origin 1.1,
   https://web.archive.org/web/20060524185355/http://www.osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html

.. [#DCO-1.1] Developer's Certificate of Origin 1.1,
   https://developercertificate.org/

.. [#FLA] FSFE Legal: Fiduciary Licence Agreement (FLA),
   https://fsfe.org/activities/ftf/fla.en.html

.. [#SUBMITTING-PATCHES] Submitting patches: the essential guide to
   getting your code into the kernel,
   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v4.18#n460
   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=af45f32d25cc1e374184675eadc9f740221d8392

.. [#CC-SOFTWARE] Can I apply a Creative Commons license to software?
   https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software

.. [#DEBIAN-LICENSE] [debian-legal] License of the GPL license,
   https://lists.debian.org/debian-legal/2018/04/msg00006.html

.. [#CC0-1.0] Creative Commons: CC0 1.0 Universal,
   https://creativecommons.org/publicdomain/zero/1.0/

.. [#CC-PDM-1.0] Creative Commons: Public Domain Mark 1.0,
   https://creativecommons.org/publicdomain/mark/1.0/

.. [#CHROMIUM] Chromium: Contributing Code,
   https://www.chromium.org/developers/contributing-code#TOC-Legal-stuff


Copyright
=========

This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
Unported License.  To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[kuzetsa]

[-- Attachment #1.1: Type: text/plain, Size: 1533 bytes --]

On 09/26/2018 03:25 PM, Ulrich Mueller wrote:
> Here is another small update of the copyright GLEP, resulting from a
> recent discussion on IRC. This is not a change of policy, but merely
> a clarification of the real name requirement:
> 

Traced the language to a commit from 2006, seems to have zero
open discussion for its legal reasoning, or any specific cited
model for how or why a person writing their name is valid (I
can't find any evidence of a legal analysis performed at the
time, or since) - specifically, language in the LKML commit:

http://article.gmane.org/gmane.linux.kernel.commits.head/85223

["The DCO does not mean anything if we allow anonymous
contributors to the kernel.  As this is an open source
project, we need to do everything in the open."]

This meme (in the original sense of being like a gene, though
inherited and expressed and mutated by way of memory and idea.
the modern sense of the word "meme" doesn't resemble the original)

Could benefit from some open legal review. Ironic for multiple
organizations to express the same sentiment without considering
the legal intent of a signature: "I have reviewed this, and am
marking it as such" is far less valid when it is not witnessed
or authenticated. (as by a notary or officer of the court)

I'd like clarification of the origin of the requirement, but
this is as far as I'll go, publicly. I don't wish to be the
voice or face of this issue. I don't have the energy or legal
resources for it.

- signed by key


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 600 bytes --]

On 09/26/2018 03:25 PM, Ulrich Mueller wrote:
> Here is another small update of the copyright GLEP, resulting from a
> recent discussion on IRC. This is not a change of policy, but merely
> a clarification of the real name requirement:
> 
> - The Signed-off-by line must contain the name of a natural person.
> 
> - A copyright holder can be a legal entity (e.g., a company) in some
>   jurisdictions.
> 

IANAL, but as per the Berne Convention, anonymous and pseudonymous works
are granted copyright protection.  What's the rationale behind mandating
a real name?

-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Rich Freeman]

On Thu, Sep 27, 2018 at 8:00 AM NP-Hardass <NP-Hardass@gentoo.org> wrote:
>
> On 09/26/2018 03:25 PM, Ulrich Mueller wrote:
> > Here is another small update of the copyright GLEP, resulting from a
> > recent discussion on IRC. This is not a change of policy, but merely
> > a clarification of the real name requirement:
> >
> > - The Signed-off-by line must contain the name of a natural person.
> >
> > - A copyright holder can be a legal entity (e.g., a company) in some
> >   jurisdictions.
> >
>
> IANAL, but as per the Berne Convention, anonymous and pseudonymous works
> are granted copyright protection.  What's the rationale behind mandating
> a real name?

The DCO/GCO have nothing to do with obtaining copyright protection.
This is always present if not waived.

It is about showing due diligence in the event somebody claims that
somebody ripped off their work and contributed it to Gentoo without
authorization.

If your real name is attached to a statement saying that you didn't
steal the work, and you did steal the work, then they can go after you
as well as Gentoo.  That deters contributing stuff without checking on
its legality.  That same deterrence also helps show good faith on
Gentoo's part.  This is why organizations generally pursue these
policies.

If somebody violates a copyright anonymously, then they have no skin
in the game.  They can just disappear if anything bad happens.  If a
contributor isn't willing to stake their own money and reputation on
the statement that something is legal to contribute, then why should
Gentoo assume that they've put a lot of effort into the accuracy of
that statement?

-- 
Rich

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

[kuzetsa]

[-- Attachment #1.1: Type: text/plain, Size: 2295 bytes --]

On 09/27/2018 08:42 AM, Rich Freeman wrote:
> On Thu, Sep 27, 2018 at 8:00 AM NP-Hardass <NP-Hardass@gentoo.org> wrote:
>>
>> On 09/26/2018 03:25 PM, Ulrich Mueller wrote:
>>> Here is another small update of the copyright GLEP, resulting from a
>>> recent discussion on IRC. This is not a change of policy, but merely
>>> a clarification of the real name requirement:
>>>
>>> - The Signed-off-by line must contain the name of a natural person.
>>>
>>> - A copyright holder can be a legal entity (e.g., a company) in some
>>>   jurisdictions.
>>>
>>
>> IANAL, but as per the Berne Convention, anonymous and pseudonymous works
>> are granted copyright protection.  What's the rationale behind mandating
>> a real name?
> 
> The DCO/GCO have nothing to do with obtaining copyright protection.
> This is always present if not waived.
> 
> It is about showing due diligence in the event somebody claims that
> somebody ripped off their work and contributed it to Gentoo without
> authorization.
> 
> If your real name is attached to a statement saying that you didn't
> steal the work, and you did steal the work, then they can go after you
> as well as Gentoo.  That deters contributing stuff without checking on
> its legality.  That same deterrence also helps show good faith on
> Gentoo's part.  This is why organizations generally pursue these
> policies.
> 
> If somebody violates a copyright anonymously, then they have no skin
> in the game.  They can just disappear if anything bad happens.  If a
> contributor isn't willing to stake their own money and reputation on
> the statement that something is legal to contribute, then why should
> Gentoo assume that they've put a lot of effort into the accuracy of
> that statement?
> 

in this case, the GCO (or the DCO from which it borrowed it's ideas)
should explicitly state its purposes, rather than relying on the
assumption that a person can be tracked down if the license was is ever
in doubt.

people can and do physically relocate from time to time, and if they're
no longer a contributor there's no way to track them down, should the
need arise for any legal or ethical questions (the kind of purpose which
the policy makes no mention of: a way to reach the contributor)

- via key


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Rich Freeman]

On Thu, Sep 27, 2018 at 9:08 AM kuzetsa <kuzetsa@gmail.com> wrote:
>
> in this case, the GCO (or the DCO from which it borrowed it's ideas)
> should explicitly state its purposes, rather than relying on the
> assumption that a person can be tracked down if the license was is ever
> in doubt.

While I'm all for having background, I don't see how it actually
changes the situation.

Also, there is no need to track people down, ever.  The purpose of the
GCO/DCO is to make the contributor liable for their contributions, and
this is already accomplished.  If the true copyright holder wants to
try to track them down that is their problem.

If somebody provides us evidence that they are the true copyright
holder and ask us to remove their code, we simply have to remove their
code.  No stack of licenses/certificates/attestations/etc will ever
change that.

It is like buying a house.  If you buy a house from somebody, and it
later turns out that they never owned the house, then the owner is
going to be able to take his house back from you free of charge.  It
doesn't matter how many documents the "seller" signed in the process -
it was never their house to sell.  However, those documents CAN place
some liability on them for such things, or provide you with due
diligence / reasonable care so that it shows that you acted in good
faith and the owner won't go after you beyond just getting back their
house.  You're still out the house either way.

I believe this is the basic principle behind these kinds of documents.
It is basically an affirmation of compliance, which is a form of
showing reasonable care on the part of the recipient.

>
> people can and do physically relocate from time to time, and if they're
> no longer a contributor there's no way to track them down, should the
> need arise for any legal or ethical questions (the kind of purpose which
> the policy makes no mention of: a way to reach the contributor)
>

See above.  Tracking down the contributor is unlikely to really get us
far, and it really makes no sense.  The purpose of the DCO is to
collect the affirmation of compliance up-front so that we don't have
to try to get it later.  It doesn't change who owns copyright.  If it
turns out somebody lied to us then bad things will always happen, but
they just won't be as bad as they could have been.

-- 
Rich

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

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 2996 bytes --]

On 09/27/2018 08:42 AM, Rich Freeman wrote:
> On Thu, Sep 27, 2018 at 8:00 AM NP-Hardass <NP-Hardass@gentoo.org> wrote:
>>
>> On 09/26/2018 03:25 PM, Ulrich Mueller wrote:
>>> Here is another small update of the copyright GLEP, resulting from a
>>> recent discussion on IRC. This is not a change of policy, but merely
>>> a clarification of the real name requirement:
>>>
>>> - The Signed-off-by line must contain the name of a natural person.
>>>
>>> - A copyright holder can be a legal entity (e.g., a company) in some
>>>   jurisdictions.
>>>
>>
>> IANAL, but as per the Berne Convention, anonymous and pseudonymous works
>> are granted copyright protection.  What's the rationale behind mandating
>> a real name?
> 
> The DCO/GCO have nothing to do with obtaining copyright protection.
> This is always present if not waived.
> 
> It is about showing due diligence in the event somebody claims that
> somebody ripped off their work and contributed it to Gentoo without
> authorization.
> 
> If your real name is attached to a statement saying that you didn't
> steal the work, and you did steal the work, then they can go after you
> as well as Gentoo.  That deters contributing stuff without checking on
> its legality.  That same deterrence also helps show good faith on
> Gentoo's part.  This is why organizations generally pursue these
> policies.
> 
> If somebody violates a copyright anonymously, then they have no skin
> in the game.  They can just disappear if anything bad happens.  If a
> contributor isn't willing to stake their own money and reputation on
> the statement that something is legal to contribute, then why should
> Gentoo assume that they've put a lot of effort into the accuracy of
> that statement?
> 

And, AFAICT, this only applies to the Signed-off-by line (the
committer).  The author may be anonymous or pseudonymous... So, your
statement is that people making commits to Gentoo must have real
names... and be public.  This doesn't have any impact on whether the
source of the code is legit, just gives you a point of blame for who
actually committed it (which, TBH, doesn't mean much).  I can say John
Doe committed code that wasn't legal.  But i_steal_code_1337 authored
it... I guess we know not to accept code from him... or do we... since
we have no way of vetting authors.  Making the restriction of names for
committers and not authors, IMO, has no weight.  Requiring that all
contributions be from real named sources is a pretty drastic change, and
not what is being proposed, TTBOMK.

But that's really besides the point... The current status quo (as is the
case with me) is that a committer may be pseudonymous under the
condition that the Foundation have that individual's name in the event
of a copyright issue. So, I still don't understand how forcing everyone
to publicly use a real name achieves something that we aren't currently
achieving...  Is that incorrect?

-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Rich Freeman]

On Thu, Sep 27, 2018 at 9:52 AM NP-Hardass <NP-Hardass@gentoo.org> wrote:
>
> But that's really besides the point... The current status quo (as is the
> case with me) is that a committer may be pseudonymous under the
> condition that the Foundation have that individual's name in the event
> of a copyright issue. So, I still don't understand how forcing everyone
> to publicly use a real name achieves something that we aren't currently
> achieving...  Is that incorrect?

Interesting point.

If we were going to go down this road I'd still suggest that the
Foundation have a policy on when the real names of contributors can be
disclosed, either privately or publicly.  If we were to use the
defense that we have a statement from a contributor that they checked
the copyright and it was ok, the first question somebody will respond
with is, "who?"  An answer of "we know who it is but can't tell
anybody, even a court" probably isn't going to work.

I think there are other arguments to be made against anonymity.
You're hardly a list troll, but anonymity can breed this sort of
thing.  From a strictly copyright standpoint I don't see why the
identity of contributors needs to be publicly disclosed, as long as it
can be disclosed where legally necessary.  Of course, if that is a
court then depending on the jurisdiction it may become public anyway.
Also, if we were going to go down this route then we also need to have
better archives of such things, as trying to dig up some trustee email
from 10 years ago is not the right solution.  A secured repository of
identities/etc would be better (the Foundation already has a place to
store stuff like bank account details).

Another practical argument against anonymity.  If everybody agrees
everything is public, then we don't have any personal information we
need to protect under various privacy laws.  As soon as we agree to
keep some info private, then we potentially have obligations under
such laws.  Also, legally the Foundation is a US organization - so I'm
not sure if things like the US-EU Safe Harbor provisions start to
apply if we want to collect this sort of info from EU citizens.  It is
just a can of worms you can avoid simply by not hanging onto this kind
of information.  I believe that many of these privacy protections
cannot be simply waived - we can't get some EU citizen to agree that
they don't apply to us.  If the laws apply then we need to follow
them.  Now, we're obviously not a big fish, so enforcement may never
happen.  Maybe compliance isn't burdensome - I only know enough about
such things to know that I'd want to know more before going down that
road...

-- 
Rich

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

[kuzetsa]

On 09/27/2018 09:43 AM, Rich Freeman wrote:
> On Thu, Sep 27, 2018 at 9:08 AM kuzetsa <kuzetsa@gmail.com> wrote:
>>
>> in this case, the GCO (or the DCO from which it borrowed it's ideas)
>> should explicitly state its purposes, rather than relying on the
>> assumption that a person can be tracked down if the license was is ever
>> in doubt.
> 
> While I'm all for having background, I don't see how it actually
> changes the situation.
> 
> Also, there is no need to track people down, ever.  The purpose of the
> GCO/DCO is to make the contributor liable for their contributions, and
> this is already accomplished.  If the true copyright holder wants to
> try to track them down that is their problem.

This suggests the "real name" requirement from GCO / DCO could be
enforced, but isn't. Even if name alone was all that is truly required,
without a way to tie a specific name to a specific person who has the
same name, the legal meaning is moot due to "real names" not being a
unique identifier.

> If somebody provides us evidence that they are the true copyright
> holder and ask us to remove their code, we simply have to remove their
> code.  No stack of licenses/certificates/attestations/etc will ever
> change that.
> 
> It is like buying a house.  If you buy a house from somebody, and it
> later turns out that they never owned the house, then the owner is
> going to be able to take his house back from you free of charge.  It
> doesn't matter how many documents the "seller" signed in the process -
> it was never their house to sell.  However, those documents CAN place
> some liability on them for such things, or provide you with due
> diligence / reasonable care so that it shows that you acted in good
> faith and the owner won't go after you beyond just getting back their
> house.  You're still out the house either way.

Nobody is proving their name or where they're located. In this metaphor,
I believe gentoo is the one buying a house without verifying the
identity of the seller. (see above)

> I believe this is the basic principle behind these kinds of documents.
> It is basically an affirmation of compliance, which is a form of
> showing reasonable care on the part of the recipient.
> 
>>
>> people can and do physically relocate from time to time, and if they're
>> no longer a contributor there's no way to track them down, should the
>> need arise for any legal or ethical questions (the kind of purpose which
>> the policy makes no mention of: a way to reach the contributor)
>>
> 
> See above.  Tracking down the contributor is unlikely to really get us
> far, and it really makes no sense.  The purpose of the DCO is to
> collect the affirmation of compliance up-front so that we don't have
> to try to get it later.  It doesn't change who owns copyright.  If it
> turns out somebody lied to us then bad things will always happen, but
> they just won't be as bad as they could have been.
> 

It's true that affirmation of compliance would be helpful, but if gentoo
doesn't ask for that diligently, relying on the presumed validity of a
name (and no other significant metadata) is little use to anyone's legal
injury which could've been prevented be a more rigorous policy.

-

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

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 3420 bytes --]

On 09/27/2018 10:13 AM, Rich Freeman wrote:
> On Thu, Sep 27, 2018 at 9:52 AM NP-Hardass <NP-Hardass@gentoo.org> wrote:
>>
>> But that's really besides the point... The current status quo (as is the
>> case with me) is that a committer may be pseudonymous under the
>> condition that the Foundation have that individual's name in the event
>> of a copyright issue. So, I still don't understand how forcing everyone
>> to publicly use a real name achieves something that we aren't currently
>> achieving...  Is that incorrect?
> 
> Interesting point.
> 
> If we were going to go down this road I'd still suggest that the
> Foundation have a policy on when the real names of contributors can be
> disclosed, either privately or publicly.  If we were to use the
> defense that we have a statement from a contributor that they checked
> the copyright and it was ok, the first question somebody will respond
> with is, "who?"  An answer of "we know who it is but can't tell
> anybody, even a court" probably isn't going to work.
> 
> I think there are other arguments to be made against anonymity.
> You're hardly a list troll, but anonymity can breed this sort of
> thing.  From a strictly copyright standpoint I don't see why the
> identity of contributors needs to be publicly disclosed, as long as it
> can be disclosed where legally necessary.  Of course, if that is a
> court then depending on the jurisdiction it may become public anyway.
> Also, if we were going to go down this route then we also need to have
> better archives of such things, as trying to dig up some trustee email
> from 10 years ago is not the right solution.  A secured repository of
> identities/etc would be better (the Foundation already has a place to
> store stuff like bank account details).
> 
> Another practical argument against anonymity.  If everybody agrees
> everything is public, then we don't have any personal information we
> need to protect under various privacy laws.  As soon as we agree to
> keep some info private, then we potentially have obligations under
> such laws.  Also, legally the Foundation is a US organization - so I'm
> not sure if things like the US-EU Safe Harbor provisions start to
> apply if we want to collect this sort of info from EU citizens.  It is
> just a can of worms you can avoid simply by not hanging onto this kind
> of information.  I believe that many of these privacy protections
> cannot be simply waived - we can't get some EU citizen to agree that
> they don't apply to us.  If the laws apply then we need to follow
> them.  Now, we're obviously not a big fish, so enforcement may never
> happen.  Maybe compliance isn't burdensome - I only know enough about
> such things to know that I'd want to know more before going down that
> road...
> 

But enforcing committers only to be named doesn't really avoid the
issues you are espousing wrt copyright issues... All it does is give you
someone to blame (who isn't the perpetrator of the copyright violation).
 Any random person can submit code under the new proposed copyright
policy, and as long as they aren't making a commit, there is no force
for using a real name.

So, unless we are outlawing all anonymous and pseudonymous contributions
of any sort (authorship, not just a commit), there is really no point in
forcing committers to be publicly named.

-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[kuzetsa]

On 09/27/2018 10:13 AM, Rich Freeman wrote:
> On Thu, Sep 27, 2018 at 9:52 AM NP-Hardass <NP-Hardass@gentoo.org> wrote:
>>
>> But that's really besides the point... The current status quo (as is the
>> case with me) is that a committer may be pseudonymous under the
>> condition that the Foundation have that individual's name in the event
>> of a copyright issue. So, I still don't understand how forcing everyone
>> to publicly use a real name achieves something that we aren't currently
>> achieving...  Is that incorrect?
> 
> Interesting point.
> 
> If we were going to go down this road I'd still suggest that the
> Foundation have a policy on when the real names of contributors can be
> disclosed, either privately or publicly.  If we were to use the
> defense that we have a statement from a contributor that they checked
> the copyright and it was ok, the first question somebody will respond
> with is, "who?"  An answer of "we know who it is but can't tell
> anybody, even a court" probably isn't going to work.
> 
> I think there are other arguments to be made against anonymity.
> You're hardly a list troll, but anonymity can breed this sort of
> thing.  From a strictly copyright standpoint I don't see why the
> identity of contributors needs to be publicly disclosed, as long as it
> can be disclosed where legally necessary.  Of course, if that is a
> court then depending on the jurisdiction it may become public anyway.
> Also, if we were going to go down this route then we also need to have
> better archives of such things, as trying to dig up some trustee email
> from 10 years ago is not the right solution.  A secured repository of
> identities/etc would be better (the Foundation already has a place to
> store stuff like bank account details).
> 
> Another practical argument against anonymity.  If everybody agrees
> everything is public, then we don't have any personal information we
> need to protect under various privacy laws.  As soon as we agree to
> keep some info private, then we potentially have obligations under
> such laws.  Also, legally the Foundation is a US organization - so I'm
> not sure if things like the US-EU Safe Harbor provisions start to
> apply if we want to collect this sort of info from EU citizens.  It is
> just a can of worms you can avoid simply by not hanging onto this kind
> of information.  I believe that many of these privacy protections
> cannot be simply waived - we can't get some EU citizen to agree that
> they don't apply to us.  If the laws apply then we need to follow
> them.  Now, we're obviously not a big fish, so enforcement may never
> happen.  Maybe compliance isn't burdensome - I only know enough about
> such things to know that I'd want to know more before going down that
> road...
> 

which is worse? the hassle of tracking some personal metadata in a way
which is legally compliant, or admitting that gentoo didn't bother
collecting it and then allowed itself to facilitate legal injuries on
other parties - gentoo could be liable for that too.

if someone opts-in to submitting legal documentation as an acceptable
condition for affirming a name, that could make things easier for some
LGBTQ people, or persons who don't feel like using a female-coded name,
or any other personal attachment to a certain name. not sure how heavily
to weigh my own bias VS the value of inclusiveness & the optics for
gentoo's image, the spirit of the social contract (things like having a
choice), and all those other factors which never came up in 2006 when
the DCO first got its "real name" policy.

-

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3820 bytes --]

On Thu, 2018-09-27 at 09:52 -0400, NP-Hardass wrote:
> On 09/27/2018 08:42 AM, Rich Freeman wrote:
> > On Thu, Sep 27, 2018 at 8:00 AM NP-Hardass <NP-Hardass@gentoo.org> wrote:
> > > 
> > > On 09/26/2018 03:25 PM, Ulrich Mueller wrote:
> > > > Here is another small update of the copyright GLEP, resulting from a
> > > > recent discussion on IRC. This is not a change of policy, but merely
> > > > a clarification of the real name requirement:
> > > > 
> > > > - The Signed-off-by line must contain the name of a natural person.
> > > > 
> > > > - A copyright holder can be a legal entity (e.g., a company) in some
> > > >   jurisdictions.
> > > > 
> > > 
> > > IANAL, but as per the Berne Convention, anonymous and pseudonymous works
> > > are granted copyright protection.  What's the rationale behind mandating
> > > a real name?
> > 
> > The DCO/GCO have nothing to do with obtaining copyright protection.
> > This is always present if not waived.
> > 
> > It is about showing due diligence in the event somebody claims that
> > somebody ripped off their work and contributed it to Gentoo without
> > authorization.
> > 
> > If your real name is attached to a statement saying that you didn't
> > steal the work, and you did steal the work, then they can go after you
> > as well as Gentoo.  That deters contributing stuff without checking on
> > its legality.  That same deterrence also helps show good faith on
> > Gentoo's part.  This is why organizations generally pursue these
> > policies.
> > 
> > If somebody violates a copyright anonymously, then they have no skin
> > in the game.  They can just disappear if anything bad happens.  If a
> > contributor isn't willing to stake their own money and reputation on
> > the statement that something is legal to contribute, then why should
> > Gentoo assume that they've put a lot of effort into the accuracy of
> > that statement?
> > 
> 
> And, AFAICT, this only applies to the Signed-off-by line (the
> committer).  The author may be anonymous or pseudonymous... So, your
> statement is that people making commits to Gentoo must have real
> names... and be public.  This doesn't have any impact on whether the
> source of the code is legit, just gives you a point of blame for who
> actually committed it (which, TBH, doesn't mean much).  I can say John
> Doe committed code that wasn't legal.  But i_steal_code_1337 authored
> it... I guess we know not to accept code from him... or do we... since
> we have no way of vetting authors.  Making the restriction of names for
> committers and not authors, IMO, has no weight.  Requiring that all
> contributions be from real named sources is a pretty drastic change, and
> not what is being proposed, TTBOMK.
> 
> But that's really besides the point... The current status quo (as is the
> case with me) is that a committer may be pseudonymous under the
> condition that the Foundation have that individual's name in the event
> of a copyright issue. So, I still don't understand how forcing everyone
> to publicly use a real name achieves something that we aren't currently
> achieving...  Is that incorrect?
> 

Gentoo publishes a number of open source projects.  The code of those
projects is used beyond Gentoo and beyond Gentoo Foundation.  Therefore,
it is natural that we need all the copyright assessments and agreements
to be *public* and not hidden behind some opaque Foundation which may or
may not actually have the data (how can a regular Gentoo user be sure of
that?), and which may or may not choose to actually disclose it.

As for the case with you, I think the 'status quo' is more complex but
that's beside the point, and I don't think it would be helpful to anyone
expanding on that.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[kuzetsa]

On 09/27/2018 10:32 AM, Michał Górny wrote:
> On Thu, 2018-09-27 at 09:52 -0400, NP-Hardass wrote:
>> On 09/27/2018 08:42 AM, Rich Freeman wrote:
>>> On Thu, Sep 27, 2018 at 8:00 AM NP-Hardass <NP-Hardass@gentoo.org> wrote:
>>>>
>>>> On 09/26/2018 03:25 PM, Ulrich Mueller wrote:
>>>>> Here is another small update of the copyright GLEP, resulting from a
>>>>> recent discussion on IRC. This is not a change of policy, but merely
>>>>> a clarification of the real name requirement:
>>>>>
>>>>> - The Signed-off-by line must contain the name of a natural person.
>>>>>
>>>>> - A copyright holder can be a legal entity (e.g., a company) in some
>>>>>   jurisdictions.
>>>>>
>>>>
>>>> IANAL, but as per the Berne Convention, anonymous and pseudonymous works
>>>> are granted copyright protection.  What's the rationale behind mandating
>>>> a real name?
>>>
>>> The DCO/GCO have nothing to do with obtaining copyright protection.
>>> This is always present if not waived.
>>>
>>> It is about showing due diligence in the event somebody claims that
>>> somebody ripped off their work and contributed it to Gentoo without
>>> authorization.
>>>
>>> If your real name is attached to a statement saying that you didn't
>>> steal the work, and you did steal the work, then they can go after you
>>> as well as Gentoo.  That deters contributing stuff without checking on
>>> its legality.  That same deterrence also helps show good faith on
>>> Gentoo's part.  This is why organizations generally pursue these
>>> policies.
>>>
>>> If somebody violates a copyright anonymously, then they have no skin
>>> in the game.  They can just disappear if anything bad happens.  If a
>>> contributor isn't willing to stake their own money and reputation on
>>> the statement that something is legal to contribute, then why should
>>> Gentoo assume that they've put a lot of effort into the accuracy of
>>> that statement?
>>>
>>
>> And, AFAICT, this only applies to the Signed-off-by line (the
>> committer).  The author may be anonymous or pseudonymous... So, your
>> statement is that people making commits to Gentoo must have real
>> names... and be public.  This doesn't have any impact on whether the
>> source of the code is legit, just gives you a point of blame for who
>> actually committed it (which, TBH, doesn't mean much).  I can say John
>> Doe committed code that wasn't legal.  But i_steal_code_1337 authored
>> it... I guess we know not to accept code from him... or do we... since
>> we have no way of vetting authors.  Making the restriction of names for
>> committers and not authors, IMO, has no weight.  Requiring that all
>> contributions be from real named sources is a pretty drastic change, and
>> not what is being proposed, TTBOMK.
>>
>> But that's really besides the point... The current status quo (as is the
>> case with me) is that a committer may be pseudonymous under the
>> condition that the Foundation have that individual's name in the event
>> of a copyright issue. So, I still don't understand how forcing everyone
>> to publicly use a real name achieves something that we aren't currently
>> achieving...  Is that incorrect?
>>
> 
> Gentoo publishes a number of open source projects.  The code of those
> projects is used beyond Gentoo and beyond Gentoo Foundation.  Therefore,
> it is natural that we need all the copyright assessments and agreements
> to be *public* and not hidden behind some opaque Foundation which may or
> may not actually have the data (how can a regular Gentoo user be sure of
> that?), and which may or may not choose to actually disclose it.
> 
> As for the case with you, I think the 'status quo' is more complex but
> that's beside the point, and I don't think it would be helpful to anyone
> expanding on that.
> 

for what it's worth, when I originally realized I didn't need to author
commits using my legal name I came to that decision after a discussion
with NP-Hardass. Just sayin'

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

[kuzetsa]

[-- Attachment #1.1: Type: text/plain, Size: 4831 bytes --]

On 09/26/2018 03:25 PM, Ulrich Mueller wrote:

> Here is another small update of the copyright GLEP, resulting from a
> recent discussion on IRC. This is not a change of policy, but merely
> a clarification of the real name requirement:
> 
> - The Signed-off-by line must contain the name of a natural person.
> 
> - A copyright holder can be a legal entity (e.g., a company) in some
>   jurisdictions.
> 
> Below is a diff to the previous (approved) version, followed by the
> GLEP's full text.
> 
> Ulrich
> 


[...]

> A proper copyright notice reads::
> 
>     Copyright YEARS MAIN-CONTRIBUTOR [OTHER-CONTRIBUTOR]... [and others]
> 
> It must list the main copyright holder, who is usually the original
> author, or the contributor holding copyright to the largest portion
> of the file.  Additional copyright holders can be listed, but this is
> normally not required.  The "and others" text may be omitted if the
> explicitly listed contributors hold copyright to the entire file.
> In some jurisdictions, the copyright holder can also be a company or
> other legal entity, and therefore be different from the original
> author.
> 

[...]

> Copyright Notice
> ----------------
> 
> Especially for ebuild repositories, constantly keeping track of the
> main copyright holder of any file would be rather inconvenient and
> tedious.  Therefore, projects are free to use either a traditional
> copyright notice listing the individual author(s), or a simplified
> notice with an attribution to the "Gentoo Authors".  The latter
> resembles the scheme used by the Chromium project [#CHROMIUM]_.
> 

Further copyright clarification:

per the RFC for GLEP 76: Copyright Policy [v4]

["A copyright holder can be a legal entity (e.g., a
company) in some jurisdictions."]

^ this likely extends outside the jurisdiction of
a copyright holder as well, but could also apply
in the case of pseudonymous copyright holders (in
some cases, as that can vary by jurisdiction)

pseudonymous authors and/or legal entities such as companies
will need to know their own legal status / laws of their
jurisdiction prior to writing a copyright attribution line.

-----

WIPO Copyright Treaty: Article 4. Computer Programs

["Computer programs are protected as literary works within
the meaning of Article 2 of the Berne Convention. Such
protection applies to computer programs, whatever may be
the mode or form of their expression."]

-----

Berne Convention for the Protection of Literary
and Artistic Works. Articles 2 (6), and 15 (1)

Article 2, (6) Protected Works:

["The works mentioned in this Article shall enjoy
protection in all countries of the Union. This protection
shall operate for the benefit of the author and his
successors in title."]

Article 15, (1) Where author's name is indicated or where
pseudonym leaves no doubt as to author's identity:

["In order that the author of a literary or artistic work
protected by this Convention shall, in the absence of
proof to the contrary, be regarded as such, and
consequently be entitled to institute infringement
proceedings in the countries of the Union, it shall
be sufficient for his name to appear on the work in the
usual manner. This paragraph shall be applicable even if
this name is a pseudonym, where the pseudonym adopted by
the author leaves no doubt as to his identity."]

-----

This should apply when a contributor (who wishes to have
a pseudonymous attribution for their copyright) does so
under their registered trade name, so long as this natural
person has complied with the laws in their jurisdiction,
and may legally conduct business under the assumed name...

The patch for GLEP 76 [v4] update adds the langauge:

["In some jurisdictions, the copyright holder can also be
a company or other legal entity, and therefore be
different from the original author."]

This should also mean the copyright would be valid under
the berne convention when authors or copyright holders are
already recognized by the copyright laws of their country
legal residence (both for legal entities as well as
pseudonymous authors who DO NOT choose to be anonymous)

-----

Summary / emphasis: the copyright protection for a
legal entity or pseudonymous author (copyright holder)
may also have validity outside the copyright holder or
author's jurisdiction under the berne convention.

(personal note)
I have legal capacity to conduct business under the name
kuzetsa, and this is not an anonymous name - there should
be no legal issue to use in copyright attribution lines.

this was questioned in a recent PR, though the name for
the Signed-off-by line is less certain so for that I'll
be using my legal name as a natural person to be safe.

- via key


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[desultory]

On 09/27/18 10:13, Rich Freeman wrote:
> On Thu, Sep 27, 2018 at 9:52 AM NP-Hardass <NP-Hardass@gentoo.org> wrote:
>>
>> But that's really besides the point... The current status quo (as is the
>> case with me) is that a committer may be pseudonymous under the
>> condition that the Foundation have that individual's name in the event
>> of a copyright issue. So, I still don't understand how forcing everyone
>> to publicly use a real name achieves something that we aren't currently
>> achieving...  Is that incorrect?
> 
> Interesting point.
> 
> If we were going to go down this road I'd still suggest that the
> Foundation have a policy on when the real names of contributors can be
> disclosed, either privately or publicly.  If we were to use the
> defense that we have a statement from a contributor that they checked
> the copyright and it was ok, the first question somebody will respond
> with is, "who?"  An answer of "we know who it is but can't tell
> anybody, even a court" probably isn't going to work.
> 
> I think there are other arguments to be made against anonymity.
> You're hardly a list troll, but anonymity can breed this sort of
> thing.  From a strictly copyright standpoint I don't see why the
> identity of contributors needs to be publicly disclosed, as long as it
> can be disclosed where legally necessary.  Of course, if that is a
> court then depending on the jurisdiction it may become public anyway.
> Also, if we were going to go down this route then we also need to have
> better archives of such things, as trying to dig up some trustee email
> from 10 years ago is not the right solution.  A secured repository of
> identities/etc would be better (the Foundation already has a place to
> store stuff like bank account details).
> 
> Another practical argument against anonymity.  If everybody agrees
> everything is public, then we don't have any personal information we
> need to protect under various privacy laws.  As soon as we agree to
> keep some info private, then we potentially have obligations under
> such laws.  Also, legally the Foundation is a US organization - so I'm
> not sure if things like the US-EU Safe Harbor provisions start to
> apply if we want to collect this sort of info from EU citizens.  It is
> just a can of worms you can avoid simply by not hanging onto this kind
> of information.  I believe that many of these privacy protections
> cannot be simply waived - we can't get some EU citizen to agree that
> they don't apply to us.  If the laws apply then we need to follow
> them.  Now, we're obviously not a big fish, so enforcement may never
> happen.  Maybe compliance isn't burdensome - I only know enough about
> such things to know that I'd want to know more before going down that
> road...
> 

We should just publish all e-mail addresses (including those explicitly
marked to not publish), all private messages, and all IP adresses of
every forum, wiki, github, telegram, slack, discord, zulip, facebook,
google+, twitter, and reddit user that any Gentoo account has access to,
and a full archive of the -core list (which is expressly not public),
and all information stored in Gentoo's LDAP, and private wikis, and all
mailing list subscribers who have not actually posted to the list(s) to
which they are subscribed because... you think that it might be more
convenient for you? Are you sure that is a road that you want to go
down? Because that seems, to put it gently, completely insane.

Before you plead strawman, consider that your claim is that retaining
any private information is too problematic. Gentoo already retains
private information, where and as it is useful. Gentoo is not likely to
stop retaining such information to at least some extent, given that some
of it is necessary for fairly basic functions. Gentoo is not well served
by pointless double standards, not that anyone is.

Actively dissuading developers who would, for whatever reason, prefer to
use an identifier that is not their legal name seems counterproductive
given the apparent constant search for additional contributors.

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 2895 bytes --]

On Thu, 27 Sep 2018 10:13:30 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> I think there are other arguments to be made against anonymity.

Pseudonymity is hardly anything like anonymity.

Creating a pseudonym requires much work, and its a constructed
"persona" that is a public representation of your natural person.

Just like a real person, a pseudonym requires establishing networks of
trust between peers.

And you don't need to know my physical identity in order for me to
prove, when you meet me, that my physical identity is the owner of the
pseudonym.

If pseudonymity is forbidden, significant contributors of opensource
projects would have to cease existing, among, but not limited to:

 _why of Ruby ( who disappeared entirely from opensource when people
 started leaking his true name )

 Chromatic ( The author of the Modern Perl book, who has respectable
 involvement in both Perl5 and Perl6 )

Its all good to talk about "openness", but forbidding pseudonymity on
this basis is nearly forbidding privacy, because you're tempting that
whole "why do you need privacy if you've got nothing to hide" mentality.

Lets say for example you have a job, and your employer is a dick who
doesn't understand how software works, and will make your life unduely
miserable if they find you out in the real world contributing to
opensource in your free time, despite having no legal right to
persecute you as such.

You're not doing anything untoward, but your employer's braindead
mentality conspires with this policies braindead mentality to forbid
you from contributing for no good reason.

Your options become "quit your job" or "quit contributing".

And you're not actually achieving any real "openness" as a result of
this insanity, you're just making the lives of people who have
legitimate grounds for pseudonymity, harder.

And have people forgotten 'doxxing' is a thing? And in some cases
having your real identity out there in the real world simply serves as
a vector for undue harassment? Even if everything you do is above
board, that doesn't stop busy-bodies deciding you're conflicting with
their distorted sense of morality and using that as grounds to
persecute you.

Say for example you present opinions in favour of something that is not
politically popular where you live ( say you're a gay rights activist,
but live in russia ). You're known by the same pseudonym all over
opensource, but your real name is not published.

And then, this policy comes around, and you have a choice: either keep
using a pseudonym, or tempt associating that pseudonym with your real
self, which potentially invites significant negative social
consequences.

I don't think these sorts of "expose yourself to the elements for all
to attack" behaviours are something Gentoo should be encouraging under
the banner of openness.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

>>>>> On Fri, 28 Sep 2018, kuzetsa  wrote:

> Summary / emphasis: the copyright protection for a
> legal entity or pseudonymous author (copyright holder)
> may also have validity outside the copyright holder or
> author's jurisdiction under the berne convention.

A work is protected by copyright even if it doesn't carry any copyright
notice at all. Our policy requires a notice mainly to protect us against
a possible "innocent infringement" defense under U.S. law:
https://en.wikipedia.org/wiki/Copyright_notice#Reasons_to_include_an_optional_copyright_notice

IANAL, but as I understand it, the requirements for the name that
appears in a copyright notice are rather lax, and your quote from the
Berne convention seems to confirm that. Also there is nothing in the
GLEP's wording that would forbid the use of a pseudonym in the copyright
notice, as long as it will qualify as an identifier of the copyright
holder. (The Signed-off-by line is a different issue, though.)

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 3435 bytes --]

>>>>> On Sat, 29 Sep 2018, Kent Fredric wrote:

> On Thu, 27 Sep 2018 10:13:30 -0400
> Rich Freeman <rich0@gentoo.org> wrote:

>> I think there are other arguments to be made against anonymity.

> Pseudonymity is hardly anything like anonymity.

Both serve the same purpose, namely to conceal your true identity.
This doesn't go well together with a sign-off which is a legal
statement.

> Creating a pseudonym requires much work, and its a constructed
> "persona" that is a public representation of your natural person.

> Just like a real person, a pseudonym requires establishing networks of
> trust between peers.

> And you don't need to know my physical identity in order for me to
> prove, when you meet me, that my physical identity is the owner of the
> pseudonym.

> If pseudonymity is forbidden, significant contributors of opensource
> projects would have to cease existing, among, but not limited to:

>  _why of Ruby ( who disappeared entirely from opensource when people
>  started leaking his true name )

>  Chromatic ( The author of the Modern Perl book, who has respectable
>  involvement in both Perl5 and Perl6 )

> Its all good to talk about "openness", but forbidding pseudonymity on
> this basis is nearly forbidding privacy, because you're tempting that
> whole "why do you need privacy if you've got nothing to hide" mentality.

> Lets say for example you have a job, and your employer is a dick who
> doesn't understand how software works, and will make your life unduely
> miserable if they find you out in the real world contributing to
> opensource in your free time, despite having no legal right to
> persecute you as such.

> You're not doing anything untoward, but your employer's braindead
> mentality conspires with this policies braindead mentality to forbid
> you from contributing for no good reason.

> Your options become "quit your job" or "quit contributing".

> And you're not actually achieving any real "openness" as a result of
> this insanity, you're just making the lives of people who have
> legitimate grounds for pseudonymity, harder.

> And have people forgotten 'doxxing' is a thing? And in some cases
> having your real identity out there in the real world simply serves as
> a vector for undue harassment? Even if everything you do is above
> board, that doesn't stop busy-bodies deciding you're conflicting with
> their distorted sense of morality and using that as grounds to
> persecute you.

> Say for example you present opinions in favour of something that is not
> politically popular where you live ( say you're a gay rights activist,
> but live in russia ). You're known by the same pseudonym all over
> opensource, but your real name is not published.

> And then, this policy comes around, and you have a choice: either keep
> using a pseudonym, or tempt associating that pseudonym with your real
> self, which potentially invites significant negative social
> consequences.

> I don't think these sorts of "expose yourself to the elements for all
> to attack" behaviours are something Gentoo should be encouraging under
> the banner of openness.

Not sure how all that is relevant for the v4 update. The real name was
already required in v3, which has been accepted by both Council and
Trustees.

v4 is merely a clarification that rules for copyright notice (where a
legal entity can be listed) and sign-off (which must be by a natural
person) are different.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 3632 bytes --]

On 09/29/2018 03:46 AM, Ulrich Mueller wrote:
>>>>>> On Fri, 28 Sep 2018, kuzetsa  wrote:
> 
>> Summary / emphasis: the copyright protection for a
>> legal entity or pseudonymous author (copyright holder)
>> may also have validity outside the copyright holder or
>> author's jurisdiction under the berne convention.
> 
> A work is protected by copyright even if it doesn't carry any copyright
> notice at all. Our policy requires a notice mainly to protect us against
> a possible "innocent infringement" defense under U.S. law:
> https://en.wikipedia.org/wiki/Copyright_notice#Reasons_to_include_an_optional_copyright_notice
> 
> IANAL, but as I understand it, the requirements for the name that
> appears in a copyright notice are rather lax, and your quote from the
> Berne convention seems to confirm that. Also there is nothing in the
> GLEP's wording that would forbid the use of a pseudonym in the copyright
> notice, as long as it will qualify as an identifier of the copyright
> holder. (The Signed-off-by line is a different issue, though.)
> 
> Ulrich
> 

"For commits made using a VCS, the committer shall certify agreement to
the Certificate of Origin by adding Signed-off-by: Name <e-mail> to the
commit message as a separate line. Committers must use their real name,
i.e., the name that would appear in an official document like a passport."

"By making a contribution to this project, I certify that:
[...]
The contribution was provided directly to me by some other person who
certified 1., 2., 3., or 4., and I have not modified it."

Which means a contribution of pseudonymous copywritten code cannot be
made.  The person making the commit cannot sign off on it unless the
author signs off on it, and the author cannot sign off on it because
that requires that the author not be pseudonymous.

UNLESS you think this falls under #2:
"The contribution is based upon previous work that, to the best of my
knowledge, is covered under an appropriate free software license, and I
have the right under that license to submit that work with
modifications, whether created in whole or in part by me, under the same
free software license (unless I am permitted to submit under a different
license), as indicated in the file; or"
Which, as written, means that the committer must make a modifications to
the pseudonymous work to qualify as "[FOSS licensed and] created in
whole or in part by me."
The premise of which is that pseudonymous contributions aren't allowed
unless the author submits it as a patch, not using a VCS (as
contributions via VCS must use the Certificate of Origin), and the
committer makes some trivial modification to them, and then, by magic,
we avoid requirements for real names.

Honestly, the whole thing comes across as a massive double
standard/loophole with no real purpose behind it.  If pseudonymous code
is to be accepted for the sake of copyright, then how does one make a
pseudonymous contribution?  If one cannot make a pseudonymous
contribution, then we should be stating that explicitly.

[Quoted from elsewhere for the sake of reducing ML spam]
> "Not sure how all that is relevant for the v4 update. The real name
> was already required in v3, which has been accepted by both Council
> and Trustees.

> v4 is merely a clarification that rules for copyright notice (where a
> legal entity can be listed) and sign-off (which must be by a natural
> person) are different."

TBH, just because this criticism is being levied at the time of v4
doesn't mean that the passing of v3 was without issue.

-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

On Tue, 2018-10-02 at 16:29 -0400, NP-Hardass wrote:
> [Quoted from elsewhere for the sake of reducing ML spam]
> > "Not sure how all that is relevant for the v4 update. The real name
> > was already required in v3, which has been accepted by both Council
> > and Trustees.
> > v4 is merely a clarification that rules for copyright notice (where a
> > legal entity can be listed) and sign-off (which must be by a natural
> > person) are different."
> 
> TBH, just because this criticism is being levied at the time of v4
> doesn't mean that the passing of v3 was without issue.

The issues of the original copyright policy as approved belonged
in the specific threads prior to its approval.  If you failed to raise
your voice in those threads, you have only yourself to blame.  If you
expressed it and it wasn't considered justified, then I'm sorry but
that's all.

This thread is merely about a specific wording change addressing
specific issue.  If you have anything to add regarding this change or
the issue in question, please say it.  If you don't, then please stop
hijacking this thread.

If you really believe the wider aspect of pseudonymous developers needs
being discussed again, please start a separate thread on that topic
and/or prepare a GLEP update for review.  However, please be prepared to
*justify* your changes with actual arguments and explanation why you
need to do this rather than expecting us to justify requiring you to
follow the same rules as everybody else in Gentoo.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 3007 bytes --]

>>>>> On Tue, 02 Oct 2018, NP-Hardass  wrote:

> On 09/29/2018 03:46 AM, Ulrich Mueller wrote:
>> IANAL, but as I understand it, the requirements for the name that
>> appears in a copyright notice are rather lax, and your quote from the
>> Berne convention seems to confirm that. Also there is nothing in the
>> GLEP's wording that would forbid the use of a pseudonym in the copyright
>> notice, as long as it will qualify as an identifier of the copyright
>> holder. (The Signed-off-by line is a different issue, though.)

> "For commits made using a VCS, the committer shall certify agreement to
> the Certificate of Origin by adding Signed-off-by: Name <e-mail> to the
> commit message as a separate line. Committers must use their real name,
> i.e., the name that would appear in an official document like a passport."

> "By making a contribution to this project, I certify that:
> [...]
> The contribution was provided directly to me by some other person who
> certified 1., 2., 3., or 4., and I have not modified it."

> Which means a contribution of pseudonymous copywritten code cannot be
> made.  The person making the commit cannot sign off on it unless the
> author signs off on it, and the author cannot sign off on it because
> that requires that the author not be pseudonymous.

That doesn't contradict my statement that the author be listed under a
pseudonym in the copyright notice (or in an attribution).

> UNLESS you think this falls under #2:
> "The contribution is based upon previous work that, to the best of my
> knowledge, is covered under an appropriate free software license, and I
> have the right under that license to submit that work with
> modifications, whether created in whole or in part by me, under the same
> free software license (unless I am permitted to submit under a different
> license), as indicated in the file; or"
> Which, as written, means that the committer must make a modifications to
> the pseudonymous work to qualify as "[FOSS licensed and] created in
> whole or in part by me."

That wording has be copied from the Linux DCO. Presumably it would be
clearer if it said "submit that work with or without modifications".
If unmodified distribution/submission was not allowed, the license
wouldn't qualify as a free software license, in the first place.

> The premise of which is that pseudonymous contributions aren't allowed
> unless the author submits it as a patch, not using a VCS (as
> contributions via VCS must use the Certificate of Origin), and the
> committer makes some trivial modification to them, and then, by magic,
> we avoid requirements for real names.

See above, the right to distribute the work with modifications doesn't
preclude its distribution without modifications.

The only problem I see is that usually it would not be very polite to
sign off someone else's work. However, I don't think there is a real
problem with that, as long as the committer can confirm that the
contribution is under a free software license.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2152 bytes --]

On Wed, 03 Oct 2018 17:48:18 +0200 Ulrich Mueller wrote:
> >>>>> On Tue, 02 Oct 2018, NP-Hardass  wrote:
> > UNLESS you think this falls under #2:
> > "The contribution is based upon previous work that, to the best of my
> > knowledge, is covered under an appropriate free software license, and I
> > have the right under that license to submit that work with
> > modifications, whether created in whole or in part by me, under the same
> > free software license (unless I am permitted to submit under a different
> > license), as indicated in the file; or"
> > Which, as written, means that the committer must make a modifications to
> > the pseudonymous work to qualify as "[FOSS licensed and] created in
> > whole or in part by me."
> 
> That wording has be copied from the Linux DCO. Presumably it would be
> clearer if it said "submit that work with or without modifications".
> If unmodified distribution/submission was not allowed, the license
> wouldn't qualify as a free software license, in the first place.
> 
> > The premise of which is that pseudonymous contributions aren't allowed
> > unless the author submits it as a patch, not using a VCS (as
> > contributions via VCS must use the Certificate of Origin), and the
> > committer makes some trivial modification to them, and then, by magic,
> > we avoid requirements for real names.
> 
> See above, the right to distribute the work with modifications doesn't
> preclude its distribution without modifications.
> 
> The only problem I see is that usually it would not be very polite to
> sign off someone else's work. However, I don't think there is a real
> problem with that, as long as the committer can confirm that the
> contribution is under a free software license.

Sign-off usually means "I have reviewed this commit and approve it".
This is how it works in the Linux kernel where one have to collect
sufficient number of sign-offs to pass commit in the main tree. An
attempt to give it another meaning like "I'm the author of this
commit" looks questionable. Of course DCO certification is fine as
well.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Rich Freeman]

On Wed, Oct 3, 2018 at 3:16 PM Andrew Savchenko <bircoph@gentoo.org> wrote:
>
> Sign-off usually means "I have reviewed this commit and approve it".
> This is how it works in the Linux kernel where one have to collect
> sufficient number of sign-offs to pass commit in the main tree. An
> attempt to give it another meaning like "I'm the author of this
> commit" looks questionable. Of course DCO certification is fine as
> well.
>

In Linux kernel development signed-off-by has nothing to do with code
reviews/approvals per se, and everything to do with the DCO.

Documentation/process/submitting-patches.rst

Simply giving approval without certifying the DCO is done with the Acked-by tag.

Anybody in the process of forwarding the patch up to Linux has to
append a Signed-off-by, because they're signing the DCO for that
patch.  A maintainer who isn't forwarding the patch would use
Acked-by, since they didn't touch the patch and thus could not have
introduced copyrightable changes.

-- 
Rich