[...] the W3C cannot prevent companies from grafting DRM onto HTML. They do this through nonfree plug-ins such as Flash, and with nonfree Javascript code, thus showing that we need control over the Javascript code we run and over the C code we run. However, where the W3C stands is tremendously important for the battle to eliminate DRM. On a practical level, standardizing DRM would make it more convenient, in a very shallow sense. This could influence people who think only of short-term convenience to think of DRM as acceptable, which could in turn encourage more sites to use DRM. On the political level, making room for DRM in the specifications of the World Wide Web would constitute an endorsement in principle of DRM by the W3C. Standardization by the W3C could facilitate DRM that is harder for users to break than DRM implemented in Javascript code. If the DRM is implemented in the operating system, this could result in distribution of works that can't be played at all on a free operating system such as GNU/Linux.
Heya Karl,
You're right, it isn't the "threshold pledge" system, and it is directed donations in a large way. Even so, when we had the conversations with the FSF initially about the campaign, the conversation was really a "Are we going with the FSF or with Kickstarter?" type of conversation, and what we said was "we'd like to go with you, but there's a whole set of things that Kickstarter does that you don't yet." But the FSF implemented them, retooling a ton of their infrastructure specifically for this campaign: the list of rewards that you can select from, a progress bar that auto-updates as the campaign goes along, the list that you get subscribed to when donating so you can hear updates as the project goes along, and a bunch of other things: these are things that Kickstarter had that the FSF didn't, but the FSF developed those tools so that they can better support campaigns that run in this way for free software projects.
So you're right that it's not an assurance contract system, but there are other crowdfunding platforms that have been on the rise that have been (rightly) lumped together when describing the rise of project crowdfunding. And the campaign that we set out is one that fits the type of patterns that projects fundraising under those systems have been using. So while it's not an assurance contract system, I think it's also incorrect to redcuce Kickstarter and friends to just assurance contracts. And the fact that the FSF did significant retooling of its infrastructure to reflect those changes is I think quite noteworthy.
It is easier to write an incorrect program than understand a correct one.
