[cc-licenses] PROCEDURAL SUGGESTION
teloscorbin at gmail.com
Tue Oct 3 15:35:10 EDT 2006
On 10/3/06, MJ Ray <mjr at phonecoop.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
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 London]
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
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 London 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 London 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
This is a red herring.
> Greg London 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
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
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
> 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
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:
I've tried to summarize my point in a single email here
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:
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:
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
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.
More information about the cc-licenses