So it seems that the ebuild copyright issue has been stalled after bouncing the ball a bit, and one of the most important problems that affect most of Gentoo developers is still unsolved. AFAIK the latest version of the proposal is at: https://wiki.gentoo.org/wiki/User:Aliceinwire/CopyrightPolicy I also recall that some people had planned some changes to it. It'd be probably beneficial if we could focus on a joint effort from Council and Trustees to push this forward. I think it'd be best if we discussed this here, prepared a single proposal signed by both groups and submitted it to the ml for further discussion. Credits for the idea go to Robin. I've also CC-ed him and Rich as I recall them working on this somewhat. Feel free to CC anyone else you think relevant.
(In reply to Michał Górny from comment #0) > So it seems that the ebuild copyright issue has been stalled after bouncing > the ball a bit, and one of the most important problems that affect most of > Gentoo developers is still unsolved. AFAIK the latest version of the > proposal is at: > > https://wiki.gentoo.org/wiki/User:Aliceinwire/CopyrightPolicy > > I also recall that some people had planned some changes to it. Indeed. I had said this previously in the mailing list, but I repeat it here so it will be in one place: 1. The formatting of the DCO doesn't follow its logical structure. Basically, the contributor will certify one of the points a, b, or c (note the full stop at the end of point c). Whereas point d (which was added later) is independent of the rest and especially isn't part of the logical or. So maybe this should just be changed into a new paragraph. 2. Our social contract says "free software" throughout, so we should use this term (rather than "open source") in the DCO, too. The FLA draft also says "free software". Can we stay consistent please? 3. Note that the OSDL have released the Linux DCO under the CC-BY-SA-2.5 in 2005, so we are allowed to modify it (we will have to change its name to something different like "Gentoo DCO",though): https://web.archive.org/web/20060524185355/http://www.osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html With these changes, the wording would be as follows: | 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 free software 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 free software | license and I have the right under that license to submit that | work with modifications, whether created in whole or in part by | me, under the same free software license (unless I am permitted | to submit under a different license), as indicated in the file; or | | (c) The contribution was provided directly to me by some other person | who certified (a), (b) or (c) and I have not modified it. | | I understand and agree that this project and the contribution are | public and that a record of the contribution (including all personal | information I submit with it, including my sign-off) is maintained | indefinitely and may be redistributed consistent with this project or | the free software license(s) involved. 4. Under "Licensing of Gentoo Projects" the copyright policy currently says: "Any project hosted on Gentoo infrastructure not listed above must be licensed GPL-2+. If you wish to add a new Gentoo project to this page, contact the trustees." Looking at the social contract again, it explicitly mentions GPL-2+ and CC-BY-SA (version 2.0 or later). So at least the latter should be permitted in addition. More generally, one could ask if that policy isn't too restrictive, and if any FSF (or OSI) approved free software license should be allowed.
(In reply to Ulrich Müller from comment #1) > | (b) The contribution is based upon previous work that, to the best > | of my knowledge, is covered under an appropriate free software > | license and I have the right under that license to submit that > | work with modifications, whether created in whole or in part by > | me, under the same free software license (unless I am permitted > | to submit under a different license), as indicated in the file; or Also: 5. There are non-free files (like patches, or licenses), both in the tree and in repos hosted on Gentoo infrastructure. Should the DCO apply to these too? If yes, then maybe point b needs to be changed to say just "license" rather than "free software (or open source) license".
(In reply to Ulrich Müller from comment #1) > > 3. Note that the OSDL have released the Linux DCO under the CC-BY-SA-2.5 in > 2005, so we are allowed to modify it (we will have to change its name to > something different like "Gentoo DCO",though): > https://web.archive.org/web/20060524185355/http://www.osdlab.org/newsroom/ > press_releases/2004/2004_05_24_dco.html The Linux Foundation and Linus have also released it under the GPL, as part of the kernel source tree. Whether they really intended to is a matter of some dispute, but they continue to publish it there. > > 4. Under "Licensing of Gentoo Projects" the copyright policy currently says: > "Any project hosted on Gentoo infrastructure not listed above must be > licensed GPL-2+. If you wish to add a new Gentoo project to this page, > contact the trustees." > > Looking at the social contract again, it explicitly mentions GPL-2+ and > CC-BY-SA (version 2.0 or later). So at least the latter should be permitted > in addition. > > More generally, one could ask if that policy isn't too restrictive, and if > any FSF (or OSI) approved free software license should be allowed. The intent here wasn't to restrict what license people use for new projects, but to actually have our project licenses documented and ensure that we're not combining incompatible licenses. Another option would simply be to say that nothing can be hosted on Gentoo infra without contacting the Trustees first to add it to the page, but that seemed a bit more intrusive. The assumption was that the Trustees would act more as administrators here than gatekeepers. Whether it ought to be the Trustees or some other group is another matter to consider.
Hate to double post, but this one has a lot of text so I thought this would make this change more distinct. IMO the most problematic section of the text is this: |A proper copyright notice appears near the top of the file, and reads, |"Copyright YEAR LARGEST-CONTRIBUTOR and others (see below)." The |largest contributor is whatever entity owns copyright to some portion |of the largest number of lines in the file. The "and others (see |below)" text may be omitted if the largest contributor holds copyright |to the entire file. |If there are other copyright holders, then somewhere in the file the |full list of copyright holders must be listed, or a reference to a list |in another file stored in a Gentoo repository. |No file may be committed to a Gentoo repository unless at least 60% |of the lines in the file are accounted for in the list of copyright |holders. Any content already in a Gentoo repository as of DATE shall |count towards the 60% rule even if not attributed. Note that 60% is the |minimum required for compliance with this policy - all contributors are |strongly encouraged to strive for 100% attribution. |It is the responsibility of anyone making a commit to update the |contributor list for any additions made to the repository. Committers |are not required to double-check content already in the repository. |Anyone finding a file out of compliance should log a bug against |the associated project/package providing as much information as |possible. Files that are not brought into compliance within 60 days |or upon a request for removal by a aggrieved copyright holder will be |removed. Any concerns not addressed by a maintainer can be appealed to |the Trustees. This requires a fair bit of overhead to track the line counts. I suggest revising it by removing the middle paragraphs to read something like this: |A proper copyright notice appears near the top of the file, and reads, |"Copyright YEAR LARGEST-CONTRIBUTOR and others (see below)." The |largest contributor is whatever entity owns copyright to some portion |of the largest number of lines in the file. The "and others (see |below)" text may be omitted if the largest contributor holds copyright |to the entire file. |Anyone finding a file out of compliance should log a bug against |the associated project/package providing as much information as |possible. Files that are not brought into compliance within 60 days |or upon a request for removal by a aggrieved copyright holder will be |removed. Any concerns not addressed by a maintainer can be appealed to |the Trustees. The change is to eliminate the tracking system entirely. When files are checked in we still have a policy that states what the copyright ought to be. If somebody has a problem with how we implemented it, they can contact us, so I think we're still covered. As far as I can tell this is more-or-less how the Linux kernel upstream handles things, except they don't really even document it explicitly. Files get contributed under whatever copyright header the author provides, and over time it doesn't seem like there is any central effort to ensure the copyright notices are updated as files get patched. This section was added in response to the eudev fiasco because we didn't really have a policy for copyright notices other than to stick the Foundation in everything. I would also change the header on this section from "Special license" to "Copyright Notices." I'd have to dig up the history of the file to know where the original header came from. If we make this change I'd also change one sentence in the following section to remove the text "(fewer copyright holders to list)."
(In reply to Richard Freeman from comment #3) > > 3. Note that the OSDL have released the Linux DCO under the CC-BY-SA-2.5 in > > 2005, so we are allowed to modify it (we will have to change its name to > > something different like "Gentoo DCO",though): > > https://web.archive.org/web/20060524185355/http://www.osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html > > The Linux Foundation and Linus have also released it under the GPL, as part > of the kernel source tree. Whether they really intended to is a matter of > some dispute, but they continue to publish it there. Right, but this may not be so clear because Documentation/SubmittingPatches doesn't carry a license notice. The DCO was explicitly released under CC-BY-SA, however. Anyway, the important thing is that we are not bound by the restrictive (and non-free!) terms at https://developercertificate.org/ saying that "changing it is not allowed". > > More generally, one could ask if that policy isn't too restrictive, and if > > any FSF (or OSI) approved free software license should be allowed. > > The intent here wasn't to restrict what license people use for new projects, > but to actually have our project licenses documented and ensure that we're > not combining incompatible licenses. Then maybe the policy should just say that projects must use a free software license, and that trustees should be informed if it is something other than GPL or CC-BY-SA? > Another option would simply be to say that nothing can be hosted on Gentoo > infra without contacting the Trustees first to add it to the page, but that > seemed a bit more intrusive. > > The assumption was that the Trustees would act more as administrators here > than gatekeepers. Whether it ought to be the Trustees or some other group > is another matter to consider. Thanks for the clarification.
(In reply to Richard Freeman from comment #4) > |A proper copyright notice appears near the top of the file, and reads, > |"Copyright YEAR LARGEST-CONTRIBUTOR and others (see below)." The > |largest contributor is whatever entity owns copyright to some portion > |of the largest number of lines in the file. The "and others (see > |below)" text may be omitted if the largest contributor holds copyright > |to the entire file. Presumably this can be applied straight forward for most project repositories, but I have my doubts about how to apply it to ebuild repositories. I suppose most ebuilds won't be written from scratch, but will be copied from other ebuilds, from skel.ebuild, from examples in the devmanual, etc. There is also code being moved between ebuilds and eclasses. I am not at all sure how the largest contributor would be determined for any given ebuild. Then there are ebuilds that may not be copyrightable at all (e.g. ebuilds in the virtual category). So the question is if we consider the individual ebuild as a "work" where we must trace the largest contributor. We could also consider the whole tree (maybe excluding some files like patches) as a single work.
(In reply to Ulrich Müller from comment #6) > > I am not at all sure how the largest contributor would be determined for any > given ebuild. Well, if somebody doesn't even know who wrote the ebuild, how can they sign off on the DCO? And how can we be reasonable assured that it is legal to redistribute? > So the question is if we consider the individual ebuild as a "work" where we > must trace the largest contributor. We could also consider the whole tree > (maybe excluding some files like patches) as a single work. Most ebuilds seem pretty non-trivial to me. I'm not sure I'd even agree with your assertion that virtual ebuilds aren't copyrightable, but I agree they're borderline. Here's a scenario for why I think we have a policy (and keep in mind the whole policy was inspired by eudev and the problems with not having a policy): Let's suppose somebody has an overlay full of ebuilds published under GPLv2+. Let's suppose they're actively hostile to Gentoo. His ebuilds have his name in a copyright notice at the top, along with the clear GPLv2+ license. I'd like to add one of these ebuilds to the tree. Under the proposed policy I'd just leave his name on the copyright notice and add it to the tree, and I'm done. If I had to make some tweaks I'd add the "and others" text to the notice. If we want to treat the entire tree as a single work then presumably you're suggesting that we strip his copyright notice. That might not be a great move if the person in question is actively hostile to Gentoo and it gives him an excuse to sue. In any case, is there a better alternative? I think we need to give clear guidance one way or another around what should be done with copyright headers on files being added to the tree. Otherwise we end up in another eudev situation because well-intentioned developers have no guidance to work with.
I apologise for being late to the party. The FLA – that to my great and welcome surprise is mentioned as being used by Gentoo Foundation – has been updated to 2.0 with the biggest changes being: - compatibility with more jurisdictions; - added patent licence for further protection against patent litigation; - clearer wording; - narrowing down the list of Free Software licences; - more practical licensing options directed towards third parties – including referencing to an external licensing policy. Also, the FLA-2.0 has been merged with ContributorAgreements.org, so it is much easier to fill in (and sign): http://contributoragreements.org/ca-cla-chooser/ As such, I very warmly suggest updating the FLA Gentoo uses from 1.x to 2.0. Especially if there has not been (m)any FLA-1.x signed so far. For more info on the changes in FLA-2.0: https://fsfe.org/activities/ftf/fla.html http://matija.suklje.name/fiduciary-license-agreement-20 I am very happy to answer any further questions about it. Also, happy to collect any concerns and prepare them for 2.1. As for wrapping DCO and/or FLA into a more streamlined workflow, I was already playing with the idea that one could wrap up an FLA into a DCO-like text and that a tag similar to Signed-Off could be used as proof/indication of intent. This logic leans on the fact that in most countries an electronic signature is enough for an exclusive copyright license (which FLA-2.0 is) and the presumption that an SSH or GPG key should count as a valid electronic signature. If there is interest, I am happy to explore this further. Regarding the copyright/license headers, the following best practices could be of (partial) help: http://reuse.software/
Few notes: 1. I would scratch the section on licenses of Gentoo projects for now. It's incomplete, problematic and the remaining part is more important. 2. At least for the Gentoo repository, we need to consider two kinds of files separately: Gentoo-specific code files (ebuilds, init scripts) and potentially external files (patches and other misc files): 2a. Ebuilds and other Gentoo-specific files are usually written by contributors, so that's kinda easy (but see below). 2b. A lot of patch files and other stuff comes from upstream, other distros and in some cases are fetched randomly from mailing lists, bug trackers, etc. I don't think we (as Gentoo or as contributors) can claim copyright on them or enforce a specific license. 3. I think the past discussions indicated a potential 'derivative work' problem for ebuilds. After all, most of the ebuilds are very simple and often are copied from skeleton files or other ebuilds. Given the limited amount of 'original work', it may be hard to determine who actually is the major 'copyright holder'. 4. We had potential contributors who had refused to contribute anything to Gentoo unless their name stays on the copyright line. Not sure if we want to account for that but listing for completeness anyway. 4a. If we allow for that, then we have an open question on replacing that line whenever other person takes over the package (particularly in context of derivative work). 5. We had contributors who had tried to submit ebuilds fetched off other people's repositories with copyright line changed, with the authors noticing that (before it got committed to Gentoo, hopefully) and complaining. 5a. But the ebuild format and Gentoo policies make it quite likely for independent parties to create very similar (or even identical) ebuilds.
Most of these items are related, but the first is not, so I'll deal with it in a separate comment. (In reply to Michał Górny from comment #9) > > 2. At least for the Gentoo repository, we need to consider two kinds of > files separately: Gentoo-specific code files (ebuilds, init scripts) and > potentially external files (patches and other misc files): > > 2a. Ebuilds and other Gentoo-specific files are usually written by > contributors, so that's kinda easy (but see below). > > 2b. A lot of patch files and other stuff comes from upstream, other distros > and in some cases are fetched randomly from mailing lists, bug trackers, > etc. I don't think we (as Gentoo or as contributors) can claim copyright on > them or enforce a specific license. IMO treating these differently would be an unnecessary complication. Ebuilds aren't as simple as you're suggesting, and upstream stuff isn't actually that difficult to deal with under my newer proposal. We certainly can enforce a license, if we choose to limit what we accept. For example, if somebody offers a CDDL contribution to a GPL work, we could choose not to accept that change. (And this is why I'm replying to your first point after all of these.) > > 3. I think the past discussions indicated a potential 'derivative work' > problem for ebuilds. After all, most of the ebuilds are very simple and > often are copied from skeleton files or other ebuilds. Given the limited > amount of 'original work', it may be hard to determine who actually is the > major 'copyright holder'. With my newer proposal there generally wouldn't be any formal process for this. For something new the main author would stick their name "and others" on the ebuild (if they didn't just create it entirely themselves), or Gentoo if they had signed the FLA. For something they grab from elsewhere they would keep the copyright notice intact, possibly adding "and others" if they modified it. This greatly reduces the need for some kind of analysis and avoids most conflict. If somebody has a problem with the final result, they can always escalate the issue. This seems to be what the Linux kernel does. > > 4. We had potential contributors who had refused to contribute anything to > Gentoo unless their name stays on the copyright line. Not sure if we want to > account for that but listing for completeness anyway. And under my proposed modification they could do just that. > > 4a. If we allow for that, then we have an open question on replacing that > line whenever other person takes over the package (particularly in context > of derivative work). Other than adding "and others" copyright lines wouldn't be likely to be modified at all once a file is in a repository. If there were a major rewrite of a file it might be possible, but how often does this even happen (I'm talking >50% of the original lines being unrecognizable)? > > 5. We had contributors who had tried to submit ebuilds fetched off other > people's repositories with copyright line changed, with the authors noticing > that (before it got committed to Gentoo, hopefully) and complaining. Under my proposed modifications this would not be permitted. The most that would happen is adding "and others" if there were changes to the file, which doesn't seem like something likely to draw a lot of complaints (and it is certainly factual - changing even one line to a file is an addition of an author), and it doesn't diminish the original author's rights. > > 5a. But the ebuild format and Gentoo policies make it quite likely for > independent parties to create very similar (or even identical) ebuilds. IMO the potential for conflict in this situation is unavoidable under any reasonable policy. If two authors independently and without knowledge of each other write a similar story, both are going to assume that the other stole it, and the only way to sort it out would be with a lot of argument/investigation. The best we can do is be transparent. IMO something like this is really only going to happen with trivial ebuilds. Sure, there are plenty of those, but is somebody really going to complain because our ebuild is similar to theirs when all it does is inherit some stuff set the homepage/src_uri, and maybe add one statement to one of the phases?
Replying to this point separately because it is not strongly related to the rest of the document. (In reply to Michał Górny from comment #9) > > 1. I would scratch the section on licenses of Gentoo projects for now. It's > incomplete, problematic and the remaining part is more important. IMO this should probably end up someplace separate from the policy itself. The policy would change very infrequently, but the table of licenses would need to evolve as new projects are added/etc. I think the fundamental need here is to define what licenses we accept for what projects, with the goal of proactively managing our licenses. One of the purposes of this policy is to allow more flexibility in accepting outside code, but this increases the need to manage our licenses or we could end up with a mess. Let's suppose somebody pulls in a BSD codebase. Somebody adds one file and makes that one GPL2. Is that OK? Legally it is fine, but anything built from that file now falls under GPL2. If that file is buried in the middle of the repo a user might not notice. What happens when another contributor adds another file under the CDDL? Clearly individual projects need to manage their licenses at a level higher than the individual file. Also, what about GPL2 vs GPL2+? Right now the files in the Gentoo repo just say GPL2. Maybe we could relicense those, or maybe we coudn't (this hinges on ownership, which IMO we shouldn't debate here). However, if we start letting in ebuilds that don't have Gentoo copyrights and are GPL2 and not GPL2+ then we definitely wouldn't be able to relicense the entire tree to GPL2+ if we wanted to. Maybe we want to require that all future contributions be explicitly GPL2+. There are certainly many ways this could be done, and a manually-entered table on a wiki page is just one of these. I think we ought to solve this problem before adopting a new policy that makes it easier to pull in upstream code, because that is going to open the floodgates and this issue could get out of hand quickly. You could make the rules simple and just give a list of compatible licenses and say that any contributions must be on the list. Once we have a ton of contributions that we don't own the copyright on we lose the ability to manage that situation easily. Again, I realize there are some that might claim that we're already in that situation - I disagree but that isn't something we need to settle now, and I don't think it changes the need to improve this going forward.
I don't think this is as simple as that. The usual procedures you mentioned may work well with projects like the Linux kernel because the code there rarely moves from one file to another, and each new piece of code has significant level of originality. On the other hand, in Gentoo copying code is very common. For example, when you are bumping a package multiple times, you tend to be copying the previous ebuild and possibly doing small changes. After multiple bumps, it's very hard to tell how much of the ebuild belongs to the previous listed copyright owner. Also, at some point it becomes silly that you're doing all the work for years now yet you have to keep putting someone else on top of the ebuild because there was never a need for a major enough change. Furthermore, the level of originality in ebuilds is very low. After all, the simplest ebuilds are just plain metadata files, possibly using a few eclasses. Ebuilds that have real amount of executable code are not that common, and frequently that code is copied from other existing ebuilds or guides. All that said, I feel like the proposed policy is going to result pretty much in the copyright assignments being pretty arbitrary, and boiling down to whoever committed the package first and/or whoever dares change the copyright when bumping package.
(In reply to Michał Górny from comment #12) > > Also, at some point it becomes silly that you're doing all the work for > years now yet you have to keep putting someone else on top of the ebuild > because there was never a need for a major enough change. I suspect a lot of maintainers don't really care that much whose name appears at the top. If a maintainer wants to do a diff against the original file and change the name if it looks like a total rewrite they could. If the original author notices and complains it could be dealt with, but that is likely to be rare. It should be noted that every ebuild is more-or-less a derived work of everybody who ever touched it (unless a contribution was completely removed), so the one name at the top is mostly to check a box. Which brings me to... > All that said, I feel like the proposed policy is going to result pretty > much in the copyright assignments being pretty arbitrary, and boiling down > to whoever committed the package first and/or whoever dares change the > copyright when bumping package. I agree, but my main goal was to keep things simple (especially with the revision I proposed). To try to make it less arbitrary would require more effort, unless somebody wants to make an auto-copyright tool using git blame or something like that (and there is no reason that such an approach couldn't be used on top of the simpler policy as a fallback for when such tools aren't available). If you look at the linux kernel source files I bet a lot of those copyright notices are also fairly arbitrary. How many patches get merged into the kernel in a year? Every one touches a file that has a copyright notice on it. How often are any of those notices modified? I'm sure if it really bothered somebody they'd push to change the notice, but most people aren't going to care THAT much about the notice on a file that is GPL anyway. Copyright notices shouldn't be confused with giving credit where credit is due. That could be done in a lot of other ways that might be less obscure and more automated, without having to worry about what changes do/don't count legally for copyright purposes. Don't want to harp on this too much - if there is another solution that is practical it could be considered.
Just for completeness, could you remind me what we couldn't do something generic like: Copyright ... Gentoo Linux contributors ...provided we keep a detailed list of all those contributors somewhere in the repo?
(In reply to Michał Górny from comment #14) > Just for completeness, could you remind me what we couldn't do something > generic like: > > Copyright ... Gentoo Linux contributors > > ...provided we keep a detailed list of all those contributors somewhere in > the repo? I see two sources of issues here: 1. Is the copyright holder even a "Gentoo Linux contributor?" Let's use the eudev fork of udev/systemd as an example. Upstream had no intention of contributing anything to Gentoo specifically. It is just a fork. I imagine that if the code were used in a "hostile" way that this might be particularly contentious, and this is the sort of situation where getting right matters most. 2. Even if the author intends to be a "Gentoo Linux contributor" is that phrase legal under US law. Under US law the requirement is that we state "the name of the owner of copyright in the work, or an abbreviation by which the name can be recognized, or a generally known alternative designation of the owner." I suspect we could get away with it if the Foundation owned the copyright, but the intent of the new policy is that not all contributions need be owned by the Foundation (and indeed with the FLA approach nothing really is "owned" by the Foundation per se as it isn't an assignment). Keep in mind that issue #1 was what basically triggered me to author the proposed policy in the first place, with the eudev fork, the change of copyright notices (without malicious intent), and the reaction by the udev project.
(In reply to Ulrich Müller from comment #2) > 5. There are non-free files (like patches, or licenses), both in the tree > and in repos hosted on Gentoo infrastructure. Should the DCO apply to these > too? If yes, then maybe point b needs to be changed to say just "license" > rather than "free software (or open source) license". I retract this suggestion, because it looks like it is a small issue. AFAICS, there are the following two classes of non-free files in the Gentoo repository: - Non-free patches. These would be found in files/ directories of individual packages. In order to get an estimate of their number, I have scanned the tree (on 2018-01-22) and matched the licenses of all packages against the @FREE license group. In total, there are 309 packages (out of about 19000) with a non-free license and at the same time having a files/ directory. Patches (files named *.diff or *.patch) exist in about 200 of these directories. It needs to be checked if all of these are non-free; it may well be that the actual number is much smaller. - License files in the licenses/ directory. Typically, even free software licenses are themselves *not* distributed under a free license. For example, the GPL-2 allows only verbatim copying of the license document, but not changing it. I don't see this as a problem, but it means that most commits of license files cannot include a Signed-off-by line.
(In reply to Ulrich Müller from comment #16) > > - License files in the licenses/ directory. Typically, even free software > licenses are themselves *not* distributed under a free license. For example, > the GPL-2 allows only verbatim copying of the license document, but not > changing it. I don't see this as a problem, but it means that most commits > of license files cannot include a Signed-off-by line. Is it really preferable to not having a Signed-off-by line in some commits, vs just having a DCO that actually covers all our cases generically? Removing "open source" from the DCO doesn't in any way allow people to commit non-open-source-licensed material in general. The copyright policy already addresses what licenses may be permitted, and it could more easily accomodate nuances than the DCO. We'd just need to add the list of license files as a separate line in the table and say any redistributable license permitted for just those. (Heaven help us if we want to host something which is redistributable but the license terms aren't redistributable.)
(In reply to Richard Freeman from comment #17) > Is it really preferable to not having a Signed-off-by line in some commits, > vs just having a DCO that actually covers all our cases generically? > Removing "open source" from the DCO doesn't in any way allow people to > commit non-open-source-licensed material in general. The copyright policy > already addresses what licenses may be permitted, and it could more easily > accomodate nuances than the DCO. We'd just need to add the list of license > files as a separate line in the table and say any redistributable license > permitted for just those. (Heaven help us if we want to host something > which is redistributable but the license terms aren't redistributable.) Not sure what would be the purpose of applying the DCO to license texts. These are legal documents that usually must be distributed verbatim (with few exceptions, like WTFPL-2). So the central sentence of the DCO, "I have the right under that license to submit that work with modifications" can never apply. And yes, people should actually *think* before adding a Signed-off-by line to their commit. Otherwise this is completely worthless and we can stop here.
(In reply to Ulrich Müller from comment #18) > (In reply to Richard Freeman from comment #17) > > Is it really preferable to not having a Signed-off-by line in some commits, > > vs just having a DCO that actually covers all our cases generically? > > Removing "open source" from the DCO doesn't in any way allow people to > > commit non-open-source-licensed material in general. The copyright policy > > already addresses what licenses may be permitted, and it could more easily > > accomodate nuances than the DCO. We'd just need to add the list of license > > files as a separate line in the table and say any redistributable license > > permitted for just those. (Heaven help us if we want to host something > > which is redistributable but the license terms aren't redistributable.) > > Not sure what would be the purpose of applying the DCO to license texts. > These are legal documents that usually must be distributed verbatim (with > few exceptions, like WTFPL-2). So the central sentence of the DCO, "I have > the right under that license to submit that work with modifications" can > never apply. Perhaps it should say "with or without modifications" then. > > And yes, people should actually *think* before adding a Signed-off-by line > to their commit. Otherwise this is completely worthless and we can stop here. Absolutely people should be affirming compliance with the DCO. The purpose of the DCO is to ensure that we are distributing things that we're allowed to distribute. I'm not sure why that need would go away just because what we're distributing is the text of a license and not source code. The DCO isn't just about making changes to things.
(In reply to Matija "hook" Šuklje from comment #8) > > I am very happy to answer any further questions about it. Also, happy to > collect any concerns and prepare them for 2.1. > Along these lines: 1. The tool that automatically generates the document is VERY useful. Previously I had to do a lot of careful checking to update the doc to insert "Gentoo" in various places. 2. The tool might benefit from more instructions about the pros/cons of various options in the tool itself. 3. The generated document (using all the default options - FSF+OSI licenses and the rest based on FSFe recommendations) had this text in section 0: "You need to have Your employer approve this Agreement or sign the Entity version of this document" It is not clear what is meant by the "Entity version of this document" - there is just one version and it seems to me that it would work for any legal entity.
(In reply to Richard Freeman from comment #19) > (In reply to Ulrich Müller from comment #18) > > Not sure what would be the purpose of applying the DCO to license texts. > > These are legal documents that usually must be distributed verbatim (with > > few exceptions, like WTFPL-2). So the central sentence of the DCO, "I have > > the right under that license to submit that work with modifications" can > > never apply. > > Perhaps it should say "with or without modifications" then. IMHO the "with modifications" part is very important, and we shouldn't weaken the DCO because of a few files that are exceptions. > > And yes, people should actually *think* before adding a Signed-off-by line > > to their commit. Otherwise this is completely worthless and we can stop > > here. > > Absolutely people should be affirming compliance with the DCO. > > The purpose of the DCO is to ensure that we are distributing things that > we're allowed to distribute. I'm not sure why that need would go away just > because what we're distributing is the text of a license and not source code. > > The DCO isn't just about making changes to things. I think we simply need to change the paragraphs preceding the DCO. Currently we have there: | All commits to Gentoo-hosted repositories must be accompanied by a | certificate of origin. The purpose of the certificate is to declare that | the content of the commit may be used in accordance with the project | license. | | For commits made using CVS, the commiter will certify agreement to the | Gentoo DCO by adding "Signed-off-by: Name/email" to the commit message as | a separate line. Repoman will add this automatically if DCO_SIGNED_OFF_BY | is set to Name/email in make.conf. Compared to this, the wording used in the kernel's "submitting-patches" is much more lightweight: "if you can certify the below [the DCO] then you just add a line saying: Signed-off-by: [...] using your real name (sorry, no pseudonyms or anonymous contributions.)" So I'd suggest to have something like the following: | In order to improve tracking of authorship, commits to Gentoo-hosted | repositories should be accompanied by a certificate of origin. The purpose | of the certificate is to declare that the contribution may be modified and | redistributed according to the project's license. | | For commits made using a VCS, committers can certify agreement with the | Gentoo DCO by adding a line like: | | Signed-off-by: Larry T. Cow <committer@example.org> | | to the commit message, including their real name (no pseudonym) and e-mail | address. I have also left out the "repoman will add this automatically" part, because it is a technical detail that doesn't need to be part of the policy. (Also, one could argue that "added automatically" defeats the purpose of "people should be affirming compliance".)
(In reply to Ulrich Müller from comment #21) Update: With the newest version of the DCO we can make it mandatory again. I still suggest a slight update of the wording, as indicated below in wdiff style (i.e., with [-deletions-] and {+additions+} indicated by brackets and braces): All commits to Gentoo-hosted repositories must be accompanied by a certificate of origin. The purpose of the certificate is to declare that the [-content of the commit-] {+contribution+} may be [-used-] {+modified and redistributed+} in accordance with the [-project-] {+project's+} license. For commits made using [-CVS,-] {+a VCS,+} the committer [-will-] {+can+} certify agreement to the Gentoo DCO by adding a line "Signed-off-by: Name <e-mail>" to the commit message as a separate line. [-Repoman will add this automatically if DCO_SIGNED_OFF_BY is set to Name/email in make.conf.-]
(In reply to Ulrich Müller from comment #22) > (In reply to Ulrich Müller from comment #21) > > Update: With the newest version of the DCO we can make it mandatory again. I > still suggest a slight update of the wording, as indicated below in wdiff > style (i.e., with [-deletions-] and {+additions+} indicated by brackets and > braces): > > All commits to Gentoo-hosted repositories must be accompanied by a > certificate of origin. The purpose of the certificate is to declare that the > [-content of the commit-] {+contribution+} may be [-used-] {+modified and > redistributed+} in accordance with the [-project-] {+project's+} license. Do I need a DCO to commit to my dev/antarus.git "Gentoo-hosted" repository? > > For commits made using [-CVS,-] {+a VCS,+} the committer [-will-] {+can+} > certify agreement to the Gentoo DCO by adding a line "Signed-off-by: Name > <e-mail>" to the commit message as a separate line. [-Repoman will add this > automatically if DCO_SIGNED_OFF_BY is set to Name/email in make.conf.-] I'm confused. Either its Mandatory (quoting above: "All commits to Gentoo-hosted repositories must be accompanied by a certificate of origin.") or its optional. If its mandatory, the committer *must* certify agreement to the Gentoo DCO. If they *can* certify agreement, then "all commits to Gentoo-hosted repositories shall be accompanied by a certificate of origin." (using RFC parlance for "shall v must").
(In reply to Alec Warner from comment #23) > (In reply to Ulrich Müller from comment #22) > > (In reply to Ulrich Müller from comment #21) > > > > Update: With the newest version of the DCO we can make it mandatory again. I > > still suggest a slight update of the wording, as indicated below in wdiff > > style (i.e., with [-deletions-] and {+additions+} indicated by brackets and > > braces): > > > > All commits to Gentoo-hosted repositories must be accompanied by a > > certificate of origin. The purpose of the certificate is to declare that the > > [-content of the commit-] {+contribution+} may be [-used-] {+modified and > > redistributed+} in accordance with the [-project-] {+project's+} license. > > Do I need a DCO to commit to my dev/antarus.git "Gentoo-hosted" repository? > IMO the answer this should be yes, for a couple of reasons: 1. It helps cover Gentoo, which is redistributing anything hosted by us. 2. It is a best practice anyway, so it actually increases the confidence that the various hosted projects have accurate licenses. That provides value to anybody who uses our projects, and it provides value to those contributing to those projects, whether those contributors recognize that value or not. If somebody just wants git hosting they can host their stuff anywhere. If somebody chooses to host their project with Gentoo it should be because they want to be part of a larger ecosystem/etc. Sticking a -s on your git commits isn't really a hardship anyway. That's just my own personal two cents.
All that said, there's a dozen or so developers who are currently using Signed-off-by. Should we do somehow inform them that their action will now have consequences?
(In reply to Alec Warner from comment #23) > > For commits made using [-CVS,-] {+a VCS,+} the committer [-will-] {+can+} > > certify agreement to the Gentoo DCO by adding a line "Signed-off-by: Name > > <e-mail>" to the commit message as a separate line. [-Repoman will add this > > automatically if DCO_SIGNED_OFF_BY is set to Name/email in make.conf.-] > > I'm confused. Either its Mandatory (quoting above: "All commits to > Gentoo-hosted repositories must be accompanied by a certificate of origin.") > or its optional. > > If its mandatory, the committer *must* certify agreement to the Gentoo DCO. > If they *can* certify agreement, then "all commits to Gentoo-hosted > repositories shall be accompanied by a certificate of origin." (using RFC > parlance for "shall v must"). It is mandatory, and *when using a VCS* then agreement can be certified by adding the Signed-off-by line. (In the sense that when it's not in a VCS then it must be certified in a different way. For example, documentation in the Wiki.) But yes, let's use "shall" throughout: All commits to Gentoo-hosted repositories shall be accompanied by a certificate of origin. The purpose of the certificate is to declare that the contribution can be modified and redistributed in accordance with the project's license. For commits made using a VCS, the committer shall certify agreement to the Gentoo DCO by adding a line "Signed-off-by: Name <e-mail>" to the commit message as a separate line.
(In reply to Michał Górny from comment #25) > All that said, there's a dozen or so developers who are currently using > Signed-off-by. Should we do somehow inform them that their action will now > have consequences? Sure, but when this policy is approved there will need to be a general communications anyway. That includes making this clear, and also instructing devs that they have to add this header or else their commits will be rejected.
(In reply to Richard Freeman from comment #20) > (In reply to Matija "hook" Šuklje from comment #8) > > > > I am very happy to answer any further questions about it. Also, happy to > > collect any concerns and prepare them for 2.1. > > > > Along these lines: Thank you, these help a lot and I’ll make sure to store your feedback. I will most likely meet with Catharina Maracke in April again to discuss ideas for FLA-2.1 (as well as another update of the website/chooser). > 2. The tool might benefit from more instructions about the pros/cons of > various options in the tool itself. Agreed. We planned that already for 2.0, but then pushed it to 2.1, as it already took years and we just didn’t want to let the > 3. The generated document (using all the default options - FSF+OSI licenses > and the rest based on FSFe recommendations) had this text in section 0: > "You need to have Your employer approve this Agreement or sign the Entity > version of this document" > It is not clear what is meant by the "Entity version of this document" - > there is just one version and it seems to me that it would work for any > legal entity. That indeed seems like a bug. I’ll note it down so we can fix in in 2.1. AFAIK, as you said yourself, there is currently no separate Entity version.
GLEP 76 has been accepted unanimously in today's council meeting. Now pending approval by trustees.
GLEP 76 has been approved by the Trustees in their 2018-09-15 meeting. Reusing this bug as tracker for implementation.
We can close this after >=portage-2.3.80 and >=repoman-2.3.19 are stable.
(In reply to William Hubbs from comment #31) > We can close this after >=portage-2.3.80 and >=repoman-2.3.19 are > stable. These versions are stable on all arches except arm64, and the only remaining issue waiting for this is renaming of a variable from DCO_SIGNED_OFF_BY to SIGNED_OFF_BY (which is a minor problem, in the first place). Therefore closing. Thanks everybody!
