[Commons-l] How non-free is Flash?

Gregory Maxwell gmaxwell at gmail.com
Tue Mar 6 14:18:59 UTC 2007


On 3/6/07, Erik Moeller <erik at wikimedia.org> wrote:
> How non-free do we consider Flash to be? The Gnash player appears to
> be making good progress. Would it be acceptable to permit useful Flash
> files which work in Gnash and don't require non-free codecs to be
> uploaded?
>
> I did not see any issues with patents mentioned in the relevant
> Wikipedia article. The old Macromedia Flash website lists a US patent
> on "creating gradient fills", but that seems so bizarre as to pose no
> real threat.

For what application? I see that you say 'don't require non-free
codecs', but it's not clear that you're aware of the status of codecs
in flash:


For video support the flash plugin contains a H.263 video and a MP3
audio codec.

It's not possible to write MP3 software which does not infringe
5,105,463 among several other patents
(http://news.bbc.co.uk/2/hi/business/6388273.stm Weee!).

H.263 is covered by a pool of patents similar to MPEG-4.

Flash player 8 and above also includes the VP6 video codec. On2 has
patents they license for VP6 use, but overall they are pretty cool
company though, so I'm not fully sure where that stands. I expect that
requiring flash player 8 would leave Java as a more compatible web toy
solution.

Unlike the Java video player implementations the codec isn't actually
'written in flash'. Actionscript is a poor match for doing lots of
data manipulation. I understand that someone nearly has a Vorbis codec
working actually written in actionscript, but it's too slow to be
useful.

So for video, flash does not look good. The use of cortado in Java
would be much better. (http://www.flumotion.net/cortado/). Success
rate of the inline Java audio player hasn't been bad, and cortado
should be even more compatible with older JVMs.

A bigger concern I have with the freedom of flash doesn't have
anything to do with patents: There are no free authoring tools, other
than some hacks that are used for dynamic authoring. I think this is a
pretty big killer. Nothing we need for authoring today requires
proprietary software.

If we're looking to allow users to submit flash there another freedom
related issue:

Since the toolchain is proprietary and built around desktop usage
we'll be stuck with the 'opaque object' problem. In short, for
downloadable turing complete software (Java, Flash, JS) it can be
impossible to fully understand what the software will do. Perhaps on
the 3rd of the month it displays the goastse image, perhaps it
exploits the sandbox and steals your data. In cases where we have the
source, it's possible to require the software be simple enough that no
such tricks could be easily inserted.  As a result I previously
suggested that if we ever accept user submitted java that we have
people submit source and we compile it on our side. Because the flash
authoring tools are proprietary this option is closed to us.

These are just some quick points, a little more knowledge of the
intended application would help me drill in and look for freedom
related limitations.

I hope that I'll be given the opportunity to comment on the
non-freedom related aspects, since I think there are some significant
issues. Again, knowing the application is critical.



More information about the Commons-l mailing list