From: Jan Harkes <jaharkes@cs.cmu.edu>
To: Alexandre Oliva <oliva@lsd.ic.unicamp.br>
Cc: linux-kernel@vger.kernel.org
Subject: Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
Date: Tue, 26 Jun 2007 00:10:13 -0400 [thread overview]
Message-ID: <20070626041013.GG24745@delft.aura.cs.cmu.edu> (raw)
In-Reply-To: <orhcov7qsz.fsf@oliva.athome.lsd.ic.unicamp.br>
On Mon, Jun 25, 2007 at 04:54:52PM -0300, Alexandre Oliva wrote:
> Consider this scenario: vendor tivoizes Linux in the device, and
> includes the corresponding sources only in a partition that is
> theoretically accessible using the shipped kernel, but that nothing in
> the software available in the machine will let you get to. Further,
> sources (like everything else on disk) are encrypted, and you can only
Interesting scenario, it seems to comply with GPLv2 on the surface.
If that kernel doesn't actually allow access and wipes the source
partition to use it as swap on first boot, then no machine is actually
capable of reading the source. So it isn't really machine readable.
Another gripe is that encrypted media are not customarily used for
software interchange. So that's 2 (minor) strikes where this method of
distribution doesn't seem to match the language of section 3a.
You also cannot interpret the encrypted partition as source code because
a bit further down in section 3, it defines source code as,
"The source code for a work means the preferred form of the work for
making modifications to it."
So now we get to section 6. The recipient receives a license to copy,
distribute or modify. You may not impose further restrictions on
these rights granted herein.
You could argue that they do not restrict copying, distribution
and modification of the sources in general, only of the specific copy
they distribute. However here we go back to section 2 which states that
their modified copy is a derived work which must be licensed under the
GPLv2, so that would make it specific enough that recipients have in
fact been granted the right to copy, distribute and modify the copy of
the source of that corresponds to the distributed binaries, which is
restricted because of the encryption which prevents the user to copy,
distribute or modify the source code.
> Does anyone think this is permitted by the letter of GPLv2?
No.
> How are the sources passed on in this way going to benefit the user or
> the community?
Not a really interesting question if the method of distribution violates
the letter of the GPLv2, is it? They get sued for copyright infringement
because they are not in compliance with section 3 and the sources are
released as a result.
Jan
next prev parent reply other threads:[~2007-06-26 4:10 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-21 9:39 Alexandre Oliva
2007-06-21 11:35 ` jimmy bahuleyan
2007-06-21 17:53 ` Alexandre Oliva
2007-06-21 18:00 ` david
2007-06-21 20:02 ` Alexandre Oliva
2007-06-21 21:13 ` David Schwartz
2007-06-21 23:37 ` Alexandre Oliva
2007-06-22 0:31 ` David Schwartz
2007-06-22 1:00 ` Alexandre Oliva
2007-06-22 1:34 ` Al Viro
2007-06-22 4:19 ` Theodore Tso
2007-06-22 6:00 ` Alexandre Oliva
2007-06-22 14:43 ` Theodore Tso
2007-06-25 13:28 ` Lennart Sorensen
2007-06-25 19:54 ` Alexandre Oliva
2007-06-26 4:10 ` Jan Harkes [this message]
2007-06-26 6:33 ` Alexandre Oliva
2007-06-26 7:47 ` Alexandre Oliva
2007-06-26 16:25 ` Jan Harkes
2007-06-27 23:08 ` Alexandre Oliva
2007-06-27 23:53 ` David Schwartz
2007-06-28 0:56 ` Alexandre Oliva
2007-06-28 1:37 ` David Schwartz
2007-06-28 2:37 ` Alexandre Oliva
2007-06-28 2:51 ` Daniel Hazelton
2007-06-28 4:45 ` Alexandre Oliva
2007-06-28 4:52 ` Daniel Hazelton
2007-06-28 6:15 ` David Schwartz
2007-06-28 17:40 ` Alexandre Oliva
2007-06-28 19:13 ` David Schwartz
2007-06-30 2:53 ` Alexandre Oliva
2007-06-30 4:04 ` David Schwartz
2007-06-30 6:16 ` Alexandre Oliva
2007-06-28 3:44 ` David Schwartz
2007-06-28 4:57 ` Alexandre Oliva
2007-06-28 5:08 ` Jan Harkes
2007-06-28 6:58 ` Alexandre Oliva
2007-06-28 17:52 ` Alexandre Oliva
2007-07-01 8:48 ` Alexandre Oliva
2007-06-22 9:14 ` Alan Cox
2007-06-22 14:47 ` Theodore Tso
2007-06-22 19:14 ` Alexandre Oliva
2007-06-22 4:26 ` Alexandre Oliva
2007-06-22 5:23 ` Al Viro
2007-06-22 6:15 ` Alexandre Oliva
2007-06-22 9:05 ` Alan Cox
2007-06-22 21:28 ` David Schwartz
2007-06-21 20:44 ` Jesper Juhl
2007-06-21 23:08 ` Alexandre Oliva
2007-06-21 23:20 ` Jesper Juhl
2007-06-22 0:13 ` Alexandre Oliva
2007-06-21 18:00 ` Al Viro
2007-06-21 20:15 ` Alexandre Oliva
2007-06-21 23:04 ` Al Viro
2007-06-22 0:47 ` Alexandre Oliva
2007-06-21 18:29 ` David Schwartz
2007-06-21 19:56 ` Alexandre Oliva
2007-06-21 20:48 ` David Schwartz
2007-06-21 23:23 ` Alexandre Oliva
2007-06-22 0:58 ` Jan Harkes
2007-06-22 4:14 ` Alexandre Oliva
2007-06-22 4:59 ` Jan Harkes
2007-06-22 1:33 ` Bron Gondwana
2007-06-22 4:40 ` Alexandre Oliva
2007-06-22 1:18 ` Bron Gondwana
2007-06-22 4:34 ` Alexandre Oliva
2007-06-22 5:25 ` Al Viro
2007-06-22 5:31 ` Randy Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070626041013.GG24745@delft.aura.cs.cmu.edu \
--to=jaharkes@cs.cmu.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=oliva@lsd.ic.unicamp.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®