Crypto Patch: Legal Issues

Crypto Patch: Legal Issues

[Michael Gorven]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

Hi

Two months ago[1] I announced on this list that I was working on adding 
support for LUKS encrypted partitions to GRUB. I had some queries[2] 
regarding other code which I have used, and still haven't had a proper 
response to those queries. Could someone please advise me on what needs to be 
done to get my patch integrated?? The patch includes the following pieces of 
code.

Ciphers and hashes from libgcrypt: Copyright FSF, LGPL 2.1 or later
Simon's crypto framework: Copyright Simon Peter, GPL 3
AFsplitter: Copyright Clemens Fruhwirth, GPL 2 or later
PBKDF2: Copyright FSF, GPL 2 or later
Code I've written

What needs to be done to convert these to compatible licenses and/or reassign 
copyright?

Michael

[1] http://lists.gnu.org/archive/html/grub-devel/2008-05/msg00127.html
[2] http://lists.gnu.org/archive/html/grub-devel/2008-05/msg00184.html

-- 
http://michael.gorven.za.net
PGP Key ID 6612FE85
S/MIME Key ID D33AEB31

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Crypto Patch: Legal Issues

[Marco Gerards]

Hi Michael,

Michael Gorven <michael@gorven.za.net> writes:

> Two months ago[1] I announced on this list that I was working on adding 
> support for LUKS encrypted partitions to GRUB. I had some queries[2] 
> regarding other code which I have used, and still haven't had a proper 
> response to those queries. Could someone please advise me on what needs to be 
> done to get my patch integrated?? The patch includes the following pieces of 
> code.

Sorry to keep you waiting.  After the weekend I will have more time
and get back to you.

> Ciphers and hashes from libgcrypt: Copyright FSF, LGPL 2.1 or later
> Simon's crypto framework: Copyright Simon Peter, GPL 3
> AFsplitter: Copyright Clemens Fruhwirth, GPL 2 or later
> PBKDF2: Copyright FSF, GPL 2 or later
> Code I've written
>
> What needs to be done to convert these to compatible licenses and/or reassign 
> copyright?

I was about the review Simon's patch.  What is the best way to
proceed.  More than one person works on this and I am confused about
how to deal with this.  Would it help if Simons work got in first, or
didn't you continue with this, but did you just pick pieces of code
from him instead?

--
Marco

Re: Crypto Patch: Legal Issues

[Michael Gorven]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

On Saturday 09 August 2008 17:24:23 Marco Gerards wrote:
> I was about the review Simon's patch.  What is the best way to
> proceed.  More than one person works on this and I am confused about
> how to deal with this.  Would it help if Simons work got in first, or
> didn't you continue with this, but did you just pick pieces of code
> from him instead?

I used his "crypto" module, which manages the available ciphers and hashes. I 
did however make some changes to that, and I also replaced Simon's AES and 
RIPEMD implementations with ones from libgcrypt. I gather that there was a 
problem with the license of those implementations, and so I think that it may 
be easier for me to submit Simon's patch along with mine. My "luks" module 
also has a lot of code in common with Simon's "devmapper" module (which 
handles non-LUKS encrypted partitions), and so I'm planning to incorporate 
that functionality in my "luks" module.

Regards
Michael

-- 
http://michael.gorven.za.net
PGP Key ID 6612FE85
S/MIME Key ID D33AEB31

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Crypto Patch: Legal Issues

[Simon Peter]

> > I was about the review Simon's patch.  What is the best way to
> > proceed.  More than one person works on this and I am confused about
> > how to deal with this.  Would it help if Simons work got in first,
> > or didn't you continue with this, but did you just pick pieces of
> > code from him instead?
> I used his "crypto" module, which manages the available ciphers and
> hashes. I did however make some changes to that, and I also replaced
> Simon's AES and RIPEMD implementations with ones from libgcrypt. I
> gather that there was a problem with the license of those
> implementations, and so I think that it may be easier for me to
> submit Simon's patch along with mine. My "luks" module also has a lot
> of code in common with Simon's "devmapper" module (which handles
> non-LUKS encrypted partitions), and so I'm planning to incorporate
> that functionality in my "luks" module.

In the meantime, I've assigned copyright of my work (excluding the AES
and RIPEMD implementations) to the FSF. The documents are probably
already waiting in my mailbox at home. I'll get the signing done once
I'm back home at the end of this month.

 -- Simon

Re: Crypto Patch: Legal Issues

[Michael Gorven]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

