Ævar Arnfjörð Bjarmason wrote: > On Thu, Dec 24 2020, Felipe Contreras wrote: > > > Ævar Arnfjörð Bjarmason wrote: > >> On Wed, Dec 23 2020, Felipe Contreras wrote: > >> > >> > When I express my dissenting opinion I'm not saying nobody should write > >> > a patch on top of mine. Of course they can. Anybody can take my code and > >> > do whatever they want with it (as long as they don't violate the license > >> > of the project). > >> > > >> > What they cannot do is add my Signed-off-by line to code I don't agree > >> > with. > >> > >> I don't think that's what Signed-off-by means, per SubmittingPatches: > >> > >> To improve tracking of who did what, we ask you to certify that you > >> wrote the patch or have the right to pass it on under the same > >> license as ours, by "signing off" your patch[...under the DCO: > >> https://developercertificate.org/] > > > > Yes, but the DCO requires (d): > > > > d. I understand and agree that this project and the contribution are > > public and that a record of the contribution (including all personal > > information I submit with it, including my sign-off) is maintained > > indefinitely and may be redistributed consistent with this project or > > the open source license(s) involved. > > > > We can narrow down the part I'm talking about: > > > > d. I *agree* that a record of the contribution is maintained > > indefinitely. > > > > I don't agree with that. > > I don't understand you here. You don't agree that we retain > Signed-off-by lines indefinitely, or just in the case of amended > patches? The DCO requires that I agree that a record of my contribution is maintained indefinitely. If I don't agree that a record of a particular contribution is maintained indefinitely, the DCO says you shouldn't use it. > > Moreover, the relevant definition of "sign off" in English in my opinion > > is [1]: > > > > to approve or acknowledge something by or as if by a signature (sign > > off on a memo) > > > > If I didn't put my "signature" in a commit, then it's not signed off by > > me. > > I think this use of 'signed off" makes perfect sense if you interpret > the sign-off to mean "I signed off on the copyright eligibility of this > work for inclusion" which is what I think it means. > > Not "I signed off on my subjective approval of this patch & what it's > for etc.", which seems to be closer to your interpretation. Why does it have to be only one meaning? Junio doesn't sign off on a patch that he doesn't think is good. Same happens with all the lieutenants of Linux. > >> "No Discrimination Against Fields of Endeavor" is an integral part of > >> free software & open source. In our case it means that when you > >> contribute code under our COPYING terms someone else might use in a way > >> you don't approve of. > > > > Yes, you just have to make the record straight; do your changes in a > > separate commit without my "sign off". > > We like to maintain "make test" passing for every commit, and sometimes > we have patches on the ML with a SOB that don't even compile yet, let > alone pass tests, because they were provided by their authors as "maybe > try this" or other near-pseudocode. > > We also like to optimize patch order/size/splits/etc. for the benefit of > reviewers. Sometimes someone might send a patch with a SOB that's better > squashed into another one, or refactored into N commits spread across a > series etc. Yes. And most of the time that's fine, because the original author is not objecting to the clause (d). > >> E.g. I'm sure that arms contractors, totalitarian regimes etc. or other > >> entities some might disapprove of are using git in some way. > > > > Yes, and you can modify my patch and keep my s-o-b, I'm not going to sue > > you. > > > > I just don't think that's right. > > > >> That non-restriction on fields of endeavor also extends to individual > >> patches licensed under a free software license & the necessity to > >> maintain a paper trail about who their authors are and if they certified > >> them under the DCO. > > > > Sure, so if you need to keep a paper trail about the copyright of the > > code, why would you risk that simply because the author didn't agree on > > the further changes. > > > > Just do them on a separate commit. Problem solved. > > I don't understand how the copyright paper trail is at risk just because > we combine N patches into one. It's not just a copyright paper trail, the DCO clearly states that the author should: d. I *agree* that a record of the contribution is maintained indefinitely. > The important part is that we have a declaration that the sum of the > work (and whatever it's derived from) is properly licensed, that the > authors had the right to license it for inclusion etc. That's the important part, yes. It's not the only part. Cheers. -- Felipe Contreras
