Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: gcrypt

Relaxing the need for copyright assignments

 

 

GnuPG gcrypt RSS feed   Index | Next | Previous | View Threaded


wk at gnupg

Apr 12, 2012, 2:49 AM

Post #1 of 5 (369 views)
Permalink
Relaxing the need for copyright assignments

Hi!

Nowadays we have wealth of crypto libraries available. It is often
easier to contribute to them than to Libgcrypt. The copyright
assignments required for Libgcrypt turned out to be a major hassle and
thus I plan to relax the rules.

What do you think of this:

Libgcrypt is currently licensed under the LGPLv2+ with tools and
the manual being under the GPLv2+. We may eventually update to a
newer version of the license or a combination of them. It is thus
important, that all contributed code allows for an update of the
license; thus we can't accept any code under the LGPLv2(only).

We used to have a strict policy of requiring copyright assignments
to the FSF. To avoid this major organizational overhead and to
allow inclusion of code, not copyrighted by the FSF, this policy has
been relaxed. It is now also possible to contribute code by
asserting that the contribution is in accordance to the "Libgcrypt
Developer's Certificate of Origin" as found in the file "doc/DCO".
(Except for a slight wording change, this DCO is identical to the
one used by the Linux kernel.)

If your want to contribute code (or documentation) to Libgcrypt and
you didn't signed a copyright assignment with the FSF in the past,
you need to take these simple steps:

- Decide which mail address you want to use. Please have your real
name in the address and not a pseudonym. Anonymous contributions
can only be done if you find a proxy who certifies for you.

- If your employer or school might claim ownership of code written
by you; you need to talk to them to make sure that you have the
right to contribute under the DCO.

- Send a mail to the gcrypt-devel [at] gnupg mailing list from that
mail address. Include a copy of the DCO as found in the official
master branch. Insert your name and email address into the DCO in
the same way you want to use it later. For example:

Signed-off-by: Joe R. Hacker <joe [at] example>

If you really need it, you may perform simple transformations of
the mail address: Replacing "@" by " at ", "." by " dot ".

- That's it. From now on you only need to add a "Signed-off-by:"
line with your name and mail address to the commit message.


The DCO is

Libgcrypt Developer's Certificate of Origin. Version 1.0
=========================================================

By making a contribution to the Libgcrypt 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 free software 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 free
software 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 free software 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 free software license(s)
involved.

Signed-off-by: [Your name and mail address]


I pondered with the idea of requiring OpenPGP signed statements but
rejected it. They don't gain much unless we want to establish another
complicated procedure to check the trustworthiness of the key. Even if
we would do so, we will have no way to check the provenience of the
submitted code.



Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


phcoder at gmail

Apr 12, 2012, 3:01 AM

Post #2 of 5 (351 views)
Permalink
Re: Relaxing the need for copyright assignments [In reply to]

On 12.04.2012 11:49, Werner Koch wrote:
> license; thus we can't accept any code under the LGPLv2(only).
LGPLv2-only is compatible with GPLv2+ and GPLv3+:
See: http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility

> I pondered with the idea of requiring OpenPGP signed statements but
rejected it. They don't gain much unless we want to establish another
complicated procedure to check the trustworthiness of the key. Even if
we would do so, we will have no way to check the provenience of the
submitted code.

This could allow to check that noone attempts to impersonate an already
known contributor. While legally having almost no effect it may have
other advantages like enhancing code trustworthiness if it comes from
well-known contributor but it doesn't replace the code review.

--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
Attachments: signature.asc (0.29 KB)


simon at josefsson

Apr 12, 2012, 3:12 AM

Post #3 of 5 (351 views)
Permalink
Re: Relaxing the need for copyright assignments [In reply to]

Werner Koch <wk [at] gnupg> writes:

> Hi!
>
> Nowadays we have wealth of crypto libraries available. It is often
> easier to contribute to them than to Libgcrypt. The copyright
> assignments required for Libgcrypt turned out to be a major hassle and
> thus I plan to relax the rules.
>
> What do you think of this:

+1

> Libgcrypt is currently licensed under the LGPLv2+ with tools and
> the manual being under the GPLv2+. We may eventually update to a
> newer version of the license or a combination of them. It is thus
> important, that all contributed code allows for an update of the
> license; thus we can't accept any code under the LGPLv2(only).

I think GPLv3+ for tools and and either GPLv3+ or GFDLv1.2+ for the
manual is fine too.

> I pondered with the idea of requiring OpenPGP signed statements but
> rejected it. They don't gain much unless we want to establish another
> complicated procedure to check the trustworthiness of the key. Even if
> we would do so, we will have no way to check the provenience of the
> submitted code.

Couldn't you recommend OpenPGP signed statements, at least?

/Simon

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


wk at gnupg

Apr 12, 2012, 6:12 AM

Post #4 of 5 (351 views)
Permalink
Re: Relaxing the need for copyright assignments [In reply to]

On Thu, 12 Apr 2012 12:12, simon [at] josefsson said:

> I think GPLv3+ for tools and and either GPLv3+ or GFDLv1.2+ for the
> manual is fine too.

Sure, I have simply not come around to change it.

> Couldn't you recommend OpenPGP signed statements, at least?

Okay.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


wk at gnupg

Apr 12, 2012, 6:20 AM

Post #5 of 5 (347 views)
Permalink
Re: Relaxing the need for copyright assignments [In reply to]

On Thu, 12 Apr 2012 12:01, phcoder [at] gmail said:
> On 12.04.2012 11:49, Werner Koch wrote:
>> license; thus we can't accept any code under the LGPLv2(only).
> LGPLv2-only is compatible with GPLv2+ and GPLv3+:

Yes, it is compatible, but it would inhibit us to change to LGPLv3.

> This could allow to check that noone attempts to impersonate an already
> known contributor. While legally having almost no effect it may have

Yes, sure. However if you start to implement something like this, you
end up writing a policy, implement checks and do all other kind of
security business. And that only to have a little bit of trust in the
provenience of the code. For example I rarely check signatures; the
context of a discussion is much more relevant to me.

> other advantages like enhancing code trustworthiness if it comes from
> well-known contributor but it doesn't replace the code review.

What about a suggestion to send signed patches? This would be a
diversion from the Linux rules but I don't have a problem do handle
signed mails.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

GnuPG gcrypt RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.