List Info

Thread: PROCEDURAL SUGGESTION




PROCEDURAL SUGGESTION
user name
2006-10-03 19:35:10
On 10/3/06, MJ Ray <mjrphonecoop.coop> wrote:
> 1. intuitively, the Creative Commons Attribution and
> Attribution-ShareAlike licences should be compatible
with the
> Debian Free Software Guidelines (DFSG) when applied to
software;

License compatibility is a good thing.
But if you're assuming that Debian has
the "right" license because they're
"Debian"
and all others should be compatible with Debian,
you haven't made any logical argument,
you've made an "appeal to authority".

It could be that Debian has made an error,
and the best solution to maintain license
compatibility would be for Debian to
alter its position on anti-TPM.

> 2. Technological Protection Measures (TPM) are a
> problem and it is a  good idea to counteract them
> with licence *judo* that makes people roll over as
> we want, similar to the GPL's approach to binary-only
> distribution;

Right, except comparing DRM to binary distributions is a
crock.
So while parallel source distribution counters a binary and
essentially fixes the issues of Freedom that a binary alone
would take away, parallel distribution does not fix the
platform
monopoly that DRM creates.

> 4. I don't see why the last anti-TPM language I saw
would
>  mean "You can apply DRM to your local copy and
play
> it on your own hardware player" [Greg bond]

I can't find the wording at the moment to quote.
But I believe the wording was something to teh effect of:
"You cannot apply TPM to restrict the rights to a work
you distribute."

Which has some interesting exceptions. One of which,
Mia pointed out and has been quoted on the list a number
of times now. You can apply TPM on your own local copy
of the content. the anti-TPM clause does not prohibit that.

I also believe the wording of the anti-TPM clause was such
that you may even be able to distribute content that has
transparent TPM applied to it. The requirement being that
TPM is allowed so long as it does not restrict the rights
to the work.

Just as an aside, I keep shaking my head everytime I
find myself having to argue that using TPM to restrict
the rights to the work is not Free.
"Restrict the rights to the work"
is a phrase that should set off alarm bells.


> Also, that anti-TPM language seems
> like it would still be hazardous after we
> succeed in reversing the bad TPM laws;

I believe transparent TPM is allowed, so if you've reveresed
bad TPM laws, and transparent TPM is required to be
supported
on all hardware platforms as a legal minimum, then you
should
have no worries.

> Greg bond wrote:
> > How much does bandwidth cost where you live?
> > Over here, it's pretty cheap. Dirt cheap.
> Currently? GBP6.00 per hour at 9600bps.

You've missed the point of this statement.
The point was in response to someone saying
parallel distribution is a real drag to DRM Dave.
It isn't. Any manufacturer who can afford to
assembly line produce hardware players will
consider the bandwidth needed to transmit
parallel copies to be a pitance to pay in exchange
for keeping their platform monopoly.


> Greg bond wrote:
> > So, should we allow Microsoft to pull in some
GPL'ed
> > linux code into its OS or applications and let
> > Microsoft parallel distribute the source code
> > of the linux software but not their own code?
>
> I thought that had happened.  I'm sure Microsoft have
pulled
> BSD code into its software in the past.

BSD is similar to CC-BY, and if you had been paying
attention,
you might have noticed that on several different occaisions
I've said I do not demand the anti-TPM clause in CC-BY.
I believe the anti-TPM clause is important for CC-SA,
which is designed to prevent proprietary competition,
but if BSD works or CC-BY works are taken private,
well, the folks who created the original works didn't
have a problem with that, or they would have picked a
copyleft license.

This is a red herring.

> Greg bond wrote:
> > One could likewise argue that software patents
> > should not be restricted in a copyright license
> > for a FLOSS community. [...]
>
> I do.  They should be in a patent licence.  I think
that's pretty
> obvious.  Keep the problems independent, as far as
possible.

I don't. Because legal language is completely arbitrary.
Patents and copyrights are purely made up boundaries
that separates one piece of intellectual thing from another.
DRM and DMCA and encryption are other legal arbitrary
boundaries.

Arguing that of these arbitrarily created legal boundaries
that somehow "Copyright" will encompass all the
Freedoms
needed for a software project, is to focus on surface
differences, asthetics, rather than to look at what it
would mean to have Free Intellectual Works.

I simply cannot fathom this argument.

If you want to throw your work under BSD, fine,
go for it. That's up to you. But if you have a project
that needs protection from proprietary competition.
If you are building something and want to guarantee
that the project remains Free and no one can take
the project private, and use the project as a basis
for competing against the project, then you need
copyleft.

And to design a copyleft license such that it protects
the project from all legal threats that can be used to
take the project content private and compete against
the Free version of the project, you cannot simply
decide to limit yourself to Copyright law and think
that's the end of potential threats to the project.

> C. Do not expect a copyright licence to solve all
problems.

Do not arbitrarily limit a license intended to protect
a Free project to just copyright law.

> Further, using it to argue that even the CC-By licence
> should contain anti-TPM would mean that CC-By would
> prevent such lock-in while not doing anything to stop
other
> copyright-based lock-ins.  That would be bizarre.

Yes. It would. And I've said probably three or four times
in other emails that I am not against allowing TPM in
the CC-BY license. If you want to remove the anti-TPM
clause from CC-BY, I won't oppose it. I even suggested
it as a possible change prior to the new licenses being
released.

> DRM Dave is not a tenable argument for an anti-TPM
CC-By.

I never used DRM-Dave to argue for putting anti-TPM in
CC-BY.
I only used it to argue for anti-TPM in CC-SA.


> Personally, I think ShareAlike could deal with DRM Dave
> by requiring him to ShareAlike, including permission to
> use his DRM encoder for all derived works.

One of my earlier suggested alternatives to anti-TPM
was to authorize circumvention of any DRM applied
to the work or any alternative. Apparently that won't work
due to the way the DMCA works.

