Skip to main content
Topic: Drop the "sign-off" from the requirements? (Read 6473 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Drop the "sign-off" from the requirements?

Background: back in the SMF-era, the "sign-off" was introduced in order to kind of replace the CLA. Obviously the two things are completely different.

So, the question is: after ne year and a half of development, do we still need that "tool"?
What do you think about dropping that requirement from the contributions?
Bugs creator.
Features destroyer.
Template killer.

Re: Drop the "sign-off" from the requirements?

Reply #1

What's the sign-off?


Re: Drop the "sign-off" from the requirements?

Reply #3

Does it benefit tracking contributions, or do you have other methods to do that?

If the former, keep it. If the latter, toss it.

Re: Drop the "sign-off" from the requirements?

Reply #4

It's too make sure all contributions follow the BSD license right?  So no one tries to claim you didn't have rights to their code later.

Re: Drop the "sign-off" from the requirements?

Reply #5

It's a feature that was used by the Linux guys as a way to say the authors were giving away a license to use it to Linux. However has no legal footing AFAIK and is only a de facto standard because everyone does it.

In fact I'm not sure a court of law would give any attention to this, despite the fact that the feature was created for them. I mean, without PGP signing, anyone can forge your commits and signatures.

If people start committing and signing off things in someone else's name, what is the legal value of regular sign offs? Zero.

Note: this commit...
https://github.com/elkarte/Elkarte/commit/5b977403fd16a2c75c1d59c5aa473852ad4ffff4
Why was it made on my name, but without my knowledge?
Also, why was it signed-off, rather than acked-by?
Last Edit: April 05, 2014, 04:59:40 am by Nao

Re: Drop the "sign-off" from the requirements?

Reply #6

Standard disclaimer applies: IANAL.

That said, my feeling is that the legal basis are zero or close to. Especially if the sign-off is done using a nickname and/or a fake email.

The sign-off is "something in addition to".
Let's take the case Nao posted: it was used his name because he proposed the patch (somewhere on the forum) and use his name means attribution (I find it nicer than adding a string to the commit message): Nao proposed the patch, he didn't explicitly state the license under which he released the patch, the person doing the commit takes (in front of the project) the responsibility to say "I know Nao has released the patch under a license acceptable for the project.

Of course, the very act of doing the commit states pretty much the same thing because git tracks both the "author" (or better the one that the commit was "authored" to (hoping that the sentence makes sense in English), and the person that actually run the command "git commit".

Now, why did I raise the point?
https://github.com/elkarte/Elkarte/pull/1524

In that case, at the moment, I have two options:
1) ask scripple to repeat the commit (but I hate to ask people to re-do what they have already done),
2) grab the branch, do a rebase, sign-off the commit myself, push and merge it.

It's in fact a barrier to contribution, and I have seen several pull requests refused somewhere else just for that (of course refuse the contribution is the most wrong thing you can do, at the very least the first time you do 2 and suggest the author to use -s next time), and I would avoid that situations.

@Spuds?
@TE?
You have the longest history of contributions, how do you feel about that?
Bugs creator.
Features destroyer.
Template killer.

Re: Drop the "sign-off" from the requirements?

Reply #7

Quote from: emanuele – The sign-off is "something in addition to".
Let's take the case Nao posted: it was used his name because he proposed the patch (somewhere on the forum) and use his name means attribution (I find it nicer than adding a string to the commit message):
I prefer having my name in the changelog rather than the author field, because of how GitHub works... I get 'credit' for that commit, even though I didn't do it.[1] The only reason I noticed is because I checked my Ohloh account, and I had an extra commit in Elk, and I didn't get why. At first I thought some Wedge commit had been integrated without approval. Anyway, I'm probably not familiar enough with github flows to find it 'normal'. Am I upset? Of course not. I just think that this is the kind of example that demonstrates it's hard to find a legal ground for sign-offs (vs. no sign-offs.)

QuoteNao proposed the patch, he didn't explicitly state the license under which he released the patch,
Well, it's just removing a constant from a list. It's not even fixing a bug... It's just saving a few bytes. It's released under the Common Sense License. ;D (i.e., "if you think you can claim any kind of copyright over this, then you're crazier than I thought.")