On Monday 18 August 2008 23:23:54 Simon Peter wrote:
> In the meantime, I've assigned copyright of my work (excluding the AES
> and RIPEMD implementations) to the FSF. The documents are probably
> already waiting in my mailbox at home. I'll get the signing done once
> I'm back home at the end of this month.

I assume that I shall need to do this as well. What is the procedure for this? 
I couldn't find anything on the GRUB wiki, and can't find any forms on the 
FSF website.

Michael

-- 
http://michael.gorven.za.net
PGP Key ID 6612FE85
S/MIME Key ID D33AEB31

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Crypto Patch: Legal Issues

[W. Michael Petullo]

>> In the meantime, I've assigned copyright of my work (excluding the AES
>> and RIPEMD implementations) to the FSF. The documents are probably
>> already waiting in my mailbox at home. I'll get the signing done once
>> I'm back home at the end of this month.
 
> I assume that I shall need to do this as well. What is the procedure for this? 
> I couldn't find anything on the GRUB wiki, and can't find any forms on the 
> FSF website.

Is anyone reviewing Michael's patch? It seems that when he mentions it,
no one follows up other than to make a brief comment. I am presently
using it and it works quite well. I would like to see it in GRUB2's
mainstream tree. This is a significant new capability.

-- 
Mike

:wq

Re: Crypto Patch: Legal Issues

[Simon Peter]

> >> In the meantime, I've assigned copyright of my work (excluding the
> >> AES and RIPEMD implementations) to the FSF. The documents are
> >> probably already waiting in my mailbox at home. I'll get the
> >> signing done once I'm back home at the end of this month.
> > I assume that I shall need to do this as well. What is the
> > procedure for this? I couldn't find anything on the GRUB wiki, and
> > can't find any forms on the FSF website.
> Is anyone reviewing Michael's patch? It seems that when he mentions
> it, no one follows up other than to make a brief comment. I am
> presently using it and it works quite well. I would like to see it in
> GRUB2's mainstream tree. This is a significant new capability.

I'd like to join Mike in petitioning for the incorporation of Michael's
patch into GRUB. This feature is badly needed for a secure bootup.

Furthermore, my work is not really useful to end-users without all the
ciphers that Michael implemented.

Simon

Re: Crypto Patch: Legal Issues

[Robert Millan]

Marco, I think you're the only one who can take care of this.  Please could
you have a look?

On Mon, Sep 01, 2008 at 05:26:46PM +0200, Simon Peter wrote:
> > >> In the meantime, I've assigned copyright of my work (excluding the
> > >> AES and RIPEMD implementations) to the FSF. The documents are
> > >> probably already waiting in my mailbox at home. I'll get the
> > >> signing done once I'm back home at the end of this month.
> > > I assume that I shall need to do this as well. What is the
> > > procedure for this? I couldn't find anything on the GRUB wiki, and
> > > can't find any forms on the FSF website.
> > Is anyone reviewing Michael's patch? It seems that when he mentions
> > it, no one follows up other than to make a brief comment. I am
> > presently using it and it works quite well. I would like to see it in
> > GRUB2's mainstream tree. This is a significant new capability.
> 
> I'd like to join Mike in petitioning for the incorporation of Michael's
> patch into GRUB. This feature is badly needed for a secure bootup.
> 
> Furthermore, my work is not really useful to end-users without all the
> ciphers that Michael implemented.
> 
> Simon
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
> 

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Crypto Patch: Legal Issues

[Robert Millan]

On Mon, Aug 18, 2008 at 11:39:05PM +0200, Michael Gorven wrote:
> On Monday 18 August 2008 23:23:54 Simon Peter wrote:
> > In the meantime, I've assigned copyright of my work (excluding the AES
> > and RIPEMD implementations) to the FSF. The documents are probably
> > already waiting in my mailbox at home. I'll get the signing done once
> > I'm back home at the end of this month.
> 
> I assume that I shall need to do this as well. What is the procedure for this? 
> I couldn't find anything on the GRUB wiki, and can't find any forms on the 
> FSF website.

Sorry for the delay in repliing.  It seems both GRUB maintainers are terribly
busy these days.

Simon's assignment is complete now.  We would only need yours, and after this
I think we can start merging the code.

Please can you request the assignment papers to FSF's copyright clerk?  I've
added him to CC.

Also, if you can submit the other parts separately (FSF copyrighted code
from libgcrypt, Simon's patch, etc), we can start merging that right away,
without having to wait for your assignment.

Thank you

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."