I believe that the current clause allows transparent TPM
to be applied, which means Dave can wrap a work in
DRM and sell it to Alice so she can play it on her player,
as long as the DRM does not somehow prohibit Alice from
any of the rights to that copy of the work, such as giving
a copy of that DRM-enabled work to Bob.

So, it doesn't mean DRM Dave must provide an encoder,
(which would be like requiring someone provide a compiler,
which would be weird in my opinion), but it does mean
that Dave can apply TPM and give a copy to alice, but
that TPM must be transparent enough that it would be
nearly equivalent ot having a wrapper tool.

> > Dave has a platform monopoly that would be similar
> > to Microsoft distributing Linux/Microsoft
executables,
> > distributing some of their source code, and then
> > using DRM and DMCA to PREVENT ALICE AND BOB
> > FROM EVER COMPILING THAT SOURCE CODE ON
> > A MICROSOFT SYSTEM.
>
> Hello!  Cross-compilers!  I have had GPL'd apps on a
> Palm computer, but I can't compile them on it.

Except DRM + DMCA makes "cross compilers" illegal
if Dave does not want to permit them to be publically
available. The platform monopoly with parallel distribution
is complete. Alice and Bob cannot "cross compile"
the open copy that was parallel distributed, the DRM-enabled
version they get from Dave is DRM'ed so they can't
even share copies of taht file with each other, and
the DMCA provides complete and total lockdown on
any attempts to exercise any Freedom on the platform.

If DRM-Dave wishes to enforce a platform monopoly,
there is no equivalent to your "cross compiler"
metaphor.

> Availability of convenient tools for the TPM-encoding
> is a different problem and I feel it's one that should
> not be covered directly by a CC licence.  It is a
> terrible motivation for banning all TPM.

I don't think anyone is currently suggesting DRM tools
ought to be made availabe if Dave wraps some CC-SA
content and sells it to Alice. That would be like arguing
that someone who compiles GNU-GPL code on some
weird embedded hardware platform and sells the platform
must make a freely available compiler for that platform.

I have never suggested this. I'm not sure that anyone has
suggested DRM tools must be made freely available
for Dave to distribute DRM-enabled CC-SA content.

Rather, the DRM enabled content must be Transparent.
It must not restrict any rights to the drm-enabled copy
of the work. A parallel copy of the work is not sufficient.
If Dave wraps CC-SA content in DRM, and sells it to
Alice, Alice must be allowed to do whatever she wants
to do with that wrapped copy of the file that she could
do with the original CC-SA version. DRM cannot be
used to restrict the rights to that copy of the work.

> Terry Hancock wrote:
> > Finally, I have suggested that this is more than
just a
> > Creative Commons or Free Culture issue. Debian is
> > making a mistake by claiming that parallel
distribution
> > meets the Debian Free Software Guidelines (DFSG).
>
> There are some who hold that opinion, but it has not
> been explained on debian-legal in any understandable
> way yet.

What Debian decides to do is up to them.
I'm not going to invade their mailing list
to tell them what to do with their license.

I've explained my point here in a couple of
different emails.

My first self-contained argument against parallel
distribution and for anti-TPM, and the reasons
I believe Debian's basic argument is wrong is here:
http://lists.ibiblio.org/pipermail/cc-l
icenses/2006-September/004130.html

I've tried to summarize my point in a single email here
http://lists.ibiblio.org/pipermail/cc-lic
enses/2006-October/004245.html

I've tried to explain why DRM is not like a binary and
parallel distribution does not solve the monopoly it allows,
and also explained why DRM is more liek a software
patent and the way a patent should be Free or should
not be allowed to monopolize Free content here:
http://lists.ibiblio.org/pipermail/cc-lic
enses/2006-October/004192.html

I compare DRM hardware platform monopolies
with printer manufacturers using teh DMCA to
set themselves up as sole supplier of ink cartridges,
using DMCA to exclude all competition here:
http://lists.ibiblio.org/pipermail/cc-lic
enses/2006-October/004226.html

That's four emails, pretty much self contained
explanations of my argument. If you want to
forward those emails or links to those emails
to Debian, go ahead.

> Some parts of some derived works may be non-free,
> yes.  However, one must consider the whole work,
> else you'll find several of the DFSG violated by every
> package in the archive, which is clearly absurd.

Since you don't explain -why- or -how- these violations
occur, it is difficult to respond. I think that just about
every time I've heard someone use the phrase
"the work as a whole is Free", they end up at a
bad conclusion.

Binaries are allowed as long as you distribute source,
which means everyone can compile their own binary
for the same platform. This does not require that
you supply a compiler for your platform, only that
you ALLOW compilation and provide the source.

Patents are allowed as long as the patent is made Freely
available to the project. If you use a patent to try to
monoopolize some software functionality, using the
Free content, fencing off some space, and charging
admission, then the license to the Free content is
revoked, and you are not permitted to use it.

DRM is allowed as long as it is transparent.
If you use DRM to restrict the rights to the work
such that Alice cannot share the DRM-ed work with Bob,
This does not require that you supply everyone
DRM-enabling tools, but any DRM enabled work
must have exactly the same rights as the original
work. Rights to the work cannot be stripped away
simply because Dave ported it to his DRM platform.

> E. It is about format bans:
>
> rob at robmyers.org wrote:
> > This is not a case of format bans. DRM can be
> > contained within existing file formats, Apple's
> > use of MP4 is a good example of this. We are
> >  not discussing banning MP4. Rather we are
> > discussing how data stored in various file formats
> > affects the file legally.
>
> Rather, given your preferred type of solution, there
would
> exist some pattern which MP4 files of any part of a
CC'd
> work could not match. That is a format ban.  Allowing
some
> MP4 files which do not match the pattern only
emphasises
> the ban.

"there exists some pattern"? Are you talking about
DRM here?
You have gone into fantasy land if the basis of this
argument
is that "some pattern" of 1's and 0's have no
meaning, that
you should be able to create any pattern of 1's and 0's you
wish or the license is too restrictive. Why? Because you
are arguing about these "patterns" as if they have
no other
meaning beyond a magnetic spot on your harddrive.