QuoteOf course, the very act of doing the commit states pretty much the same thing because git tracks both the "author" (or better the one that the commit was "authored" to (hoping that the sentence makes sense in English), and the person that actually run the command "git commit".
Yes, in this case I'm in the Author field, not in the Commit Name field. But then again, it's easy to do a git filter command to change the commit name for the last entry, and then do a PR for that (or push it directly.)

QuoteNow, why did I raise the point?
https://github.com/elkarte/Elkarte/pull/1524
No surprise here. Even at Wedge, a couple of my new contributors had a LOT of trouble getting to sign-off their commits.
Not only that, but GITHUB ITSELF does not sign-off commits made on behalf of others through the UI, e.g. PR merges on Wedge are made using my name, but not sign-off, or acked-by, or anything. At this point, you end up with a repo full of commits that aren't signed-off, and no "legal" way to say that "it's okay, the merger is part of the project".

If someone decides to edit a Wedge language file in the Wedge/languages repo, they can. It'll create a pull request. However, the web edit feature also DOES NOT add a sign-off mention automatically. So, what should we say..?
I also forgot to sign off one of my commits to the Plugins repo (I think... Or languages repo) recently, then I pushed. I realized that a couple of days later. It was too late to do a force push and re-add the sign-off. Meaning that commit was suddenly no longer part of the "signed off contents" of Wedge. How do you deal with that..? Personally, I have no time to waste checking that everyone's pull requests are done "the git way". They're already done the github way, it's good enough for me. Sign off or no sign off, the simple fact that you're doing a pull request should be enough to qualify a commit as "signed off". I understand that Linux, with its e-mail-based pull requests, might need to add an extra header, but github PRs do pretty much the same thing here.

QuoteIn that case, at the moment, I have two options:
1) ask scripple to repeat the commit (but I hate to ask people to re-do what they have already done),
It's even worse than that... Especially if the person isn't very proficient in git.

Quote2) grab the branch, do a rebase, sign-off the commit myself, push and merge it.
Which takes a minimum of 2 minutes if you've already set up everything (fetching the pr branch...), and can take hours, maybe days if you don't know a thing about it and have never rebased before.

Well, it's simple: git is exactly not that -- simple. git is hard. It's very powerful, but it has a lot of limitations[2], and complexity and sign-offs are part of it. I'd be thrilled to be able to offer a 'simple' system for my users who want to contribute. Even learning SVN back in 2008 was hard to me. I can't imagine how people with no CVS experience must feel with git, these days..! Well, they must feel like gits.

QuoteIt's in fact a barrier to contribution, and I have seen several pull requests refused somewhere else just for that (of course refuse the contribution is the most wrong thing you can do, at the very least the first time you do 2 and suggest the author to use -s next time), and I would avoid that situations.
But what about people who know how to sign-off, but commit so often that sometimes they'll just forget, eh..?
(Of course, in that situation you can always force your repo to add the sign-offs. I should change my sub-repos to do that, I guess...)
I only reported the bug in question because I was comparing security header implementations between Wedge, SMF 2.1 and ElkArte to see if something wrong was done in Wedge. I don't find it a very useful fix, in fact none of the two fixes I'm credited for in ElkArte are any useful. I could have made tons more important fixes, which I didn't do because I don't want anyone thinking I'm jumping ship. It would be bad for both Elk and Wedge communities.
Pulling into a dirty repo should automatically merge new lines with uncommitted lines if they're not in direct conflict, and yet it doesn't, making it impossible for instance to have nested repos and pulling them both without having to first revert (between both pulls) any files that are in common in both repos, such as the index.english.php file in Wedge!

Re: Drop the "sign-off" from the requirements?

Reply #8

I'd be fine with removing it, I think its a throw away for us given how its used and enforced. 

