[gentoo-dev] Dealing with GitHub Pull Requests the easy way

[gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Patrice Clement]

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

Hello fellow Gentoo developers and subscribers of the gentoo-dev mailing list,

I've been wanting to write this email for a while but for some reason never got
round to doing it due to lack of motivation and time. 

I will be discussing many topics in this email revolving around git
essentially. I first want to go over some basic concepts about git and GitHub
and why we should be doing things differently if we want to avoid cluttering up
our repository with useless stuff.

* Background

As you know, a little while ago we've migrated the main tree to git, the
revision control tool which needs no introduction. A few months after the
migration, our repository was mirrored over to GitHub to give the project a bit
more exposure to what some developers refers to as "the GitHub generation". The
response from the community was extordinary and as a result, a massive number
of Pull Requests came our way. We soon then started to lend ourselves to the
duty of PR triaging and merging, and started to make what's called in the git
world "merge commits". Understanding merge commits requires understanding how
GitHub considers a contribution. 

When a contributor sends a PR via GitHub, he will essentially be making a
different branch, start working on it and eventually file it. For those of you
familiar with git or who've already filed PRs on GitHub, this is old news.
However, there's a number of different way to deal with PRs on the receiving
end (us) in order to keep a sane log history (graph actually).

When we first started working with git, and GitHub, the tendency was to rely on
merge commits to merge contributions back into the main repo. In my opinion,
this was, and still is, a bad idea. What's so special about merge commits? 

* A short walk through merge commits

As you may know, merging one branch into another often results in creating a
new commit. This commit is called a "merge commit" in git jargon. Let's pick
for instance cf4cce36684de5e449ec60bde3421fa0e27bac74. I'm not trying to put
the blame on a particular developer, we've all used merge commits at one point
or another and I was one of the first! In the log graph, this commit is
displayed as such:

$ git log --graph --oneline master
[snip]
* | |   cf4cce3 Merge remote-tracking branch 'github/pr/1845'
|\ \ \
| * | | abf61de net-im/ejabberd: require <dev-lang/erlang-19
* | | | 72c688f app-cdr/xcdroast: remove old revisions
* | | | ced099c package.mask: update xcdroast p.mask
[snip]

The problem here is two fold. First off, we've created a commit which is
pretty much meaningless. Merge commits often tell a story which says nothing
interesting: Merge remote-tracking branch 'github/pr/1845'. OK, that's great
but we care? Not really. 

