A problem that has arisen several times in the history of LinuxCNC is that a well-meaning developer contributes to the software, but their additions are not explicitly licensed. If they have moved on to other projects by the time someone realizes this, it can be difficult to get their permission later simply because of their disinterest. If they have added new files or added code in files without a license block, this problem is compounded.
In the Linux kernel, they have addressed this problem by requiring a "Signed-off-by" pseudo-header in every commit message. The presence of a Signed-off-by means that the named person certifies the Deveoper Certificate of Origin, which basically states that the contribution is Open Source that is compatible with the project's license. (Unlike a Contributor License Agreement (CLA) used in some projects, this does not take away or transfer any rights of the developer, or give any special rights to LinuxCNC; the developer owns their submission, and LinuxCNC can only use it under the stated license(s). In any case, LinuxCNC could not use a CLA since there is no legal LinuxCNC entity) I believe we should adapt and adopt this practice in LinuxCNC, in order to remove doubt about any submitted code in the future. (In fact, the git workflow pages we originally wrote for the wiki called for use of s-o-b but most developers--including me--do not routinely remember to use "git commit -s") I have prepared some files based on https://github.com/wking/signed-off-by with some modifications for LinuxCNC; it is prepared in a form that could be merged into all our maintainance branches (or, rather, merged into 2.5 and then merged up to 2.6 and master). Due to the "new file" problem, I added a clause to the DCO stating that in any case the contribution is compatible with "GPLv2+" licensing. This also helps with file types that cannot easily carry license notifications, such as images. I enclose the proposed patch (but not as a git patch, because it actually merges history from wking's repository) and welcome comments. Please follow up to the mailing list. I also believe that we should implement a pre-receive or update hook that checks for s-o-b headers and rejects any push that doesn't have them; I have a partially implemented script for that, but it's not debugged yet. Otherwise, un-s-o-b'd code will inevitably creep in by the actions of well-meaning developers. Jeff diff --git a/docs/SubmittingPatches b/docs/SubmittingPatches new file mode 100644 index 0000000..efa4cc3 --- /dev/null +++ b/docs/SubmittingPatches @@ -0,0 +1,46 @@ +To improve tracking of who did what, we use the "sign-off" procedure +introduced by the Linux kernel. The sign-off is a simple line at the +end of the explanation for the patch, which certifies that you wrote +it or otherwise have the right to pass it on as an open-source patch. +The rules are pretty simple: if you can certify the Developer's +Certificate of Origin 1.1 with GPLv2+ clause (see the +developer-certificate-of-origin file), then you just add a line saying + + Signed-off-by: Random J Developer <[email protected]> + +using your real name (sorry, no pseudonyms or anonymous +contributions). This line can be automatically added by git if you +run the git-commit command with the -s option. + +If you like, you can put extra tags at the end: + +1. "Reported-by:" is used to credit someone who found the bug that + the patch attempts to fix. +2. "Acked-by:" says that the person who is more familiar with the area + the patch attempts to modify liked the patch. +3. "Reviewed-by:", unlike the other tags, can only be offered by the + reviewer and means that she is completely satisfied that the patch + is ready for application. It is usually offered only after a + detailed review. +4. "Tested-by:" is used to indicate that the person applied the patch + and found it to have the desired effect. + +You can also create your own tag or use one that's in common usage +such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:". + +Sometimes you need to slightly modify patches you receive in order to +merge them, because the code is not exactly the same in your tree and +the submitters'. If you stick strictly to rule (c), you should ask the +submitter to rediff, but this is a totally counter-productive waste of +time and energy. Rule (b) allows you to adjust the code, but then it +is very impolite to change one submitter's code and make him endorse +your bugs. To solve this problem, 0K .. it is recommended that you add a +line between the last Signed-off-by header and yours, indicating the +nature of your changes. While there is nothing mandatory about this, +it seems like prepending the description with your mail and/or name, +all enclosed in square brackets, is noticeable enough to make it +obvious that you are responsible for last-minute changes. Example : + + Signed-off-by: Random J Developer <[email protected]> + [[email protected]: struct foo moved from foo.c to foo.h] + Signed-off-by: Lucky K Maintainer <[email protected]> diff --git a/docs/developer-certificate-of-origin b/docs/developer-certificate-of-origin new file mode 100644 index 0000000..41229ad --- /dev/null +++ b/docs/developer-certificate-of-origin @@ -0,0 +1,43 @@ +Developer Certificate of Origin +Version 1.1 + +Copyright (C) 2004, 2006 The Linux Foundation and its contributors. +660 York Street, Suite 102, +San Francisco, CA 94110 USA + +Everyone is permitted to copy and distribute verbatim copies of this +license document, but changing it is not allowed. + +Developer's Certificate of Origin 1.1 + +By making a contribution to this project, I certify that: + +(a) The c.ontribution was created in whole or in part by me and I + have the right to submit it under the open source 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 open source + 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 open source 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. + +(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. + +[verbatim copy of Developer's Certificate of Origin 1.1 ends just above +this line] + +In addition, by making a contribution to this project, I certify that: + +.(e) The contribution is covered under a license that is compatible + with the GNU GPL version 2 with the "or later" clause. 100% 4.49M=0.001s 2014-07-31 09:06:22 (4.49 MB/s) - written to stdout [4642/4642] ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