Software patents are just 1's and 0's. But legally, you are
not allowed to implement certain patterns of 1's and 0's
on any program if someone holds a patent on the
functionality you end up creating.

You may wish it were just 1's and 0's, all technical
problems
to be solved with no legal ramifications, but that is not a
full
or realistic appraisal of what is so, or what must be dealt
with.

So, no, you will not be allowed to implement any pattern of
1's and 0's that you wish if that pattern is interpreted by
some platform to be a DRM flag that restricts the rights
to the work. Well, the anti-TPM clause will allow you to
do this, but it will not allow you to distribute it.

That is not a format war. You cannot write "some
pattern" on
a work, as if that pattern has no meaning. The world is not
a purely technical playground where it's just a matter of
finding some pattern, and all patterns are allowed.

The law says some patterns mean certain things
and places massive restrictions on those patterns.
Software patents restricts what patterns you can create.
DRM restricts what patterns you can create.
Even copyright restricts what patterns you can put
in a file and distribute.

If you distribute the pattern of 1's and 0's that represent
a song by Red Hot Chilli Peppers, you have violated
copyright law. And making sure your Free license
avoids doing that is not a format war.

To design a license to keep a project Free,
all these restrictions on various patterns must
be taken into account. Which is why a license
cannot stop at copyright law and exclude patent
law. Because you're talking about restrictions on
1's and 0's that have legal implications. some patterns
might run into Copyright restrictions, some might
turn on Patent restrictions, some might turn on DRM
restrictions.

To demand that a pattern of 1's and 0's is
to remain Free, adn all derivatives and copies
are to remain Free, which then means that
certain patterns of 1's and 0's are disallowed
because they are not Free, is not a format war.

It's the entire basis of what Licensing is.

> No, DRM is both law and code.  The law currently props
> up weak and evil code, but it need not always be so.
> Does anyone really not see that?

the anti-TPM clause allows transparent TPM.
that is the only TPM that is Free.
Any other type of TPM can be used to monopolize
the Free community's work and is not Free.
_______________________________________________
cc-licenses mailing list
cc-licenseslists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-licenses
PROCEDURAL SUGGESTION
user name
2006-10-03 22:07:41
Greg bond wrote:
>  On 10/3/06, MJ Ray <mjrphonecoop.coop> wrote:
> > 4. I don't see why the last anti-TPM language I
saw would mean "You
> > can apply DRM to your local copy and play it on
your own hardware
> > player" [Greg bond]
>
>  I can't find the wording at the moment to quote. But I
believe the
>  wording was something to teh effect of: "You
cannot apply TPM to
>  restrict the rights to a work you distribute."

[and elsewhere...]

>  Can the generic licence safely rely on fair use, which
seems to vary
>  wildly around the world? I thought I'd seen it defined
in the Berne
>  treaty as essentially whatever the local laws say.
Reliance on 'fair
>  use' to make a licence free is something I see as a
big warning sign.
>
>
Yes. This is apparently already agreed.

According to the response paper posted earlier by Mia
Garlick, Creative 
Commons has already agreed that the license should be
re-worded to 
emphasize that it is only distribution that is affected by
the anti-TPM 
language (although it's apparently the case that the
"fair use" language 
does already make this so in the 2.5 licenses).

>  I also believe the wording of the anti-TPM clause was
such that you
>  may even be able to distribute content that has
transparent TPM
>  applied to it. The requirement being that TPM is
allowed so long as
>  it does not restrict the rights to the work.

