This is exactly why many commercial applications do not or can not port to
Linux.
The GPL is a virus license, if you really wanted the code to be free it
would be released under an MIT style license. The GPL/LGPL is just another
proprietary license scheme that is meant to prevent people from
On Tue, Feb 01, 2011 at 07:04:44AM -0600, Patrick Cannon wrote:
This is exactly why many commercial applications do not or can not port to
Linux.
Again: you mean closed-source applications here, not commercial, right ?
The GPL is a virus license, if you really wanted the code to be free it
On 11-02-01 09:21 AM, strk wrote:
On Tue, Feb 01, 2011 at 07:04:44AM -0600, Patrick Cannon wrote:
The GPL is a virus license, if you really wanted the code to be free it
would be released under an MIT style license. The GPL/LGPL is just another
proprietary license scheme that is meant to
On Tue, Feb 01, 2011 at 10:33:20AM -0500, Daniel Morissette wrote:
I speak from experience: I had to refrain from using QGIS in a
(closed-source) project for a client not long ago because of its GPL
license. If there had been a single copyright holder I'd have talked to
that person instead
On 11-02-01 11:04 AM, Ray Gardener wrote:
Oh man. So over time, as more GPL'd drivers are written, the very purpose of
GDAL gets watered down. It's not like people are going to develop MIT-licenced
drivers if they see an existing GPL driver that does the job. At the very
least, the motivation
Well said Frank. Thank you.
matt wilkie
Geomatics Analyst
Information Management and Technology
Yukon Department of Environment
10 Burns Road * Whitehorse, Yukon * Y1A 4Y9
867-667-8133 Tel * 867-393-7003 Fax
On 11-01-29 03:44 PM, Frank Warmerdam wrote:
To that end, I have prepared an RFC which attempts to address this at
the GDAL driver registration level. I'd appreciate feedback:
http://trac.osgeo.org/gdal/wiki/rfc34_license_policy
Kudos for coming up with what sounds like a viable solution
On 11-01-29 03:44 PM, Frank Warmerdam wrote:
To that end, I have prepared an RFC which attempts to address this at
the GDAL driver registration level. I'd appreciate feedback:
http://trac.osgeo.org/gdal/wiki/rfc34_license_policy
I'm asymptotically approaching -1 on this RFC. My concern is
Frank,
I've reviewed the document and it looks good to me, though it seems better
to enforce these constraints rather at deployment time and not at run-time.
However I would have some further questions:
1. With regards to GDAL_APPLICATION_LICENSE_POLICY=DEFAULT does this mean
that GDAL will
On 11-01-31 11:30 AM, Tamas Szekeres wrote:
Frank,
I've reviewed the document and it looks good to me, though it seems better to
enforce these constraints rather at deployment time and not at run-time.
However I would have some further questions:
1. With regards to
On 11-01-31 10:45 AM, Howard Butler wrote:
http://trac.osgeo.org/gdal/wiki/rfc34_license_policy
I'm asymptotically approaching -1 on this RFC. My concern is that it
misplaces the apparent responsibility for managing licensing constraints on
*us*. It should always be the responsibility of
I think Mr. Butler makes a good point.
Maybe just have folders in the source tree called frmts/reciprocal and
frmts/proprietary and the same for any libs. That way it's in people's
face all the time and impossible not to be conscious of what is licenced
how. And easy to exclude such drivers,
On 11-01-31 12:28 PM, Ray Gardener wrote:
I think Mr. Butler makes a good point.
Maybe just have folders in the source tree called frmts/reciprocal and
frmts/proprietary and the same for any libs. That way it's in people's face
all the time and impossible not to be conscious of what is licenced
On 1/31/2011 12:32 PM, Frank Warmerdam wrote:
That would be adequate for those who are building things from source
and wanting to distribute the resulting binaries under a single
consistent licensing policy. However it does not help me for the
OSGeo4W need.
OSGeo4W is a unified installer...
then you can
honestly claim that any violation happened beyond your control
...except that Frank is the principle organizer/maintainer behind
OSGeo4W as well as GDAL.
Not that this necessarily contravenes your main point, that since the
gray area is in o4w and not gdal that's where the
I should ask, is it okay for commercial apps to include GPL'd drivers
currently? What would happen if my app included one? Do I have to wait
for it to be under LGPL?
I don't mind at all sharing any changes I may make to such drivers, but
if I can't even include the drivers, that seems
On Mon, Jan 31, 2011 at 08:59:25PM -0800, Ray Gardener wrote:
I should ask, is it okay for commercial apps to include GPL'd drivers
currently? What would happen if my app included one? Do I have to wait
for it to be under LGPL?
I don't mind at all sharing any changes I may make to such
On 11-01-29 06:16 PM, Even Rouault wrote:
1) I had a strange feeling when I read that In the absence of a user or
application level policy, default to a policy of PREFER_PROPRIETARY. It
sounds a bit paradoxical for an open source library... I guess that on Linux,
it should be PREFER_RECIPROCAL
Le dimanche 30 janvier 2011 18:00:19, Frank Warmerdam a écrit :
b) For MySQL, it depends on whether you use the open source version (GPL)
or the commercial version.
Really? I had assumed that the client libraries would have been
under a non-reciprocal license even if the database server
2011/1/30 Even Rouault even.roua...@mines-paris.org
On Windows, I think that the actual license of the odbc library doesn't
really
count as people won't distribute the windows odbc system library right ?
Otherwise it would make it impossible to distribute GPL software on Windows
since the
Folks,
I have been thinking about how to adjust OSGeo4W in particular, and GDAL
in general to make it easier to distribute software in a way that complies
with the conflict between GPLed software and proprietary software.
In the case of OSGeo4W the main restrictions is that we should not be
Frank,
It looks mostly good to me.
A few remarks :
1) I had a strange feeling when I read that In the absence of a user or
application level policy, default to a policy of PREFER_PROPRIETARY. It
sounds a bit paradoxical for an open source library... I guess that on Linux,
it should be
22 matches
Mail list logo
