Skip Links

Solving the Apple App Store Incompatibility with the GPL

What’s needed is a little legal linguistic grease to enable the two orgs and their differing goals to slide by one another.

By Stephen Walli on Mon, 01/10/11 - 1:43pm.

Here’s an idea for all open source legal experts to gnaw on and solve for the community. I saw today that Apple pulled down the VLC media player because of the conflict between the GPL and the Apple App Store terms of service. The SJVN article does a great job of reporting the issues of the actual conflict between the GPL and Apple’s ToS as well as the social concerns raised over the previous “don’t ask, don’t tell” actions and someone not associated with the VLC software on the App Store calling the question for Apple. I think there may be a different solution.

A person that creates software has the ability to license it as they see fit as many times and in as many ways as they can reasonably create. A lot of people have termed this as “dual licensing” in the open source world after MySQL AB used it to license their software to the community as free software under the GPL while continuing to sell a proprietary closed edition of the software under a separate license to businesses that wished to make changes to the software and protect those changes as closed.

The practice of applying multiple licenses to a specific piece of software, however, predates the MySQL practice. The Perl community often published software under both the original Artistic License as well as the GPL to enable the software to be combined easily with other GPL licensed software. The terms of the GPL and Artistic license are otherwise incompatible. (The Artistic License 2.0 solves this problem.) Microsoft licenses its software in a range of proprietary ways under different licenses to customers from Enterprise agreements and other bulk licenses down to the shrink wrap EULA on the box of an individual copy at the corner office supply store.

This suggests a way for developers that are strong believers in free software to also use the Apple App store as a channel to get their software in front of a larger audience. The project could essentially create a dual licensing scheme using the GPL for its wider audience and a separate Apple App Store distribution license for the executable version and its derivatives that sits on the App Store and that further allows others to use and to publish the binary on the App Store.

The project wins. It maintains its software freedom goals using the GPL as the contract with its contributors and committers in the project’s community. No one outside the project community can thwart the GPL to create a closed version. The project gains the powerful distribution channel of the Apple App Store to promote the use of the software beyond the other channels it uses to distribute software freedom goodness.

Developers and users outside the project win. They still benefit from the freedoms ensured by the GPL that allow them to inspect, modify, and distribute the software as they see fit. If they wanted to download the software from the project website under the GPL, change the software, and load it up, they can. (The Apple SDK allows one to load one’s own developed apps.) If they wanted to distribute their modified derivative on the Apple App Store, they could do that as well because they can do that through the project’s Apple App Store distribution license.

Apple doesn’t care. Apple cares if you take the binaries from the App Store and re-distribute those particular binaries elsewhere out of Apple’s control. Apple cares if you try to reverse engineer Apple’s DRM. They created their Terms of Service to prevent such practices. Apple certainly doesn't care if a developer gives there software away for free on the App Store, and I'm betting they have no opinion on whether or not the developer believes in software freedom.

This legal tactic may not solve the VLC problem, because if I read SJVN’s article correctly, it was another group that produced the Apple App Store version of the software. The dual license tactic needs to come from the project itself.

I also understand that this feels like a legal shuffle that shouldn’t be needed or seems contradictory. But the reality is that two organizations with separate goals in mind have created two licenses that are incompatible in language because of those unrelated goals. This is not a contradictory situation in intent, but rather in language. They clash because of the ease in the digital web-enabled world for things to come together in ways that the legal and business community didn’t foresee in the fast low-friction world of the Internet. What’s needed is a little legal linguistic grease to enable the two organizations and their orthogonal goals to slide by one another.

Trying to get the two organizations to work together to solve the situation would require massive amounts of good will that is likely missing between the two. It would also require them to care about the others goals. It would likely create more friction when other voices and opinions and interests get involved. A second separate license using all the rules in place will likely solve free software needs a whole lot faster than complaining to Apple or demonizing them unjustly in this case.

So how simple a distribution license can be created (and how quickly) for free software projects to use as they dual distribute through the Apple App Store? Are there any free software friendly lawyers that want to take a try at this for the good of all? Or is this completely impractical?

On The Web
Twitter
Blog Roll
Once More unto the Breach
http://stephesblog.blogs.com