Other than the fact that "transparent TPM" would
seem to be an oxymoron, 
I think this is correct (I presume that by "transparent
TPM" you mean 
"encryption which would be called 'TPM' if it were used
to protect a 
monopoly on a work, but which isn't because no such intent
has been 
expressed").

> > Further, using it to argue that even the CC-By
licence should
> > contain anti-TPM would mean that CC-By would
prevent such lock-in
> > while not doing anything to stop other
copyright-based lock-ins.
> > That would be bizarre.

It's quite possibly true that CC-By should not worry about
this kind of 
restriction. I've probably contributed to confusing this
issue, so I 
should try to clarify. I disagree politically with the idea
that Debian 
should take a position of allowing CC-By (but not CC-By-SA)
on the basis 
of such anti-TPM language. That's a little off-topic on this
list, 
because my reason for my wanting that is that I'm a Debian
user, and I 
(now) think the position is inconsistent with the DFSG.

So rather than see Debian try to "fence off the
damage", I would prefer 
that they fundamentally re-examine the issues.  But it's
fair to say I 
should take that up on Debian Legal rather than here.

> > DRM Dave is not a tenable argument for an anti-TPM
CC-By.

No, but there are reasons a creator would fear TPM on CC-By,
but not 
other forms of "lock-in" as you put it.  It's
important to remember that 
we are talking about artistic, directly-observable value
when we talk 
about "free culture" licenses like the CC
licenses.

One consequence of this is that the value of these works is
not 
intrinsically hidden, as it is for utilitarian works like
free software.

What I mean by this, is that if a piece of software is BSD
licensed, the 
author has done that with full knowledge that their work can
be sucked 
into the bowels of some corporate proprietary product.  So
they've 
obviously reconciled themselves with this possibility.

A work of art or music, however, will be directly accessible
if it is 
incorporated.  So, for example, if you wrote and recorded a
nice little 
jingle, and Microsoft decides to use it as their new default
start-up 
sound, then you will hear your work clearly everytime
someone logs into 
a Windows machine near you.  That means your music will be
accessible to 
everyone around the world.  CC-By (and BSD) assure you will
get 
credited. But the *nature of the work* assures that the work
will be 
separable from the proprietary context (you will be able to
extract the 
sound file from Windows, and it's still yours).  An artistic
creator may 
well be releasing their work with the expectation that this
will remain so.

The only thing that can change this dynamic is if Microsoft
deliberately 
applies some kind of TPM to prevent it.  In that context,
the anti-TPM 
language in CC-By makes sense, because it preserves the
social contract 
the creator felt they were making when they released the
work.

Admittedly, this is not nearly so strong an argument as in
the case of 
CC-By-SA, and I don't plan to fight for it, but it's a
plausible 
interpretation, IMHO.

> > Personally, I think ShareAlike could deal with DRM
Dave by
> > requiring him to ShareAlike, including permission
to use his DRM
> > encoder for all derived works.
>
>  One of my earlier suggested alternatives to anti-TPM
was to authorize
>  circumvention of any DRM applied to the work or any
alternative.
>  Apparently that won't work due to the way the DMCA
works.

Mia Garlick is so sure that the DMCA language won't permit
this kind of 
requirement, that she says further discussion of it is
"not 
productive".  I hate declarations from on-high like
that, but she's 
apparently got a point.

Yes, of course this just underscores the stupidity of the
DMCA, but we 
have to remember that much of the point of the existence of
CC licenses 
(and all free licenses) at all is to correct what we see as
stupid laws  
(for example, inadequate scope of fair use and too long a
duration of 
copyright terms).

If we had the power to just rewrite the copyright laws to
suit us, we 
wouldn't need all this legal jiu jitsu in the first place.


> >> Dave has a platform monopoly that would be
similar to Microsoft
> >> distributing Linux/Microsoft executables,
distributing some of
> >> their source code, and then using DRM and DMCA
to PREVENT ALICE
> >> AND BOB FROM EVER COMPILING THAT SOURCE CODE
ON A MICROSOFT
> >> SYSTEM.
> >
> > Hello! Cross-compilers! I have had GPL'd apps on a
Palm computer,
> > but I can't compile them on it.

Greg could/should have said "...COMPILING THAT SOURCE
CODE *FOR* A 
MICROSOFT SYSTEM" and it would make the same point. 
The point is not 
that such a compiler is difficult to write or that Dave's
particular 
compiler is non-free, the point is that *it is illegal to
implement such 
a compiler* (DMCA anti-circumvention clause).

Again, this is stupid law.  We should probably (continue to)
lobby to 
change it. But as things stand, we have to tolerate the
existing law.

However, what this is effectively arguing is that we can't
allow the 
work to be TPM'd unless the key to TPM a modified work is
available. 
This would be exactly like the GPLv3 anti-tivo-ization
language (the 
corresponding source key requirement).

In principle allowing the TPM, but requiring the key to be
published is 
not an unreasonabkle idea, but....

1) this would make the TPM "transparent", thus
meaning it is not being 
used to restrict, hence the CC language already allows it

2) it requires the authorization of the owner of the TPM
technology to 
make the key legally publishable. Encouraging anyone else to
release the 
key without such authorization could be interpreted as
incitement to 
break the law

>  Terry Hancock wrote:
> >> 2) DRM application, unlike binary compilation
is a technically
> >> trivial process. This means that there is no
significant burden
> >> on the end user
>
>  I saw this repeated several times, but I think it's
obviously not
>  true. A binary compilation:
>
>  cc -ofoo foo.c can be as technically
>
>  trivial a process as a DRM application:
>
>  tp -ofoo.tpm foo.ogg but many
>
>  people still won't want to do it themselves. I've yet
to see
>  anything to suggest that TPM is inherently not a
translation.

This is totally missing the point.  Yes, a compilation *can*
be trivial, 
but it almost never *is* trivial in practice.  The technical
reason for 
this (e.g. library and hardware dependencies), isn't
important here. The 
important thing is that it biases your perception of the
obstacle that 
compilation represents, and therefore the importance of
binary 
distribution (very important for unskilled users!).

And while it might be technically possible for a TPM program
to 
introduce all kinds of weird dependencies and obstacles for
the express 
purpose of making it hard to apply, there is no *natural*
reason for it 
to be hard.  And there is no *motivation* for it to be made
artificially 
difficult.  Hence, it's perfectly reasonable to expect that
in 
*practice* TPM will *always* be trivial to apply (assume you
know the 
encryption key).

The difference is not unlike comparing the construction of a
pressure 
hatch to the use of a lock.  The pressure hatch is complex
and possibly 
prone to error because it is constrained by its application
to have a 
certain amount of complexity, plus a dependence on the
environment in 
which it will be used.  You can't avoid that complexity.

A lock could, in principle, be designed to be that difficult
(think Rube 
Goldberg!), but in practice, locks are designed to be simple
to operate 
devices requiring only the insertion  of the right key.

Thus, if for example, you were sold a submarine, it's one
thing to turn 
it over locked and just give the user the key, and quite
another to hand 
them a bag of parts and say, "here's the door, just put
it together, and 
you're set to go"!

Debian has been arguing that it's important to be able to
distribute the 
TPM copy based on experience from managing binary and source

distributions of software.  But that experience teaches the
wrong 
lesson, because the TPM is in a very different complexity
regime than 
binaries are.  In fact, it's really no trouble at all for
the end user 
to apply their own TPM, provided the keys to do so are made
available.

I admit this isn't much of an argument on principle, it's
more about the 
pragmatics. But let's not forget that the
"pragmatics" of getting people 
on TPM-only platforms to use free content is part of the
sales-pitch 
Debian has made against the anti-TPM language.  Here we see
that the 
pragmatic assumption (it's hard to apply TPM yourself) is
not really 
true, so long as the keys are available.

Now, in practice, the real obstacle is not *difficulty*, but
*expense*.  
The argument that has been made is more typically that
access to the 
secret key costs some exhorbitant amount of money that might
be paid 
once for the whole community if one community member agrees
to apply TPM 
as a service. However, that puts us in the position of
having to pay a 
per-seat license fee for everyone who wants to retain their
"freedom 1" 
(the freedom to modify) in the work.  This is getting into
"free as in 
beer" territory (much as I hate that expression, it
sort of fits here).  
Also, there is nothing in the law that forces the TPM
provider to sell 
its keys *at all*, so it may be that there is no benevolent
TPM-keeper 
in the picture, but only a hostile TPM-keeper whose actions
are designed 
to undermine the community.

