From: <rog...@ro...> - 2007-02-02 17:42:52
|
To avoid writing an essay, let me just make a "few" statements. Heh. 1 - It's important that the license for PanoTools be respected and =20 actively enforced, or it means little, and is bound to lead to =20 conflicts; 2 - It's equally important that the license for PanoTools be a best =20 fit for the mix of stakeholders 3 - The PanoTools stakeholders include, in no order of importance, =20 core PanoTools developers, third-party PanoTools product developers, =20 and direct and indirect users of PanoTools 4 - GPL is simply a means to an end; it is not the point of the project 5 - GPL and perhaps other free/open source licenses, serve both an =20 active role as a license, but perhaps an equally important role for =20 attracting and maintaining developer interest 6 - Core developers and third-party product developers may have =20 conflicting interests, especially with regards to point 2 above 7 - The GPL is significantly useful as a means of promoting and =20 protecting an ecosystem of free (as in speech) products in a =20 particular niche 8 - Attracting qualified, interested developers will always be a =20 challenge for what is a pretty small market to begin with 9 - The panoramic ecosystem is not large enough to expect secondary, =20 non-traditional funding for development - this is a key difference =20 from people working on Linux, Apache, MySQL and other products that =20 have attracted enterprise support and funding 10 - Ultimately, end-users are (by and large) unconcerned about the =20 license specifics; they are looking for productivity tools, and =20 (mostly) not looking to advance any larger agenda 11 - End users are willing to pay a reasonable price for panoramic =20 imaging tools; free (as in beer) is not a *major* benefit for most =20 users; I'll happily pay $100 for a PT-based product 12 - Using a license to enforce arbitrary and ultimately counter-=20 productive requirements such as specifying *how* a product may =20 integrate with a tool (rather than whether it can or cannot) seems =20 largely petty and nitpicky; either a product is derivative or not; =20 whether it integrates via one method or another seems utterly =20 irrelevant to most users, and forcing a third-party product to use a =20 less efficient interface is not a compromise, it's a curse 13 - I see very little discussion about the impact on users; even in =20 open source there are users, and they are ultimately the audience. =20 PanoTools is not developed in a vacuum 14 - If the developers can't find a compromise that allows the open =20 and closed-source products to thrive then we've taken a huge step =20 backwards. Forget Linux, forget Apache, we are nothing like those products or =20 markets. While we are also nothing like MySQL, I think they offer a =20 fairly interesting model, as it's a product both standalone and often =20= embedded in both closed and open source products. MySQL offers a dual-=20= license approach. You can get it in completely free, GPL-like =20 licensing models, with all its restrictions - this helps promote open =20= source by attracting legions of developers and third-party =20 integration within the terms of that license. However, for markets =20 and products where that licensing model doesn't work, they offer a =20 closed-source compatible licensing option. Consider the following approach: 1. Form an organization - let's call it the PanoTools Foundation 2. Make the foundation the holder of PanoTools source code copyright, =20= and the relevant trademarks (though none exist today, it may be too =20 late for PanoTools=99, but perhaps it's time to move past that name =20 anyhow, or at least deprecate it) 3. Provide PanoTools free (beer/speech) under a GPL-like license, and =20= use the foundation to actively enforce that license 4. Provide an alternative license to commercial entities, allowing =20 complete liberty to use PanoTools in commercial products - for a fee =20 (to be determined - a blanket license fee, a per unit sales fee, an =20 annual fee, etc) 5. Provide incentives for third-party commercial licensees to =20 actively contribute to PanoTools developments, through fee waivers =20 (for instance) or rebates 6. Use the collected funds to support core PanoTools development - =20 for instance, purchasing gear such as lenses (as we did earlier this =20 year as a group) This would seem, with refinement, of course - I'm writing this on a =20 smelly, packed, noisy old Airbus 320 so I'm not suggesting this is a =20 complete model - to address the core needs. 1. Continue to support development of PanoTools as an open source effort 2. Provide commercial developers a reasonable option to share the =20 benefits of PanoTools while contributing something back to the core =20 effort, either through funding or code sharing 3. Prevent forking PanoTools 4. Create the incentive to formalize an organization designed to =20 protect and promote PanoTools IP Finally, one further thought. What is PanoTools really? It's both a =20 specific chunk of code, but it's also broader than that. Perhaps it's =20= time to retire the name, or better define it. Is Hugin part of =20 PanoTools? Is nona? What, really, is PanoTools? Best, Roger |