Kernel developers' position on GPLv3

Posted Sep 22, 2006 22:51 UTC (Fri) by k8to (guest, #15413)
Parent article: Kernel developers' position on GPLv3

Disingenuous.

That is my takeaway from this position statement. The claims that the
provisions requiring end-user modification to be possible will prevent
encryption applications seem to be wholly specious. The claims that such
a provision is political and therefore unconscionable is just nuts. The
choice of a license such as GPLv2 as opposed to some other license is
_also_ political, but yet no one is making position statements against
this.

I can understand some of the concerns raised here, but they are raised in
a sloppy and ill-considered way.

to post comments

Kernel developers' position on GPLv3

Posted Sep 24, 2006 18:37 UTC (Sun) by msbrown (guest, #38262) [Link] (1 responses)

Refutation:

I point you to FIPS 140-2 ( http://csrc.nist.gov/cryptval/140-2.htm ).

Yes, GPLv3 (draft 2) code cannot be used in FIPS 140 environments.

You really _don't_ want crypto modules that can be modified by third-parties, not all of whom intend to _improve_ your your module.

Kernel developers' position on GPLv3

Posted Sep 24, 2006 23:04 UTC (Sun) by k8to (guest, #15413) [Link]

That GPLv3 draft two requires it be possible that code be modified and
still perform in its primary function does not require that the crypto
module itself which is used in conjunction with GPLv3 code be modifiable.

I am uncertain if that makes the code usable in a FIPS 140-2 context, but
your comment seems overbroad.

Separately it seems to me an open question whether making it possible to
run code on such a platform after modification, but with a flag that
indicates that it is not original code, would satisfy the GPLv2
provisions as writtten. It is also an interesting question whether it is
desirable that it be possible for same to satisfy these conditions.