<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Good evening, Dave.<br>
<br>
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?<br>
<br>
What I just hope to achieve is a way how "proprietary/commercial" is
allowed but needs a license that is (maybe) not gratis. <br>
Well, if we don't want to charge money for this license, let's give it
for "free". Is this then like MIT/BSD? <br>
<br>
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.<br>
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. <br>
If someone wants to use it in closed source software, isn't it
legitimate to ask for money? ;-)<br>
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. <br>
<br>
Is there any recommendation of OSGeo on licensing?<br>
<br>
Daniel<br>
<br>
<br>
Dave McIlhagga schrieb:
<blockquote
cite="mid:6340B685-BF33-4376-BCCF-86210EAD2F83@dmsolutions.ca"
type="cite">Hi Daniel,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Dave</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div apple-content-edited="true"> </div>
<br>
<div>
<div>On 3-Dec-08, at 8:44 PM, Daniel Kastl wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000"> Hi Andrew and others,<br>
<br>
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:<br>
<ul>
<li>It should assure when projects use the "free" license (for
example GPL), that this leads to collaboration and contributions. <br>
</li>
<li>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.</li>
</ul>
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. <br>
<br>
Daniel<br>
<br>
<br>
Andrew Ross schrieb:
<blockquote cite="mid:004401c95588$20e8ca10$0c00000a@rosan01"
type="cite">
<pre wrap="">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: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:routergeocoder-bounces@lists.osgeo.org">routergeocoder-bounces@lists.osgeo.org</a>
[<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="mailto:routergeocoder-bounces@lists.osgeo.org">mailto:routergeocoder-bounces@lists.osgeo.org</a>] On Behalf Of Anton Patrushev
Sent: December 2, 2008 11:31 PM
To: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:routergeocoder@lists.osgeo.org">routergeocoder@lists.osgeo.org</a>
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
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Routergeocoder@lists.osgeo.org">Routergeocoder@lists.osgeo.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.osgeo.org/mailman/listinfo/routergeocoder">http://lists.osgeo.org/mailman/listinfo/routergeocoder</a>
_______________________________________________
Routergeocoder mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Routergeocoder@lists.osgeo.org">Routergeocoder@lists.osgeo.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.osgeo.org/mailman/listinfo/routergeocoder">http://lists.osgeo.org/mailman/listinfo/routergeocoder</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
Routergeocoder mailing list<br>
<a moz-do-not-send="true"
href="mailto:Routergeocoder@lists.osgeo.org">Routergeocoder@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/routergeocoder">http://lists.osgeo.org/mailman/listinfo/routergeocoder</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>