This seems completely plausible to me, in terms of where
DRM/TPM is 
going in the marketplace.

In fairness, I should suggest this point: if there's room to
budge on 
this issue, it might be that we could somehow require the
TPM-keeper to 
provide fair conversion service (in a way that is similar in
spirit to 
parallel distribution or source distribution requirements).
This would 
be pretty unattractive from the TPM-keeper's point of view
(committing 
to a free service), but not entirely unfeasible, if the
keeper were to 
provide a TPM-conversion web application, for example, that
would 
convert any content into the TPM'd format.

However, our hypothetical 'benevolent community-based'
TPM-keeper 
probably can't do this within the terms of his contract to
acquire the 
key, and the more probable 'evil corporate stooge'
TPM-keeper has a 
strong profit motive not to provide this service (easier to
open his 
platform up to play un-TPM'd material). So I can't see that
it would 
help in any practical way.

>  Terry Hancock wrote:
> >> After reading Greg's "DRM Dave"
scenario I am convinced that he's
> >> right after all and parallel distribution does
not solve the
> >> question of "platform lock-in".
[...]
>
>  For all its cute names, the DRM Dave story seems to
make several
>  assumptions, including my points A (everyone is a
clone of me) and B
>  (overgeneralisation and buggy examples) above.

These are unfair and unsupported claims about the case.
Which bit was 
"overgeneralized" or "buggy", and at
which point does it make any 
assumptions about "clones"?  If you want to find a
fault with the 
example, fine, but this kind of arm-waving doesn't make any
kind of case 
against it.  Be specific.

> > Terry Hancock wrote:
> >> Finally, I have suggested that this is more
than just a Creative
> >> Commons or Free Culture issue. Debian is
making a mistake by
> >> claiming that parallel distribution meets the
Debian Free
> >> Software Guidelines (DFSG).
> >
> > There are some who hold that opinion, but it has
not been explained
> > on debian-legal in any understandable way yet.

Fair point. I've already said I'm willing to bring it up
myself, but 
I'll need to re-join Debian Legal (haven't been on the list
in over a 
year), and so I'm not doing it right away.

> >> IMHO, the problems above render the work
*non-free* under the
> >> Free Software Definition and in violation of
the Debian Free Software
> >> Guidelines.
>
>  Some parts of some derived works may be non-free, yes.
However, one
>  must consider the whole work, else you'll find several
of the DFSG
>  violated by every package in the archive, which is
clearly absurd.

Again, this is isn't argued clearly, but it sounds like
sophistry. It's 
sounding very much anti-copyleft (a position which clearly
must be 
contrary to Debian's historical policy and Social Contract).

> >> [seen several times:] I suggest that Greg's
"DRM Dave" example is
> >> just as important a lithmus test as the
existing "Desert Island",
> >> "Dissident", and "Tentacles of
Evil" tests which Debian Legal
> >> uses to examine new license terms that are in
question [...]
>
>  Whoa! Anyone who has experience on debian-legal should
know that
>  those tests are merely indicators - like the litmus
test - and not
>  definitive proofs of DFSG failure. A litmus test can
give screwy
>  indications, just like DRM Dave gives some screwy
indications of some
>  of the anti-TPM suggestions. Of course, it's better
not to give the
>  wrong indications, but sometimes it is simpler.

And your point is? 

I used the expression "litmus test" myself.

Surely the point of these examples is to expose questionable
cases that 
ought to be considered.  I think "DRM Dave"
(though you're welcome to 
suggest a better name) is just as important a test case as
these other 
three tests.  It certainly opened my eyes to the problem.

There *are* no "definitive proofs of DFSG
failure", because (as the 
litany goes) the DFSG are *guidelines*. Duh. Yes, I know
this.

