diff options
author | Jeremy Allison <jra@samba.org> | 2011-10-11 17:00:08 -0700 |
---|---|---|
committer | Jeremy Allison <jra@samba.org> | 2011-10-12 03:46:41 +0200 |
commit | bd01ae227bc567fd7953e446236364fc4d110a48 (patch) | |
tree | d7eb82b2c9c8e19ee72c27720d9ade682f81c3ba /README.contributing | |
parent | eb971614e538a16852b3cbc3677fb06eb57e6a83 (diff) | |
download | samba-bd01ae227bc567fd7953e446236364fc4d110a48.tar.gz samba-bd01ae227bc567fd7953e446236364fc4d110a48.tar.bz2 samba-bd01ae227bc567fd7953e446236364fc4d110a48.zip |
Add new contributing FAQ announcing acceptance of corporate (C).
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Wed Oct 12 03:46:41 CEST 2011 on sn-devel-104
Diffstat (limited to 'README.contributing')
-rw-r--r-- | README.contributing | 120 |
1 files changed, 120 insertions, 0 deletions
diff --git a/README.contributing b/README.contributing new file mode 100644 index 0000000000..2d72f0c3c4 --- /dev/null +++ b/README.contributing @@ -0,0 +1,120 @@ +How to contribute a patch to Samba +---------------------------------- + +Simple, just make the code change, and email it as either a "diff -u" +change, or as a "git format-patch" change against the original source +code to samba-technical@samba.org, or attach it to a bug report at +http://bugzilla.samba.org + +For larger code changes, breaking the changes up into a set of simple +patches, each of which does a single thing, are much easier to review. +Patch sets like that will most likely have an easier time being merged +into the Samba code than large single patches that make lots of +changes in one large diff. + +Ownership of the contributed code +--------------------------------- + +Samba is a project with distributed copyright ownership, which means +we prefer the copyright on parts of Samba to be held by individuals +rather than corporations if possible. There are historical legal +reasons for this, but one of the best ways to explain it is that it's +much easier to work with individuals who have ownership than corporate +legal departments if we ever need to make reasonable compromises with +people using and working with Samba. + +We track the ownership of every part of Samba via git, our source code +control system, so we know the provenance of every piece of code that +is committed to Samba. + +So if possible, if you're doing Samba changes on behalf of a company +who normally owns all the work you do please get them to assign +personal copyright ownership of your changes to you as an individual, +that makes things very easy for us to work with and avoids bringing +corporate legal departments into the picture. + +If you can't do this we can still accept patches from you owned by +your employer under a standard employment contract with corporate +copyright ownership. It just requires a simple set-up process first. + +We use a process very similar to the way things are done in the Linux +kernel community, so it should be very easy to get a sign off from +your corporate legal department. The only changes we've made are to +accommodate the licenses we use, which are GPLv3 and LGPLv3 (or later) +whereas the Linux kernel uses GPLv2. + +The process is called signing. + +How to sign your work +--------------------- + +Once you have permission to contribute to Samba from +your employer, simply email a copy of the following text +from your corporate email address to contributing@samba.org + +------------------------------------------------------------ +Samba Developer's Certificate of Origin. Version 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 appropriate + version of the GNU General Public License; 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 GNU General Public License, in the + appropriate version; or + +(c) The contribution was provided directly to me by some other + person who certified (a) or (b) 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 metadata and personal + information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed + consistent with the Samba Team's policies and the + requirements of the GNU GPL where they are relevant. + +(e) I am granting this work to this project under the terms of both + the GNU General Public License and the GNU Lesser General Public + License as published by the Free Software Foundation; either version + 3 of these Licenses, or (at the option of the project) any later + version. + + http://www.gnu.org/licenses/gpl-3.0.html + http://www.gnu.org/licenses/lgpl-3.0.html +------------------------------------------------------------ + +We will maintain a copy of that email as a record that you have the +rights to contribute code to Samba under the required licenses whilst +working for the company where the email came from. + +Then when sending in a patch via the normal mechanisms described +above, add a line that states: + +Signed-off-by: Random J Developer <random@developer.example.org> + +using your real name and the email address you sent the original email +you used to send the Samba Developer's Certificate of Origin to us +(sorry, no pseudonyms or anonymous contributions.) + +That's it ! Such code can then quite happily contain changes that have +copyright messages such as : + + (C) Example Corporation. + +and can be merged into the Samba codebase in the same way as patches +from any other individual. You don't need to send in a copy of the +Samba Developer's Certificate of Origin for each patch, or inside each +patch. Just the sign-off message is all that is required once we've +received the initial email. + +Have fun and happy Samba hacking ! + +The Samba Team. + |