So it turns out everyone and their mother's attorneys love the
Signed-off-by tag and its definition as explained on the Linux kernel
under the Developer's Certificate of Origin. Its to the extent other
projects have picked it up and started documenting their own
documentation for submitting patches to embrace the same definition,
some without knowing what they were doing, some knowingly and
rightfully doing so. I think it'd be good to see more embracement of
the tag but to help do this it occurs to me perhaps it'd be good to
treat the 'Developer's Certificate of Origin' as a standalone
document that we can reference independently, and then have the kernel
itself refer to it. That is, provide a unified easy way to refer to
the practice for requiring the SOB tag and what it means.
Thoughts?
Luis
On Tue, 20 Nov 2012 12:59:40 -0800
"Luis R. Rodriguez" <[email protected]> wrote:
> So it turns out everyone and their mother's attorneys love the
> Signed-off-by tag and its definition as explained on the Linux kernel
> under the Developer's Certificate of Origin. Its to the extent other
> projects have picked it up and started documenting their own
> documentation for submitting patches to embrace the same definition,
> some without knowing what they were doing, some knowingly and
> rightfully doing so. I think it'd be good to see more embracement of
> the tag but to help do this it occurs to me perhaps it'd be good to
> treat the 'Developer's Certificate of Origin' as a standalone
> document that we can reference independently, and then have the kernel
> itself refer to it. That is, provide a unified easy way to refer to
> the practice for requiring the SOB tag and what it means.
>
> Thoughts?
Nobody is stopping you putting a copy on a web site.
On 11/20/2012 10:16 PM, Alan Cox wrote:
> On Tue, 20 Nov 2012 12:59:40 -0800
> "Luis R. Rodriguez" <[email protected]> wrote:
>>
>> Thoughts?
>
> Nobody is stopping you putting a copy on a web site.
Correct me if I am wrong, but I think what Luis is referring to, is the
fact that the 'Developer's Certificate of Origin' is currently included
in the SubmittingPatches file. Probably the proposal is to take it out
and have it in a separate document in the tree.
Gr. AvS
On Tue, Nov 20, 2012 at 2:08 PM, Arend van Spriel <[email protected]> wrote:
> On 11/20/2012 10:16 PM, Alan Cox wrote:
>>
>> On Tue, 20 Nov 2012 12:59:40 -0800
>> "Luis R. Rodriguez" <[email protected]> wrote:
>>>
>>>
>>> Thoughts?
>>
>>
>> Nobody is stopping you putting a copy on a web site.
>
>
> Correct me if I am wrong, but I think what Luis is referring to, is the fact
> that the 'Developer's Certificate of Origin' is currently included in the
> SubmittingPatches file. Probably the proposal is to take it out and have it
> in a separate document in the tree.
Not just a separate document but project / github / whatever given
that other projects are referring to it now, and we stand to gain more
in the community by streamlining it more and making it ubiquitous.
Luis
> Not just a separate document but project / github / whatever given
> that other projects are referring to it now, and we stand to gain more
> in the community by streamlining it more and making it ubiquitous.
Cutting and pasting it somewhere works (subject to whatever licensing
it may have itself), as does having a list and a location for a copy, but
you still want it in the tree proper.
There's a reason that lawyers copy documents into other documents rather
than doing late dynamic binding - you want to be sure that what you
reference is the *exact* text that is valid for this case.
If you have a single master official copy and a link then you break all
that and you'd have to have everyones consensus and planning to change a
word of it.
Alan
On Tue, Nov 20, 2012 at 4:10 PM, Alan Cox <[email protected]> wrote:
>> Not just a separate document but project / github / whatever given
>> that other projects are referring to it now, and we stand to gain more
>> in the community by streamlining it more and making it ubiquitous.
>
>
> Cutting and pasting it somewhere works (subject to whatever licensing
> it may have itself), as does having a list and a location for a copy, but
> you still want it in the tree proper.
>
> There's a reason that lawyers copy documents into other documents rather
> than doing late dynamic binding - you want to be sure that what you
> reference is the *exact* text that is valid for this case.
>
> If you have a single master official copy and a link then you break all
> that and you'd have to have everyones consensus and planning to change a
> word of it.
Ah so keep the original in place to let references to the original in
whatever way those may exist to keep pointing but promote new usage to
a copy and.. perhaps refer to the new copy in master, or just leave
that in place as is?
Luis
On 11/21/2012 02:13 AM, Luis R. Rodriguez wrote:
> Ah so keep the original in place to let references to the original in
> whatever way those may exist to keep pointing but promote new usage to
> a copy and.. perhaps refer to the new copy in master, or just leave
> that in place as is?
It depends if they really want to have the same thing we do. I.e. don't
they want to rephrase the document a bit? If so, there is no point of
linking the document at all.
If no, we can create a separate document from that in the kernel so that
we allow people to link that at some fixed version using git commit SHA.
This can be done easily doing a link to git.kernel.org.
The link to git.kernel.org might seem to be long. One can create a
dynamic helper on some web like signed-off-by.cgi?id=SHA and it will
return that document in that version. (It will redirect basically.)
regards,
--
js
suse labs
> > If you have a single master official copy and a link then you break all
> > that and you'd have to have everyones consensus and planning to change a
> > word of it.
>
> Ah so keep the original in place to let references to the original in
> whatever way those may exist to keep pointing but promote new usage to
> a copy and.. perhaps refer to the new copy in master, or just leave
> that in place as is?
I imagine people would make copies of it for their project and treat it
as a reference document to work from. Possibly also a mailing list ?
Alan
On Wed, Nov 21, 2012 at 12:10:43AM +0000, Alan Cox wrote:
> > Not just a separate document but project / github / whatever given
> > that other projects are referring to it now, and we stand to gain more
> > in the community by streamlining it more and making it ubiquitous.
>
> Cutting and pasting it somewhere works (subject to whatever licensing
> it may have itself), as does having a list and a location for a copy, but
> you still want it in the tree proper.
I'm transitioning a project to the DCO-1.1 and trying to get its
licensing straightened out. The DCO-1.0 [1] and DCO-1.1 [2] commits
were both by Linus, but lacked SOB lines in the commit. The initial
proposal was also by Linus [3] (and this initial DCO version is what
was committed in [1]). However, the OSDL (where Linus was working at
the time) seems to claim copyright for itself and claims
CC-BY-SA-2.5-generic [4]. Strangely, the DCO-1.1 text listed on the
archived OSDL page does not match the text of the DCO-1.1 text in the
kernel tree (the differences look minor to me, but I'm not a laywer).
So. What license is the DCO distributed under and who holds
copyright?
Cheers,
Trevor
[1]: From: Linus Torvalds
Subject: Start documenting the sign-off procedure in SubmittingPatches
Date: 2004-06-01 19:13:52 GMT
Gmane: http://permalink.gmane.org/gmane.linux.kernel.commits.head/33254
ChangeSet 1.1726.1.148, 2004/06/01 12:13:52-07:00, torvalds…
[2]: commit cbd83da82b15292337ff2b71e619c9a3a95f6d80
Author: Linus Torvalds <[email protected]>
Date: Mon Jun 13 17:51:55 2005 -0700
Update DCO ("signoff") rules to 1.1
[3]: From: Linus Torvalds <torvalds <at> osdl.org>
Subject: [RFD] Explicitly documenting patch submission
Date: 2004-05-23 06:46:29 GMT
Gmane: http://article.gmane.org/gmane.linux.kernel/205867
[4]: http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html
--
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