[RouterGeocoder] Dual-licensing

Wed Dec 3 23:05:55 EST 2008

Hi Daniel,

I see where you are going with this -- but I suspect that if there is  
actually legitimate demand for the "commercial" license -- in the long  
run this will simply encourage setup of a parallel open source project  
with MIT/BSD style license to appear. I'm not sure if that would  
really serve anyone's needs as it would result in duplication of  
effort and two weaker projects then one single initiative.

I'm not sure why a license change is necessarily seen as a major  
challenge if the initial contributor group is small. PAGC changed it's  
license in less than a week with a brief discussion, a single vote,  
and some updates to documentation / source code files.

Dave

On 3-Dec-08, at 8:44 PM, Daniel Kastl wrote:

> Hi Andrew and others,
>
> The recent posts were interesting. Because I was discussing this  
> dual-licensing  with Anton during lunch breaks, this is what I  
> believe is what a licensing model should provide:
> It should assure when projects use the "free" license (for example  
> GPL), that this leads to collaboration and contributions.
> It should not lock out closed source, but allow proprietary software  
> to make use of it through a "commercial" license. And for this  
> license the Routing/Geocoder project could charge money, which would  
> then help to sponsor development.
> There are probably many successful examples. I don't know a dual- 
> license is the solution for this issue. I'm glad to be convinced  
> that there is a better way. I just thought this would be worth to  
> discuss before changing the license of existing projects.
>
> Daniel
>
>
> Andrew Ross schrieb:
>>
>> Hi Anton, Everyone,
>>
>> This is an interesting discussion, thanks for posting.
>>
>> I'm going to make the point that driving business with dual  
>> licensing (and
>> GPL specifically) is a myth. Here goes...
>>
>> Quoting directly from the GPL:
>>
>>     b) 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.
>>
>> Section 3 in the license goes on to state you must make the code  
>> available
>> somehow. Either by providing it or offering to provide it for no  
>> markup.
>>
>> In other words, if your work depends on this GPL code, and you  
>> publish it,
>> your software thus becomes GPL. This is obviously scary if you link  
>> your
>> unprotected (via. patents, etc.) IP against GPL code and distribute  
>> it.
>>
>> As an important aside, the fact remains code can be decompiled so  
>> if you're
>> only protection of your IP is obscuring access to the code, good  
>> luck!
>>
>> What's more interesting is what happens if you don't distribute  
>> your code?
>> i.e. you just use it to provide a service, but you don't modify it  
>> and don't
>> distribute derivative code. Is such a service a derivative work?
>>
>>
>> In the dual licensing model the commercial license provides the  
>> right to
>> link against a non-GPL version of the code. Doing so would avoid GPL
>> contamination of the code. It is felt that this is the crux of the  
>> dual
>> license business model. This model is used by RedHat, Ingres,  
>> MySQL, and
>> others. However, I'm not sure this is valid.
>>
>> Here's why: the end customer could go out and get the GPL and use  
>> it for
>> free. They could even link to it. Unless they redistribute, I don't  
>> believe
>> GPL contamination kicks in. Thus the GPL itself is *not* as far as  
>> I can see
>> a motivating factor for buying the commercial license.
>>
>> However, if at 3am the code explodes causing mass carnage, they're  
>> on their
>> own unless they have a support contract with someone. Thus support  
>> and
>> insurance against failure is the value they're interested in. You  
>> pay for
>> support from Company because they're good at it and hopefully can  
>> do it
>> better and cheaper than you can in-house.
>>
>> In other words, in my opinion: business is based on insurance against
>> failure. This is orthogonal to the notion of GPL contamination.
>>
>> If anyone knows of any precedent that disagrees or agrees with the  
>> above, I
>> would be delighted to know about it.
>>
>> Andrew
>> As is obvious by Ingres' GPLv2 license - my opinions are my own and  
>> not
>> those of my employer
>>
>> -----Original Message-----
>> From: routergeocoder-bounces at lists.osgeo.org
>> [mailto:routergeocoder-bounces at lists.osgeo.org] On Behalf Of Anton  
>> Patrushev
>> Sent: December 2, 2008 11:31 PM
>> To: routergeocoder at lists.osgeo.org
>> Subject: [RouterGeocoder] Dual-licensing
>>
>> Hi list,
>>
>> I was thinking about how to adopt GPLed tools for proprietary  
>> solutions and
>> I think the answer is dual-licensing.
>> For example,
>>
>> 1. The community makes a Router/Geocoder library and grant all  
>> copyrights to
>> the Foundation.
>> 2. Foundation reissues it under two licenses - GPL for using with  
>> Open
>> Source tools and some kind of commercial license for proprietary  
>> ones.
>> 3. Commercial version is sold to proprietary tool developers and  
>> the money
>> goes to the Foundation.
>> 4. ?????
>> 5. PROFIT!
>> :)
>>
>> I think it is much better than reissuing existing tools under any  
>> kind of
>> exotic BSD/MIT-ish license.
>> What do you think?
>>
>>
>> Anton.
>> _______________________________________________
>> Routergeocoder mailing list
>> Routergeocoder at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/routergeocoder
>>
>> _______________________________________________
>> Routergeocoder mailing list
>> Routergeocoder at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/routergeocoder
>>
>>
>
> _______________________________________________
> Routergeocoder mailing list
> Routergeocoder at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/routergeocoder

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/routergeocoder/attachments/20081203/8be60061/attachment-0001.html