It could it have teeth, sure, should it .. I don't think so.  Thats because given what we are its not enforceable (meaning unless you want to have a lawyer on retainer and set these up like true contracts and spend a bunch of money etc).  Many other projects of our size and type don't have nor require it either.    The entire thing was put in place from a project trying to pretend it was bigger than it was IMO.

I'm not going to change my use of the author tag, if someone provides an update, regardless of it simplicity, they still spent the time finding and reporting.  If they don't have a github account then I use the comments.

Now there are plenty of commits missing authors or with wrong authors or missing signoffs anyway (you are welcome  :-[ ),  so if (when) someone wants to be a dick, we have given them plenty of fodder, but thats why they are dicks.

Re: Drop the "sign-off" from the requirements?

Reply #9

Sorry to be the basis of this, I had never heard of this sign off thing and github's pull request instructions didn't mention it..  I amended the commit with a signoff and pushed it to github. 

Agree these don't seem to have much legal basis, but I'll also state here that my patch is made available under the same BSD license as the rest of Elkarte.

Re: Drop the "sign-off" from the requirements?

Reply #10

Don't worry scripple, in fact I was thinking to raise the point since a long time, I was just too lazy to... lol
I took your commit just as a good opportunity to ask the question and get the feedback needed. ;D
Bugs creator.
Features destroyer.
Template killer.

Re: Drop the "sign-off" from the requirements?

Reply #11

Sorry, I'm very short in time but I'd vote for: drop the sign-off...  :)
Thorsten "TE" Eurich
------------------------

Re: Drop the "sign-off" from the requirements?

Reply #12

Don't worry TE! ;D

Quote from: Nao – I also forgot to sign off one of my commits to the Plugins repo (I think... Or languages repo) recently, then I pushed. I realized that a couple of days later. It was too late to do a force push and re-add the sign-off. Meaning that commit was suddenly no longer part of the "signed off contents" of Wedge. How do you deal with that..? Personally, I have no time to waste checking that everyone's pull requests are done "the git way". They're already done the github way, it's good enough for me. Sign off or no sign off, the simple fact that you're doing a pull request should be enough to qualify a commit as "signed off". I understand that Linux, with its e-mail-based pull requests, might need to add an extra header, but github PRs do pretty much the same thing here.
Well, that's exactly the reason I proposed to drop the requirement.
If it is something that 1) doesn't make much difference in legal terms, 2) we are not really interested in enforcing, 3) makes more difficult for people to contribute, let's just drop it and be done with it.

Quote from: Nao –
Quote2) grab the branch, do a rebase, sign-off the commit myself, push and merge it.
Which takes a minimum of 2 minutes if you've already set up everything (fetching the pr branch...), and can take hours, maybe days if you don't know a thing about it and have never rebased before.
Well, I start from the point I know what I'm doing. :P
Also because I already did it in the past a couple of times. ;)

Quote from: Nao – Pulling into a dirty repo should automatically merge new lines with uncommitted lines if they're not in direct conflict, and yet it doesn't, making it impossible for instance to have nested repos and pulling them both without having to first revert (between both pulls) any files that are in common in both repos, such as the index.english.php file in Wedge!
Well, from that description it looks like you have two files with the same name, in the same place, but with different contents, how could a merge not complain? ???

Quote from: Nao – ven learning SVN back in 2008 was hard to me. I can't imagine how people with no CVS experience must feel with git, these days..!
No idea what CVS is, never used it, not even to have an idea of how it worked.
I had a bit of a hard time with SVN as well, but I used it just for few commits mostly alone, so not a biggie.

Quote from: Nao – But what about people who know how to sign-off, but commit so often that sometimes they'll just forget, eh..?
I have no problem grumbling at Spuds or TE in the case! :P
Bugs creator.
Features destroyer.
Template killer.

Re: Drop the "sign-off" from the requirements?

Reply #13

I think I'm going to remove this requirement for Wedge contributions.
Who's with me? :P

Re: Drop the "sign-off" from the requirements?

Reply #14

PR sent: https://github.com/elkarte/Elkarte/pull/1750

If anyone has something against it, it's time to speak, otherwise... go and for the repository. :P
Bugs creator.
Features destroyer.
Template killer.