Introduction
Adobe Flash (formerly Macromedia Flash) is a proprietary program probably best known these days for two things: showing people videos (YouTube) and making animated interactive graphics on the web (many ads are require Flash). Flash documentation was also, until recently, only available if one agreed to rather onerous non-disclosure terms which restricted how many people could write their own Flash player.
The most widely used Flash implementation is proprietary and not available for all kinds of computers and operating systems. A free software Flash player program was needed so that people could use their computer in freedom without having to forgo visiting a number of popular websites.
One free software Flash player, Swfdec (pronounced “swiff deck”), has been in active development for some time, and generally becoming more capable. Another free software Flash player, Gnash (the GNU Flash player), offers considerable capability to play Flash websites. Gnash has also been in active development.
What’s happening now
Today Adobe announced that they have released documents which describe the structure of Flash files one finds online. These documents are restrictively licensed—sharing the document files is not allowed, not even verbatim non-commercial sharing—but the information is available without agreeing to the non-disclosure terms. There’s no clear indication that Adobe holds patents on the ideas one needs to implement their own Flash software and no clear license granted for such patents.
Why would Adobe do this at all, why would they do this now?
I think that when free software gets to a point where it can perform sufficiently well, competitors take notice and react. The free software competition doesn’t have to be a drop-in substitute to be an effective means of applying pressure which engenders more software freedom.
Is Microsoft’s Silverlight responsible for pushing Adobe to make their documentation available to more people? If so I doubt it played a very big role because Silverlight exerts little pressure; hardly anyone uses Silverlight (so users are unlikely to come across a Silverlight-based website) and Silverlight doesn’t come with Microsoft’s currently most popular variant of Microsoft Windows so it’s not widely installed by its target audience.
What’s the value of Adobe’s new release?
Adobe isn’t divulging very much. Adobe isn’t changing the license for its Flash implementation; that’s still proprietary software. Adobe isn’t even distributing their Flash player for all kinds of consumer-grade computers in use today, there’s no 64-bit Flash player program. But Adobe has taken one step toward making it possible for more hackers to contribute to free Flash software players.
Adobe could be providing a trap as well. If there are any Adobe patents covering ideas described in the documentation, Adobe gives no indication that you are licensed to deal in those patents. So this raises (at the very least) questions about whether Adobe is trying to trap people into implementing something that they couldn’t distribute as free software. Adobe could grant a license to implement anything covered by those patents, but the larger problem would remain for patents Adobe doesn’t control. The real fix for this is simple: end software patents.
People in countries that don’t have software patents don’t have to fear losing a patent infringement lawsuit, but software patents have put quite a chill on users who deal with software (which is virtually everyone and every organization). Software innovation happens without government intervention. So we don’t need to worry that people will stop improving computer software if software patents were no longer enforceable. Everyone who uses a computer is at risk with software patents. Around 1990, Paul Heckel threatened Apple over a patent of his that covered something in Apple’s Hypercard program. After Heckel told Apple he’d sue Apple’s users, Apple realized that for the price of licensing Heckel’s patent (paying him off), Apple could avoid becoming known as the computer company that will put its customers at risk of losing a patent infringement lawsuit. Apple paid Heckel an undisclosed sum and Heckel went away. But the example Heckel set remains a potent demonstration of the power of software patents.
Adobe didn’t release much of interest to Swfdec. Benjamin Otte, the chief swfdec developer, said that Adobe’s release today isn’t valuable:
For Swfdec the Flash playe it means pretty much nothing. Swfdec already implements everything that is written down in that specifications. This is just the Adobe version of http://www.m2osw.com/swf_alexref.html
For Swfdec the project it’s nice that people will stop asking “Did you read the forbidden specs? Are you sure what you’re doing is legal?” Even though these where pretty much non-issues before. It also means we now have a document to show newcomers that want to hack on Swfdec. It seems nicer as an introduction text than the link above.
This isn’t the first time we’ve seen such a reaction on the part of a major proprietor. Sun Microsystems distributed their proprietary Java software for years and recently liberated it. At about the time they had announced their plan to liberate their Java software, free software Java implementations were coming of age. It was increasingly likely that one could run a free software Java program without relying on Sun’s proprietary Java software.
In late 2006, Philip Langdale wrote about a similar move with SD card readers (those devices that read the media you might use with a digital camera, digital audio player, or personal digital assistant). When Pierre Ossman reverse-engineered the relevant standard that allowed him to use his SD card reader and then shared his software, we all benefitted. Subsequently the SD Association released a version of the specification that helped filled in some gaps Ossman’s software didn’t include. Langdale explains:
Although I can’t prove it, I feel that the subsequent publishing of the ‘simplified’ spec (without the DRM bits that we don’t care about) by the SD Association was provoked by his efforts (Why bother hiding it now?) Thanks to those specs, Pierre was able to polish the driver up even more and support a wider range of implementations (of course, there are some that are so out there that even having the SDHCI spec isn’t enough to get them working).