winningham at gmail.com
Sun Jan 23 22:27:09 EST 2005
Thank you all so much for all comments. I'm compiling them, and first
off I would agree that a separate dictionary in the .torrent may be
Anyway, that is to be worked out, but some goals and use cases (and
I'll put these up on the page too):
1. To identify a BitTorrent distribution act as Creative Commons licensed.
2. To provide the proper metadata associated with that (deriv, source, etc)
3. To allow people the ability to easily note the CC license during
the act of creating the .torrent along-side of the tracker, and files.
4. To foster the commons in using BitTorrent as a means of
distribution that allows them more reach than their existing bandwidth
can realize, and proportionally so with demand.
Whether or not marking each files' license within the .torrent
distribution is something that could be decided upon, however, adding
per-file descriptive information beyond file and size is beyond the
scope of the protocol. The info_hash is derived (as best as I can read
the spec) from the content of the info dictionary where this sort of
per-file license would most logically reside. A .torrent file has no
per-file user-specified data beyond file name for each individual file
in the .torrent.
So, I think that if you're going to distribute it "under" a license
(and a distribution act such as making a BitTorrent file available
would imply some kind of authority to do so), each file should perhaps
have the same license as the distribution as a whole.
Maybe you all could help me with that quagmire.
Use cases would be:
1. A tool for creating a .torrent file where the user could go ahead
and apply a license to all of the work as a collection.
2. Downloading content through BitTorrent and being assured of your
legal rights to do so (as well as your legal right to allow uploads
back to the swarm)
3. Creating a site where you can be assured that .torrents coming in
for submission to be published on your site (*and* to use the site's
BitTorrent tracker) can programatically look for the license before
the work can be published (to keep the site admin's safe)
4. Auditing tracker use according to license, tracing back use of a
tracker back to licensee in case of dispute.
I hope that helps. This is my first work with standards, and I figured
that the XML types out there that know the nuances between things that
I'm only beginning to uderstand (difference between schema and DTD,
for instance) could help with.
The technical challenge to adapt these ideas to the becoded format is
something I feel readily able to facilitate.
Thanks so much,
On Fri, 21 Jan 2005 21:19:28 -0800, Mike Linksvayer
<ml at creativecommons.org> wrote:
> Thomas Winningham wrote:
> > http://writtorrent.sourceforge.net/2005/01/rfc-bittorrent-creative-commons.html
> > This needs to be hammered out a bit, as far as tags within tags, and
> > attributes. I have a shout out to the BitTorrent development group as
> > well.
> Is your goal to support any "CC metadata" then you want to create a RDF
> serialization. I doubt you want to do that. Or a container for
> aribitrary RDF/XML in your XML document, and perhaps RDF/XML as a string
> in the bencoded version.
> Much as I'd like to promote the use of RDF, any of the above sound
> fairly unnatural and painful -- unless you want to have the potential
> include complex metadata in the .torrent (xml or bencoded) file, e.g.,
> describe each file in a multifile torrent, in which case RDF fits the
> bill (if you don't use RDF you'll just reinvent it).
> Something flat, akin to
> http://dublincore.org/documents/dc-xml-guidelines/ would probably
> satisfy your requirements, though I'm not sure what those are. You can
> specify a license with cc:license = licenseURI. Those who want to know
> what permissions, etc. are associated with licenseURI can grab the RDF
> from that URI.
> Sorry for rambling. Can you spell out your goals and some use cases?
> Mike Linksvayer
More information about the cc-metadata