I and several other Gentoo developers are unable to commit to Gentoo on work time now for legal reasons. The issue is that we need written approval from our employer's legal department before we can commit to open source under a DCO and actually sign off on our work. We are requesting a 30 day reprieve on the hard enforcement of sign-off-by lines in commits to give our legal dept time to approve the new copyright policy.
I vote: No
At least one of the Gentoo developers in your cohort is already contributing to the Ceph project, which uses the kernel DCO. What are the conditions & permission attached to those contributions? Specific to Ceph? Specific to the contributor? If they are not specific to Ceph or the contributor, AND your management has not specifically disallowed it, then I see that existing permission you have as portable to Gentoo, under the 'or kernel DCO' provisions of GLEP76.
Since this was originally requested of me (as the one who implemented the hook), and since the original IRC discussion had some arguments listed, I'd like to note a few things, officially: 1. The new policy was explicitly approved by both the Council and the Trustees. Neither the policy itself, nor the approvals made of it listed any specific provisions for delaying the application of it. I'm also not aware of any specific Gentoo policy that would state that Council/Trustee decisions start applying after some generic delay. Therefore, given no real claim otherwise, I would consider the new policy applicable from the moment it was approved by both groups, i.e. 15 Sep. 2. It is understandable that not all developers can be made aware of the new policy immediately. Therefore, it is inevitable that some developer activities past the approval of the new policy would not conform to it yet. However, I believe that any developer who becomes aware of the new policy should learn it and start following it ASAP. 3. It is also understandable that not having technical means of enforcing the policy prepared beforehand, the policy would not be enforced for some time past the approval. However, once the technical means are in place, there is no excuse for Gentoo not to enforce the approved policy. If someone asked me to disable the hook temporarily because it's misbehaving, it would be different. However, in this instance I've been asked to disable the hook because the developers do not wish to follow the standing policy. Therefore, it puts Gentoo in a position of explicitly allowing the developers not to follow the policy. Given the legal importance of this policy, I believe this should be backed by a Council and/or Trustee vote. That said, if we are to implement this, I would prefer it being a whitelist of developers who are in explicit need of this rather than generic disabling. The hook is useful for detecting commits accidentally lacking sign-off, and I don't want to lose that feature for developers who can sign off the policy.
it may be possible to return a warning for a while as well (countdown timer like).
(In reply to Robin Johnson from comment #2) > If they are not specific to Ceph or the contributor, AND your management has > not specifically disallowed it, then I see that existing permission you have > as portable to Gentoo, under the 'or kernel DCO' provisions of GLEP76. Consider my Ceph contributions as an unrelated case that does not imply permission to contribute to Gentoo projects.
This response is here because I feel that I need to correct a couple of inaccurate statements. (In reply to Michał Górny from comment #3) > Since this was originally requested of me (as the one who implemented the > hook), and since the original IRC discussion had some arguments listed, I'd > like to note a few things, officially: > > 1. The new policy was explicitly approved by both the Council and the > Trustees. Neither the policy itself, nor the approvals made of it listed > any specific provisions for delaying the application of it. I'm also not > aware of any specific Gentoo policy that would state that Council/Trustee > decisions start applying after some generic delay. Therefore, given no real > claim otherwise, I would consider the new policy applicable from the moment > it was approved by both groups, i.e. 15 Sep. I feel like we are splitting hairs here, but I need to state something officially as well. I was a member of the council which voted on this policy, and we voted 7-0 for approval. There wasn't a timeline discussed by the council, but a warning would be better than what we have now. > 2. It is understandable that not all developers can be made aware of the new > policy immediately. Therefore, it is inevitable that some developer > activities past the approval of the new policy would not conform to it yet. > However, I believe that any developer who becomes aware of the new policy > should learn it and start following it ASAP. No one is disagreeing on this. > 3. It is also understandable that not having technical means of enforcing > the policy prepared beforehand, the policy would not be enforced for some > time past the approval. However, once the technical means are in place, > there is no excuse for Gentoo not to enforce the approved policy. > > If someone asked me to disable the hook temporarily because it's > misbehaving, it would be different. However, in this instance I've been > asked to disable the hook because the developers do not wish to follow the > standing policy. Therefore, it puts Gentoo in a position of explicitly > allowing the developers not to follow the policy. Given the legal > importance of this policy, I believe this should be backed by a Council > and/or Trustee vote. No, This is not about developers not wishing to follow the policy. It is about developers not having permission from their employer to follow the policy. Given the legal ramifications of that, I think a grace period so we can get that permission is reasonable. > That said, if we are to implement this, I would prefer it being a whitelist > of developers who are in explicit need of this rather than generic > disabling. The hook is useful for detecting commits accidentally lacking > sign-off, and I don't want to lose that feature for developers who can sign > off the policy. I don't think anyone cares about how it is specifically implemented.
> I don't think anyone cares about how it is specifically implemented. You would be wrong about that. There's a big difference between whitelisting specific developers versus disabling the hook for everybody. I like the whitelist idea much better.
(In reply to William Hubbs from comment #0) > We are requesting a 30 day reprieve on the hard enforcement of > sign-off-by lines in commits to give our legal dept time to approve the > new copyright policy. For understanding, the 30 day period would start when? At the approval date, i.e. 2018-09-15?
(In reply to Ulrich Müller from comment #8) > (In reply to William Hubbs from comment #0) > > We are requesting a 30 day reprieve on the hard enforcement of > > sign-off-by lines in commits to give our legal dept time to approve the > > new copyright policy. > > For understanding, the 30 day period would start when? At the approval date, > i.e. 2018-09-15? I would prefer that the 30 days start on the day we get the majority vote on this bug if we are going with a vote. If we are not, it should start asap, as in current time. There's no reason to have the start date in the past.
In my understanding, certifying the DCO is precisely what you would otherwise do *implicitly* by pushing to Gentoo. Which means that, if you have trouble certifying a DCO, you shouldn't push either way until that is clarified. Also, if we now, after we have the policy, deliberately remove its enforcement (whether for one person or all does not matter), that makes * all non-certified commits somewhat suspect * and us complicit if there are problems with these commits. For these reasons I vote no. (Sorry, that's not personal, but you've had plenty of time to take care of this beforehand.)
(In reply to Andreas K. Hüttel from comment #10) > In my understanding, certifying the DCO is precisely what you would > otherwise do *implicitly* by pushing to Gentoo. Which means that, if you > have trouble certifying a DCO, you shouldn't push either way until that is > clarified. > > Also, if we now, after we have the policy, deliberately remove its > enforcement (whether for one person or all does not matter), that makes > * all non-certified commits somewhat suspect > * and us complicit if there are problems with these commits. I second that. An affected developer might now argue that he/she is only asking to postpone the enforcement, e.g. keep status quo from before that decision just a little bit longer. So what's the big deal here? Before "today" we assumed that any Gentoo developer has the permission to commit somehow. Now we have real reasons to believe that some developers don't have that permission at all. With that knowledge I think we cannot even keep previous status. So any affected developer should stop pushing until he/she got a written permission from their employer's legal department.
I vote no on a transitional period. The GLEP draft was first posted in June, and during the discussion nobody has mentioned that a transitional period would be necessary. Neither was that issue raised during the council meeting approving GLEP 76. As far as whitelisting of specific devs is concerned, I would not vote against that, if it was for a limited time (e.g., one month). Still, I think that it is highly problematic if at this point you cannot certify that your contributions are under a free software license.
Here is a bit more clarification. The policy wasn't finalized and approved until the September Council Meeting -- you can't send a draft to a corporate legal dept and have them approve it. They are interested in the final policy. They approve contributions by project, not by license agreement, so the ceph contributions cited in this bug were approved for ceph. We are working to make Gentoo an approved project, but we have no idea how long that process will take. All we can do is file a form and mark it urgent. All we are asking for from Gentoo is flexibility while we are waiting.
Fortunately, our company approved glep 76 yesterday, so we are back to committing to Gentoo. Feel free to close this bug.
