Make sign-off for contributed content explicit about deprecated-website HOT 18 CLOSED

Here's a dump of the earlier mailing list discussion into this issue:

On Sat, Dec 08, 2012 at 09:39:54AM -0800, Greg Wilson wrote:
> Create some sort of sign-off for content contributors so that it's
> clear we have the right to use stuff.

On Sat, Dec 08, 2012 at 11:54:44AM -0500, W. Trevor King wrote:
> On Sat, Nov 24, 2012 at 10:36:35AM -0500, W. Trevor King wrote:
> > On Mon, Oct 29, 2012 at 02:57:59PM -0400, Greg Wilson wrote:
> > > [reformatted to remove HTML]
> > > * Licensing
> > >   * Existing content is CC-BY / MIT licensed
> > >   * Do *not* want to have to manage content with multiple licenses
> > >   * Need sign-off from contributors
> > >   * Linux Submitting Patches [1] guide and GitHub's Contributing
> > >     Guidelines [2] are both examples we can copy.
> > >
> > > [1]: http://kernel.org/doc/Documentation/SubmittingPatches
> > > [2]: https://github.com/blog/1184-contributing-guidelines
> > 
> > I've been trying to figure out the licensing for Linux's Developer
> > Certificate of Origin (listed in SubmittingPatches).  As best I can
> > determine, it is CC BY-SA 2.5 generic, copyright by the OSDL [1].
> > 
> > I've asked for clarification on this issue [2], because if it is true
> > and we want to stick to pure CC BY 3.0 unported, the Linux DCO is
> > *not* and example we can copy.
> > 
> > [1]: http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html
> > [2]: Thread:  http://thread.gmane.org/gmane.linux.kernel/1397613
> >      Message: http://article.gmane.org/gmane.linux.kernel/1400065
> 
> I emailed some of the related Linux/Git devs to get explicit
> confirmation of the licensing for the DCO/s-o-b.  The clearest
> response I got was:
> 
> On Sat, Nov 24, 2012 at 02:39:39PM -0800, Greg Kroah-Hartman wrote:
> > All you should care about is the DCO itself, if you want to use it
> > somewhere else.
> >
> > Using it in the Git project, which has the same license as the kernel,
> > should be fine, so there's no problem there.
> 
> So it looks like the DCO/s-o-b documentation is under GPLv2-exact.
> 
> I've pulled relevant commits from Linux and Git out into a new
> repository [1], with some of my own documentation on top.  This can be
> merged directly into GPLv2-exact projects, but the SWC docs are under
> CC BY 3.0, which isn't GPLv2 compatible.  To handle cases like this,
> I've put added contributing [2] and contributing-github [3] branches
> that contain CC0-licensed CONTRIBUTING files which link to external
> documentation.  For an example of this in action, see the GPLv{2,3}
> rss2email [4].
> 
> I think this is now ready for use by SWC projects, but we can discuss
> that on the 19th.  For anyone interested in the actual procedure (and
> not the particulars of how to link to the procedure), look here [5].
> 
> [1]: https://github.com/wking/signed-off-by
> [2]: https://github.com/wking/signed-off-by/tree/contributing
> [3]: https://github.com/wking/signed-off-by/tree/contributing-github
> [4]: https://github.com/wking/rss2email/
> [5]: https://github.com/wking/signed-off-by/blob/master/Documentation/SubmittingPatches

from deprecated-website.

So if I understand this, we're going to link to https://github.com/wking/signed-off-by/blob/master/Documentation/SubmittingPatches in our contributing guidelines and then just have people put a signed-off-by line in their commit messages?

from deprecated-website.

On Sat, Dec 08, 2012 at 10:22:44AM -0800, Matt wrote:

So if I understand this, we're going to link to
https://github.com/wking/signed-off-by/blob/master/Documentation/SubmittingPatches
in our contributing guidelines and then just have people put a
signed-off-by line in their commit messages?

Yup. The link actually uses an explicit commit hash instead of
master, so it is clear which version of a potentially evolving
SubmittingPatches a particular s-o-b agreed to.

This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

from deprecated-website.

