[RouterGeocoder] Dual-licensing
Paul Spencer
pspencer at dmsolutions.ca
Thu Dec 4 08:22:36 EST 2008
I'd like to weigh in with my point of view as well ...
1. I believe the point of using the GPL is that you believe that all
software should be Free Software. The use of the GPL to 'force'
commercial users to pay a license fee (however small) does not seem to
fit into the GPL model as I understand it. Would it serve your
objective if ESRI decided to release their software under the GPL to
their clients so that they could incorporate your code without having
to pay your fee? You would not get the benefit of their software
anyway (because they only have to provide the source to the folks they
redistribute to I think) and you would not get any money. The folks
they redistribute to would (arguably) reap the benefit by having
ESRI's code available - the GPL is purely altruistic in this sense
because its use potentially makes the world a better place.
2. Part of my job is to choose the best software on which to build
solutions for our clients. We choose primarily Open Source software
because we strongly believe that it is better value for our clients.
It can actually cost us more to use Open Source software because we
need to become involved in the community and learn the software enough
to be able to use it and effectively contribute to it when we need new
features or bug fixes. With Open Source software, we are the support
mechanism for our clients. If there is a license fee associated with
software, then I expect that I don't have to commit any of my
resources to doing these things because I am paying someone else to do
it. I think this point was more eloquently made by Andrew re
commercial support options for Open Source being more important than
the license.
3. For better or worse, the GPL has a bad reputation with commercial
companies (perhaps in part because it is used like this). For an Open
Source project to be successful, it really needs to build a community
of developers and users who support it. If the use of GPL discourages
end users or developers from being involved, your project will not
thrive as much as it might otherwise have.
I think that commercial companies are willing to pay for the value
they get in solving a problem. Its just that the form of payment
might not always be ca$h ... depending on the size of the company and
its business model, it may be onerous to pay a license fee but quite
acceptable to donate some portion of their developers' time to
supporting the project, or maintaining documentation etc. If the
project markets its needs well, then companies can understand how they
can contribute (through sponsorship, documentation, coding, mailing
list participation or just plain old promotion by mentioning the
project on their web site) and I believe many will find a way to
contribute.
Cheers
Paul
On 4-Dec-08, at 12:08 AM, Daniel Kastl wrote:
> Good evening, Dave.
>
> Well, it might be I don't get the idea behind MIT/BSD style ideas.
> Doesn't it mean that in this case ESRI for example could just use
> this library without any obligations, without giving credits to the
> authors?
>
> What I just hope to achieve is a way how "proprietary/commercial" is
> allowed but needs a license that is (maybe) not gratis.
> Well, if we don't want to charge money for this license, let's give
> it for "free". Is this then like MIT/BSD?
>
> I think, it's always difficult for OSGeo projects to find sponsors.
> It could be a way to support ongoing development with such a dual-
> licensing. Maybe not from the very first day, but in the future.
> Why do you think "parallel open source project" would appear if
> there are two licenses? Through GPL for example there will be always
> a way to use it gratis.
> If someone wants to use it in closed source software, isn't it
> legitimate to ask for money? ;-)
> With MIT/BSD style licenses we believe in goodwill of people/
> companies. That people contribute improvements or sponsor the
> project. I just don't think this is the case usually.
>
> Is there any recommendation of OSGeo on licensing?
>
> Daniel
>
>
> Dave McIlhagga schrieb:
>>
>> 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
>>
>
> _______________________________________________
> Routergeocoder mailing list
> Routergeocoder at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/routergeocoder
__________________________________________
Paul Spencer
Chief Technology Officer
DM Solutions Group Inc
http://research.dmsolutions.ca/
More information about the Routergeocoder
mailing list