GPL Plugin architectures
XBMC announced their 10.05 version (Dharma release). Looking at the features this will be a great step in the future! A little more info your can find on Trac. Those features will make sure a lot of user will switch from other Media Centers to XBMC and new users will sooner adopt this product.
Since this version is postponed and e.g. the PVR functionality won’t make it in the Dharma release, the Addon Manager will be the most important new feature. Since the world of XBMC becomes more commercial every day, with commercial forks, paid plugins and ‘premium’ skins (right now this business is focused on the commercial forks), I thought it is important to understand what GPL really brings to that world. XBMC Plugin repository guidelines should answer all questions, from XBMC Foundation perspective. Those guidelines are a lot more flexibeble then Apple’s App Stores’ Terms of Service; they just banned GPL software since the App Store is a vendor-controlled environment with tight obscure rules and shaky practices. The same goes for the Microsoft Marketplace.
The Addon Manager
This repository contains all approved (thus GPL and legal to distribute) Addons (skins, scrapers, plugins, scripts, etc.). It also can host other repo’s; you can easily setup your own SVN and distribute its content with the Addon Manager to the XBMC platform. This means flexibility for everyone in terms of license issues and legal issues (the disputable linking clause is circumvented this way). This feature will boost XBMC with lots of easy to install streaming features!
Since XBMC offers a plugin and skinning architecture, plugins and skins *might* be derivatived work. It depends on the operation of the plugin or skin.
From GNU.org: (The FAQ has no legal effect – only the license does, and the license expressly invokes copyright law.)
If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
This means that whenever a skin or a plugin uses just one function from the XBMC code, GPL license automatically ‘kicks in’ and takes over. And since plugins and skins must use XBMC functions they automatically become GPL as well since they combine into a single unit at run time. This interpretation is used when FSF/SFLC give advise over GPL plugin-architectures (see: the WordPress skin case, Joomla, phpBB, Planetshift and many other discussions)
But the GPL-license states:
You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
If identifiable sections of [the modified] work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
To me, it looks like FSF/SFLC doesn’t have a consitent story. Besides, unless developer explicitly made his code GPL, it isn’t. You can’t assume GPL! All or part of extension code can be completely XBMC-unspecific, except for meta information needed to recognize it as extension.
This discussion, what is derivatived work, is a legal rathole. I don’t believe there will ever be consensus within communities. Community guidelines can set the consensus and legal cases can set the playfield.
Is there a solution to this mess?
The solution exists and is technical in nature. For plugins you can develop your whole code as a library under your own licensing model. Then you would have the XBMC plugin which will call functions from your library. The plugin itself becomes GPL but the library not and you are free to slap any kind of license and restriction to it.
For skins it is a bit of a different story. A skin forms a whole with XBMC. It is impossible not to call XBMC functions and the XBMC datastructure from within a skin.
Remember Boxee, Voddler and the Addon Manager discussion? As you can read in the discussion of the associated ticket, they really upset one of the best developers. So what’s the deal? Why is teamXBMC is so eager on this functionality? Because this features adds Upgrading and Installing to the core and this will make XBMC a much more attractive platform for users and thus third-party developers, while legally XBMC Foundation (more correct: the copyrightholders) has all the card in their hands.
Remember: the busybox case showed that single persons in community-driven development can act as copyright owners. Overhere you can read what this means.