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.