The ebuild has this header: # Copyright 1999-2018 Gentoo Authors # Copyright 2018 Sony Interactive Entertainment Inc. # Distributed under the terms of the GNU General Public License v2 By GLEP 76, the copyright notice reads either: Copyright YEARS MAIN-CONTRIBUTOR [OTHER-CONTRIBUTOR]... [and others] or: Copyright YEARS Gentoo Authors Combining both doesn't comply with the GLEP. It is also nonsensical, because the only purpose of using the simplified attribution is to avoid listing more than one entity. So please, change the notice to a single line with "Gentoo Authors" (which is strongly preferred by tree policy). Alternatively, if you use the long form, then figure out which contributor holds copyright to the largest portion of the file, and list that main contributor "and others".
The GLEP does not require a single line, the multi line format is easier to read. I can change it to this if really preferred, but it is rather long and unwieldy. I am required to explicitly list Sony in any ebuild that I do a copyright-able amount of work on work time, so I can change the single line to look like like below, if preferred: # Copyright 1999-2018 Gentoo Authors, Sony Interactive Entertainment Inc. Unfortunately, I cannot simply drop Sony from the copyright. There are multiple copyright holders on this file, most of the copyright owners accept the generic "Gentoo Authors", but one of the owners requires an explicit notice.
(In reply to Patrick McLean from comment #1) > I am required to explicitly list Sony in any ebuild that I do a > copyright-able amount of work on work time, so I can change the single line > to look like like below, if preferred: > > # Copyright 1999-2018 Gentoo Authors, Sony Interactive Entertainment Inc. That won't comply with the policy either. If Sony holds copyright to the largest portion of the file, then the attribution can read: # Copyright 1999-2018 Sony Interactive Entertainment Inc. and others However, if someone else is the main copyright holder, then Sony would be subsumed under "and others". Or the simplified attribution would be used, which is preferred anyway. > Unfortunately, I cannot simply drop Sony from the copyright. There are > multiple copyright holders on this file, most of the copyright owners > accept the generic "Gentoo Authors", but one of the owners requires > an explicit notice. As I said, if you list "Gentoo Authors" then this will cover _all_ copyright holders (natural person or other entity). It would be quite unfair to the main contributor to omit their name, but OTOH explicitly list another (possibly minor) contributor.
Sony is not the main copyright holder on this file, but it does hold the copyright on portions of it. Policy at Sony dictates that we cannot use "and others" or the generic "Gentoo Authors" for this case, any file that contains a non-insignificant contribution must have an explicit copyright.
(In reply to Patrick McLean from comment #3) > Sony is not the main copyright holder on this file, but it does hold the > copyright on portions of it. I don't challenge that. > Policy at Sony dictates that we cannot use "and others" or the generic > "Gentoo Authors" for this case, any file that contains a non-insignificant > contribution must have an explicit copyright. No problem with that either (though I think that it is an unfortunate policy which makes things needlessly complicated). The problematic part is mixing of the generic "Gentoo Authors" with an explicit list, because it could misrepresent the authorship of the file. With "Gentoo Authors" alone it is clear that e.g. git history must be consulted, in order to determine the authors. However, this becomes much less clear when some entity (which is not the main contributor) is explicitly listed in addition. Personally, I think that something like the following might be acceptable: # Copyright 1999-2018 MAIN CONTRIBUTOR and others # Copyright 2018 Sony Interactive Entertainment Inc. CCing council, maybe we can discuss this in the upcoming meeting.
The format of "(X & Others)\n(Y)" DOES occur in the kernel & chromium sources, so I'd be inclined to accept it.
If we are going to do this, why not just change our policy to allow multiple copyright lines? # Copyright (c)<years> Gentoo Authors # copyright (c) <years> Sony Interactive Entertainment, Inc. That would eliminate arguments about who the main contributor is.
(In reply to William Hubbs from comment #6) > If we are going to do this, why not just change our policy to allow > multiple copyright lines? > > # Copyright (c)<years> Gentoo Authors > # copyright (c) <years> Sony Interactive Entertainment, Inc. > > That would eliminate arguments about who the main contributor is. How many lines should we allow in such a scenario? To make an argumentum ad absurdium; what will we do when the number of copyright lines is higher than the number of actual lines of code in the ebuild content?
(In reply to Kristian Fiskerstrand from comment #7) > (In reply to William Hubbs from comment #6) > > If we are going to do this, why not just change our policy to allow > > multiple copyright lines? > > > > # Copyright (c)<years> Gentoo Authors > > # copyright (c) <years> Sony Interactive Entertainment, Inc. > > > > That would eliminate arguments about who the main contributor is. > > How many lines should we allow in such a scenario? To make an argumentum ad > absurdium; what will we do when the number of copyright lines is higher than > the number of actual lines of code in the ebuild content? That is highly unlikely, and I'm not convinced it matters. The important things are the license we use and the right to redistribute. I feel that it is in our best interest to be as flexable as possible about copyright headers to allow the largest number of contributors. Take a look at the kernel source; it has multiple copyright holders and no one seems to mind. I don't even think all of the kernel source files are copyright Linus Torvalds or the Linux Foundation.
I don't mind having multiple copyright lines, so long as we can still have Gentoo Authors at the top for automatic updates by repoman. I assume the other lines could be updated manually by the respective copyright holders if/when they make changes.
(In reply to William Hubbs from comment #8) > That is highly unlikely, and I'm not convinced it matters. The important > things are the license we use and the right to redistribute. Exactly. So why do you care so much about sticking a specific line in there, instead of going with "Gentoo Authors" like everyone else? I am really surprised that previously everyone was fine with "Gentoo Foundation", but suddenly some entities cannot go with "Gentoo Authors" which is way more correct than what we had previously. And so far, you haven't even bothered to tell us what is the reason for that.
(In reply to Ulrich Müller from comment #10) > (In reply to William Hubbs from comment #8) > > That is highly unlikely, and I'm not convinced it matters. The important > > things are the license we use and the right to redistribute. > > Exactly. So why do you care so much about sticking a specific line in there, > instead of going with "Gentoo Authors" like everyone else? > > I am really surprised that previously everyone was fine with "Gentoo > Foundation", but suddenly some entities cannot go with "Gentoo Authors" > which is way more correct than what we had previously. And so far, you > haven't even bothered to tell us what is the reason for that. Essentially Sony wants public credit for work it pays for, which most other projects do. The vast majority of FOSS projects that I have checked out (selection bias aside) list multiple authors on individual lines, not on one. Of course, some projects require copyright assignment, but Gentoo does not. I'd argue that if we're going to require _only_ Gentoo Authors, then that implies a copyright assignment. Is an extra copyright line really worth locking out (several) contributors over? I have yet to hear an argument about the harm from some a minor amount of extra text.
Also, if you're going to a stickler: app-i18n/fcitx dev-db/sqlite net-irc/kvirc net-libs/serf sys-kernel/ck-sources all have copyrights that are not 'Gentoo Authors' (or Sony).
(In reply to Austin English from comment #11) > Essentially Sony wants public credit for work it pays for, which most other > projects do. The copyright notice has nothing to do with credit. The intention of the policy is that we can be lazy and put a single line with "Gentoo Authors". And the assumption was that this would work because previously everyone was fine with "Gentoo Foundation". If the simplified attribution is not acceptable, then pretty please do a full copyright audit and mention the main contributor. Explicitly listing a minor contributor but subsuming others all (including the main contributor) under "Gentoo Authors" is a misrepresentation of the work's copyright, IMHO. (In reply to Austin English from comment #12) > Also, if you're going to a stickler: > app-i18n/fcitx > dev-db/sqlite > net-irc/kvirc > net-libs/serf > sys-kernel/ck-sources > > all have copyrights that are not 'Gentoo Authors' (or Sony). AFAICS, all of these are in agreement with the policy, because the person listed is the main contributor.
Anyway, looks like the tree policy that the council decided upon in the October meeting is too complicated. I therefore ask the council to vote on the following motion: The simplified form of the copyright attribution according to GLEP 76 [1], i.e., "Copyright YEARS Gentoo Authors", must be used for ebuilds and profile files in the Gentoo repository. [1] https://www.gentoo.org/glep/glep-0076.html#simplified-attribution
(In reply to Ulrich Müller from comment #10) > (In reply to William Hubbs from comment #8) > > That is highly unlikely, and I'm not convinced it matters. The important > > things are the license we use and the right to redistribute. > > Exactly. So why do you care so much about sticking a specific line in there, > instead of going with "Gentoo Authors" like everyone else? > > I am really surprised that previously everyone was fine with "Gentoo > Foundation", but suddenly some entities cannot go with "Gentoo Authors" > which is way more correct than what we had previously. And so far, you > haven't even bothered to tell us what is the reason for that. The answer to this is very simple. Sony legal mandates it for any new copyrightable work we do on work time. Also, if we are going to talk about policy, we allowed a bit of flexability anyway for employment situations like this as discussed in the meeting log.
(In reply to Ulrich Müller from comment #14) It seems like you're the one making it overly complex. I don't see the problem with allowing both "Gentoo Authors" and individuals/organizations to appear on multiple lines.
(In reply to Mike Gilbert from comment #16) > It seems like you're the one making it overly complex. Great that you're telling me that. :( We have spent quite some time and effort to come up with a policy that is very simple to use, because ebuild developers need not think about what names they should list in the copyright notice. In comparison, look at what we had in an earlier iteration of GLEP 76 (which indeed was "overly complex", IMHO): https://gitweb.gentoo.org/data/glep.git/tree/glep-0076.rst?id=8cc0b8dbed310155eab9b71864b2f419485d54b1#n135 Now that we have a simple policy, some people (who were happy with "Gentoo Foundation" before) come along and claim that they're special and need an exception from the policy, thereby putting additional maintenance burden on other developers (because e.g. automated tools won't work with complex copyright notices). I am not happy at all about that. Anyway, in comment #4 I had suggested what I think could be a compromise, namely adding the main contributor to the list.
The "Gentoo Authors" is meant to be a catch-all for entities who don't care if they are listed explicitly, the GLEP does also say that other entities can be listed. If a contributor cares that their copyright appears in the file, they they add it explicitly, otherwise it falls under the "Gentoo Authors" catch-all. If an entity that cares about explicit listing adds a non-trivial change, they can add their copyright to the list (even if it's just a separate line after "Gentoo Authors"). Are you saying that anyone that wants to add a copyright to the list should go through the history and add everyone who ever contributed, but didn't care enough to add their name? Or are you saying that now everything _must_ be "Gentoo Authors", if so that is a change of policy and there should be time (say at least 3 months) for people to authorize the new policy with their employer's legal department. If a copyright owner wants their contribution listed explicitly (as is done in tens of thousands of places throughout the Linux kernel, and I can point out at least a couple of instances in Chromium) they why is it a problem to allow it? Are you concerned about the performance of processing a few lines of comments at the top of the file (processing a single character and moving to the next line)? Are you concerned about the space consumption (that would kind of run counter to the policy of unconditionally installing small files such as logrotate snippets and systemd units unconditionally).
(In reply to Ulrich Müller from comment #17) > > Anyway, in comment #4 I had suggested what I think could be a compromise, > namely adding the main contributor to the list. The main contributor is not the only contributor, why should other contributors be left out because their contribution was smaller? If the main contributor wants to be listed, then they can list themselves, I don't see how anyone is preventing that. If you want to list yourself in ebuilds that you are the main contributor to, they go for it. If Sony (or anyone else who cares) adds a nontrivial contribution, they then can add more lines. If the main contributor doesn't care if their name is there or not, they can put "Gentoo Authors" as a placeholder. The "Gentoo Authors" is just a catch all for other entities that contributed without needing to be listed explicitly.
(In reply to Ulrich Müller from comment #17) > (In reply to Mike Gilbert from comment #16) > > It seems like you're the one making it overly complex. > > Now that we have a simple policy, some people (who were happy with "Gentoo > Foundation" before) come along and claim that they're special and need an > exception from the policy, thereby putting additional maintenance burden on > other developers (because e.g. automated tools won't work with complex > copyright notices). I am not happy at all about that. > How are a few lines of comment at the top of a file a maintenance burden? Most of the time a developer working on the ebuild can simply ignore the copyright header, the only real change that is likely to be made is adding an extra line if desired or required. One could even write a plugin for their favourite editor that hides the copyright lines by default if you don't want to see them on your screen.
We've already wasted so much time discussing it, and I think we all know there's nothing that can be really done here. We can either live with explicit SIE copyright, or we can reject all contributions from their employees. If we go for allowing SIE copyright, it would be nice if developers were given a clear hint when they can remove SIE copyright, e.g. when bumping ebuilds. Say, A-1.ebuild did not have SIE copyright. SIE employee bumps it to A-2.ebuild with no changes and adds SIE copyright. Somebody else bumps it to A-3.ebuild -- should he remove SIE copyright? If we go for the latter, we should also consider whether SIE doesn't hold copyright to things they do outside work hours, especially given they'll be doing stuff very similar (if not identical) to what they need to do at work hours anyway. Either way, Gentoo will prevail. Worst case, there will be chaos for some time, then somebody else will step in to fill the void.
(In reply to Michał Górny from comment #21) > We've already wasted so much time discussing it, and I think we all know > there's nothing that can be really done here. We can either live with > explicit SIE copyright, or we can reject all contributions from their > employees. Thank you, that is probably a decent summary of the situation. I will add some clarifications below. > If we go for allowing SIE copyright, it would be nice if developers were > given a clear hint when they can remove SIE copyright, e.g. when bumping > ebuilds. Say, A-1.ebuild did not have SIE copyright. SIE employee bumps it > to A-2.ebuild with no changes and adds SIE copyright. Somebody else bumps > it to A-3.ebuild -- should he remove SIE copyright? The internal guidance SIE is using for Gentoo contributions states that employees should _not_ add a copyright to version bumps that are just a rename, or with only trivial fixes. The copyright only gets added with feature additions or bumps that require significant work. However, SIE employees _will_ add a copyright to what appears to be a trivial version bump if significant work was done to the same ebuild on SIE time before the policy change. > If we go for the latter, we should also consider whether SIE doesn't hold > copyright to things they do outside work hours, especially given they'll be > doing stuff very similar (if not identical) to what they need to do at work > hours anyway. SIE does _not_ hold any copyrights done on what employees do outside work hours, so employees generally should not add SIE copyrights to said work.
(In reply to Michał Górny from comment #21) > If we go for allowing SIE copyright, it would be nice if developers were > given a clear hint when they can remove SIE copyright, e.g. when bumping > ebuilds. I think it would be problematic to drop the line when SIE is the main contributor. In all other cases, it is a derivative work, and IIUC there is no need to completely attribute all minor contributions (otherwise "MAIN CONTRIBUTOR and others" of GLEP 76 would not work, in the first place). Specifically, section 1 of the GPL-2 only requires to "publish on each copy an appropriate copyright notice". > Say, A-1.ebuild did not have SIE copyright. SIE employee bumps it to > A-2.ebuild with no changes and adds SIE copyright. If there are no changes or only minor changes, then adding their copyright notice is a false copyright claim. > Somebody else bumps it to A-3.ebuild -- should he remove SIE copyright? Yes. But this is an example of what we tried to avoid with GLEP 76 and the associated tree policy. Developers should not be required to waste their time on doing copyright audits. Anyway, in the meantime I am convinced that allowing any exceptions was a mistake, and in comment #14 a motion to change that is on the table. If your employer has an unreasonable policy then please sort that out internally. Disclaimer: IANAL, TINLA.
(In reply to Patrick McLean from comment #18) > The "Gentoo Authors" is meant to be a catch-all for entities who don't care > if they are listed explicitly, the GLEP does also say that other entities > can be listed. If a contributor cares that their copyright appears in the > file, they they add it explicitly, otherwise it falls under the "Gentoo > Authors" catch-all. The problem is that "Some Contributor" along with "Gentoo Authors" is not so much different from "Some Contributor and others". So it misrepresents copyright of the file (unless it is the main contributor). > Are you saying that anyone that wants to add a copyright to the list should > go through the history and add everyone who ever contributed, but didn't > care enough to add their name? As I said before, as soon as there is any explicit copyright attribution, then at least the main contributor must be listed. And IMHO the burden to figure that out is on those who want to change the simplified notice to the explicit form of the notice. If you want to be lazy, then go with "Gentoo Authors" and be done. > Or are you saying that now everything _must_ be "Gentoo Authors", if so > that is a change of policy and there should be time (say at least 3 months) > for people to authorize the new policy with their employer's legal > department. I don't think that there would be opposition against a transition time.
(In reply to Ulrich Müller from comment #24) > (In reply to Patrick McLean from comment #18) > > The "Gentoo Authors" is meant to be a catch-all for entities who don't care > > if they are listed explicitly, the GLEP does also say that other entities > > can be listed. If a contributor cares that their copyright appears in the > > file, they they add it explicitly, otherwise it falls under the "Gentoo > > Authors" catch-all. > > The problem is that "Some Contributor" along with "Gentoo Authors" is not so > much different from "Some Contributor and others". So it misrepresents > copyright of the file (unless it is the main contributor). The general implication is that the first listed contributor is the main contributor, if that is "Gentoo Authors" and another contributor follows, that that suggests that the primary contributor is in the generic catch-all, and the latter lines are to specify that there are other contributors that also have copyrights in the code. I don't think that it is misrepresenting anything, IANAL, but YANAL either. I have certainly seen this pattern in projects where lawyers have been involved. Here are a few examples from the Linux kernel I found on some cursory poking around: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/dtc/util.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ide/ide-probe.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ide/ide-disk.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/jvmti/jvmti_agent.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/security/yama/yama_lsm.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/util/jitdump.h https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/oprofile/op_model_ppro.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/vgem/vgem_drv.h Chromium: https://github.com/chromium/chromium/blob/master/content/renderer/history_entry.cc I gave up after that. It seems like other rather successful open sources projects just add lines to existing copyright headers as other entities do work on them. It also seems that SIE is not alone in requiring headers to be added when work is done. > > > Are you saying that anyone that wants to add a copyright to the list should > > go through the history and add everyone who ever contributed, but didn't > > care enough to add their name? > > As I said before, as soon as there is any explicit copyright attribution, > then at least the main contributor must be listed. And IMHO the burden to > figure that out is on those who want to change the simplified notice to the > explicit form of the notice. That seems an undue burden (especially since many of the copyrights in Gentoo are from the pre-git era, and some are likely pre-cvs). If the original author really wants their name in there, then they should just put it there in the first place. There may even be some authors who don't want their names explicitly in the copyright. > If you want to be lazy, then go with "Gentoo Authors" and be done. Except I can't, my employer wants the copyright line in there. I don't see why this is so hard to understand. Please help me understand why exactly you are objecting to adding extra copyright lines when new entities do work, I really truly don't understand why adding copyright lines are such a major problem that you are willing to possibly lose paid work time of 8 very active developers over it (and possibly dissuade other companies and persons that might want to contribute). The signed-off-by in the commit should be enough, since that is certifying that the code can be distributed under the GPL.
Would you accept it if it was made clear SIE is not the primary copyright holder when adding the copyright to files that significant work is done on? Something like this, making it obvious they are not the primary holder: # Copyright YEARS Gentoo Authors # Portions Copyright YEARS Sony Interactive Entertainment Inc. Ebuilds where the primary copyright is held by SIE I suppose would look like this after someone else touches it (unless they add their own copyright): # Copyright YEARS Sony Interactive Entertainment Inc. # Portions Copyright YEARS Gentoo Authors
(In reply to Patrick McLean from comment #25) > The general implication is that the first listed contributor is the main > contributor, if that is "Gentoo Authors" and another contributor follows, > that that suggests that the primary contributor is in the generic catch-all, > and the latter lines are to specify that there are other contributors that > also have copyrights in the code. Sorry, but that's not what the policy says. Quoting GLEP 76 (emphasis is mine): | Simplified Attribution | ---------------------- | | *Alternatively,* projects are welcome to use a simplified form of the | copyright notice, which reads:: | | Copyright YEARS Gentoo Authors Or below, in the rationale: | 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". From the wording it is quite clear that is can be either a traditional notice or a simplified notice. It cannot be a combination of both. Sorry, but if you think that this policy is bad, then write your own replacement of GLEP 76 and get it approved. > > If you want to be lazy, then go with "Gentoo Authors" and be done. > > Except I can't, my employer wants the copyright line in there. I don't see > why this is so hard to understand. It is hard to understand because you (or your employer) so far hasn't given a reason why that additional line would be needed. It is not required by law, and in case of a copyright infringement, the presence of *any* notice is enough to protect against the "innocent infringement" defence. Beyond that, you would have to consult the git history in any case, in order to find out what each author's contribution is. That's all the more true if the ebuild is a derivative work where SIE isn't the main contributor. (In reply to Patrick McLean from comment #26) > Would you accept it if it was made clear SIE is not the primary copyright > holder when adding the copyright to files that significant work is done on? > > Something like this, making it obvious they are not the primary holder: > > # Copyright YEARS Gentoo Authors > # Portions Copyright YEARS Sony Interactive Entertainment Inc. See above, and also comment #4. > Ebuilds where the primary copyright is held by SIE I suppose would look like > this after someone else touches it (unless they add their own copyright): > > # Copyright YEARS Sony Interactive Entertainment Inc. > # Portions Copyright YEARS Gentoo Authors More likely, they would add "and others" to the line, and update the years if necessary: # Copyright YEARS Sony Interactive Entertainment Inc. and others
(In reply to Ulrich Müller from comment #27) > > > If you want to be lazy, then go with "Gentoo Authors" and be done. > > > > Except I can't, my employer wants the copyright line in there. I don't see > > why this is so hard to understand. > > It is hard to understand because you (or your employer) so far hasn't given > a reason why that additional line would be needed. It is not required by > law, and in case of a copyright infringement, the presence of *any* notice > is enough to protect against the "innocent infringement" defence. Beyond > that, you would have to consult the git history in any case, in order to > find out what each author's contribution is. That's all the more true if the > ebuild is a derivative work where SIE isn't the main contributor. They (the legal department) did not give a reason, they just stated it as a requirement. I don't think contributors are required to give a reason why they want a copyright notice in code they contribute, that is not a requirement I have ever heard of _any_ open source project having, and it would be a rather silly one if one wants to accept as many contributions as possible. > > > > Something like this, making it obvious they are not the primary holder: > > > > # Copyright YEARS Gentoo Authors > > # Portions Copyright YEARS Sony Interactive Entertainment Inc. > > See above, and also comment #4. > I reiterate that SIE wants us to add a copyright notice when we do significant work, I am not sure how to make it more clear. SIE is spending money to contribute fixes or feature additions, they want an explicit copyright notice added when the work is added. I don't see how this is either unreasonable or illegal.
(In reply to Patrick McLean from comment #28) > SIE is spending money to contribute fixes or feature additions, they want > an explicit copyright notice added when the work is added. I don't see how > this is either unreasonable or illegal. I don't understand this argument. Are you implying that paid work is more valuable than the work of volunteers?
(In reply to Patrick McLean from comment #22) > (In reply to Michał Górny from comment #21) > > We've already wasted so much time discussing it, and I think we all know > > there's nothing that can be really done here. We can either live with > > explicit SIE copyright, or we can reject all contributions from their > > employees. > > Thank you, that is probably a decent summary of the situation. I will add > some clarifications below. > > > If we go for allowing SIE copyright, it would be nice if developers were > > given a clear hint when they can remove SIE copyright, e.g. when bumping > > ebuilds. Say, A-1.ebuild did not have SIE copyright. SIE employee bumps it > > to A-2.ebuild with no changes and adds SIE copyright. Somebody else bumps > > it to A-3.ebuild -- should he remove SIE copyright? > > The internal guidance SIE is using for Gentoo contributions states that > employees should _not_ add a copyright to version bumps that are just a > rename, or with only trivial fixes. The copyright only gets added with > feature additions or bumps that require significant work. 1) Can you please explain sys-cluster/ceph-12.2.8-r1 -> sys-cluster/ceph-12.2.9 bump? --- sys-cluster/ceph-12.2.8-r1.ebuild 2018-11-10 03:43:03.000000000 +0100 +++ sys-cluster/ceph-12.2.ebuild 2018-11-10 03:42:43.000000000 +0100 @@ -1,4 +1,5 @@ # Copyright 1999-2018 Gentoo Authors +# Copyright 2017-2018 Sony Interactive Entertainment Inc. # Distributed under the terms of the GNU General Public License v2 EAPI=6 @@ -14,7 +15,7 @@ SRC_URI="" else SRC_URI="https://download.ceph.com/tarballs/${P}.tar.gz" - KEYWORDS="amd64 x86" + KEYWORDS="~amd64 ~x86" fi DESCRIPTION="Ceph distributed filesystem" @@ -87,6 +88,7 @@ net-misc/socat sys-apps/gptfdisk sys-block/parted + sys-fs/e2fsprogs sys-fs/cryptsetup sys-fs/lvm2 !<sys-apps/openrc-0.26.3 @@ -129,6 +131,7 @@ "${FILESDIR}/ceph-12.2.4-cflags.patch" "${FILESDIR}/ceph-12.2.4-rocksdb-cflags.patch" "${FILESDIR}/ceph-12.2.5-no-werror.patch" + "${FILESDIR}/ceph-13.2.2-dont-install-sysvinit-script.patch" ) check-reqs_export_vars() { 2) My problem with all of that is that I want to avoid a large copyright header like outlined in comment #7. 3) But more important: Cleanup of those copyright markers. Comparing kernel work vs ebuild work is a bad example from my POV because kernel code will usually stay for years. But ebuilds will change very often. It isn't unusually that an ebuild will be rewritten from time to time... but how do we track copyright? When do we know "That line can be removed *now*"? 4) If we allow an exception for SIE we have to allow others, too. Do we really want that? Imagine that https://patch-diff.githubusercontent.com/raw/gentoo/gentoo/pull/10158.patch would have added a line like chutzpah added. After talking with the user it would be clear that the user insists on having a dedicated copyroght line like SIE. I think we cannot reject saying "Well, you aren't a dev so you cannot claim an exception...".
I'm going to discuss all the copyright attribution variants here, because there are clarifications around implementations needed for both of them; and then a couple of separate comments to address other things raised on the bug. First as a general point, the GLEP did not explicitly state that multiple lines of the non-simplified format isn't valid. Indeed, in my initial reading, I took it as valid, because it's also used in the kernel AND Chromium, even for tiny files. Problems with Simplified attribution: "Foo Authors" TL;DR: we need to add an explicit copyright-holder field SOMEWHERE, for when copyright-holder != author, AND the LIST of copyright holders data MUST persist even outside of the VCS (the exact association commit:copyright-holder can be VCS-only) [AUTHORS file] GLEP76 based simplified attribution off the Chromium model, but lost one of the implementation details, which needs to be restored (not a GLEP change, but an implementation change). GLEP76: > Projects using this scheme must track authorship in a VCS, > unless they list all authors of copyrightable contributions in an AUTHORS file. Chromium, per https://dev.chromium.org/developers/contributing-code > You must add your (or your organization's) name and contact info to the AUTHORS file for Chromium or Chromium OS. Chromium's AUTHORS file is NOT a substitute for VCS authorship information, it is meant to be used in addition to VCS authorship. a) VCS authorship in itself does NOT show what entity owns the copyright for a given change. b) AUTHORS is preserved even in non-VCS copies of the code [Chromium tarballs, or rsync of the gentoo repo] If we persist with the simplified attribution model, the AUTHORS file must be added to every repo where it is used (this is already the case in OpenRC). Further, the AUTHORS file may end up with TWO entries for a single person: one of their name, and another with a wildcard pointing to the entity that holds copyright over their commit. VCS authorship, combined with AUTHORS file, traces the copyright holder. It's important in this case that the corporate commits would explicitly have committer != author email, e.g. this: commit 699e7ae01806807eb88cedda80e241a1b5d42b7e author Foo Bar <foobar@gentoo.org> 1540509984 -0700 committer Foo Bar <foo.bar@example-company.com> 1540510013 -0700 Further, this adjusts the model of commits: - pusher (who pushed a given commit to Gentoo) - committer (who made the actual commit that was pushed) - author (who wrote the content of a commit) - copyright holder (who holds the copyright to content) The author may also be the copyright holder, but not always, such as the SIE commits. The copyright holder identity might not even be easily tracable from the email of the author, such work developed under consulting contracts to businesses, and might even change over time for a given author email. For example, I have previously made commits under consulting agreements, and explicitly marked the organization that paid for that work as part of my commit message. AUTHORS in the case of Gentoo, is going to comprise all of the committers, and all of the unique authors, both as individuals and corporate entities. It would have to be VCS plus additional static data [to cover CVS history era].
Problems with non-simplified ("traditional") attribution: Chromium does try to push the simplified attribution, but does NOT require it. There are many places in the Chromium source that use the non-simplified attribution, with multiple lines. I have already mentioned the outside-of-VCS use-case above: the non-simplified form permits the copyright-holder to exist in the files that were changed. There's a minor wrinkle in the non-simplified attribution model: It misrepresents when a contribution was made. If a new contributor makes a major contribution, and becomes the largest copyright holder, then the date range does not correctly capture what timeframe the contribution existed in. Knowing when that was made is important because it greatly simplifies queries about new material was added, esp. when the content is outside of the VCS. My understanding of ulm's model for single-line-traditional, with the example of the above commit: before: # 1999-2018 Gentoo Foundation after: # 1999-2018 Foobar Company, Gentoo Foundation, and others multi-line-traditional: before: # 1999-2018 Gentoo Foundation after: # 1999-2018 Gentoo Foundation after: # 2018 Foobar Company Trying to force the non-simplified lines also has another problem beyond date ranges: line length. The longest copyright line right now is this, at 68 characters > # Copyright 1999-2018 Arfrever Frehtes Taifersar Arahesis and others If Sony also made a major contribution to this file, we could wind up with 106 characters: > # Copyright 1999-2018 Arfrever Frehtes Taifersar Arahesis, Sony Interactive Entertainment Inc., and others This would be much better in multiple lines, as the line length limit would only be hit if the name of the single copyright holder itself was too long.
Minor correction, these two are reversed, it should have been @gentoo.org for committer field. (In reply to Robin Johnson from comment #31) > committer != author email, e.g. this: > commit 699e7ae01806807eb88cedda80e241a1b5d42b7e > author Foo Bar <foobar@gentoo.org> 1540509984 -0700 > committer Foo Bar <foo.bar@example-company.com> 1540510013 -0700
The further TL;DR for my proposal: As an implementation detail to GLEP76, any commit where the author != copyright-holder, MUST include a commit message footer, stating who the copyright holder is. This data can be exported to an AUTHORS file (in addition to other manual data for the AUTHORS file).
Notability: what is a big enough contribution to have a contributor explicitly listed? K_F raised a concern that the copyright holders list could be longer than the ebuild itself. If the requirement for adding a listing is considered as 30% of the copyrightable lines of a work (e.g. ebuild), and code is repeatedly removed to shrink the work, the number of copyright holders will strictly NEVER exceed the number of copyrightable lines in the work. This would be N copyrightable lines, each with a different copyright holder. This should be considered an extreme case, and unlikely to ever occur. Even if it did occur, it would be rarer than works with much fewer holders. Automation, with the copyright-holder tag, would allow easy detection of when a copyright line could be removed.
(In reply to Robin Johnson from comment #34) > As an implementation detail to GLEP76, any commit where the author != > copyright-holder, MUST include a commit message footer, stating who the > copyright holder is. > > This data can be exported to an AUTHORS file (in addition to other manual > data for the AUTHORS file). Should we introduce a special tag for this information, so that automated extraction will be simple and straightforward?
(In reply to Thomas Deutschmann from comment #30) > (In reply to Patrick McLean from comment #22) > > (In reply to Michał Górny from comment #21) > > > We've already wasted so much time discussing it, and I think we all know > > > there's nothing that can be really done here. We can either live with > > > explicit SIE copyright, or we can reject all contributions from their > > > employees. > > > > Thank you, that is probably a decent summary of the situation. I will add > > some clarifications below. > > > > > If we go for allowing SIE copyright, it would be nice if developers were > > > given a clear hint when they can remove SIE copyright, e.g. when bumping > > > ebuilds. Say, A-1.ebuild did not have SIE copyright. SIE employee bumps it > > > to A-2.ebuild with no changes and adds SIE copyright. Somebody else bumps > > > it to A-3.ebuild -- should he remove SIE copyright? > > > > The internal guidance SIE is using for Gentoo contributions states that > > employees should _not_ add a copyright to version bumps that are just a > > rename, or with only trivial fixes. The copyright only gets added with > > feature additions or bumps that require significant work. > > 1) Can you please explain sys-cluster/ceph-12.2.8-r1 -> > sys-cluster/ceph-12.2.9 bump? > It's explained in the following paragraph: > However, SIE employees _will_ add a copyright to what appears to be a trivial > version bump if significant work was done to the same ebuild on SIE time > before the policy change. The ceph ebuild had significant work done on SIE time before the policy change (at least 60%-70% of the code was written on SIE time), this just reflects the status of the copyright. > 2) My problem with all of that is that I want to avoid a large copyright > header like outlined in comment #7. > > 3) But more important: Cleanup of those copyright markers. Comparing kernel > work vs ebuild work is a bad example from my POV because kernel code will > usually stay for years. But ebuilds will change very often. It isn't > unusually that an ebuild will be rewritten from time to time... but how do > we track copyright? When do we know "That line can be removed *now*"? Much ebuild work will stay for years as well, it really depends on the ebuilds. It's safe to say if the ebuild gets entirely rewritten because upstream changed their build system, then it's safe to remove the line. There are likely other scenarios, but yes it is hard to keep track. > 4) If we allow an exception for SIE we have to allow others, too. Do we > really want that? Imagine that > https://patch-diff.githubusercontent.com/raw/gentoo/gentoo/pull/10158.patch > would have added a line like chutzpah added. After talking with the user it > would be clear that the user insists on having a dedicated copyroght line > like SIE. I think we cannot reject saying "Well, you aren't a dev so you > cannot claim an exception...". I am not sure it's an exemption, robbat2 pointed out a lot of the issues with the current copyright policy, as written there is no way to reflect the appropriate copyrights, the git history is insufficient as the author and committer information do not convey the copyright holder. I am not going to re-iterate all of robbat2's points, I think he was very clear describing the various issues.
(In reply to Andrew Savchenko from comment #36) > (In reply to Robin Johnson from comment #34) > > As an implementation detail to GLEP76, any commit where the author != > > copyright-holder, MUST include a commit message footer, stating who the > > copyright holder is. > > > > This data can be exported to an AUTHORS file (in addition to other manual > > data for the AUTHORS file). > > Should we introduce a special tag for this information, so that automated > extraction will be simple and straightforward? I copyright tag for this information would be fine, though it would have to be exposed to rsync somehow, either via a file added during the "fattening" process or some other method.
(In reply to Ulrich Müller from comment #4) > Personally, I think that something like the following might be acceptable: > > # Copyright 1999-2018 MAIN CONTRIBUTOR and others > # Copyright 2018 Sony Interactive Entertainment Inc. To clarify again: 1. The simplified attribution ("Gentoo Authors") is a placeholder which cannot be combined with any explicit copyright holder. 2. IMHO, GLEP 76 does not explicitly forbid multiple lines for the traditional attribution. (Especially, the notice can be wrapped if it is longer than 80 characters.) 3. If the current header says "Gentoo Foundation", then I think that something like the following would comply with GLEP 76: # Copyright 1999-2018 Gentoo Foundation and others # Copyright 2018 Sony Interactive Entertainment Inc. My understanding would be that "Gentoo Foundation" could stay in place until a contributor will challenge it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fc3568be09224dcc85954b1ad2aece662c827721 commit fc3568be09224dcc85954b1ad2aece662c827721 Author: William Hubbs <williamh@gentoo.org> AuthorDate: 2018-11-12 19:53:33 +0000 Commit: William Hubbs <williamh@gentoo.org> CommitDate: 2018-11-12 19:57:55 +0000 sys-apps/util-linux: 2.33 Fix copyright for compliance with glep 76 Closes: https://bugs.gentoo.org/670702 Package-Manager: Portage-2.3.51, Repoman-2.3.11 Signed-off-by: William Hubbs <williamh@gentoo.org> sys-apps/util-linux/util-linux-2.33.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
> The simplified attribution ("Gentoo Authors") is a placeholder which cannot be combined with any explicit copyright holder. How do we go about revising the GLEP to allow this? Listing Gentoo Foundation as the primary copyright holder is a horrible workaround for this.
I dare agree that putting 'Gentoo Foundation' there when we explicitly know that's not correct is not a feasible solution. I wouldn't mind if people wanting to add additional copyright lines would be expected to figure out the proper person to attribute as majority copyright holder. After all, if they can pay for turning copyright header into attribution, I suppose they can pay for doing proper copyright research as well.
(In reply to Michał Górny from comment #42) > I dare agree that putting 'Gentoo Foundation' there when we explicitly know > that's not correct is not a feasible solution. Do we know that it is not correct? util-linux goes back to before 2004, when Gentoo Technologies transferred copyright of the tree to the Foundation. > I wouldn't mind if people wanting to add additional copyright lines would > be expected to figure out the proper person to attribute as majority > copyright holder. After all, if they can pay for turning copyright header > into attribution, I suppose they can pay for doing proper copyright research > as well. For util-linux that may well turn out not to be feasible. I told you on IRC yesterday that you are the main contributor by number of lines ("git blame -M -C -C", and disregarding empty lines), and your reaction to it was like "what, me and util-linux?". (In reply to Ulrich Müller from comment #39) > 3. If the current header says "Gentoo Foundation", then I think that > something like the following would comply with GLEP 76: > > # Copyright 1999-2018 Gentoo Foundation and others > # Copyright 2018 Sony Interactive Entertainment Inc. > > My understanding would be that "Gentoo Foundation" could stay in place until > a contributor will challenge it. To clarify further, this was specifically about util-linux, but not a general statement. For example, if an ebuild was written from scratch in 2005 or later, then an attribution to Gentoo Foundation would most likely not be correct.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1cd31691dafbb1f442db47873d8b6fb819146999 commit 1cd31691dafbb1f442db47873d8b6fb819146999 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2019-06-09 19:39:50 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2019-06-09 19:40:17 +0000 sys-apps/util-linux: adjust copyright Bug: https://bugs.gentoo.org/670702 Package-Manager: Portage-2.3.67, Repoman-2.3.14 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> sys-apps/util-linux/util-linux-2.33.2.ebuild | 1 - sys-apps/util-linux/util-linux-2.34_rc2.ebuild | 1 - sys-apps/util-linux/util-linux-9999.ebuild | 1 - 3 files changed, 3 deletions(-)
