For people making videos, I created cuts of 20 seconds, 30 seconds, and 40 seconds. I have noticed that the length of a piece of music is a big factor in choosing it, so these cuts are to increase the number of situations that this music fits.
For people doing remixes, I created a sample pack with eight clips under five seconds. I did this because chopping up a song into samples is a fair amount of work, and eliminating that work increases the number of people who might use samples for the song.
With both of these sets of cuts, the goal was to increase the potential growth of my music. The popularity of my song can only grow linearly, as the sum of listens. For each song or video that it is incorporated into, there is a multiplier on that growth curve. If songs or videos that incorporate my work are themselves incorporated into other works, there is exponential growth in the listenership for my music.
I also created a clip to be used as a ringtone. My thinking was that supporting more playback contexts, and especially a playback context as common as cell phones, would again do good things for the potential growth curve.
Lastly, I created a page which can transpose and play back the sheet music using the Scorch browser plugin. This should increase the number of contexts that the sheet music and tablature are useful in and the number of people who can follow the sheet music. Having people incorporate my musical work by learning from a piece of sheet music that I created is again a way of hitching a ride on other people’s works.
What I didn’t do was go out and plug my song. I didn’t make CDs to mail to radio, press, and booking agents. I didn’t email bloggers one by one. I didn’t post comments on other musicians’ Myspace pages. I didn’t email all my friends. All of these ways of marketing are good things to do, but I am lazy and would rather have other people do that for their own stuff and bring mine along for the ride.
I also didn’t make a new song. It’s good to keep up a steady flow of fresh work, but winner songs don’t come along all that often and once you have one you’ll probably get more growth overall by focusing your efforts on the winner.
Something I’ve never understood about Creative Commons is the emphasis on redistribution rights.
For the most part, CC licenses focus on who can upload a copy of a file. A song under any CC license can by uploaded by anybody whose activity fits within the terms of the license. For example, the Attribution-Sharealike license allows third parties to upload copies without asking permission as long as they give attribution and use the same license on their uploads.
Who needs the right to upload? It’s not something that anybody making work under a CC license even needs to grant, since virtually of them host freely accessible copies on the web. All anybody needs to access these works is to know the URL of the original file.
With files that are already on the web it doesn’t make sense to do filesharing, so there’s no need to permit redistribution. Filesharing is purely a pain in the ass for users, who have to leave the normal browser experience and launch a dedicated piece of software. You could maybe make a case for BitTorrent as a way to spread the bandwidth load, but that relies on a level of popularity which almost no CC works attain. And anyhow, there’s no need for an explicit license to permit BitTorrent as long as the rights holder hosts the seed file, since that would very much imply that BitTorrenting was fine.
The only thing that you really need a Creative Commons license for is the ability to make derivative works, which gives you the ability to do remixes. This is genuinely useful because there is no other way to do it. Without a license to make a derivative work you are up a creek, and making derivative works is a fundamental operation for participation in culture.
When you put a Creative Commons license in a web page, it usually applies to that page. For example, if you generated HTML for the Attribution-ShareAlike license using the license chooser at CreativeCommons.org and put that claim into a web page at http://example.com, it would mean that the page at http://example.com could be freely shared as long as there was attribution and the sharer applies the same license to their copy.
By using the “about” attribute specified in RDFa, you can modify that claim HTML so that it applies to a different URL and not the page in which the HTML is embedded.
Let’s say you have a media file “my.mp3” (which may or may not have embedded license info), it is online at http://example.com/my.mp3, and you have a web page at http://example.com. Let’s also say you have a chunk of HTML for saying that the current web page is under an Attribution-Sharealike license.
Your web page containing that chunk would normally have HTML along these lines:
[the HTML for the license claim]
The modified HTML would look like this:
[the HTML for the license claim]
This is a new way to publish a license claim for a media file. The existing way is to embed the claims into the file using a tool like liblicense. The reason you would use the new method is that the benefits and drawbacks are a better match for your needs.
Pros of embedding within media files:
A license claim inside a file travels with the file, so that the license claims on the copy are still identifiable. If you use the external HTML method, the only way to tell that a copy at a different URL is under the same license is to do a byte-for-byte comparison of the files.
A license claim inside a media file is instantly accessible to any program which is already accessing the file and only slightly less accessible to a program which already has a copy of the file. A license claim in external HTML requires the HTML page to be found, fetched, and parsed.
Pros of using an external HTML file:
A license claim inside a media file is hard for web spiders to see, and most search engines won’t index it. In contrast, a license claim in HTML is easy for a spider to see and all search engines will index it.
A license claim inside a media file requires a dedicated program like liblicense on the client side to edit. A license claim in HTML can be generated using a simple web application like the license chooser at CreativeCommons.org, and any decent content management system (like Drupal or WordPress) could easily do it.
You don’t have to choose between these methods. There is no reason why these two methods can’t be used together, which would give you the good parts of both.
As with all implementation proposals, this method may not work. It may be that the RDFa “about” element isn’t widely available enough, given that it is specific to XHTML 2 as far as I know. It may be that the rel-license microformat can’t be extended like this.
There’s one improvement to this method that I don’t know how to do — making it work in existing search engines with no changes on their part. If it’s possible to tweak the HTML syntax so that existing search APIs or query arguments could be used to find Creative Commons works, the entire open media ecosystem would benefit.