Re: GPL Alternatives
- From: zaimoni <zaimoni@xxxxxxxxxxx>
- Date: Thu, 1 Nov 2007 04:54:55 +0000 (UTC)
On 2007-11-01 02:09:52, Jeff Lait <torespondisfutile@xxxxxxxxxxx> wrote:
On Oct 31, 1:44 pm, zaimoni wrote:
On 2007-10-31 14:38:43, Jeff Lait wrote:
On Oct 31, 12:05 am, Sherman Pendley wrote:
zaimoni writes:
In particular, it is a license violation to put GPLV3 software in any format
with digital rights management, or hardware with digital rights management.
I've always thought that the FSF's rabid hatred of DRM technology is mis-
directed. Technically, it should be possible to implement a DRM scheme
that requires a (possibly signed) source bundle to accompany a binary,
effectively enforcing the terms of the GPL.
I think you have misunderstood the goal of the GPL. The goal of the
GPL is not to ensure the source code is available. The goal of the
GPL is to ensure that end user can change the source code.
Distributing the source and binary in a DRM'ed archive whose permissions allow
complete exporting to a non-DRM'ed format does implement this goal. The end
user just has to extract the source from the DRM'ed archive, like they would
from a normal archive format. And for source-only distributions, these DRM
formats already exist.
The end user can change the source code, just not easily update the DRM archive.
This is not only an immaterial restriction, it is good practice not to update
the source archive when forking.
Okay, I think we have a problem of terminology here. As far as I
understand, what you are talking about is a digital signature system.
An archive that I have is signed by another party and I can thus trust
that it is the original archive. This I think FSF has no problems
with - indeed, most sites provide signatures for their downloads for
just this reason. No one objects to the fact that one can distribute
GPLV3 code that is signed despite the fact that no redistributor is
allowed to sign the changes with the same key.
A digital signature is complementary, but not what I'm thinking of.
I do have a concrete example of DRM in mind: Adobe Acrobat PDF. I have a
licensed copy of the full version for other reasons; it is indeed capable of
setting permissions the way I describe.
The issue at hand is when one implements access control depending on
the signature. Ie, a hardware or OS level constraint that says only
certain signed files are executable. In this case, your distribution
of "source" is a sham. If I am unable to compile the source into a
new executable with the same functions as the original package, it
can't really be called the source.
Agreed. In order to allow end users to modify the source, the permissions must
be set to allow full export to a non-DRM'd format suitable for compilation into
a new executable, etc.
A good DRM system can select this behavior, as well as more restrictive ones
that are not useful for distributing the source code for a GPLV2 application.
We seem to have a different definition of DRM then. DRM of the nature
you describe, where one has a file which, when granted access, you are
able to render into plain text, is not prohibited by the FSF as far as
I can tell.
While a legal reference does need to be traced to be sure, it does seem like the
GPLV3 does prohibit even this use of DRM in distributing:
"3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological measure under
any applicable law fulfilling obligations under article 11 of the WIPO copyright
treaty adopted on 20 December 1996, or similar laws prohibiting or restricting
circumvention of such measures. ...."
Indeed, it seems to be not much more than encryption +
signing. The file is encrypted against a secret key and signed by the
creator. The user can verify the integrity and source by checking the
signature. When rights are granted the secret key is sent to the user
can copy it into plain text to do with as they wish.
In the full-export mode, DRM ships the public key with the file. The main
problem is that you can have platform lock-in (as a working DRM interpreter is
needed to get the source into a non-DRM'ed format), but as long as the exported
source can be transferred to the target system this is no more onerous than
needing a ZIP decompressor to access the files in a ZIP archive. Likewise for
tar, gzip, and bzip2.
DRM, as I understand it, tries to do one more. It tries to prevent
the archive from being rendered to plain text even after rights are
granted.
A working DRM implementation does provide the option to do this. A good
implementation does not require you into doing this.
This is where it gets difficult to envision an open source
solution. One approach is to use build hardware/OS that only
authorizes signed programs to work with the data.
As you mentioned, we do have a difference of terminology here.
There's a reason that hardware hasn't been released by Intel yet. The hardware
seems to have reached lab stage in 2004, but so far the hardware also makes
properly designed malware unremovable.
This ensures that
even if one has the source to the app, one can't write a version that
saves out the private key ....
That is, a native compiler is explicitly designed out of the platform; even the
OS vendor will have to cross-compile from a non-restrictive platform to create
applications.
.... And then we find ourself in a
console-like world where permission to publish programs is granted at
the whim of the corporate gate keepers.
They want their money. Currently ~U.S.$300 every two years or so.
That's for user licensing. We still have to wait to find out what
development licenses will cost.
Lousy memory on my part, should have said ~U.S.$500/2 years. An example price
quote for code signing licenses is at
https://www.thawte.com/ssl-digital-certificates/code-signing/index.html?click=main-nav-products-codesigning
This is not the cheapest vendor, either.
.
- References:
- Re: GPL Alternatives
- From: Jeff Lait
- Re: GPL Alternatives
- Prev by Date: Re: GPL Alternatives
- Next by Date: Re: GPL Alternatives
- Previous by thread: Re: GPL Alternatives
- Next by thread: Re: GPL Alternatives
- Index(es):
Relevant Pages
|
Loading