Your assessment of the DRM Dave example of giving
"screwy indications" 
is still completely unsupported.  All this means is you
didn't like the 
answer you got (and we already knew you wouldn't).  But a
"test" is 
worthless if you only pay attention to the answer if it
happens to come 
up with the answer you wanted. If you don't like the
outcome, you need 
to explain *why* you think it's "not typical" or
"not accurate" or "not 
applicable" or "not important" or whatever
your reason for rejecting it 
is.  "Not the answer I wanted" isn't enough.

Now please realize that I gave Greg a pretty direct
challenge to show me 
what was wrong about the binary/source to TPM/non-TPM
analogy. He 
responded fairly and persuasively.

If you want to sway the argument back the other way, you
need to find an 
actual hole in the test case, or make an effective
counter-argument.  
Just pounding the old argument without addressing the
counter-example 
that Greg has provided is not persuasive. You can't just
dismiss this 
("it gives a screwy indication"), you have to
refute it ("the indication 
it gives is screwy because ...").

As I told Greg, I'm all ears. Convince me. 

Cheers,
Terry

-- 
Terry Hancock (hancockAnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpac
eworks.com


_______________________________________________
cc-licenses mailing list
cc-licenseslists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-licenses
PROCEDURAL SUGGESTION
user name
2006-10-03 23:37:21
Lots of cutting and some responses below.

On Tuesday 03 October 2006 06:07 pm, Terry Hancock wrote:
> Greg bond wrote:
> >  On 10/3/06, MJ Ray <mjrphonecoop.coop> wrote:

> Other than the fact that "transparent TPM"
would seem to be an oxymoron,
> I think this is correct (I presume that by
"transparent TPM" you mean
> "encryption which would be called 'TPM' if it were
used to protect a
> monopoly on a work, but which isn't because no such
intent has been
> expressed").

Let me use the term DRM instead of TPM for a second and use
the implementers 
preferred meaning for a second. (Digital Rights Management
and not the other 
one even if I might prefer it.)

Now, int the envisioned Digital Rights Management world
being promoted these 
days, supposedly it is creator's Rights that are supposeldy
to be managed. Is 
it too much as creators to request that these systems manage
our rights as we 
wish? Why can these systems only properly manage the rights
of creators who 
want all rights reserved but not those who want to offer
more generous terms. 
Seem to me like these are fairly broken systems even if you
cede the 
arguments which I don't.
>
> > > Further, using it to argue that even the
CC-By licence should
> > > contain anti-TPM would mean that CC-By would
prevent such lock-in
> > > while not doing anything to stop other
copyright-based lock-ins.
> > > That would be bizarre.
>
> It's quite possibly true that CC-By should not worry
about this kind of
> restriction. I've probably contributed to confusing
this issue, so I
> should try to clarify. I disagree politically with the
idea that Debian
> should take a position of allowing CC-By (but not
CC-By-SA) on the basis
> of such anti-TPM language. That's a little off-topic on
this list,
> because my reason for my wanting that is that I'm a
Debian user, and I
> (now) think the position is inconsistent with the DFSG.

I keep pointing out the incorrectness of this point
although, as I too have 
indicated, if that is what is wanted, I do not have the same
interest with 
respect to what is in the BY license as I do with the BY-SA
license.

> Yes, of course this just underscores the stupidity of
the DMCA, but we
> have to remember that much of the point of the
existence of CC licenses
> (and all free licenses) at all is to correct what we
see as stupid laws
> (for example, inadequate scope of fair use and too long
a duration of
> copyright terms).

Bingo.
>
> If we had the power to just rewrite the copyright laws
to suit us, we
> wouldn't need all this legal jiu jitsu in the first
place. 

Double Bingo!

> In fairness, I should suggest this point: if there's
room to budge on
> this issue, it might be that we could somehow require
the TPM-keeper to
> provide fair conversion service (in a way that is
similar in spirit to
> parallel distribution or source distribution
requirements). This would
> be pretty unattractive from the TPM-keeper's point of
view (committing
> to a free service), but not entirely unfeasible, if the
keeper were to
> provide a TPM-conversion web application, for example,
that would
> convert any content into the TPM'd format.
>
> However, our hypothetical 'benevolent community-based'
TPM-keeper
> probably can't do this within the terms of his contract
to acquire the
> key, and the more probable 'evil corporate stooge'
TPM-keeper has a
> strong profit motive not to provide this service
(easier to open his
> platform up to play un-TPM'd material). So I can't see
that it would
> help in any practical way.

Here is where it could help in a practical way:

DRM-Dave could provide the service of applying DRM at not
cost to FREE works 
while charging to do so for non-FREE works. This would allow
Dave to sell 
FREE works for his DRM only platform while conducting
business as usual with 
respect to non-Free works.
>

> As I told Greg, I'm all ears. Convince me. 
>
> Cheers,
> Terry

all the best,

drew
-- 
(da idea man)
http://www.ourmed
ia.org/node/145261
Record a song and you might win $1,000.00
http://www.ourmedi
a.org/user/17145
_______________________________________________
cc-licenses mailing list
cc-licenseslists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-licenses
PROCEDURAL SUGGESTION
user name
2006-10-04 01:06:22
drew Roberts wrote:
>  DRM-Dave could provide the service of applying DRM at
not cost to
>  FREE works while charging to do so for non-FREE works.
This would
>  allow Dave to sell FREE works for his DRM only
platform while
>  conducting business as usual with respect to non-Free
works.

This is not an unreasonable idea.  It strikes me as fair in
principle. 
But I don't think it's so easy in practice.

The problem I see with it is that it seems like it would be
very hard to 
sell the idea to a TPM/DRM provider.  OTOH, I can imagine a
company like 
Sony (which is currently trying to win hearts by running
Linux on 
Playstation 3) offering a service on terms like this for the
goodwill 
value.  The biggest problem might be the guarantee to
maintain this 
service in the future (e.g. for how long?).  Remember, we're
not talking 
about something DRM-Dave *can* do, we're talking about
something he 
*must* do.

One possibility is that he must maintain such a service for
X years 
after the last time that he provides the DRM'd work.

Or he might publish the key, rendering the DRM
ineffective/transparent 
(this might be a good platform-retirement option).

However, this is obviously a pretty complex requirement to
draft, and 
the relative lack of any DRM provider who'd want it seems to
make it a 
lot of work for little gain.

Of course, the biggest question here is why is this more
attractive to 
the TPM platform owner than just allowing their platform to
play free, 
non-TPM content?  (Which we'd prefer anyway).

Cheers,
Terry

-- 
Terry Hancock (hancockAnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpac
eworks.com

_______________________________________________
cc-licenses mailing list
cc-licenseslists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-licenses
PROCEDURAL SUGGESTION
user name
2006-10-04 01:53:29
On Tuesday 03 October 2006 09:06 pm, Terry Hancock wrote:
> drew Roberts wrote:
> >  DRM-Dave could provide the service of applying
DRM at not cost to
> >  FREE works while charging to do so for non-FREE
works. This would
> >  allow Dave to sell FREE works for his DRM only
platform while
> >  conducting business as usual with respect to
non-Free works.
>
> This is not an unreasonable idea.  It strikes me as
fair in principle.
> But I don't think it's so easy in practice.
>
> The problem I see with it is that it seems like it
would be very hard to
> sell the idea to a TPM/DRM provider.  OTOH, I can
imagine a company like
> Sony (which is currently trying to win hearts by
running Linux on
> Playstation 3) offering a service on terms like this
for the goodwill
> value.  The biggest problem might be the guarantee to
maintain this
> service in the future (e.g. for how long?).  Remember,
we're not talking
> about something DRM-Dave *can* do, we're talking about
something he
> *must* do.
>
> One possibility is that he must maintain such a service
for X years
> after the last time that he provides the DRM'd work.

As long as he wants to have the rights to distribute the
licensed works with 
TPM applied?
>
> Or he might publish the key, rendering the DRM
ineffective/transparent
> (this might be a good platform-retirement option).

This might be an important line of thinking to explore.
>
> However, this is obviously a pretty complex requirement
to draft, and
> the relative lack of any DRM provider who'd want it
seems to make it a
> lot of work for little gain.
>
> Of course, the biggest question here is why is this
more attractive to
> the TPM platform owner than just allowing their
platform to play free,
> non-TPM content?  (Which we'd prefer anyway).

I thought I answered this when I pointed out that the
platform owner could 
still have sort of monopoly position when it came to
non-Free works. He could 
still charge his rent for those works. If he allowed the
platform to play 
non-DRM works, he could not charge this rent from anyone.

Please note, I am not saying I like this situation. I am
meerly exploring 
possibilities.
>
> Cheers,
> Terry

all the best,

drew
-- 
(da idea man)
http://www.ourmed
ia.org/node/145261
Record a song and you might win $1,000.00
http://www.ourmedi
a.org/user/17145
_______________________________________________
cc-licenses mailing list
cc-licenseslists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-licenses
PROCEDURAL SUGGESTION
user name
2006-10-04 02:21:54
drew Roberts wrote:
>  On Tuesday 03 October 2006 09:06 pm, Terry Hancock
wrote:
> > drew Roberts wrote:
> > One possibility is that he must maintain such a
service for X years
> > after the last time that he provides the DRM'd
work.
>
>  As long as he wants to have the rights to distribute
the licensed
>  works with TPM applied?

Merely "as long as" isn't all that great. What if
he only decides to 
publish these works during their "top of the
charts" period (well, 
probably "top of the free-licensed charts")?  Or
for only a couple of 
weeks after they are released. Then he abandons the work, so
as to avoid 
any responsibility to the "conducers" in the
audience who want to 
publish remixed versions.

I don't think that's adequate. It still leaves the work in
Greg's 
non-free platform monopoly position, for all practical
purposes.

> > Or he might publish the key, rendering the DRM
> > ineffective/transparent (this might be a good
platform-retirement
> > option).
>
>  This might be an important line of thinking to
explore.

But remember he can only do this if he is also the TPM
platform owner.  
Our hypothetical community based TPM-keeper can't do it
legally, because 
of the terms under which he receives the key.

> > Of course, the biggest question here is why is
this more attractive
> > to the TPM platform owner than just allowing their
platform to play
> > free, non-TPM content? (Which we'd prefer anyway).
>
>  I thought I answered this when I pointed out that the
platform owner
>  could still have sort of monopoly position when it
came to non-Free
>  works. He could still charge his rent for those works.
If he allowed
>  the platform to play non-DRM works, he could not
charge this rent
>  from anyone.

Yes, you're right. There's even a certain business logic to
that.

Still, I feel that the obligation has to go a bit beyond the
immediate 
moment. That's a bit like the 3-year source code offer that
GPL insists 
on.  However, it's unclear whether 3 years is adequate. 
Cultural works 
don't become obsolete so easily (and especially when we are
considering 
derivative works. It's not at all difficult to imagine a
2000s techno 
remix of a 1930s song like "Over the Rainbow", for
example).

So maybe we need an almost "in perpetuity"
promise. Or to put it another 
way: you must provide the service as long as you keep the
DRM key 
secret.  But note how this forces us to put these
requirements on the 
DRM owner, not any recipient of the content. So it becomes
more like a 
requirement that "you can distribute this content in
DRM form, but only 
if the DRM owner has provided a promise to DRM all
derivative works on 
demand for the entire time that the DRM key is held
secret".  But of 
course, we then have to ask how the DRM party (not party to
the 
license!) will be held accountable to such promises.  Or
what the 
responsibility of the would-be DRM'd distributor will be if
the DRM 
platform or technology owner stops offering this service.

At this point, ideas like international DRM key registries
and deposit 
of keys in escrow start to pop up as the sort of solutions
you need for 
that kind of trust (and this is the RIAA/MPAA partisans
depositing their 
crown jewels with the likes of Creative Commons and Debian,
mind you -- 
this requires a political miracle to happen! Of course, the
Space 
Shuttle did eventually dock with Mir after all, but only
after a lot of 
walls fell).

And if we require such involvement from the DRM distributor,
DRM 
platform owner, and DRM technology provider, why aren't we
just asking 
them to contact the authors, get permission, and pay a
royalty in order 
to sell the DRM'd version?  They always have this option.

It seems like we're in for some major slogging through the
mud if we 
want to draft this kind of requirement.  Lots and lots of
details with 
risks at every step.

Cheers,
Terry

-- 
Terry Hancock (hancockAnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpac
eworks.com

_______________________________________________
cc-licenses mailing list
cc-licenseslists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-licenses
PROCEDURAL SUGGESTION
user name
2006-10-04 08:38:19
Terry Hancock wrote:

[cut]

Hey, guys, you were supposed to stop this! I also support
one-post-a-day 
limit. We have to enforce it, because you really cant follow
such a 
discussion.
Jaroslaw Lipszyc
_______________________________________________
cc-licenses mailing list
cc-licenseslists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-licenses
PROCEDURAL SUGGESTION
user name
2006-10-04 09:19:43
+1 vote for making this discussion a one-post-a-day...

Jaroslaw Lipszyc wrote:
> Terry Hancock wrote:
> 
> [cut]
> 
> Hey, guys, you were supposed to stop this! I also
support one-post-a-day 
> limit. We have to enforce it, because you really cant
follow such a 
> discussion.
> Jaroslaw Lipszyc
> _______________________________________________
> cc-licenses mailing list
> cc-licenseslists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/cc-licenses
> 
_______________________________________________
cc-licenses mailing list
cc-licenseslists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-licenses
PROCEDURAL SUGGESTION
user name
2006-10-04 10:50:10
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

i don't want to start a governance debate, but i don't think
we should
enforce, or in fact use pressure to try to enforce, a
suggestion made to
members to self-regulate their discussion of substance on
this public
mailing list.

if they insist that they need to lead their discussion to
its conclusion
in this way so let them. they might consider reporting back
to the
larger part of this mailing list who doesn't have time to
follow their
extensive exchange in separate email, unless they want to
risk their
considerations being overheard in the CCv3 public
discussion.

tom

Bjorn Wijers wrote:
> +1 vote for making this discussion a one-post-a-day...
> 
> Jaroslaw Lipszyc wrote:
>> Terry Hancock wrote:
>>
>> [cut]
>>
>> Hey, guys, you were supposed to stop this! I also
support one-post-a-day 
>> limit. We have to enforce it, because you really
cant follow such a 
>> discussion.
>> Jaroslaw Lipszyc
>> _______________________________________________
>> cc-licenses mailing list
>> cc-licenseslists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/cc-licenses
>>
> _______________________________________________
> cc-licenses mailing list
> cc-licenseslists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/cc-licenses
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFFI5HhkbN024ZV0z0RAmndAKDCKzyU8Op2U/USIs8NCeLfXCWZQwCd
H924
cFfBP/ghwp86NfZgtO1Z9DQ=
=k4Mi
-----END PGP SIGNATURE-----
_______________________________________________
cc-licenses mailing list
cc-licenseslists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-licenses
PROCEDURAL SUGGESTION
user name
2006-10-04 12:26:11
On Tuesday 03 October 2006 10:21 pm, Terry Hancock wrote:
> drew Roberts wrote:
> >  On Tuesday 03 October 2006 09:06 pm, Terry
Hancock wrote:
> > > drew Roberts wrote:
> > > One possibility is that he must maintain such
a service for X years
> > > after the last time that he provides the
DRM'd work.
> >
> >  As long as he wants to have the rights to
distribute the licensed
> >  works with TPM applied?
>
> Merely "as long as" isn't all that great.
What if he only decides to
> publish these works during their "top of the
charts" period (well,
> probably "top of the free-licensed charts")? 
Or for only a couple of
> weeks after they are released. Then he abandons the
work, so as to avoid
> any responsibility to the "conducers" in the
audience who want to
> publish remixed versions.
>
> I don't think that's adequate. It still leaves the work
in Greg's
> non-free platform monopoly position, for all practical
purposes.

As long as he is distributing any works with the same
license elements hten?
>
> > > Or he might publish the key, rendering the
DRM
> > > ineffective/transparent (this might be a good
platform-retirement
> > > option).
> >
> >  This might be an important line of thinking to
explore.
>
> But remember he can only do this if he is also the TPM
platform owner.

Sure.

> Our hypothetical community based TPM-keeper can't do it
legally, because
> of the terms under which he receives the key.

Well, the community keeper could just keep functioning
instead.
>
> > > Of course, the biggest question here is why
is this more attractive
> > > to the TPM platform owner than just allowing
their platform to play
> > > free, non-TPM content? (Which we'd prefer
anyway).
> >
> >  I thought I answered this when I pointed out that
the platform owner
> >  could still have sort of monopoly position when
it came to non-Free
> >  works. He could still charge his rent for those
works. If he allowed
> >  the platform to play non-DRM works, he could not
charge this rent
> >  from anyone.
>
> Yes, you're right. There's even a certain business
logic to that.
>
> Still, I feel that the obligation has to go a bit
beyond the immediate
> moment. That's a bit like the 3-year source code offer
that GPL insists
> on.  However, it's unclear whether 3 years is adequate.
 Cultural works
> don't become obsolete so easily (and especially when we
are considering
> derivative works. It's not at all difficult to imagine
a 2000s techno
> remix of a 1930s song like "Over the
Rainbow", for example).

Here is a fun condition:

Until the work goes into the public domain or until the keys
are make Free.
>
> So maybe we need an almost "in perpetuity"
promise. Or to put it another
> way: you must provide the service as long as you keep
the DRM key
> secret.  But note how this forces us to put these
requirements on the
> DRM owner, not any recipient of the content. So it
becomes more like a
> requirement that "you can distribute this content
in DRM form, but only
> if the DRM owner has provided a promise to DRM all
derivative works on
> demand for the entire time that the DRM key is held
secret".  But of
> course, we then have to ask how the DRM party (not
party to the
> license!) will be held accountable to such promises. 
Or what the
> responsibility of the would-be DRM'd distributor will
be if the DRM
> platform or technology owner stops offering this
service.

Perhaps, but we must remember that this DRM hairball is not
something we 
created. We should perhaps think along the line of solutions
where all but 
obviously bad intentioned actors can implement easily. (Is
that clear?)
>
> At this point, ideas like international DRM key
registries and deposit
> of keys in escrow start to pop up as the sort of
solutions you need for
> that kind of trust (and this is the RIAA/MPAA partisans
depositing their
> crown jewels with the likes of Creative Commons and
Debian, mind you --
> this requires a political miracle to happen! Of course,
the Space
> Shuttle did eventually dock with Mir after all, but
only after a lot of
> walls fell).

Perhaps I don't understand DRM properly but can't there be
multiple sets of 
keys for the same device? Can't they make a set which can
only be legally 
applied to Free Works?
>
> And if we require such involvement from the DRM
distributor, DRM
> platform owner, and DRM technology provider, why aren't
we just asking
> them to contact the authors, get permission, and pay a
royalty in order
> to sell the DRM'd version?  They always have this
option.

Well, I am fine with them contacting me and paying me to use
my work in a 
non-Free manner. (Possibly.) This is pretty much the dual
license model after 
all.
>
> It seems like we're in for some major slogging through
the mud if we
> want to draft this kind of requirement.  Lots and lots
of details with
> risks at every step.

Well. Perhaps the simplest wording is transparent TPM +
parallel distribution 
and that will in effect cover all the bases. Then we could
draft a FAQ 
suggesting these various ways to achieve this.
>
> Cheers,
> Terry

all the best,

drew
-- 
(da idea man)
http://www.ourmed
ia.org/node/145261
Record a song and you might win $1,000.00
http://www.ourmedi
a.org/user/17145
_______________________________________________
cc-licenses mailing list
cc-licenseslists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-licenses
[1-10] [11-20] [21-28]

about | contact  Other archives ( Real Estate discussion Medical topics )