The second problem stems from the very nature of merge commits. Indeed, the
first parent of a merge commit is the tip of master right when the branch is
created, in our case this is when the contributor created his branch and
started working on his contribution. However, git log also displays on the left
hand side what I shall call "rails" (no, I'm not a Ruby developer). A rail is
essentially a path leading back to the parent of a merge commit. It is a meant
to be a visual aid to help you work out when two branches veered off and
enventually got merged back together. As you might have noticed by running git
log yourself in the Gentoo git repo and looking back 6 months or a year ago,
there are rails all over the place and overlapping each others. Why does it
happen? 

As I just explained above, the parent of a merge commit is the tip of master.
But because PRs i.e. branches are each created at a different time, the tip of
master is different for each of them. When merging by using a merge commit, git
tries really hard to put this information back together by working out the
parent of each merge commit. This results in a gigantic and entangled mess
shown by git log. I often joke that it looks like as messy version of the
London Tube map: colourful yet upside down.

In some open source projects, it makes sense to leverage merge commits. The
Linux kernel comes to mind for instance. In this case, merge commits are a good
way to track changes coming from a different branch. Given the sheer amount on
contributors working on the Linux kernel, this is useful information for
someone new willing to tackle a new area of the kernel. Figuring out changes
made to a file across several releases is extremely helpful and merge commits
definitely fill this gap. Also, the Linux kernel doesn't have to deal with PRs
since diffs are sent directly to a mailing list.

In the case of Gentoo though, it makes no sense. We should strive for keeping a
clean and linear history. I have yet to witness developers creating branches
in the Gentoo main repository. Even though the GitHub model considers PRs as
branches, they are in fact casual contributions and should be treated as such.

By avoiding merge commits, we make sure the history stay linear with no
parent/child commits all over the place. It leads us to the two remaining
solutions for dealing with PRs in a clean fashion: cherry-picking and git am.
These two solutions really shine at keeping a sane history.

Cherry-picking is not my go-to solution as far as I'm concerned. It requires a
bit of setup and is clearly tedious: you must know in advance the full SHA-1 of
commit(s) you want to cherry-pick. You must also set up remote repositories,
pull from them every now and then, etc. For a Git newbie, it can be daunting. A
few developers often opt for this solution (hi kensington!) which I do not
vouch for.

Eventually, we're left with git am. My favourite choice if you ask me, since it
requires very little to do compared to cherry-picking or making merge commits.
You may or may not know about it but a PR can be fetched as a git am-compatible
patch. If you've ever read emails sent by the GitHub bots, they point to this
URL:

https://github.com/gentoo/gentoo/pull/1234.patch

Once fetched, using your favourite web crawler, the patch can be directly
applied via the git am command onto HEAD of the repository you're dealing with.
There's this common idiom for fetching AND applying at patch all at once:

$ curl https://github.com/gentoo/gentoo/pull/1234.patch | git am

* This is where I'm meant to sell you my solution

Ultimately, I've decided to write a tool to leverage this way of fetching PRs
and merging them. The tool is called Gentoo-App-Pram and is available in the
tree:

# emerge Gentoo-App-Pram

It is written in Perl, works fairly well and has been used by a fair (growing?)
number of developers so far. The tool is CLI-based so you will need to feel at
home with the command line.

Once emerged, cd into your Gentoo git repo and type `pram' followed by the PR
number you wish to merge:

$ cd /home/patrice/gentoo
$ pram 1234

pram will then fetch the PR as a patch and display it to you in your
favourite $EDITOR. At this point, you can make any change to the PR i.e.
editing commit message(s), changing code in-line, etc. 

pram also leverages the "Closes:" header. This header is recognised by GitHub,
and Larry the Cow, and will automatically close a PR when parsing it in the
body of a commit message. So for instance, the following header will
automatically close PR 1234: "Closes: https://github.com/gentoo/gentoo/pull/1234".
You don't need to manually add it as pram will do this for you.

After saving and getting out of $EDITOR, pram will ask you whether the PR needs
merging by asking a yes/no question. "y" will launch git am and merge the
patch whereas "n" will abort the operation and clean it up.

That's pretty much it. Make sure to read the man page since there are other
options available (pram --man).

pram wouldn't have been possible without Kent Fredric's help. He's assisted me
in releasing the package on CPAN and contributed a few patches. Kudos to him!

To wrap up:
- Please stop making merge commits. This strategy is not useful in the case of
  Gentoo and does more harm than good.
- Cherry-pick or git-am external contributions such as PRs.
- Better yet, use Gentoo-App-Pram. :-)

If you want to contribute to Gentoo-App-Pram, send me a PR on GitHub at
https://github.com/monsieurp/Gentoo-App-Pram or file a bug report at
https://bugs.gentoo.org and assign it to me.

Comments and suggestions welcome.

Cheers,

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Peter Stuge]

Patrice Clement wrote:
> We should strive for keeping a clean and linear history.

I agree with you.


> Cherry-picking is not my go-to solution as far as I'm concerned.
> It requires a bit of setup and is clearly tedious: you must know
> in advance the full SHA-1 of commit(s) you want to cherry-pick.

git cherry-pick master..pr1234 # picks all commits on pr1234 not on master

This is essentially a "manual" rebase of pr1234 onto master.

Demo time. Preparations:

$ git config --global alias.la 'log --oneline --graph --decorate --all'
$ export PAGER=cat


Assume the following repo:
$ git la
* ccbc288 (HEAD, master) d
* d33a95b b
| * 3e5b52e (pr1234) c
| * 6491f93 b2
|/  
* 2dfcb95 a
$ 

git cherry-pick master..pr1234 would apply b2 and c onto master:

$ git cherry-pick master..pr1234
[master 305532b] b2
 1 file changed, 1 insertion(+)
 create mode 100644 b2
[master d18f1ac] c
 1 file changed, 1 insertion(+)
 create mode 100644 c
$ git la
* d18f1ac (HEAD, master) c
* 305532b b2
* ccbc288 d
* d33a95b b
| * 3e5b52e (pr1234) c
| * 6491f93 b2
|/  
* 2dfcb95 a
$ 

If the pr1234 branch has some value once b2 and c are in master then
this is a good way to do it, the main drawback IMO that it leaves a
repetitive and redundant pr1234 branch behind.


Another way would be to simply rebase the pr1234 branch. Disclaimer: I
don't know GitHub processes and assumptions, so rebase might suck for this.

If noone cares about the PR branches once they have been merged/closed
(I got that impression from your mail) then rebase may be a good choice.

$ git la
* ccbc288 (HEAD, master) d
* d33a95b b
| * 3e5b52e (pr1234) c
| * 6491f93 b2
|/  
* 2dfcb95 a
$ git rebase master pr1234
First, rewinding head to replay your work on top of it...
Applying: b2
Applying: c
$ git la
* 92417d4 (HEAD, pr1234) c
* 385ca8c b2
* ccbc288 (master) d
* d33a95b b
* 2dfcb95 a
$ 

At this point, pr1234 can be fast-forward merged into master:

$ git checkout master
Switched to branch 'master'
$ git merge --ff-only pr1234
Updating ccbc288..0565e44
Fast-forward
 b2 | 1 +
 c  | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 b2
 create mode 100644 c
$ git la
* 0565e44 (HEAD, pr1234, master) c
* 0dbfdf8 b2
* ccbc288 d
* d33a95b b
* 2dfcb95 a
$ 


> You may or may not know about it but a PR can be fetched as a git
> am-compatible patch.
..
> https://github.com/gentoo/gentoo/pull/1234.patch

Didn't know - that's pretty handy!


> $ cd /home/patrice/gentoo
> $ pram 1234

Nice work! I might have made a git pr alias instead, but pram seems
way more flexible than that would be.


Finally, while I do agree with you, the one and only reason IMO to
live with merge commits is that they implicitly preserve the branching
point. For source code that can be useful, but for ebuilds less so.


//Peter

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Benda Xu]

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

Hi Patrice,

Patrice Clement <monsieurp@gentoo.org> writes:

> [...]

Very enjoyable write-up.  I completely agree with you.

This will be an important reference. Please consider adding it into the
wiki after we reach a wider consensus on how to merge pull request on
github.

Benda

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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Michael Orlitzky]

On 10/18/2016 08:03 PM, Benda Xu wrote:
> 
> This will be an important reference. Please consider adding it into the
> wiki after we reach a wider consensus on how to merge pull request on
> github.


It's been there for a long time:

https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Pull_requests_from_developers_and_users

(that's the way I prefer to merge pull requests, too).

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Matthew Thode]

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

I've been using the curl into git am method for a while now, it's nice
to see it's not just me :D  Does pram allow you to pass options to git
am (signedoffby for instance)?

-- 
-- Matthew Thode (prometheanfire)


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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Kent Fredric]

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

On Tue, 18 Oct 2016 21:45:05 -0500
Matthew Thode <prometheanfire@gentoo.org> wrote:

>  Does pram allow you to pass options to git
> am (signedoffby for instance)?

It doesn't presently allow arbitrary arguments, and it would probably be wise
to avoid need for such arguments and prefer convention over configuration, given what this is.

--signoff is already a default:

https://metacpan.org/source/MONSIEURP/Gentoo-App-Pram-0.003000/lib/Gentoo/App/Pram.pm#L71


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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Robin H. Johnson]

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

One of the downsides both the git-am and cherry-pick workflows are that
they invalidate or otherwise omit commit signatures.

git-merge on the other hand does preserve the signature as the original
commit is intact, and the merge commit is where the signature of the
gentoo developer is introduced.

I agree clean history is valuable, but verifiable attribution may in
fact be more important.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Matthew Thode]

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

On 10/19/2016 01:00 AM, Robin H. Johnson wrote:
> One of the downsides both the git-am and cherry-pick workflows are that
> they invalidate or otherwise omit commit signatures.
> 
> git-merge on the other hand does preserve the signature as the original
> commit is intact, and the merge commit is where the signature of the
> gentoo developer is introduced.
> 
> I agree clean history is valuable, but verifiable attribution may in
> fact be more important.
> 
Yes, I don't like this aspect of any workflow that breaks history but I
personally feel that for the sake of both 'cleanliness' and ease of use
that the git am (or cherry-pick) workflow is best.  I could possibly see
the possibility of tampering with the patch could be a problem
(attribution as you say) but in the end a developer still committed it.
Authored-by and Committed-by being different fields I feel the main one
infra needs to worry about is Committed-by.

-- 
Matthew Thode (prometheanfire)


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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Alexis Ballier]

On Tue, 18 Oct 2016 23:13:26 +0200
Patrice Clement <monsieurp@gentoo.org> wrote:
 
> In the case of Gentoo though, it makes no sense. We should strive for
> keeping a clean and linear history.


A DAG is what I would call linear history :)
Merge commits preserve that structure, git log performs a topological
sort on the history DAG, effectively showing it to you as a timeline.
Now, topsort is kind of classical, very efficient, algorithm so why
should I care doing this sorting manually when git does it faster and
better than I would ever do ?

Also, if you want to see linear history, why do you use git log
--graph ? This seems to me you're inventing your own problems :)


> By avoiding merge commits, we make sure the history stay linear with
> no parent/child commits all over the place. It leads us to the two
> remaining solutions for dealing with PRs in a clean fashion:
> cherry-picking and git am. These two solutions really shine at
> keeping a sane history.

git merge ...
git rebase origin/master


this kills the merge commit and reparents the commits you merged to
the tip of origin/master

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Ulrich Mueller]

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

>>>>> On Wed, 19 Oct 2016, Kent Fredric wrote:

> On Tue, 18 Oct 2016 21:45:05 -0500
> Matthew Thode <prometheanfire@gentoo.org> wrote:

>> Does pram allow you to pass options to git
>> am (signedoffby for instance)?

> It doesn't presently allow arbitrary arguments, and it would
> probably be wise to avoid need for such arguments and prefer
> convention over configuration, given what this is.

> --signoff is already a default:

> https://metacpan.org/source/MONSIEURP/Gentoo-App-Pram-0.003000/lib/Gentoo/App/Pram.pm#L71

Maybe I have missed something, but why would one use --signoff for
a Gentoo commit?

For Linux (the kernel), the meaning of the line is that the
contributor certifies the DCO (Developer's Certificate of Origin) [1].
As we don't have a Gentoo DCO, it is not at all clear to me what the
meaning of a Signed-off-by: line would be in the context of the gentoo
tree.

Even worse, I see commits having Signed-off-by: lines with obvious
pseudonyms instead of a real name, which would be meaningless even if
one would say that the Linux rules apply. (Also, we have the rule that
real names must be provided for all developers, with no exceptions to
be made for people doing copyrightable work [2].)

Ulrich

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=dca22a63fd036c3ebb50212060eba0080f178126#n428
[2] https://wiki.gentoo.org/wiki/Project:Recruiters#What_does_the_recruitment_process_involve.3F

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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Matthew Thode]

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

On 10/19/2016 04:10 AM, Ulrich Mueller wrote:
> Maybe I have missed something, but why would one use --signoff for
> a Gentoo commit?

Personally I use it as 'I sign off on the Author's work'.  I suppose the
commit itself is good enough for this but I personally prefer verbosity.
 It also calls out that it wasn't my work.

-- 
-- Matthew Thode (prometheanfire)


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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Kristian Fiskerstrand]

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

On 10/19/2016 02:13 PM, Matthew Thode wrote:
> On 10/19/2016 04:10 AM, Ulrich Mueller wrote:
>> Maybe I have missed something, but why would one use --signoff for
>> a Gentoo commit?
> 
> Personally I use it as 'I sign off on the Author's work'.  I suppose the
> commit itself is good enough for this but I personally prefer verbosity.
>  It also calls out that it wasn't my work.
> 

This sounds more like a reviewed by or acked by?


-- 
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: 455 bytes --]

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Matthew Thode]

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

On 10/19/2016 07:15 AM, Kristian Fiskerstrand wrote:
> On 10/19/2016 02:13 PM, Matthew Thode wrote:
>> On 10/19/2016 04:10 AM, Ulrich Mueller wrote:
>>> Maybe I have missed something, but why would one use --signoff for
>>> a Gentoo commit?
>>
>> Personally I use it as 'I sign off on the Author's work'.  I suppose the
>> commit itself is good enough for this but I personally prefer verbosity.
>>  It also calls out that it wasn't my work.
>>
> 
> This sounds more like a reviewed by or acked by?
> 
> 

Yep, but do either of those have a simple switch I can use (-s)? :P

-- 
-- Matthew Thode (prometheanfire)


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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Matt Turner]

On Wed, Oct 19, 2016 at 2:10 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Wed, 19 Oct 2016, Kent Fredric wrote:
>
>> On Tue, 18 Oct 2016 21:45:05 -0500
>> Matthew Thode <prometheanfire@gentoo.org> wrote:
>
>>> Does pram allow you to pass options to git
>>> am (signedoffby for instance)?
>
>> It doesn't presently allow arbitrary arguments, and it would
>> probably be wise to avoid need for such arguments and prefer
>> convention over configuration, given what this is.
>
>> --signoff is already a default:
>
>> https://metacpan.org/source/MONSIEURP/Gentoo-App-Pram-0.003000/lib/Gentoo/App/Pram.pm#L71
>
> Maybe I have missed something, but why would one use --signoff for
> a Gentoo commit?
>
> For Linux (the kernel), the meaning of the line is that the
> contributor certifies the DCO (Developer's Certificate of Origin) [1].
> As we don't have a Gentoo DCO, it is not at all clear to me what the
> meaning of a Signed-off-by: line would be in the context of the gentoo
> tree.
>
> Even worse, I see commits having Signed-off-by: lines with obvious
> pseudonyms instead of a real name, which would be meaningless even if
> one would say that the Linux rules apply. (Also, we have the rule that
> real names must be provided for all developers, with no exceptions to
> be made for people doing copyrightable work [2].)

This is probably worthy of a separate thread.

But I completely agree: it's meaningless. Mesa, the project I work on
professionally, has the same cargo-culted Signed-off-by with patch
reviewers even pointing out lack of (still meaningless!) S-o-b.

To all: Signed-off-by doesn't mean anything without a Developer
Certificate of Origin. Until a time when Gentoo has one, please stop
putting it on your commits.

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Kent Fredric]

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

On Wed, 19 Oct 2016 14:15:11 +0200
Kristian Fiskerstrand <k_f@gentoo.org> wrote:

> > 
> > Personally I use it as 'I sign off on the Author's work'.  I suppose the
> > commit itself is good enough for this but I personally prefer verbosity.
> >  It also calls out that it wasn't my work.
> >   
> 
> This sounds more like a reviewed by or acked by?

I think the important use-case here is to understand why you can't rely
on other headers.

The beauty of Signed-Off-By is if you cherry-pick a commit with it, its
preserved.

Default behaviour:
- Author is preserved from first committer 
- Committer is changed every time the commit itself is rebased,
  cherry-picked, etc.

So if this commit was to get teleported to a different repo,
--signoff by would be preserved, as an intermediate between these two.

So I think the intent for this is "X reviewed these changes for Gentoo
and takes responsibility for them"

what text you use to convey that is irrelevant, as long as its used
consistently and everyone understands what the text means.

git help commmit, emphasis added: 

> Add Signed-off-by line by the committer at the end of the commit log message. 
> ***The meaning of a signoff depends on the project***, but it typically
> certifies that committer has the rights to submit this work under the same
> license and agrees to a Developer Certificate of Origin 
> (see http://developercertificate.org/ for more information).

And I think people get hung up too much on the second half of that
statement.

Sure, we could use some other header, but this one is standard and part
of default git tooling.

So its at least practical.

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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Wed, Oct 19, 2016 at 8:32 AM, Kent Fredric <kentnl@gentoo.org> wrote:
>
> So if this commit was to get teleported to a different repo,
> --signoff by would be preserved, as an intermediate between these two.
>
> So I think the intent for this is "X reviewed these changes for Gentoo
> and takes responsibility for them"
>
> what text you use to convey that is irrelevant, as long as its used
> consistently and everyone understands what the text means.
>

Actually, the text matters a great deal, which is why projects that
care about copyright tend to have an explicit DCO.  One for Gentoo was
in the works but has stalled somewhat (to be fair, it was stalled
originally because we were waiting for git to come along).  It
probably makes sense to at least get that into effect even if we don't
have a long-term strategy around copyright attribution and so on.

The last draft DCO was:
Gentoo DCO 1.0 By making a contribution to this project, I certify
that: (a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license indicated in
the file; or (b) The contribution is based upon previous work that, to
the best of my knowledge, is covered under an appropriate open source
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 open source license (unless I am permitted to submit under a
different license), as indicated in the file; or (c) The contribution
was provided directly to me by some other person who certified (a),
(b) or (c) and I have not modified it. (d) 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 open source
license(s) involved.

This is from the last policy draft:
https://dev.gentoo.org/~rich0/copyrightpolicy.xml

(And of course you get to read the raw xml these days...)

The main issue with the overall copyright policy was the issue with
tracking authorship and who goes on the copyright line.

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Pacho Ramos]

El mar, 18-10-2016 a las 23:13 +0200, Patrice Clement escribió:
> Hello fellow Gentoo developers and subscribers of the gentoo-dev
> mailing list,
> 
> 
[...]

Thanks a lot for your work!

But, is there any place (an official wiki page from the project taking
care of github mirror work) where all this information could be stored?
Or, at least, a simple guide about what is the preferred way to
introduce a PR in main tree for people that are not used (like me) to
work with github?

That would be really nice :)

Best regards!

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Greg KH]

On Wed, Oct 19, 2016 at 09:19:36AM -0400, Rich Freeman wrote:
> On Wed, Oct 19, 2016 at 8:32 AM, Kent Fredric <kentnl@gentoo.org> wrote:
> >
> > So if this commit was to get teleported to a different repo,
> > --signoff by would be preserved, as an intermediate between these two.
> >
> > So I think the intent for this is "X reviewed these changes for Gentoo
> > and takes responsibility for them"
> >
> > what text you use to convey that is irrelevant, as long as its used
> > consistently and everyone understands what the text means.
> >
> 
> Actually, the text matters a great deal, which is why projects that
> care about copyright tend to have an explicit DCO.  One for Gentoo was
> in the works but has stalled somewhat (to be fair, it was stalled
> originally because we were waiting for git to come along).  It
> probably makes sense to at least get that into effect even if we don't
> have a long-term strategy around copyright attribution and so on.
> 
> The last draft DCO was:
> Gentoo DCO 1.0 By making a contribution to this project, I certify
> that: (a) The contribution was created in whole or in part by me and I
> have the right to submit it under the open source license indicated in
> the file; or (b) The contribution is based upon previous work that, to
> the best of my knowledge, is covered under an appropriate open source
> 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 open source license (unless I am permitted to submit under a
> different license), as indicated in the file; or (c) The contribution
> was provided directly to me by some other person who certified (a),
> (b) or (c) and I have not modified it. (d) 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 open source
> license(s) involved.
> 
> This is from the last policy draft:
> https://dev.gentoo.org/~rich0/copyrightpolicy.xml

Why redraft the already-useful DCO that is out there for you to use
as-is:
	http://developercertificate.org/

As you copied the text, be sure to give proper reference to who owns the
copyright of that text please, you just can't rename it and claim it as
your own :)

thanks,

greg k-h

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Ulrich Mueller]

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

>>>>> On Sat, 22 Oct 2016, Greg KH wrote:

> On Wed, Oct 19, 2016 at 09:19:36AM -0400, Rich Freeman wrote:
>> This is from the last policy draft:
>> https://dev.gentoo.org/~rich0/copyrightpolicy.xml

> Why redraft the already-useful DCO that is out there for you to use
> as-is:
> 	http://developercertificate.org/

> As you copied the text, be sure to give proper reference to who owns
> the copyright of that text please, you just can't rename it and
> claim it as your own :)

In fact, Rich *does* give credit to Linux:
"The DCO is based on the
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches
Linux Kernel DCO"

Also, I wouldn't completely exclude that we need to change the wording
at some later point. Therefore, we may indeed consider taking the DCO
from the Linux source tree which is distributed under the GPL-2,
instead of the non-free version ("changing it is not allowed") from
developercertificate.org. Their wording is identical except for the
preamble.

Ulrich

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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Sat, Oct 22, 2016 at 10:47 AM, Greg KH <gregkh@gentoo.org> wrote:
> On Wed, Oct 19, 2016 at 09:19:36AM -0400, Rich Freeman wrote:
>>
>> The last draft DCO was:
>> Gentoo DCO 1.0 By making a contribution to this project, I certify
>> that: (a) The contribution was created in whole or in part by me and I
>> have the right to submit it under the open source license indicated in
>> the file; or (b) The contribution is based upon previous work that, to
>> the best of my knowledge, is covered under an appropriate open source
>> 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 open source license (unless I am permitted to submit under a
>> different license), as indicated in the file; or (c) The contribution
>> was provided directly to me by some other person who certified (a),
>> (b) or (c) and I have not modified it. (d) 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 open source
>> license(s) involved.
>>
>> This is from the last policy draft:
>> https://dev.gentoo.org/~rich0/copyrightpolicy.xml
>
> Why redraft the already-useful DCO that is out there for you to use
> as-is:
>         http://developercertificate.org/

To be honest I don't remember.  The last time I touched it was years
ago and maybe there was a reason to fork it at the time, but I can't
see a reason for it now.

>
> As you copied the text, be sure to give proper reference to who owns the
> copyright of that text please, you just can't rename it and claim it as
> your own :)
>

Makes sense.  I'd suggest copying it into the policy and attributing
it vs just incorporating it by reference, since the original might go
away (though we've already demonstrated that our own guidexml has not
lasted as long as that hosted text file).

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Daniel Campbell]

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

On 10/19/2016 02:10 AM, Ulrich Mueller wrote:
>>>>>> On Wed, 19 Oct 2016, Kent Fredric wrote:
> 
>> On Tue, 18 Oct 2016 21:45:05 -0500
>> Matthew Thode <prometheanfire@gentoo.org> wrote:
> 
>>> Does pram allow you to pass options to git
>>> am (signedoffby for instance)?
> 
>> It doesn't presently allow arbitrary arguments, and it would
>> probably be wise to avoid need for such arguments and prefer
>> convention over configuration, given what this is.
> 
>> --signoff is already a default:
> 
>> https://metacpan.org/source/MONSIEURP/Gentoo-App-Pram-0.003000/lib/Gentoo/App/Pram.pm#L71
> 
> Maybe I have missed something, but why would one use --signoff for
> a Gentoo commit?
> 
> For Linux (the kernel), the meaning of the line is that the
> contributor certifies the DCO (Developer's Certificate of Origin) [1].
> As we don't have a Gentoo DCO, it is not at all clear to me what the
> meaning of a Signed-off-by: line would be in the context of the gentoo
> tree.
> 
> Even worse, I see commits having Signed-off-by: lines with obvious
> pseudonyms instead of a real name, which would be meaningless even if
> one would say that the Linux rules apply. (Also, we have the rule that
> real names must be provided for all developers, with no exceptions to
> be made for people doing copyrightable work [2].)
> 
> Ulrich
> 
> [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=dca22a63fd036c3ebb50212060eba0080f178126#n428
> [2] https://wiki.gentoo.org/wiki/Project:Recruiters#What_does_the_recruitment_process_involve.3F
> 
The way I understood "signed off by" for Gentoo is "I am a developer who
looked at the code and tested it, confirming it works on my system". If
an AT signs off, they are certifying that it passes their test muster.

It's a more formal "looks good to me", and provides a point of
accountability if the commit _isn't_ up to par.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Michał Górny]

Dnia 24 października 2016 07:32:26 CEST, Daniel Campbell <zlg@gentoo.org> napisał(a):
>On 10/19/2016 02:10 AM, Ulrich Mueller wrote:
>>>>>>> On Wed, 19 Oct 2016, Kent Fredric wrote:
>> 
>>> On Tue, 18 Oct 2016 21:45:05 -0500
>>> Matthew Thode <prometheanfire@gentoo.org> wrote:
>> 
>>>> Does pram allow you to pass options to git
>>>> am (signedoffby for instance)?
>> 
>>> It doesn't presently allow arbitrary arguments, and it would
>>> probably be wise to avoid need for such arguments and prefer
>>> convention over configuration, given what this is.
>> 
>>> --signoff is already a default:
>> 
>>>
>https://metacpan.org/source/MONSIEURP/Gentoo-App-Pram-0.003000/lib/Gentoo/App/Pram.pm#L71
>> 
>> Maybe I have missed something, but why would one use --signoff for
>> a Gentoo commit?
>> 
>> For Linux (the kernel), the meaning of the line is that the
>> contributor certifies the DCO (Developer's Certificate of Origin)
>[1].
>> As we don't have a Gentoo DCO, it is not at all clear to me what the
>> meaning of a Signed-off-by: line would be in the context of the
>gentoo
>> tree.
>> 
>> Even worse, I see commits having Signed-off-by: lines with obvious
>> pseudonyms instead of a real name, which would be meaningless even if
>> one would say that the Linux rules apply. (Also, we have the rule
>that
>> real names must be provided for all developers, with no exceptions to
>> be made for people doing copyrightable work [2].)
>> 
>> Ulrich
>> 
>> [1]
>http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=dca22a63fd036c3ebb50212060eba0080f178126#n428
>> [2]
>https://wiki.gentoo.org/wiki/Project:Recruiters#What_does_the_recruitment_process_involve.3F
>> 
>The way I understood "signed off by" for Gentoo is "I am a developer
>who
>looked at the code and tested it, confirming it works on my system". If
>an AT signs off, they are certifying that it passes their test muster.
>
>It's a more formal "looks good to me", and provides a point of
>accountability if the commit _isn't_ up to par.

How about Gentoo developers stopping to reuse things that have well-defined meaning for something completely different?


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Kent Fredric]

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

On Mon, 24 Oct 2016 08:29:49 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> How about Gentoo developers stopping to reuse things that have well-defined meaning for something completely different?

Patching the git tools to have a simple-to-use way to indicate the
equivalent metadata welcome ... 

But like, you're either going to need to patch a lot of things in
non-standard ways, or make said feature only possible under repoman
( which makes application of said feature impossible to use as part of
a git workflow, which makes using git pointless )

Its doable for Pram, but standardizing the feature across gentoo is hard.

Just see how consistent we're using "and we have a bug somewhere" for
how not having defacto tools changes how people (fail to) achieve
consistency.



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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Daniel Campbell (zlg)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On October 23, 2016 11:29:49 PM PDT, "Michał Górny" <mgorny@gentoo.org> wrote:
>Dnia 24 października 2016 07:32:26 CEST, Daniel Campbell
><zlg@gentoo.org> napisał(a):
>>On 10/19/2016 02:10 AM, Ulrich Mueller wrote:
>>>>>>>> On Wed, 19 Oct 2016, Kent Fredric wrote:
>>>
>>>> On Tue, 18 Oct 2016 21:45:05 -0500
>>>> Matthew Thode <prometheanfire@gentoo.org> wrote:
>>>
>>>>> Does pram allow you to pass options to git
>>>>> am (signedoffby for instance)?
>>>
>>>> It doesn't presently allow arbitrary arguments, and it would
>>>> probably be wise to avoid need for such arguments and prefer
>>>> convention over configuration, given what this is.
>>>
>>>> --signoff is already a default:
>>>
>>>>
>>https://metacpan.org/source/MONSIEURP/Gentoo-App-Pram-0.003000/lib/Gentoo/App/Pram.pm#L71
>>>
>>> Maybe I have missed something, but why would one use --signoff for
>>> a Gentoo commit?
>>>
>>> For Linux (the kernel), the meaning of the line is that the
>>> contributor certifies the DCO (Developer's Certificate of Origin)
>>[1].
>>> As we don't have a Gentoo DCO, it is not at all clear to me what the
>>> meaning of a Signed-off-by: line would be in the context of the
>>gentoo
>>> tree.
>>>
>>> Even worse, I see commits having Signed-off-by: lines with obvious
>>> pseudonyms instead of a real name, which would be meaningless even
>if
>>> one would say that the Linux rules apply. (Also, we have the rule
>>that
>>> real names must be provided for all developers, with no exceptions
>to
>>> be made for people doing copyrightable work [2].)
>>>
>>> Ulrich
>>>
>>> [1]
>>http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=dca22a63fd036c3ebb50212060eba0080f178126#n428
>>> [2]
>>https://wiki.gentoo.org/wiki/Project:Recruiters#What_does_the_recruitment_process_involve.3F
>>>
>>The way I understood "signed off by" for Gentoo is "I am a developer
>>who
>>looked at the code and tested it, confirming it works on my system".
>If
>>an AT signs off, they are certifying that it passes their test muster.
>>
>>It's a more formal "looks good to me", and provides a point of
>>accountability if the commit _isn't_ up to par.
>
>How about Gentoo developers stopping to reuse things that have
>well-defined meaning for something completely different?

I did say "to my understanding". I wasn't aware of DCOs. Regardless, practices and workflows differ between projects, and it doesn't surprise me to see projects that use the same words differently. Not that we should, of course. What would you call what I decribed, though; Acked?
- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-----BEGIN PGP SIGNATURE-----

iQJRBAEBCgA7NBxEYW5pZWwgQ2FtcGJlbGwgKEdlbnRvbyBEZXZlbG9wZXIpIDx6
bGdAZ2VudG9vLm9yZz4FAlgNtlQACgkQASQOlFA54XDmhw/9HbEDo60eZp38AUMf
TgCnj8fYka65Pc9CjLBpJAcvekM2oRcSHB61FdAy8tqIVb7Zx8IvIXNXseOc9sP4
0qNSy89gOKkNRIPx/DC8JFVlmK6YoD5ezZ05tKdzFwcdBvHcJWhKfbO2R2f6L/g5
woLZb4qgxQdFNwOykDy2Ux83W075hFbHaAw9zwpVKAb9LvtMfiJJ2AYEecmnOZDx
uVVnkxMrOpAKABhcUqc3d8MnB2NCPwZogL3Z+71duy3puU+71Y338w64vrXDioBY
4pPVIrXk4Ifa799xjCj+Wr2sWYzgHqdJe/cReYZXjRMRzxbvLiZo1PWLejMWgczk
CRX0lh6o0cohDxX8oEMiY3s3COqQvD928FzppGkW+8+XQaqXE64VEyHszMuILPL3
cLBbRt39ujmSPJUp/5mX3yUA761QcvRv4wPaDAf81NYllepLoYh2IL9j+5Iqfrf4
QNm/bUeuwxnvLZOMNGTyih/5w2GvhKhLunp170Lm4LGf6BQoEw60ZYot6OlvKFLF
Th8oaacTc9acVa7K2lDlH+2ARsqFvfwQgEjGaLczfhFXi8lzIckgtb7Shn1UjEB5
u/7AwgGmO0rC3Mt9GXL7P5xYgWInNxEeyNP+O0d7Lu5CnBsKI9fUvoYnGZblSAWn
yt44aBJYOgIzLklGfuQm6xhgdDc=
=eesR
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Kristian Fiskerstrand]

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

On 10/24/2016 09:21 AM, Daniel Campbell (zlg) wrote:
> What would you call what I decribed, though; Acked?

Acked-By and/or Reviewed-By (although we don't have a specific
reviewer's statement in Gentoo (yet?))

-- 
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: 455 bytes --]

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Mon, Oct 24, 2016 at 3:21 AM, Daniel Campbell (zlg) <zlg@gentoo.org> wrote:
>
> On October 23, 2016 11:29:49 PM PDT, "Michał Górny" <mgorny@gentoo.org> wrote:
>>Dnia 24 października 2016 07:32:26 CEST, Daniel Campbell
>><zlg@gentoo.org> napisał(a):
>>>On 10/19/2016 02:10 AM, Ulrich Mueller wrote:
>>>> Maybe I have missed something, but why would one use --signoff for
>>>> a Gentoo commit?
>>>>
>>>> For Linux (the kernel), the meaning of the line is that the
>>>> contributor certifies the DCO (Developer's Certificate of Origin)
>>>[1].
>>>> As we don't have a Gentoo DCO, it is not at all clear to me what the
>>>> meaning of a Signed-off-by: line would be in the context of the
>>>gentoo
>>>> tree.
>>>>
>>>> Even worse, I see commits having Signed-off-by: lines with obvious
>>>> pseudonyms instead of a real name, which would be meaningless even
>>if
>>>> one would say that the Linux rules apply. (Also, we have the rule
>>>that
>>>> real names must be provided for all developers, with no exceptions
>>to
>>>> be made for people doing copyrightable work [2].)
>>>>
>>>> [1]
>>>http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=dca22a63fd036c3ebb50212060eba0080f178126#n428
>>>> [2]
>>>https://wiki.gentoo.org/wiki/Project:Recruiters#What_does_the_recruitment_process_involve.3F
>>>>
>>>The way I understood "signed off by" for Gentoo is "I am a developer
>>>who
>>>looked at the code and tested it, confirming it works on my system".
>>If
>>>an AT signs off, they are certifying that it passes their test muster.
>>>
>>>It's a more formal "looks good to me", and provides a point of
>>>accountability if the commit _isn't_ up to par.
>>
>>How about Gentoo developers stopping to reuse things that have
>>well-defined meaning for something completely different?
>
> I did say "to my understanding". I wasn't aware of DCOs. Regardless, practices and workflows differ between projects, and it doesn't surprise me to see projects that use the same words differently. Not that we should, of course. What would you call what I decribed, though; Acked?

I don't think we need a git header for the purpose of saying that
something looks good to somebody else.  If you commit something and it
doesn't work, we'll ask you to stop doing it.  If you keep doing it
we'll take away your commit access.  This is purely an internal
problem.

The purpose of a DCO is to withstand external scrutiny.  It helps
protect Gentoo in the event that somebody else's copyrighted code
makes it into the distro.  The audience for a signed-off-by header
isn't Comrel or QA, but rather a court of law.  It makes it harder to
contribute something to Gentoo and then argue that you didn't intend
for Gentoo to redistribute it under the GPL, or that now that you've
had a falling out you'd prefer that Gentoo remove all your past
contributions.

However, it has absolutely no meaning at all if it isn't 100% clear
what is being signed.  And if we have a long history of people adding
the header when it doesn't mean anything legally then it will probably
make it harder to argue that it suddenly means something when the
policy changes.

For example, suppose we institute a DCO tomorrow.  Then zlg ragequits
in 2 years and claims he never gave us permission to redistribute his
code under the GPL.  We point to his signed-off-by headers but he says
he never heard of the DCO policy and that it was just some default
setting in his config, and that he was adding the headers long before
the policy went into effect.  I don't think it would stick but it
really isn't an out we want to give people.  IMO infra should reject
commits with this header until we have a DCO, and then it should
reject commits without this header.  Alternatively, we could skip the
first part but require all existing devs to ack the new copyright
policy whenever it happens.

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Kent Fredric]

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

On Mon, 24 Oct 2016 07:45:56 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> I don't think we need a git header for the purpose of saying that
> something looks good to somebody else.  If you commit something and it
> doesn't work, we'll ask you to stop doing it.  If you keep doing it
> we'll take away your commit access.  This is purely an internal
> problem.

The problem is that the COMMITTER and AUTHOR headers don't actually
reflect the "I tested it and made sure its OK" metadata.

If for example, a commit made to Gentoo was replicated to another
repository by cherry-pick, the default mechanic would result in
COMMITTER changing to the person who performed the cherry-pick.

Thus, it makes the assumption that everyone who performed a COMMIT
action or an AUTHOR action verified the nature of the commit in some
manner.

However, the AUTHOR is the least qualified to verify the commit as
"Good".

and the COMMITTER value changes arbitrarily if you try to cherry-pick or
rebase the commit sequence.

And people who rebase commit sequences are typically not firing up
review engines for every commit they rebased.

Granted, this is not a very common problem in Gentoo.

But IME, this is the sort of use-case that the header is useful for.

If we deem this header useless, then we should probably consider
dropping the Portage Version and Repoman Flags headers that repoman
adds.

Because they're also made entirely irrelevant in very short times,
because it only indicates "Authored with", it doesn't indicate anything
that happened since then.

> The purpose of a DCO is to withstand external scrutiny.  It helps
> protect Gentoo in the event that somebody else's copyrighted code
> makes it into the distro.  The audience for a signed-off-by header
> isn't Comrel or QA, but rather a court of law.  It makes it harder to
> contribute something to Gentoo and then argue that you didn't intend
> for Gentoo to redistribute it under the GPL, or that now that you've
> had a falling out you'd prefer that Gentoo remove all your past
> contributions.
> 
> However, it has absolutely no meaning at all if it isn't 100% clear
> what is being signed.  And if we have a long history of people adding
> the header when it doesn't mean anything legally then it will probably
> make it harder to argue that it suddenly means something when the
> policy changes.
> 
> For example, suppose we institute a DCO tomorrow.  Then zlg ragequits
> in 2 years and claims he never gave us permission to redistribute his
> code under the GPL.  We point to his signed-off-by headers but he says
> he never heard of the DCO policy and that it was just some default
> setting in his config, and that he was adding the headers long before
> the policy went into effect.  I don't think it would stick but it
> really isn't an out we want to give people.  IMO infra should reject
> commits with this header until we have a DCO, and then it should
> reject commits without this header.  Alternatively, we could skip the
> first part but require all existing devs to ack the new copyright
> policy whenever it happens.

Under this interpretation, developers using this header to add other
peoples work to tree is making our use of DCO pointless.

Because DCO has to be the person who *authored* the commit, not the
person who merely added it to tree.

And Pram should stop adding it everywhere post-haste, because its
inferring things that aren't true.

But this doesn't change the fact there is a desire to communicate other
properties of commits, like the audit trail for QA purposes.

It just means we have to find some other way of doing this which is
standard, but the stock git commands lack any such mechanism.

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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Tue, Oct 25, 2016 at 9:39 PM, Kent Fredric <kentnl@gentoo.org> wrote:
>
> Under this interpretation, developers using this header to add other
> peoples work to tree is making our use of DCO pointless.
>
> Because DCO has to be the person who *authored* the commit, not the
> person who merely added it to tree.

That actually isn't true.  Read the DCO.  Clauses b/c are designed
specifically for cases where the committer isn't the author.

It is apparently good enough for the Linux Foundation.  They don't
require any direct interaction with the author of code to accept it
into the kernel.  They merely require that whoever submits the code
makes the certification that they've done their due diligence.

>
> And Pram should stop adding it everywhere post-haste, because its
> inferring things that aren't true.
>

I did suggest that we probably should ban this header until we
actually have a DCO because it blurs the lines.  However, it isn't
really inferring something that isn't true right now because we don't
assign any legal meaning to the header right now.  The bigger concern
is that it blurs the lines after we have a DCO because people can
argue the use of the header was accidental or meant something else.

Whether or not we proactively ban the header, it would probably make
sense that if we do institute a new copyright policy including a DCO
that we ask all devs to explicitly ack the policy and the meaning of
the signed-off-by header somehow (maybe issue a gpg signed statement
from a template).  It could also be made a part of the ebuild quiz or
such so that all new devs ack it.

I don't think we need to go nuts with it.  Simply getting everybody to
ack the policy makes it unambiguous that people understand what the
header means.

But, new policy or not the DCO really represents a practice that we
should all be doing already.  Nobody should be sticking code in a
Gentoo repository without ensuring the licenses are compatible and so
on.  The DCO just represents a best practice that didn't exist when
Gentoo started and which most projects now embrace in some form.  It
isn't that we didn't care about copyright in the past, we just care
enough to be a little more formal about it in the future.

> But this doesn't change the fact there is a desire to communicate other
> properties of commits, like the audit trail for QA purposes.

Sure.  The repository should always make it clear who made each
commit, when, and why (with appropriate bug x-refs and so on).
Ideally it should somehow capture both who authored the code and who
put it into the repository.  I think for the most part we're already
doing all of this, but I'm sure there is room for improvement (having
a bug header in the default repoman commit template probably wouldn't
hurt - then they all look the same and you can always delete it or
leave it blank if it doesn't apply).

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Kristian Fiskerstrand]

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

On 10/26/2016 04:02 AM, Rich Freeman wrote:
> I did suggest that we probably should ban this header until we
> actually have a DCO because it blurs the lines.  However, it isn't

Makes sense, at least strongly discourage, although it likely isn't too
difficult to do a full ban on git push

> really inferring something that isn't true right now because we don't
> assign any legal meaning to the header right now.  The bigger concern
> is that it blurs the lines after we have a DCO because people can
> argue the use of the header was accidental or meant something else.

This comes back to the next part, and instituting a clear timeline

> 
> Whether or not we proactively ban the header, it would probably make
> sense that if we do institute a new copyright policy including a DCO
> that we ask all devs to explicitly ack the policy and the meaning of
> the signed-off-by header somehow (maybe issue a gpg signed statement
> from a template).  It could also be made a part of the ebuild quiz or
> such so that all new devs ack it.

Exactly (although I'm pleading for people to stop talking about "gpg
signed".. thats nonsense :) OpenPGP ftw)

> 
> I don't think we need to go nuts with it.  Simply getting everybody to
> ack the policy makes it unambiguous that people understand what the
> header means.

+1
> 
> But, new policy or not the DCO really represents a practice that we
> should all be doing already.  Nobody should be sticking code in a
> Gentoo repository without ensuring the licenses are compatible and so
> on.  The DCO just represents a best practice that didn't exist when
> Gentoo started and which most projects now embrace in some form.  It
> isn't that we didn't care about copyright in the past, we just care
> enough to be a little more formal about it in the future.
> 

+1

>> > But this doesn't change the fact there is a desire to communicate other
>> > properties of commits, like the audit trail for QA purposes.
> Sure.  The repository should always make it clear who made each
> commit, when, and why (with appropriate bug x-refs and so on).
> Ideally it should somehow capture both who authored the code and who
> put it into the repository.  I think for the most part we're already
> doing all of this, but I'm sure there is room for improvement (having
> a bug header in the default repoman commit template probably wouldn't
> hurt - then they all look the same and you can always delete it or
> leave it blank if it doesn't apply).

Quality of commit messages certainly leaves something to be desired from
time to time, and actually having said trail of discussion on bugs.g.o

-- 
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: 455 bytes --]

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Greg KH]

On Sat, Oct 22, 2016 at 06:47:04PM +0200, Ulrich Mueller wrote:
> >>>>> On Sat, 22 Oct 2016, Greg KH wrote:
> 
> > On Wed, Oct 19, 2016 at 09:19:36AM -0400, Rich Freeman wrote:
> >> This is from the last policy draft:
> >> https://dev.gentoo.org/~rich0/copyrightpolicy.xml
> 
> > Why redraft the already-useful DCO that is out there for you to use
> > as-is:
> > 	http://developercertificate.org/
> 
> > As you copied the text, be sure to give proper reference to who owns
> > the copyright of that text please, you just can't rename it and
> > claim it as your own :)
> 
> In fact, Rich *does* give credit to Linux:
> "The DCO is based on the
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches
> Linux Kernel DCO"

Credit is nice, but you have to remember copyright issues :)

> Also, I wouldn't completely exclude that we need to change the wording
> at some later point. Therefore, we may indeed consider taking the DCO
> from the Linux source tree which is distributed under the GPL-2,
> instead of the non-free version ("changing it is not allowed") from
> developercertificate.org. Their wording is identical except for the
> preamble.

You can't change the text of a license and call it the same thing, which
is why that wording is there (same wording is in the GPL), so don't
think that by pointing at the one in the kernel source tree that changes
anything...

And I would _strongly_ not recomment changing the wording without
consulting with a license lawyer, you can mess things up really quickly
by changing stuff.

Again, just point to the one we have, use the web site (which better not
go away), and copy it locally if you feel it somehow will.

thanks,

greg k-h

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Thu, Oct 27, 2016 at 9:29 AM, Greg KH <gregkh@gentoo.org> wrote:
>
> You can't change the text of a license and call it the same thing,

So is the objection mainly to calling it a "Developer Certificate of Origin?"

I'd think that the title of a legal document falls more under
trademark law than copyright law.  That is why the FSF publishes the
"GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC
LICENSE."  The former has far more trademark protection than the
latter.

> which
> is why that wording is there (same wording is in the GPL), so don't
> think that by pointing at the one in the kernel source tree that changes
> anything...

The Linux Foundation published a version of their DCO under the GPL,
which we would of course abide by.  The fact that they published it
elsewhere with a different license doesn't mean that we can't re-use
the version published under the GPL.

If the FSF published the GPL under the GPL then people would be free
to redistribute modified versions of it as well.  I don't think they
would disagree with that.

> And I would _strongly_ not recomment changing the wording without
> consulting with a license lawyer, you can mess things up really quickly
> by changing stuff.

No argument there.  I don't think we're actually changing anything at
the moment.

If we aren't changing anything that does raise the question of why not
just use the Linux DCO, v1.1 or whatever it is at, incorporated by
reference.  I do think we have the legal right to fork it since it was
effectively published by the Linux Foundation under the GPL, but that
doesn't require us to fork it.

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Matthias Maier]

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

> Therefore, we may indeed consider taking the DCO from the Linux source
> tree which is distributed under the GPL-2

I highly doubt that the DCO in the readme is licensed under GPL-2. There
is no readme/header, or other indicator stating this. Not everything in
the linux repository falls under GPL-2.

Thus, we simply blatantly violate the distribution terms:

  »Everyone is permitted to copy and distribute verbatim copies of this
  license document, but changing it is not allowed.«



Best,
Matthias

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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Ulrich Mueller]

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

>>>>> On Thu, 27 Oct 2016, Greg KH wrote:

>> Also, I wouldn't completely exclude that we need to change the
>> wording at some later point. Therefore, we may indeed consider
>> taking the DCO from the Linux source tree which is distributed
>> under the GPL-2, instead of the non-free version ("changing it is
>> not allowed") from developercertificate.org. Their wording is
>> identical except for the preamble.

> You can't change the text of a license and call it the same thing,
> which is why that wording is there (same wording is in the GPL), so
> don't think that by pointing at the one in the kernel source tree
> that changes anything...

Sure, the text shouldn't be changed without changing the name. I guess
that's common sense, because otherwise it would be confusing.

> And I would _strongly_ not recomment changing the wording without
> consulting with a license lawyer, you can mess things up really
> quickly by changing stuff.

So the DCO was devised by a license lawyer? TBH, I find it less than
optimal. It is an enumeration with all its items at equal level, but
its meaning is "I certify ((a || b || c) && d)". That is, structure
doesn't follow contents there, and at first glance the "or" (or its
absence) at the end of each item can be easily missed.

Ulrich

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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Greg KH]

On Thu, Oct 27, 2016 at 10:11:45AM -0400, Rich Freeman wrote:
> On Thu, Oct 27, 2016 at 9:29 AM, Greg KH <gregkh@gentoo.org> wrote:
> >
> > You can't change the text of a license and call it the same thing,
> 
> So is the objection mainly to calling it a "Developer Certificate of Origin?"

That's one objection of mine, yes.  The other being you can't just take
almost all of the original text and still call it the same thing, when
it obviously isn't, and the document says you can't do that :)

> I'd think that the title of a legal document falls more under
> trademark law than copyright law.  That is why the FSF publishes the
> "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC
> LICENSE."  The former has far more trademark protection than the
> latter.

Do you see that term trademarked anywhere?  I will go file for one if
you really insist on it, but really, think this through please.

> > which
> > is why that wording is there (same wording is in the GPL), so don't
> > think that by pointing at the one in the kernel source tree that changes
> > anything...
> 
> The Linux Foundation published a version of their DCO under the GPL,
> which we would of course abide by.  The fact that they published it
> elsewhere with a different license doesn't mean that we can't re-use
> the version published under the GPL.

How well does "plain text" work under the GPL?  Go on, I've been down
that path before, it's well-worn, we'll be here when you get back... :)

> If we aren't changing anything that does raise the question of why not
> just use the Linux DCO, v1.1 or whatever it is at, incorporated by
> reference.  I do think we have the legal right to fork it since it was
> effectively published by the Linux Foundation under the GPL, but that
> doesn't require us to fork it.

Please just use the one as-published.

thanks,

greg k-h

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Greg KH]

On Thu, Oct 27, 2016 at 04:41:37PM +0200, Ulrich Mueller wrote:
> >>>>> On Thu, 27 Oct 2016, Greg KH wrote:
> 
> >> Also, I wouldn't completely exclude that we need to change the
> >> wording at some later point. Therefore, we may indeed consider
> >> taking the DCO from the Linux source tree which is distributed
> >> under the GPL-2, instead of the non-free version ("changing it is
> >> not allowed") from developercertificate.org. Their wording is
> >> identical except for the preamble.
> 
> > You can't change the text of a license and call it the same thing,
> > which is why that wording is there (same wording is in the GPL), so
> > don't think that by pointing at the one in the kernel source tree
> > that changes anything...
> 
> Sure, the text shouldn't be changed without changing the name. I guess
> that's common sense, because otherwise it would be confusing.
> 
> > And I would _strongly_ not recomment changing the wording without
> > consulting with a license lawyer, you can mess things up really
> > quickly by changing stuff.
> 
> So the DCO was devised by a license lawyer?

It was created with one, but that was not the only contributor of it.

> TBH, I find it less than optimal. It is an enumeration with all its
> items at equal level, but its meaning is "I certify ((a || b || c) &&
> d)". That is, structure doesn't follow contents there, and at first
> glance the "or" (or its absence) at the end of each item can be easily
> missed.

See, you have to be careful and read the whole thing, words can be
tricky :)

good luck!

greg k-h

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Matthias Maier]

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


On Thu, Oct 27, 2016, at 09:11 CDT, Rich Freeman <rich0@gentoo.org> wrote:

> I'd think that the title of a legal document falls more under
> trademark law than copyright law.  That is why the FSF publishes the
> "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC
> LICENSE."  The former has far more trademark protection than the
> latter.

What?

No, this is *not* how it works.

A license text is an original piece of work that falls under copyright
protection. In this case the copyright holder is the

  »The Linux Foundation and its contributors«.

The terms of distribution are

  »Everyone is permitted to copy and distribute verbatim copies of this
  license document, but changing it is not allowed.«



You cannot simply copy a substantial amount of text into your work (no
matter what it is) if you do not have the right to do so.



> The Linux Foundation published a version of their DCO under the GPL,
> which we would of course abide by.

I highly doubt that, see my previous e-mail.

Best,
Matthias

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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Thu, Oct 27, 2016 at 10:55 AM, Greg KH <gregkh@gentoo.org> wrote:
> On Thu, Oct 27, 2016 at 10:11:45AM -0400, Rich Freeman wrote:
>> On Thu, Oct 27, 2016 at 9:29 AM, Greg KH <gregkh@gentoo.org> wrote:
>> >
>> > You can't change the text of a license and call it the same thing,
>>
>> I'd think that the title of a legal document falls more under
>> trademark law than copyright law.  That is why the FSF publishes the
>> "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC
>> LICENSE."  The former has far more trademark protection than the
>> latter.
>
> Do you see that term trademarked anywhere?  I will go file for one if
> you really insist on it, but really, think this through please.

The term "GNU" is trademarked as far as I'm aware.  Or, if not it
would probably be trademarkable in this context, since it is fairly
unique.  The term "General Public License" seems rather, well,
general.

When your title for something is generic it is generally very
difficult to enforce a trademark against it.

If you called it the "Linux DCO" then you'd probably have a strong
recourse against anybody also using the term "Linux DCO" since Linux
is a strong mark (it is a word that Linus invented as far as I'm
aware).

Look at Microsoft's attempts to enforce trademarks against "windows"
for an example of why generic words don't make good marks.

>
>> > which
>> > is why that wording is there (same wording is in the GPL), so don't
>> > think that by pointing at the one in the kernel source tree that changes
>> > anything...
>>
>> The Linux Foundation published a version of their DCO under the GPL,
>> which we would of course abide by.  The fact that they published it
>> elsewhere with a different license doesn't mean that we can't re-use
>> the version published under the GPL.
>
> How well does "plain text" work under the GPL?  Go on, I've been down
> that path before, it's well-worn, we'll be here when you get back... :)

Well, whether the GPL is a good license for text is a separate matter,
but it is a license.

>
>> If we aren't changing anything that does raise the question of why not
>> just use the Linux DCO, v1.1 or whatever it is at, incorporated by
>> reference.  I do think we have the legal right to fork it since it was
>> effectively published by the Linux Foundation under the GPL, but that
>> doesn't require us to fork it.
>
> Please just use the one as-published.
>

Seems like a logical approach.

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Thu, Oct 27, 2016 at 11:02 AM, Matthias Maier <tamiko@gentoo.org> wrote:
>
> On Thu, Oct 27, 2016, at 09:11 CDT, Rich Freeman <rich0@gentoo.org> wrote:
>
>> I'd think that the title of a legal document falls more under
>> trademark law than copyright law.  That is why the FSF publishes the
>> "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC
>> LICENSE."  The former has far more trademark protection than the
>> latter.
>
> What?
>
> No, this is *not* how it works.
>
> A license text is an original piece of work that falls under copyright
> protection.

We're not talking about the text of the license in the paragraph
above.  We're talking about the title of the license.

> In this case the copyright holder is the
>
>   »The Linux Foundation and its contributors«.

Well, there is no statement of copyright in this file:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches

But, I don't dispute that the Linux Foundation and its contributors
hold the copyright.

>
> The terms of distribution are
>
>   »Everyone is permitted to copy and distribute verbatim copies of this
>   license document, but changing it is not allowed.«
>

That text does not appear anywhere in the file I linked.

The GPL does, however.

>
> You cannot simply copy a substantial amount of text into your work (no
> matter what it is) if you do not have the right to do so.
>

I agree.  I certainly wouldn't do it if the Linux Foundation hadn't
published it under the GPL.

>> The Linux Foundation published a version of their DCO under the GPL,
>> which we would of course abide by.
>
> I highly doubt that, see my previous e-mail.
>

I just linked it, and it was linked in the draft policy.

The fact that they published it elsewhere under a different license
just means that it is effectively dual-licensed.  It doesn't diminish
any rights conferred under the GPL.

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Ulrich Mueller]

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

>>>>> On Thu, 27 Oct 2016, Matthias Maier wrote:

>> Therefore, we may indeed consider taking the DCO from the Linux source
>> tree which is distributed under the GPL-2

> I highly doubt that the DCO in the readme is licensed under GPL-2. There
> is no readme/header, or other indicator stating this. Not everything in
> the linux repository falls under GPL-2.

Few of the files in the Documentation subdir have a license header.
It is also missing from various other files (top-level Makefile, for
example). Following your reasoning, we would not be permitted to
distribute kernel tarballs.

So, should we add mirror restriction to sys-kernel/*-sources then?
I very much doubt that this is the intention of upstream. I'd rather
conclude that they are a bit lax with their headers (as compared to
the FSF, for example).

Also, in COPYING in the top-level dir there is this:

   Also note that the GPL below is copyrighted by the Free Software
   Foundation, but *the instance of code that it refers to (the Linux
   kernel)* is copyrighted by me and others who actually wrote it.

   Also note that the only valid version of the GPL as far as the kernel
   is concerned is _this_ particular version of the license (ie v2, not
   v2.2 or v3.x or whatever), unless explicitly otherwise stated.

   [*...* my emphasis, _..._ author's emphasis]

I would conclude that the intention is that the whole of the Linux
kernel can be distributed under the GPL, version 2, unless noted
otherwise.

Ulrich

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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Thu, Oct 27, 2016 at 11:21 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> I would conclude that the intention is that the whole of the Linux
> kernel can be distributed under the GPL, version 2, unless noted
> otherwise.
>

Stepping back, I'd just like to comment that while I hold an opinion
on this that is likely different from gregkh, and possibly the Linux
Foundation, I suspect this is going to be moot since as far as I can
tell we aren't modifying the DCO and don't really think we need to.
So, it is probably simpler to avoid controversy by just incorporating
it by reference under their original name, which is certainly the
intention of the Linux Foundation in promoting it.

I think it is an interesting discussion/debate as to whether the Linux
Foundation has or hasn't effectively released the DCO under the GPL
with no further restrictions.  However, I don't think it ultimately is
going to drive what we do.  So, we can just have our private opinions
here, and I do get Greg's arguments (and I acknowledge that he is a
bit of an expert in this space).

I'll just note that tempest in a teapot actually drives home the
importance of explicit copyright and license notices, since it is the
absence of any such notice in this file that is in part driving this
controversy.  Some of the potential ambiguities with our own current
policy could create similar issues, and they have in fact gotten
people upset when code was brought into a Gentoo repository without a
good policy on how to handle the copyright notices.

Authorship and ownership matter to people.  A good copyright policy is
about respecting the rights of others as much as preserving our own.

(And, as always, everything above is just my personal opinion...)

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Matthias Maier]

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


> So, it is probably simpler to avoid controversy by just incorporating
> it by reference under their original name, which is certainly the
> intention of the Linux Foundation in promoting it.

+1

:-)

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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Daniel Campbell]

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

On 10/27/2016 08:31 AM, Rich Freeman wrote:
> On Thu, Oct 27, 2016 at 11:21 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>
>> I would conclude that the intention is that the whole of the Linux
>> kernel can be distributed under the GPL, version 2, unless noted
>> otherwise.
>>
> 
> Stepping back, I'd just like to comment that while I hold an opinion
> on this that is likely different from gregkh, and possibly the Linux
> Foundation, I suspect this is going to be moot since as far as I can
> tell we aren't modifying the DCO and don't really think we need to.
> So, it is probably simpler to avoid controversy by just incorporating
> it by reference under their original name, which is certainly the
> intention of the Linux Foundation in promoting it.
> 
> I think it is an interesting discussion/debate as to whether the Linux
> Foundation has or hasn't effectively released the DCO under the GPL
> with no further restrictions.  However, I don't think it ultimately is
> going to drive what we do.  So, we can just have our private opinions
> here, and I do get Greg's arguments (and I acknowledge that he is a
> bit of an expert in this space).
> 
> I'll just note that tempest in a teapot actually drives home the
> importance of explicit copyright and license notices, since it is the
> absence of any such notice in this file that is in part driving this
> controversy.  Some of the potential ambiguities with our own current
> policy could create similar issues, and they have in fact gotten
> people upset when code was brought into a Gentoo repository without a
> good policy on how to handle the copyright notices.
> 
> Authorship and ownership matter to people.  A good copyright policy is
> about respecting the rights of others as much as preserving our own.
> 
> (And, as always, everything above is just my personal opinion...)
> 
Forgive me, but I don't see why people have so much trouble with
copyright wrt Gentoo. I've simply assumed anything I wrote for Gentoo
would be attributed to me via git log information and/or metadata.xml
and should I leave Gentoo, Gentoo keeps the rights to it since I'm
contributing to it. Nothing stops me from pushing ebuilds to my personal
overlay *and* the primary Gentoo tree.

With a DCO, it greatly complicates things. Would my right to keep my
contributions in an overlay be infringed upon? What would change if we
switch to this?

It's just odd to me that in one case (the comrel deal) we're aiming to
simplify, but with copyright we're seemingly complicating things for --
through my perspective -- little gain.

Is anyone at Gentoo actually concerned about the copyright of their ebuilds?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


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

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Rich Freeman]

On Thu, Oct 27, 2016 at 8:08 PM, Daniel Campbell <zlg@gentoo.org> wrote:
>
> With a DCO, it greatly complicates things. Would my right to keep my
> contributions in an overlay be infringed upon? What would change if we
> switch to this?
>

The DCO doesn't change your rights at all, or change the status of the
copyright.  It is simply a declaration that the code is
redistributable under the appropriate license.  While we don't have a
DCO in place currently, it is already policy that devs are supposed to
check the license.

The FLA does change the status of the copyright/licensing situation.
However, this will be voluntary, so if it concerns anybody they simply
can choose to sign it.  However, under the FLA if you do assign
copyright to Gentoo then in accordance with the agreement Gentoo will
give you the right to redistribute your code in perpetuity without
restriction (if I'm reading it correctly).  Essentially you'd be
giving Gentoo the right to re-license the code under another FOSS
license or pursue copyright claims, but you still will be able to do
most of the things you could do if you had retained copyright.

Both practices are actually very standard in the FOSS world.  The DCO
is used by Linux and numerous other projects and is generally
considered a best practice for any project.  The FLA is less commonly
used, but I know that KDE uses it.  It is probably more common in
community products especially in Europe, since it is designed to
handle the German case.  I'd say that a CLA is a more common practice,
especially in projects that are dual-licensed with a commercial
backer.  The CLA is a much stronger transfer of the rights of the
contributor to the project and usually gives the project a blank check
to do whatever they want with the code, such as making it exclusively
closed-source in the future.  This is obviously desirable to
corporate-backed projects as it gives them more options to extract
money from the code.

The DCO basically is an extra assurance that our copyrights are sound.
The FLA is a way to give Gentoo more options for relicensing code and
such, but in a way that is more compatible with our social contract
and which probably also makes us a less attractive hostile takeover
target (since the FLA would limit the sorts of bad things somebody
could do with our copyrights if they managed to seize them).

Honestly, I think the policy actually does simplify things for the
most part by making a lot of things explicit where currently they are
vague and where a variety of opinions prevail.  However,
simplification was never really the main goal of the policy.  It is
more about not getting sued and being more flexible the next time
somebody decides to fork something like udev without starting a
fiasco.

Since she hasn't promoted it herself, I'll point out that alicef has
wikified the policy here:
https://wiki.gentoo.org/wiki/User:Aliceinwire/CopyrightPolicy

I'll go ahead and make some of the tweaks mentioned in the thread, and
maybe try to improve the attribution overhead which I think is the
only real downside.  I think if it were implemented the contents of
that page would probably be split up a bit as it combines very static
information (the policy) with things like the table of licenses which
obviously will be updated frequently.

-- 
Rich

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Greg KH]

On Thu, Oct 27, 2016 at 05:08:13PM -0700, Daniel Campbell wrote:
> Forgive me, but I don't see why people have so much trouble with
> copyright wrt Gentoo. I've simply assumed anything I wrote for Gentoo
> would be attributed to me via git log information and/or metadata.xml
> and should I leave Gentoo, Gentoo keeps the rights to it since I'm
> contributing to it. Nothing stops me from pushing ebuilds to my personal
> overlay *and* the primary Gentoo tree.

Note, lots of people (i.e. almost anyone who is employed in the US), are
in the situation where the copyright ownership of your contributions are
not owned by yourself, so you can not give the copyright away to the
Gentoo Foundation without an explicit legal document from that owner
granting that copyright transfer (or additional ownership.)

So this is a real issue, and a problem, for many of our developers
(myself included), which is why many many years ago some of us worked to
get that copyright ownership document removed.

> With a DCO, it greatly complicates things. Would my right to keep my
> contributions in an overlay be infringed upon? What would change if we
> switch to this?

Nothing, it just explicitly calls out that you know the contribution you
are making is allowed and under the license of the file/project you are
contributing to.  It does not change the ownership of the copyright of
the contribution at all.  It's a very simple document, I think I've
written more words in this email than the whole document has, I suggest
reading it for all of the details.

thanks,

greg k-h