FOSSwire

Ars Technica is reporting that the Motion Picture Association of America have been hit with a DMCA takedown notice after offering a download of an Ubuntu-based networking monitoring tool without source code, a direct violation of the GPL.

The MPAA software was supposedly designed to assist universities in detecting people using software to download and share copyrighted material and was apparently based on the Ubuntu Linux distribution.

The obvious irony here is that in trying to distribute a piece of software designed to prevent copyright infringement, the MPAA have - infringed copyright by breaking the GPL licence. Leaving that irony aside for a moment though, and it's clear that Matthew Garret, who filed the DMCA takedown on behalf of the Ubuntu team, is sending out a clear message - that GPL violation is exactly the same as violating any other copyright.

Those who aren't fans of the free software/open source movement often cite their doubt as to whether the GPL is enforceable, especially when you are dealing with individuals rights, who don't necessarily have the legal resources to chase up all possible violators. In this case, the MPAA obviously realised that not complying was definitely not an option, as the commercial arms involved in Ubuntu (and possibly others) would have piped up and put pressure on them.

Would this have happened with a small GPL'd project with limited resources, however, if a similar violation happened? It's not really an easy question to answer, although there are efforts such as GPL Violations to raise awareness of smaller violations of this nature.

Enforcing the licences is definitely important. It's important to send the message out to potential exploiters that there are consequences for not following those terms.

One feature of the free software/open source development model that is largely unique and differs from the proprietary model is sheer diversity.

For any one particular task, there might be several different implementations. Looking for a graphical email client? You've got Kmail, Evolution, Thunderbird; the list could go on. These programs might all bascially do the same thing, yet you've got three different projects with three different sets of developers, three different channels of distribution and so on.

One of the benefits of this, of course, is that you get a certain amount of 'survival of the fittest' within the FOSS world. Two different approaches to solve a problem can be developed in parallel and the strongest solution may win out and go on to become a fully-fledged software solution.

The second benefit is choice for the end user. Not everyone will want a particular bit of software to work in a particular way. When you have multiple solutions for a problem, the user gets to choose the one that works best for them. Variety and choice is most definitely a good thing in this case.

You could also argue that more diversity means more secure solutions as well.

A significant disadvantage of this diversity and fracturing, however, is duplicated work. Two developers working again in parallel on a single solution will end up implementing the same things twice between them. "Don't reinvent the wheel" programmers are told - but that's exactly what they will be doing.

Add in another complication - forking. Forking, for the uninitiated, is when a project splits into two (or more theoretically). The source code from the original is taken and becomes a new project.

In the case of a fork, it is often that the changes from a forked version will not end up propagating back to the original. Licence differences between the two projects can even legally prevent this, so again we get stuck with a high potential for duplicated work.

Also from a commercial viewpoint - having lots of choice and lots of diversity can make it more difficult to pick a solution, as you won't necessarily be able to guarantee the one you pick will remain in development and will 'win' over any competing solutions.

So what can we do to try and make the best of the diversity of FOSS, while minimising the likelihood of and impact of duplicated effort?

Getting developers to talk to each other is certainly a start. Where collaboration is possible, they can work together on common code.

This sort of collaboration is much easier to achieve when you're working with software libraries and frameworks - i.e. code that is mostly on the backend and is shared between applications. A good example of this working well is some of the coordination that Freedesktop does to achieve common standards between desktop environments like GNOME and KDE (although even that is far from perfect).

I think it's more about striking a balance between working together and letting things be done separately. Ultimately, there is no 'solution'. The FOSS model is a double-edged sword with both good and bad points - with unique advantages but also unique challenges.

Flash is everywhere on the web nowadays. From YouTube (and the myriad of other video sites), to corporate websites, to online portfolios, a web experience without Flash Player installed isn't really a complete web experience.

The problem with Flash Player is that it isn't free software or open source. Well, it's not necessarily a problem depending on your viewpoint on non-free software is, but even if you are pragmatic and do install the official Flash Player for Linux from Adobe, you have to install it manually, as most distributions don't include it by default. And installing it manually can be a pain.

For some time, the GNU Project has been working to build a free replacement for Flash Player which implements the file format so you can enjoy Flash content while using GPL'd code, which solves the pre-install problem (vendors can safely bundle GPL code) and the non-free problem. That project is called Gnash.

It is not perfect yet, in fact as you may have guessed from the title of this post, it's still only Alpha quality and only implements some of the Flash 7 standard right now. I thought I'd give the latest Alpha release a road test to see how usable it is and how much Flash content will work.

I downloaded the 0.8.1 release source code and compiled it on my Pentium 4 Kubuntu Feisty system. Once you've done the normal ./configure, make, make install routine (you will be told about any dependencies you need when you run ./configure and how to install them on most systems), you have several parts to Gnash.

There's a standalone application which will be installed (which can be launched from the command line with the command gnash). If you supply the command line application with the path to an swf file, it will do its best to play it.

I thought I'd try out the command line utility by playing good old Badger Badger Badger. To do this from the command line, I first downloaded the swf, and then fed it into Gnash:

$ wget http://badgerbadgerbadger.com/badger.swf
$ gnash badger.swf

I couldn't get any sound to play in it, but the animation played pretty much flawlessly (aside from some minor horizontal tearing) which impressed me. CPU usage did spike to around 50% during playback (this is on a 3.0 GHz system), which is a little concerning, but Flash animations are often gloriously inefficient with CPU usage even using the official player.

The other part of Gnash is the browser plugin and is probably the most important part considering that the Flash you'll be finding will be mostly, if not always, found on the web.

If you already have the official Flash Player installed in a Mozilla-compatible browser (I'm using Firefox 2.0.0.6) here, you'll need to move the libflashplayer.so file outside of the plugins directory so that Gnash will take over. Once you have done so, Gnash will handle all Flash files.

YouTube is probably the most obvious test here - so with Gnash installed and ready, I headed over there. Unfortunately, I couldn't get Gnash to play anything and the video widget just sat there with the loading animation. It's quite possible that recent updates to the YouTube widget have made it incompatible with Gnash, because the site boasts that 0.8.0 has compatibility with YouTube.

I also tried several other video sites with no success.

While FLV-based videos don't appear to be very successful with this release, pure Flash-based animations that don't use functionality specific to version 9 of the player. For example, internet cartoon Homestar Runner works pretty well under Gnash (although again, I have had no luck with sound in any of these).

Gnash is a very ambitious attempt, as the Flash format is very big and very proprietary. At the moment, at this fairly early stage of development, Gnash - from what I have seen - is only able to render reasonably simple animations and has problems with major FLV players.

If you are serious about being 100% free software and don't mind losing access to some Flash-based content, Gnash might be the right solution. At the moment though, it isn't quite at the level of a Flash replacement, even for Flash 7-based content, and I'm personally still going to be using the official Flash 9 Player.

Still, Gnash is coming along nicely considering it's started from absolutely nothing and the developers are getting no help from Adobe. If you want to check out Gnash, head over to the project page on the GNU site.

Calling all FOSSwire readers! We're looking for your feedback - answer our reader survey and you could win an awesome FOSSwire t-shirt (we'll ship anywhere on this planet).