« previous 1 2 3 next »

Flash set free?

There are questions McAllister hears all the time from customers and the open source community. Most common? "'Where is my 64-bit version of flash for Linux?' It's there and it works pretty darn well."

But, he says "the number one all time question is 'when are you going to open source the Flash player?'" And the answer? "It's as open as I can make it at the moment." Adobe’s opened a lot of the key Flash technologies over the years, from the Tamarin ActionScript JIT compiler to the ActionScript language and the Flex compiler and debuggers. Then there’s the development framework itself, in the shape of the Flex SDK, the new open source media framework to help sites build their own iPlayer-style services, and the text flow and layout tools used by the New York Times reader. Mcallister says the releases won’t stop, "The commitment I have is that when we launch new pieces of technology we will open source those technologies."

Even before Adobe open sourced this many Flash technologies, the Gnash project (under the Free Software Foundation) started work on an open source version of Flash - though there’s little contact between the two. McAllister acknowledges the importance of Gnash and similar projects. But, again pragmatically, he says, "There is a catch. The dominant format for premium video is H.264, which is encumbered in patents. The Flash Platform includes numerous video codecs, including the aforementioned H.264, Sorenson Spark, On2 VP6, and others." That means a fully compatible, fully open source player is problematic. One the one hand, he claims the specifications and open source code Adobe has released would certainly "aid such projects in developing a compliant SWF clone". On the other, he points out; "Keep in mind that the runtime for Flash platform (Flash Player) is free, widely available for most platforms. And with platforms, the stability is important."

Adobe won’t open all its code – but many tools are built around open standards, and where it competes is in look and feel, and implementation. "It is unlikely that Photoshop is going to be open sourced but the XMP metadata model is all published, along with the GIL, Adobe’s Generic Image Library. " Adobe won’t stop open source projects using these components in their own applications, even if they compete directly with Adobe’s own tools; "It's all there, anyone can do it."

Left hand of licensing

Not all Adobe open source projects are hosted – or even managed – by Adobe. Tamarin, the ActionScript compiler, is hosted by Mozilla. Adobe has a definite preference when it comes to open source licences. "We tend to favour the academic licences along the line of 'here is some code, do what you want with it, don’t sue me, have a nice day'. The MIT and BSD licences are along those lines." Most code open sourced by Adobe is placed under the BSD licence, says McAllister. When Adobe wants to use the copyleft approach favoured by the Free Software Foundation, it uses the Mozilla Public Licence, or the LGPL, which he summarises as "if you didn't modify the files you can do whatever you want; if you modify the files you need to licence".

Tamarin, the JIT compiler for the ActionScript runtime, is under the Mozilla licence simply because it went to the Mozilla foundation - which does have drawbacks; "The good thing is it’s a BSD-style licence, the bad thing is they have some things written into the licence that may not be universally applicable and our lawyers get very uncomfortable."

Only one project, Blaze DS, is under the LGPL licence and Adobe refuses to release any code under the GPL licence – and there are specific reasons for both of those decisions. It chose the LGPL for Blaze DS to control how third parties work with the code. "We had somebody say they were so interested in Blaze they wanted to grab it and modify it in ways that would not sit well with us and we said 'what is the best way to stop that?’." The answer was the LGPL.

And while McAllister suggests that "If you want to make money selling open source software use GPL," Adobe will not use it because of customer concerns about inheritance issues when GPL and LGPL licensed libraries are used in customer applications. There’s a specific exception in the GPL for Java, but it’s not specified for other languages – so Adobe adds its own exceptions to licences to ensure that inheritance doesn’t expose customers to the full force of the licence. There are good commercial reasons for this, says McAllister; "We have been frequently contacted by customers who have asked us not to use the GPL. They are under a mandate not to allow influx of GPL. Companies don’t like it, but they’re not necessarily scared of it." The same is true of Adobe itself, as McAllister notes, "We only allow it in under very tight scrutiny."

Adobe’s open source Web site is your one stop shop to find out what projects Adobe is involved in or running, and to get downloads of source code. Patents are more an issue than licences, he believes; "Right now it's not so much licences that drive open source people crazy it's what do the patents say". Adobe’s response is a patent guarantee that McAllister calls simple, "If you sue us we have the right to remove your patent licences. If you sue anyone based on our patents, we remove your right to use our patents."

Adobe builds open source technologies into its own products. LightRoom uses the Lua scripting language, and the proof-of-concept Alchemy Flash to C++ cross-compiler is built on top of the LLVM lightweight compiler (which is also driving the Flash to iPhone cross-compiler being developed for Flash Pro CS5). LLVM has a very open licence if you’re not using its GCC-based front end, which has let Adobe modify and distribute the compiler without sharing all its changes. McAllister is happy with that; "We did modify the LLVM code but LLVM grants a uniform exception to anybody’s code being exposed. It's the weirdest thing I've seen in my life, but that's the LLVM model."

Next: Getting the governance right and what's next for Open Adobe

« previous 1 2 3 next »