If a pull request contains many commits does the s-o-b line need to be in all of them or just one?

from deprecated-website.

On Sat, Dec 08, 2012 at 01:47:09PM -0500, W. Trevor King wrote:

To signoff on already-made commits, you'll either need to use git rebase --interactive or roll something up with filter-branch.

For example (from the filter-branch man page!):

$ git filter-branch --msg-filter '
               cat &&
               echo "Acked-by: Bugs Bunny <[email protected]>"
       ' HEAD~10..HEAD

from deprecated-website.

So the s-o-b line has to be in every commit?

from deprecated-website.

On Sat, Dec 08, 2012 at 10:57:02AM -0800, Matt wrote:

So the s-o-b line has to be in every commit?

Yup.

However, when Linux moved to the DCO/s-o-b, they didn't hunt down all
of the thousands of earlier devs and request signoffs for old patches.
SWC has fewer developers, so back-sign-offs would be easier for us.
Deciding whether they are a good idea is probably up to Greg.

from deprecated-website.

In the recent conference call, Greg suggested getting back-signoffs
for past commits. For the Subversion stuff, this may not be very
complicated (I don't know enough about Subversion to know), but it
will probably cause a problem in Git. Editing existing commit
messages to add s-o-b lines will change the commit hash, and you'll
get all the usual problems from publishing rewritten history 1. If
we are interested in going ahead with such a rebase, we should do it
soon to minimize the pain.

from deprecated-website.

This conversation has become a bit scattered, which is completely my fault, so:

1. The 'website' repo will have the complete, authoritative wording of our license (in 'license.html', as is) and the guidelines for contributors (which will go in a new file 'contributing.html' in the root directory of the 'website' repo.

2. The 'contributing.html' page will say that by submitting material for inclusion in this site, authors are confirming that blah, and agreeing to blah --- Trevor, this is your wording. There won't be an explicit sign-off for new contributions (as there isn't for IPython and other scientific Python projects), but I will get explicit agreement from past contributors.

3. I will add wording to 'license.html' explaining the circumstances under which people may use the name 'Software Carpentry' and our logo. (The explanation of when/how they can run boot camps on a paid-for basis as corporate training will go into our FAQ, not into the 'license.html' file.

4. Other repos (assets, boot-camps, 3_0, 4_0) will have a README.md file which includes the following wording:

   Software Carpentry is an open source/open access/open license
   project. Our software is released under the MIT License, and
   all other content under the Creative Commons - Attribution 3.0
   Unported License, while the name 'Software Carpentry' and our
   logo are both trademarked. For a full description of the terms
   of these licenses, and of the conditions under which you may use
   our name or logo, see:

   http://software-carpentry.org/license.html

   We welcome contributions to this project --- please see:

   http://software-carpentry.org/contributing.html

   for a full description of how to help.

5. We won't include the full text of the CC-BY license in our repo, but will continue to link to the Creative Commons' full-text page.

Any strong objections?

from deprecated-website.

On Sun, Dec 30, 2012 at 10:59:48AM -0800, Greg Wilson wrote:

1. The 'website' repo will have the complete, authoritative wording
   of our license (in 'license.html', as is) and the guidelines for
   contributors (which will go in a new file 'contributing.html' in the
   root directory of the 'website' repo.

I'd prefer a plain-text CONTRIBUTING or a Markdown CONTRIBUTING.md to
take advantage of GitHub's extra visibility 1.

1. The 'contributing.html' page will say that by submitting material
   for inclusion in this site, authors are confirming that blah, and
   agreeing to blah --- Trevor, this is your wording.

I can't give good wording here. I can link you to the DCO wording,
but if that's not acceptable, you'll probably want a real lawyer to
chime in.

There won't be an explicit sign-off for new contributions (as there
isn't for IPython and other scientific Python projects), but I
will get explicit agreement from past contributors.

Works for me.

1. Other repos [snip] will have a README.md file

This looks ok, but I think it should be called CONTRIBUTING.md.
README.md should explain what each repository is meant to do or how
to use it (not when you are allowed to use it).

I'm still not sure why linking from here to the website repository is
easier to use/maintain than just copying the relevant documentation
from the website repository, but I'm willing to be overruled.

from deprecated-website.

On 2012-12-30 2:24 PM, W. Trevor King wrote:

On Sun, Dec 30, 2012 at 10:59:48AM -0800, Greg Wilson wrote:

1. The 'website' repo will have the complete, authoritative wording
   of our license (in 'license.html', as is) and the guidelines for
   contributors (which will go in a new file 'contributing.html' in the
   root directory of the 'website' repo.

I'd prefer a plain-text CONTRIBUTING or a Markdown CONTRIBUTING.md to
take advantage of GitHub's extra visibility [1].

I want the material to appear on software-carpentry.org as well --- if
we're willing to complicate our tool chain a bit, we could translate
CONTRIBUTING.md to create contributing.html, pull content from that, and
include it in build/contributing.html in order to avoid duplication, but
bleah.

1. The 'contributing.html' page will say that by submitting material
   for inclusion in this site, authors are confirming that blah, and
   agreeing to blah --- Trevor, this is your wording.

I can't give good wording here. I can link you to the DCO wording,
but if that's not acceptable, you'll probably want a real lawyer to
chime in.

Re-send the DCO wording and I'll craft something, then add it to the
pile of things I need to show legal.

1. Other repos [snip] will have a README.md file

This looks ok, but I think it should be called CONTRIBUTING.md.
README.md should explain what each repository is meant to do or how
to use it (not when you are allowed to use it).

Works for me.

I'm still not sure why linking from here to the website repository is
easier to use/maintain than just copying the relevant documentation
from the website repository, but I'm willing to be overruled.

DRY?

Thx,
G

from deprecated-website.

On Sun, Dec 30, 2012 at 11:28:23AM -0800, Greg Wilson wrote:

I want the material to appear on software-carpentry.org as well --- if
we're willing to complicate our tool chain a bit, we could translate
CONTRIBUTING.md to create contributing.html, pull content from that, and
include it in build/contributing.html in order to avoid duplication, but
bleah.

Or we can just duplicate this almost entirely static content ;).

Re-send the DCO wording and I'll craft something, then add it to the
pile of things I need to show legal.

https://github.com/wking/signed-off-by/blob/master/Documentation/SubmittingPatches

I'm still not sure why linking from here to the website repository is
easier to use/maintain than just copying the relevant documentation
from the website repository, but I'm willing to be overruled.

DRY?

Moderation in all things? ;)

from deprecated-website.

On Sat, Dec 29, 2012 at 03:07:27PM -0500, Greg Wilson wrote:
Also, Trevor, can you prepare a short email we can send to everyone
who's ever given us content (I have a list) asking for retroactive
confirmation of licensing?

On Sun, Dec 30, 2012 at 01:04:18PM -0500, Greg Wilson wrote:
2. The 'contributing.html' page will say that by submitting material
for inclusion in this site, authors are confirming that blah, and
agreeing to blah --- Trevor, this is your wording.  There won't be
an explicit sign-off for new contributions (as there isn't for
IPython and other scientific Python projects), but I *will* get
explicit agreement from past contributors.

I don't have a good way to explain why you'd want this to be explicit
for past contributors, but implicit for future contributors. If
you're dropping sign-offs for new folks, you should probably come up
with a clear phrasing for your motivation to avoid weirding people out
;).

Here's what I'd say, adjust as needed (and probably run it by a
lawyer):

Subject: License sign-off for earlier Software Carpentry contributions

TARGET PERSON,

To improve tracking of who did what (EDIT but only for past commits),
we're taking a page from the Developer Certificate of Origin (DCO)
introduced by the Linux kernel 1 after the SCO lawsuit 2. The
Linux project has thousands of developers and an early history only
stored in mailing list archives 2, so they didn't bother getting DCO
signoffs on existing commits. Software Carpentry has a few less
contributors, so we're tracking you down and asking for back-sign offs
on your earlier SWC work.

Here's the DCO from Linux's SubmittingPatches [3,4]:

Developer's Certificate of Origin 1.1

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 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.

Please let us know which of the following commits you can certify are
covered by this DCO.

http://svn.software-carpentry.org/swc@123
http://svn.software-carpentry.org/swc@4567
…
(Replace as necessary for a particular author. It doesn't seem like
SWC has a Subversion history browser (e.g. WebSVN), but it would be
nice if you could link the old developers to a browsable version of
the commits you'd like them to certify)

If you can certify this for any of the above commits, please respond
with:

I certify that I my following commits were made under the
Developer's Certificate of Origin 1.1:

(list any commits you would like to certify, for example:
 http://svn.software-carpentry.org/swc@123
 http://svn.software-carpentry.org/swc@4567)

Signed-off-by: Random J Developer [email protected]

Explicitly certifying commits under DCO allows us (Software Carpentry,
under clause (d)) to post your commit in a public place (e.g. on
http://svn.software-carpentry.org/ or GitHub), which is legally
ambiguous in some jurisdictions without explicit authorization
[6,7,8]. For the motivation behind clauses (a) through (c), see
Linus' original post is 2.

Thanks,
YOUR NAME HERE (and again in [4] below)

[4]: The DCO text itself is probably under the GPLv2 copyright Linus
Torvalds and maybe others [1,2,5], so this email itself is GPLv2,
copyright Linus Torvalds, W. Trevor King, YOUR NAME HERE, and
maybe others. Feel free to send it to your friends ;).

from deprecated-website.

One question I have as someone new to the project: Are there any directions on how one can contribute, sort of like developer documentation for an open source project? I wholeheartedly believe in the goals and message of Software Carpentry, but there's a bewildering amount of material in the repos. I looked around for guidelines on contributing on the development side, and what I found was the web page I believe you're discussing. The types of questions I have are things like:

• Is there a specific style I should be following when I contribute code or material?
• Are there any organizational guidelines when it comes to how files and folders are organized within the repos?
• If I want to start contributing code, where should I start to get up to speed on the project?

I'm not terribly experienced in contributing to open source projects, and the ones I have contributed to are ones where I started out as a user. Here, it seems, the "user" role doesn't quite fit so well here, because I'd been reading up about these issues (more on the software construction side) before I joined Software Carpentry. I'm also somewhat familiar with large parts of what you guys teach in your boot camps. Would going through that material be the place to start, even though I'm familiar with a lot of it?

Is addressing these types of questions even appropriate for a contributions page?

from deprecated-website.

On Mon, Dec 31, 2012 at 06:21:48PM -0800, Geoffrey Oxberry wrote:

• Is there a specific style I should be following when I contribute
  code or material?

Currently this is not documented. It will probably be “look at
similar stuff in the repository for inspiration”, but you can also
submit whatever you like and we'll comment in the pull request.

• Are there any organizational guidelines when it comes to how files
  and folders are organized within the repos?

For the website, it's just “match what's already there”. For the boot
camps, there's a preliminary outline 1, but nothing that's been
agreed upon yet ;).

• If I want to start contributing code, where should I start to get
  up to speed on the project?

What are you trying to contribute? I think a lot of the current work
is related to streamlining the development process and reorganizing
after the migration to Git. A number of content-development issues
are blocking on this reorganization, but if you have a specific goal
in mind we can probably give you hints. Start a new issue with your
big picture idea, and we'll help fill in the details.

Would going through that material be the place to start, even though
I'm familiar with a lot of it?

Probably. Bug-fixes to existing material (e.g. typo corrections), are
easy to merge without triggering structural arguments (which is why
the discussion of structural issues are taking so long to resolve,
since they probably won't be revisited soon).

Is addressing these types of questions even appropriate for a
contributions page?

Sure. There is something along these lines in Matt's preliminary
CONTRIBUTING.md for the boot-camps repo (swcarpentry/DEPRECATED-boot-camps#6).

from deprecated-website.

Style and organization are definitely the types of things that will be documented in the contributing guidelines (at minimum there will be links to other docs). swcarpentry/DEPRECATED-boot-camps#6 is a start for that repo, for other repos we still need to work on the docs.

from deprecated-website.

I think we've decided to drop this requirement?

from deprecated-website.

That is my recollection.

from deprecated-website.