[cc-licenses] PROCEDURAL SUGGESTION

MJ Ray mjr at phonecoop.coop
Tue Oct 3 09:34:18 EDT 2006


Patrick Peiffer wrote: [...]
> discussed here at extreme frequency by very few people lately. Please,
> make one short, to the point  wrap-up of what you has been contributed
> to the public discussion so we can understand and continue.

As I'm probably the person with the least bandwidth posting to this 
list, I like this suggestion.  So, I suggest:

1. intuitively, the Creative Commons Attribution and 
Attribution-ShareAlike licences should be compatible with the Debian 
Free Software Guidelines (DFSG) when applied to software;

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;

3. The anti-TPM language proposed in the current draft is more like 
licence *sumo*, just pushing back at the problem in a way that makes it 
difficult for people stood behind the TPM problem in the queue to get 
past and still enter our side;

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] in any generic way, nor why we should forbid public 
TPM-encoding.  Also, that anti-TPM language seems like it would still be 
hazardous after we succeed in reversing the bad TPM laws;

5. Better anti-TPM language already exists in the CC-Scotland drafts,
but an equivalent solution in the treaty-style phrasing of the generic
licences could be acceptable too.

[END WRAP-UP]



Breaking the short bit, I also make the following notes about other 
contributions since my last download of list email:

A. Some participants seem to the assume that everyone else is in the 
same wired-up liberal-lawed situation that they are, with exactly the 
same skills they have.  We are not.  This does not make our 
contributions wrong.  We each need to argue for our interests, but not 
sharing someone's interests does not necessarily dismiss their argument.  
For example:

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.  (I'm involved with a weeks-long 
problem with the only telephone network provider in town, trying to get 
a line installed.  The indefinite nature of it means I have some other 
ways, but they are fiddly - I will probably buy discs of some large 
files I want if this situation continues much longer.)

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.

Rob Myers wrote:
>  The first point is a breach of both the DFSG and the FSD. More
>  importantly it is a breach of Fair Use. It is therefore unacceptable
>  both for Free Software and more importantly for Free Culture.

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.




B. Do not overgeneralise or use examples that are obviously not true.

Rob Myers wrote:
> [...] But after that first moment it either burdens
> downstream producers in a way that providing source does not (I need source to
> edit chmod, I do not need source to mash-up an OGG track),

You do not *need* source to edit chmod.  As root, type:
  vi /bin/chmod
  2GC I am the Balti King. [Escape]ZZ

Congratulations!  You have just edited chmod!  Of course, it's pretty 
terrible, but so are most of my mash-ups of OGG tracks.  ;-)

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.  Microsoft does some evil things, but not 
everything.  Maybe that's a problem with the DRM Dave story: it 
demonises Dave.  He might be Dave the Chameleon, merely an ignorant 
crowd-follower, rather than actively malevolent.

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.




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

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.

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.  DRM Dave is not a tenable argument for an anti-TPM CC-By.

Greg London wrote:
> Because source distribution means you can use the
> source code ON THE SAME PLATFORM. But DRM with parallel
> means you get the parallel copy, but YOU'LL NEVER
> BE ABLE TO USE IT ON THE SAME  PLATFORM DAVE DOES. [...]

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.  If - as suggested IIRC - it is impossible to do that 
with current law while still keeping his DRM a DRM, so be it.  We 
already know weak DRM is supported by a buggy law.

> 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.  (see point B on overgeneralisation)

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.




D. Do not tell other people what they think when it is possible that 
you have simply misunderstood their expressions of those thoughts, or 
(worse) prejudged them.

Greg London wrote:
> The only people who are NOT happy are people who
> want to sell DRM-only versions of CC-SA over the web,
> or over some physical medium that uses DRM.

And people like me who think they may want to buy DRM/non-DRM parallel 
copies of CC works.  And probably some others have other reasons too.

Sorry if anyone thinks that makes us evil.  I think it just means we (or 
our friends) weren't clueful enough when a certain player was obtained, 
or our market offered no viable alternatives for an initial compulsion.

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.

> 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.

> [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.




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.

[...]
> > DRM-banning clauses are an attempt to use law to outlaw code.
>
> DRM is law, not code. And it is law that outlaws code, ask Skyralov. 

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 GPL-3
> demonstrates how TPM code can be written without the effects of TPM law. I
> think we both agree that this would be a good way of tackling the issue.

Indeed.  Similar smart solutions for CC3.0 would be a brilliant outcome.

In hope,
-- 
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Somerset, England. Work/Laborejo: http://www.ttllp.co.uk/
IRC/Jabber/SIP: on request/peteble



More information about the cc-licenses mailing list