[E-Lang] E, DRM, ENative, openCOLA, and other stuff

Mark S. Miller markm@caplet.com
Mon, 16 Oct 2000 03:25:15 -0700


At 05:48 AM 10/15/00, Dan Moniz wrote:
>I'm presenlty employed as the research lead of a company called openCOLA
>(http://www.opencola.com/) [...] suffice to say we're also a relatively clued open source shop
>-- we plan on open sourcing under an industry accepted license the software we
>produce from our venture. 

Just to reiterate: Besides being "industry accepted", in order to work with 
E, it must also be a Mozilla compatible license.  Usually, this means any 
widely accepted open source license other than GPL.  For example, LGPL is fine.

>However, at openCOLA (oC), one of my main short-to-long term research tasks was
>to look at a number of acceptable digital rights management solutions, with an
>eye towards being able to implement something that would allow us to be able to
>share copyrighted content and make sure the correct parties get paid, etc.

Whenever we talk about this topic, we always need to be clear about what can 
and cannot be enforced.  The bad news is that copy protection itself is 
impossible.  The good news is that many other arrangements for compensating 
artists are still possible, and DRM technology can play a big role in 
supporting these arrangements.

The impossibility of preventing copying is well explained in "The Street 
Performer Protocol and Digital Copyrights" by John Kelsey and Bruce Schneier 
http://www.firstmonday.dk/issues/issue4_6/kelsey/ and 
http://www.counterpane.com/street_performer.html .  Besides copy protection 
per se, many who wish to find something like copyright have pinned their 
hopes on digital watermarking. Though watermarking is possible in principle, 
the above paper also explains why watermarking won't have the effects the 
copyright holders are hoping for.  Also, it's not yet clear how possible 
watermarking is in practice. Salon reports 
http://www.salon.com/tech/log/2000/10/12/sdmi_hacked/index.html that the 
SDMI contest has apparently resulted in all SDMI watermarks being cracked, 
despite a ridiculously short contest deadline and a (misguided) hacker boycott.

The Kelsey-Schneier paper also presents a great example of how a 
post-copyright world can still support art and artists.  They explain an 
arrangement in which the artist can still create an enforceable scarcity in 
their own works (which is all that copyright was ever about), and accept 
payment to end this scarcity.  With this proposal as a first clear example, 
many other workable arrangements will be discovered.  Many of these 
arrangements will be practical only when supported well by a DRM technology. 
We only need to give up on the idea that the R for DRM to M is the R to 
copy.  If instead we choose enforceable Rs, then the rest of this technology 
has tremendous leverage.

"Is" and "ought" statements are often confused.  For my "ought"s, I want to 
make clear that, if I could wave a magic want and cause "copyright, narrowly 
interpreted" to be enforceable, I would.  Other things being equal, I 
believe a world without copyright will be poorer than a world with 
copyright.  Patents, on the other hand, I find fundamentally immoral, and 
would sweep away in an instant with this same magic wand.  The difference is 
that copyrights only inhibit "derived works", whereas patents inhibit 
independent reinvention.  I see no moral justification for the latter.

But none of this matters, since no such magic wand exists.  Even the old 
interventionist wand of governmental force will quickly be made impotent in 
the copyright fight by cryptography and (if necessary) steganography.  The 
"is" is that we're rapidly entering a post copyright world.  So we ought to 
learn to live in that world as quickly and as well as we can.  The answer to 
the impossibility of copyright is not to give up on the problem that 
copyright used to solve, but to find other solutions -- as Kelsey and 
Schneier have done.


>Shortly before officially coming on board with openCOLA, I had made the oC guys
>aware of the E toolkit and the surrounding project, and placed a rough sketch
>of how E and the smart contract concept can really be an amazing solution to
>DRM, as well as something that goes beyond simple DRM into the realm of almost
>all financial (or otherwise) transactions across the oC network.

Thank you.  Of course, I agree!  Some of the variations and elaborations of 
Street Performer that some of us have come up with are, I believe, only 
practical given an infrastructure such as E.


>I've recently been given the go ahead to throw everything out to the list [...]

It is rare and wonderful that you can pursue these issues, which include 
business issues, in the open.  Three cheers for openCOLA!


>Also, I'm in contact with some of the Mojo Nation people, who I desperately
>want to meet with as well, since their current system and ours (openCOLA's)
>are amazingly similar, and we have goals that also seem to be in lockstep with
>one another. If anyone knows people I can talk to there that would be
>interested in talking to me, I'd appreciate referrals. I snagged ahold of Bram
>Cohen (from coderpunks) on their IRC channel one night, but again, due to a
>hectic schedule, haven't yet been able to get to a sit down meeting.

I think the Mojo folks are doing great work.  Btw, their work is not 
unrelated to the E work.  Jim McCoy says that much of what they're doing is 
based on the agoric concepts of http://www.agorics.com/agoricpapers.html and 
http://www.agorics.com/dsr.html , and that he views E as the direction he'd 
like to go in when he expands to support general purpose distributed 
computation.


>I started talking with markm about this in vague terms a while back -- oC is
>presently using C++ and some C for all of our production code, and the ENative
>[...]

>I've been reticent about getting down and dirty with Java for a while, but the
>various "small Java" pieces that are coming out of Sun and others actually have
>my interest. I've been playing with things like Wabasoft's Waba VM
>(http://www.wabasoft.com/), Sun's KVM (part of the J2ME, and more specifically,
>the CDLC), and Sun's MIDP, along with a modified Java SDK from Research in
>Motion (http://www.rim.net/), a firm with heavy Canadian ties (they make the
>BlackBerry email pagers). Naturally, this has me wondering about a microE (uE
>?) that would work on these sorts of devices. Anyone else have ideas in this
>field?

Both ENative and most of the teeny JVMs are plausible platforms for a 
headless E that doesn't need an extensive pre-existing library.  What we 
need to figure out for your usage of E is: Which of your E programs will 
need user interfaces?  Most of the teeny JVMs do not have a Swing library, 
nor even a compatible subset of Swing.  Perhaps this will change within your 
product development window?

ENative, of course, was developed under the expectation that it would run 
headless as well.  However, the Cygnus GCJ project (Gnu Compiler for Java, I 
think) provides hope.  It compiles Java (or JVM class files) to machine code 
using the same compiler backend and essentially the same calling conventions 
as their C++ compiler.  The result is that their C++ and their Java can call 
each other naturally and at full speed.  If this project gets far enough 
along to result in a compiled Swing that can inter-call with C++, then 
ENative should be able to use this Swing library in a way compatible with 
how E-on-Java uses Swing.

In any case, it sounds like we've got plenty to explore and talk about.  I 
agree that E and smart contracting is the infrastructure on which to 
build the world of post-copyright DRM, and so enable artists of all forms to 
continue to be paid for enriching our lives.