[GRASS5] Grass Projection Parameters

GRASS GRASS developer
1

Hello,

We are developing a product called MacGrass that is based on Grass as a powerful engine and MacGrass as an elegant front end while also adding capabilities, features and ease of use.

I am working on the Projection GUI and I was wondering if there is way to find out what projections and Ellipsoids require which parameters. It was not immediately apparent by looking at documentation or the source code in src/libes/proj or by grep'ing elsewhere.

    See <http://OpenOSX.com/MacGrassAlpha.jpg&gt;

Is there a way to find or generate a list that shows which parameters are required/supported by each of the 121 projections?

For instance Albers Equal Area use False Easting and Northing, etc. that say UTM does not. Another example is UTM requires a zone and so forth.

Thank you for your time,

Jeshua Lacock __________________________
Programmer/Owner Phone: 760.935.4736
http://OpenOSX.com Fax: 760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

2

On Wed, Feb 13, 2002 at 08:26:25PM -0800, Jeshua Lacock wrote:

Hello,

We are developing a product called MacGrass that is based on Grass as a
powerful engine and MacGrass as an elegant front end while also adding
capabilities, features and ease of use.

I am working on the Projection GUI and I was wondering if there is way
to find out what projections and Ellipsoids require which parameters.
It was not immediately apparent by looking at documentation or the
source code in src/libes/proj or by grep'ing elsewhere.

   See <http://OpenOSX.com/MacGrassAlpha.jpg&gt;

Is there a way to find or generate a list that shows which parameters
are required/supported by each of the 121 projections?

For instance Albers Equal Area use False Easting and Northing, etc.
that say UTM does not. Another example is UTM requires a zone and so
forth.

Have a look at grass/src/libes/gis/geo_init.c Do your user's a favor
though, and don't offer *both* datum and ellipsoid (make it either or)
as a datum defines the ellipsoid (still need it in PROJ_INFO). This
behavior in g.setproj is almost irritating enough for me to go and
fix it (that, and the state plane crap) :wink:

--
Eric G. Miller <egm2@jps.net>

3

On Wednesday, February 13, 2002, at 08:53 PM, Eric G. Miller wrote:

Is there a way to find or generate a list that shows which parameters
are required/supported by each of the 121 projections?

For instance Albers Equal Area use False Easting and Northing, etc.
that say UTM does not. Another example is UTM requires a zone and so
forth.

Have a look at grass/src/libes/gis/geo_init.c Do your user's a favor
though, and don't offer *both* datum and ellipsoid (make it either or)
as a datum defines the ellipsoid (still need it in PROJ_INFO). This
behavior in g.setproj is almost irritating enough for me to go and
fix it (that, and the state plane crap) :wink:

Hello Eric,

Thanks for the pointers, that looks like the golden ticket.

So (all?) projections use either a custom datum OR ellipsoid. I assume that one of them must be supplied with all projections (minus XY)?

Thanks again,

Jeshua Lacock __________________________
Programmer/Owner Phone: 760.935.4736
http://OpenOSX.com Fax: 760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

4

On Wed, Feb 13, 2002 at 09:53:26PM -0800, Jeshua Lacock wrote:

On Wednesday, February 13, 2002, at 08:53 PM, Eric G. Miller wrote:

>>Is there a way to find or generate a list that shows which parameters
>>are required/supported by each of the 121 projections?
>>
>>For instance Albers Equal Area use False Easting and Northing, etc.
>>that say UTM does not. Another example is UTM requires a zone and so
>>forth.
>
>Have a look at grass/src/libes/gis/geo_init.c Do your user's a favor
>though, and don't offer *both* datum and ellipsoid (make it either or)
>as a datum defines the ellipsoid (still need it in PROJ_INFO). This
>behavior in g.setproj is almost irritating enough for me to go and
>fix it (that, and the state plane crap) :wink:

Hello Eric,

Thanks for the pointers, that looks like the golden ticket.

So (all?) projections use either a custom datum OR ellipsoid. I assume
that one of them must be supplied with all projections (minus XY)?

Datums define the ellipsoid. There are some "tables" you can use in
the coorcnv library that crosswalk datums to ellipsoid (notably, the
datum.table that gets put in grass5/etc). Most the time it doesn't
matter unless a datum shift needs to be done (something which
GRASS doesn't currently handle). But some datums are a little
perculiar, whereby the prime meridian isn't at Greenwich, so
longitudes need to be shifted (again, this probably doesn't matter
until the projection code handles datum shifts).

So, the ellipsoid is always needed in PROJ_INFO, but the UI should
just look up the correct ellipsoid *iff* the user specifies a
predefined datum. The datum is optional, but should be strongly
encouraged over the use of just ellipsoid parameters.

<snippet of datum table>
FIELDS: datum abbr., Long Name, *ellipsoid*, datum shift params (3-param...).

# World Geodetic System 1984
wgs84 "World Geodetic System 1984" wgs84 dx=0.0 dy=0.0 dz=0.0
# World Geodetic System 1972
wgs72 "World Geodetic System 1972" wgs72 dx=0.0 dy=0.0 dz=5.0
# North American 1927
nad27 "North American 1927" clark66 dx=-22.0 dy=157.0 dz=176.0
# North American 1983 (CONUS)
nad83 "North American 1983" grs80 dx=0.0 dy=0.0 dz=0.0
# Alaska and Canada
a-can "Alaska and Canada NAD27" clark66 dx=-9.0 dy=151.0 dz=185.0
# European datum
eur "European" international dx=-84.0 dy=-103.0 dz=-127.0

</end snippet>

--
Eric G. Miller <egm2@jps.net>

5

On Wed, Feb 13, 2002 at 08:26:25PM -0800, Jeshua Lacock wrote:

We are developing a product called MacGrass that is based on Grass as a
powerful engine and MacGrass as an elegant front end while also adding
capabilities, features and ease of use.

Just out of curiosity:

What programming facilities are you using?
Is there any schedule for the release of the source code?

Best,
  Bernhard

--
Professional Service for Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)

6

On Thursday, February 14, 2002, at 03:37 AM, Bernhard Reiter wrote:

We are developing a product called MacGrass that is based on Grass as a
powerful engine and MacGrass as an elegant front end while also adding
capabilities, features and ease of use.

Just out of curiosity:

What programming facilities are you using?
Is there any schedule for the release of the source code?

Hello Bernhard,

We are developing the software using Apple's Project Builder in Cocoa (objective-c based), as a commercial, closed-source project.

At this time, while we do not have a schedule, we hope to start beta testing within a months time.

I personally have mixed feelings about the open-source versus closed source issue. Although we will not contribute code to the Grass community in this instance, we will continue (and hopefully increase) monetary donations to the Grass project.

Best regards,

Jeshua Lacock __________________________
Programmer/Owner Phone: 760.935.4736
http://OpenOSX.com Fax: 760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

7

On Sunday 17 February 2002 00:15, Jeshua Lacock wrote:

On Thursday, February 14, 2002, at 03:37 AM, Bernhard Reiter wrote:
>> We are developing a product called MacGrass that is based on Grass as a
>> powerful engine and MacGrass as an elegant front end while also adding
>> capabilities, features and ease of use.
>
> Just out of curiosity:
>
> What programming facilities are you using?
> Is there any schedule for the release of the source code?

Hello Bernhard,

We are developing the software using Apple's Project Builder in Cocoa
(objective-c based), as a commercial, closed-source project.

At this time, while we do not have a schedule, we hope to start beta
testing within a months time.

I personally have mixed feelings about the open-source versus closed
source issue. Although we will not contribute code to the Grass
community in this instance, we will continue (and hopefully increase)
monetary donations to the Grass project.

Best regards,

Jeshua Lacock

What you are doing is exactly what is not allowed. I consider
your work to be "work based on the Program" and GPL says: "But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License"

Where can I read something about your donations? Sorry, I am just
curious what/who is donated now in Grass project.

I am not against commercial programs for grass. I can imagine commercial
modules for some special complicated tasks, which are needed but may not
be for some reasons written as open by Grass comunity. That requires to talk
more or again about LGPL for libraries.

But create and sell GUI as closed source, is Grass license violation for me.

I am not against even your commercial project, if I know exact sums and
recipients of donations, but unfortunately we cannot ask developers who
worked on Grass in past.

Radim
Praga, Bohemia

8

Radim Blazek wrote:

> >> We are developing a product called MacGrass that is based on Grass as a
> >> powerful engine and MacGrass as an elegant front end while also adding
> >> capabilities, features and ease of use.
> >
> > Just out of curiosity:
> >
> > What programming facilities are you using?
> > Is there any schedule for the release of the source code?
>
> Hello Bernhard,
>
> We are developing the software using Apple's Project Builder in Cocoa
> (objective-c based), as a commercial, closed-source project.
>
> At this time, while we do not have a schedule, we hope to start beta
> testing within a months time.
>
> I personally have mixed feelings about the open-source versus closed
> source issue. Although we will not contribute code to the Grass
> community in this instance, we will continue (and hopefully increase)
> monetary donations to the Grass project.

What you are doing is exactly what is not allowed. I consider
your work to be "work based on the Program"

I wouldn't consider a front-end to be a "work based on the program",
assuming that it is just spawning commands via system() or similar.
Nor, AFAICT from reading the GPL FAQ, does the FSF.

If a program which executes another is a derivative of that program,
then there are a lot of unlicensed derivatives around.

--
Glynn Clements <glynn.clements@virgin.net>

9

On Sun, Feb 17, 2002 at 07:29:33PM +0000, Glynn Clements wrote:

Radim Blazek wrote:
> > >> We are developing a product called MacGrass that is based on Grass as a
> > >> powerful engine and MacGrass as an elegant front end while also adding
> > >> capabilities, features and ease of use.
> > >
> > > Just out of curiosity:
> > >
> > > What programming facilities are you using?
> > > Is there any schedule for the release of the source code?

> > We are developing the software using Apple's Project Builder in Cocoa
> > (objective-c based), as a commercial, closed-source project.

We might have to check that what you do is not voilating GRASS' license.

> > I personally have mixed feelings about the open-source versus closed
> > source issue. Although we will not contribute code to the Grass
> > community in this instance, we will continue (and hopefully increase)
> > monetary donations to the Grass project.

I am not a proponent of proprietory frontends to GRASS.
It will not only be a disadvantage to the whole GRASS user
community, but will also be suboptimal for your product and users.

> What you are doing is exactly what is not allowed. I consider
> your work to be "work based on the Program"

I wouldn't consider a front-end to be a "work based on the program",
assuming that it is just spawning commands via system() or similar.
Nor, AFAICT from reading the GPL FAQ, does the FSF.

If a program which executes another is a derivative of that program,
then there are a lot of unlicensed derivatives around.

It depends.
This probably is a hard question to answer.
Without checking the details I cannot tell in this case.
I won't be able to check the details for a couple of days.

But there is a good chance that it is not allowed to develop
propietory front ends for GRASS.

Check:
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

| Mere aggregation of two programs means putting them side by side
| on the same CD-ROM or hard disk. We use this term in the case where
| they are separate programs, not parts of a single program. In this
| case, if one of the programs is covered by the GPL, it has no effect
| on the other program.
|
| Combining two modules means connecting them together so that
| they form a single larger program. If either part is covered by the
| GPL, the whole combination must also be released under the GPL--if
| you can't, or won't, do that, you may not combine them.
|
| What constitutes combining two parts into one program? This is a
| legal question, which ultimately judges will decide. We believe that
| a proper criterion depends both on the mechanism of communication
| (exec, pipes, rpc, function calls within a shared address space,
| etc.) and the semantics of the communication (what kinds of
| information are interchanged).

Please note that there is also commerical Free Software.
High quality software done by professionals for money,
but still granting all necessary freedoms.

10

(I'm re-sending this because the quoting format got lost last message)

On Monday, February 18, 2002, at 06:45 AM, Bernhard Reiter wrote:

On Sun, Feb 17, 2002 at 07:29:33PM +0000, Glynn Clements wrote:

Radim Blazek wrote:

We are developing a product called MacGrass that is based on Grass as a
powerful engine and MacGrass as an elegant front end while also adding
capabilities, features and ease of use.

Just out of curiosity:

What programming facilities are you using?
Is there any schedule for the release of the source code?

We are developing the software using Apple's Project Builder in Cocoa
(objective-c based), as a commercial, closed-source project.

We might have to check that what you do is not voilating GRASS' license.

I am sure that it is within the context of the GPL.

I personally have mixed feelings about the open-source versus closed
source issue. Although we will not contribute code to the Grass
community in this instance, we will continue (and hopefully increase)
monetary donations to the Grass project.

I am not a proponent of proprietory frontends to GRASS.
It will not only be a disadvantage to the whole GRASS user
community, but will also be suboptimal for your product and users.

Well, all I can say is there is definitely a demand for an elegant easy to use interface. Most Macintosh users are VERY intimidated by Grass and as such will NEVER use it without s slick front-end like we are developing.

I really do not see how this could be bad for the entire Grass community.

What you are doing is exactly what is not allowed. I consider
your work to be "work based on the Program"

I wouldn't consider a front-end to be a "work based on the program",
assuming that it is just spawning commands via system() or similar.
Nor, AFAICT from reading the GPL FAQ, does the FSF.

If a program which executes another is a derivative of that program,
then there are a lot of unlicensed derivatives around.

It depends.
This probably is a hard question to answer.
Without checking the details I cannot tell in this case.
I won't be able to check the details for a couple of days.

But there is a good chance that it is not allowed to develop
propietory front ends for GRASS.

Check:
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

| Mere aggregation of two programs means putting them side by side
| on the same CD-ROM or hard disk. We use this term in the case where
| they are separate programs, not parts of a single program. In this
| case, if one of the programs is covered by the GPL, it has no effect
| on the other program.
|
| Combining two modules means connecting them together so that
| they form a single larger program. If either part is covered by the
| GPL, the whole combination must also be released under the GPL--if
| you can't, or won't, do that, you may not combine them.
|
| What constitutes combining two parts into one program? This is a
| legal question, which ultimately judges will decide. We believe that
| a proper criterion depends both on the mechanism of communication
| (exec, pipes, rpc, function calls within a shared address space,
| etc.) and the semantics of the communication (what kinds of
| information are interchanged).

Our front-end only sets system environment variables and executes binaries. It does not modify or use any Grass code internally.

Further, I do not plan to put the two products on a single disk. There really is not doubt that what we are doing is completely legal under the GPL and FSF.

Look at what Mac OS X itself is. It is a GUI for controlling (opensource) binaries through an elegant user interface. So by your logic, Apple is violating the GPL because they have a front-end to stop and start apache for example.

Please note that there is also commerical Free Software.
High quality software done by professionals for money,
but still granting all necessary freedoms.

The Macintosh community is not used to free software. They are used to paying for quality software on a CD in a box with manuals and support that they can purchase from a store.

Best regards,

Jeshua Lacock __________________________
Programmer/Owner Phone: 760.935.4736
http://OpenOSX.com Fax: 760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

11

On Mon, Feb 18, 2002 at 04:52:01PM -0800, Jeshua Lacock wrote:

On Monday, February 18, 2002, at 06:45 AM, Bernhard Reiter wrote:

> We might have to check that what you do is not voilating GRASS'
> license.

[moved up from below]
Our front-end only sets system environment variables and executes
binaries. It does not modify or use any Grass code internally.

Further, I do not plan to put the two products on a single disk.

I am sure that it is within the context of the GPL.

It might be legal,
at least it is not entirely within the spirit of the GRASS community.
I will consult more people on this.

Please make sure that it is cristal clear that GRASS comes with all
that freedom and your frontend does not. This is important in any case.

> I am not a proponent of proprietory frontends to GRASS.
> It will not only be a disadvantage to the whole GRASS user
> community, but will also be suboptimal for your product and users.

Well, all I can say is there is definitely a demand for an elegant easy
to use interface. Most Macintosh users are VERY intimidated by Grass
and as such will NEVER use it without s slick front-end like we are
developing.

Agree, but that does not mean you have to develop it non-free.

I really do not see how this could be bad for the entire Grass
community.

You are building your proprietory software on top of the functions
of GRASS which has been build as Free Software. Thus you are selling
a solution based on the ground work and do not share your work with
us groundworkers back.

Look at what Mac OS X itself is. It is a GUI for controlling
(opensource) binaries through an elegant user interface. So by your
logic, Apple is violating the GPL because they have a front-end to stop
and start apache for example.

AFAIK Mac OS X does not only contain Free Software binaries,
they rely a lot on bsd like unix based on a mach architecture.

> Please note that there is also commerical Free Software.
> High quality software done by professionals for money,
> but still granting all necessary freedoms.

The Macintosh community is not used to free software. They are used to
paying for quality software on a CD in a box with manuals and support
that they can purchase from a store.

But you can do this and let your frontend have all freedoms.
It does not stand in contrast to Free Software.
You also have the chance to educate them.
  Bernhard

12

> The Macintosh community is not used to free software. They are used to
> paying for quality software on a CD in a box with manuals and support
> that they can purchase from a store.

But you can do this and let your frontend have all freedoms.
It does not stand in contrast to Free Software.
You also have the chance to educate them.
        Bernhard

I think that this statement just shows again that there is a misunderstanding
of what free
means for free software - free does not mean that you are not supposed to pay
for it
but that you have freedom to run, modifiy, etc. So selling

"quality software on a CD in a box with manuals and support
that they can purchase from a store"

is, as Bernhard says in no conflict with making it free - and here I cannot
help it-
the word Open is just more accurate (no matter how much the free and open
source
guys do not like each other). As I said before, for most people, not
intimately familiar
with the free software and open source world, free software means something
completely
different than what it is (often it is a proprietary software that is given
away for no charge).
So I can very much understand why Jeshua does not want their product to be
free, but may be
you could consider keep it Open?
And there are many Mac people who would love to buy a nice, easy to use GIS
(I know couple of them right here), but who would also like to modify it.

Helena

  ------------------------------------------------------------------------
   Part 1.2Type: application/pgp-signature

13

On Fri, Feb 22, 2002 at 12:16:00PM -0500, Helena Mitasova wrote:

I think that this statement just shows again that there is a
misunderstanding of what free means for free software - free does
not mean that you are not supposed to pay for it but that you have
freedom to run, modifiy, etc.

This is a missunderstanding which can happen.

and here I cannot help it-
the word Open is just more accurate

There are also possible missunderstandings with the word open.
(Won't go into details here.)
These missunderstanding have more negativ weight.

(no matter how much the free and open source guys do not like each other).

There may be heated debates about the terminology at time,
(the media likes to blow this up, too)
but we are working together for a common goal.

To give you an example: Last weekend I attended a free software
developers meeting in Brussels (www.fosdem.org). (Yes I did speak
about FreeGIS and GRASS there. :slight_smile: )
Guido van Rossum (on the board of the Open Source Initiative)
was given the FSF Award for the Advancement of Free Software.

14

On Friday, February 22, 2002, at 07:34 AM, Bernhard Reiter wrote:

On Mon, Feb 18, 2002 at 04:52:01PM -0800, Jeshua Lacock wrote:

On Monday, February 18, 2002, at 06:45 AM, Bernhard Reiter wrote:

We might have to check that what you do is not voilating GRASS'
license.

[moved up from below]
Our front-end only sets system environment variables and executes
binaries. It does not modify or use any Grass code internally.

Further, I do not plan to put the two products on a single disk.

I am sure that it is within the context of the GPL.

It might be legal,
at least it is not entirely within the spirit of the GRASS community.
I will consult more people on this.

Please see my comments below.

Please make sure that it is cristal clear that GRASS comes with all
that freedom and your frontend does not. This is important in any case.

There will be distinct wording that the underlying "GIS-Engine" is the Open-Source Grass Project, and MacGrass is our Proprietory GUI.

I am not a proponent of proprietory frontends to GRASS.
It will not only be a disadvantage to the whole GRASS user
community, but will also be suboptimal for your product and users.

Well, all I can say is there is definitely a demand for an elegant easy
to use interface. Most Macintosh users are VERY intimidated by Grass
and as such will NEVER use it without s slick front-end like we are
developing.

Agree, but that does not mean you have to develop it non-free.

I cannot get funding for the project and give the source code away. From an investment point of view - I agree.

I really do not see how this could be bad for the entire Grass
community.

You are building your proprietory software on top of the functions
of GRASS which has been build as Free Software. Thus you are selling
a solution based on the ground work and do not share your work with
us groundworkers back.

Please remember, that I spent months of my life porting Grass to Mac OS X. I publish the binaries for Mac OS X - for free and I will continue to do so.

Also remember that we donated money to the Grass project and we hope to be able to generate larger donations in the future with our MacGrass project. I want to be the number one fund contributor to Grass - is that a bad goal? It is not source code, however money is what makes the world go around - unfortunately.

In the end, every one benefits. The Grass community thrives and reaches places it never has gone before.

Look at what Mac OS X itself is. It is a GUI for controlling
(opensource) binaries through an elegant user interface. So by your
logic, Apple is violating the GPL because they have a front-end to stop
and start apache for example.

AFAIK Mac OS X does not only contain Free Software binaries,
they rely a lot on bsd like unix based on a mach architecture.

I think an excellent example here is the Mac OS X Project Builder application. It is a fancy GUI for developing projects - I love using it. It's back-end is the Gnu Compiler Compilation. The GUI is Apple's proprietary front-end for gcc. The gcc is obviously distributed under the GPL. Now, I ask is that GUI a "bad thing" for the gcc team?

Absolutely not, they should be delighted that their compiler now has a user share three times the size of Linux (roughly - in theory). And I would much rather use Apples Project Builder application then "vi" and "gcc" any day, and I am still using gcc - just behind the scenes. Hooray for Apple - Hooray for GCC!

I want to do the same thing Apple has done to a Operating System to a Geographical Information System. What is the difference? They are really identical in spirit and vision. Is Apple a "bad company"? If Apple can do it, why can't we?

My vision is simple: make Grass as intuitive and easy to use (for both novices and pros) as say Mac OS X or Adobe Photoshop.

Please note that there is also commerical Free Software.
High quality software done by professionals for money,
but still granting all necessary freedoms.

The Macintosh community is not used to free software. They are used to
paying for quality software on a CD in a box with manuals and support
that they can purchase from a store.

But you can do this and let your frontend have all freedoms.
It does not stand in contrast to Free Software.
You also have the chance to educate them.
  Bernhard

The real problem here is that I cannot get a dime of capital to invest in an open-source project, its hard enough - keeping it proprietary.

Again, as I stated previously, I personally have mixed feelings about proprietary versus open-source. I love the Grass community, and I still very interested in contributing to it. In this case Money instead of Code.

Is the Grass project independently and well financed indefinitely? Or will the Grass team also welcome Money as it does source code? If you have enough capital, the Grass team can have (well) paid full time programmers, which of course plus coffee equals source code:

     $ = : ) = c++

Best regards,

Jeshua Lacock __________________________
Programmer/Owner Phone: 760.935.4736
http://OpenOSX.com Fax: 760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

15

At 4:01 PM -0800 2/22/02, Jeshua Lacock wrote:

On Friday, February 22, 2002, at 07:34 AM, Bernhard Reiter wrote:

On Mon, Feb 18, 2002 at 04:52:01PM -0800, Jeshua Lacock wrote:

On Monday, February 18, 2002, at 06:45 AM, Bernhard Reiter wrote:

We might have to check that what you do is not voilating GRASS'
license.

[moved up from below]
Our front-end only sets system environment variables and executes
binaries. It does not modify or use any Grass code internally.

Further, I do not plan to put the two products on a single disk.

I am sure that it is within the context of the GPL.

It might be legal,
at least it is not entirely within the spirit of the GRASS community.
I will consult more people on this.

I think that Jeshua's plan is completely within both the GPL and the spirit of the GRASS community. I hope he goes ahead with it, I hope we Mac users end up with a great product, and I hope Jeshua makes wheelbarrows full of money. I don't even see any reason to put his two products on separate disks.

As some of you know, I'm mainly a PalmOS developer these days. I'd like to toss out an example from that world (the word "militant" does not come close to describing some of the open-source folks over in the PalmOS community).

There are two main development environments for PalmOS, Codewarrior (proprietary, hundreds of dollars) and PRC-tools (based on GCC, GPL). However, there's also a proprietary environment from Falch.net called Developer Studio. That's simply a nice GUI/IDE wrapped around PRC Tools. If you want PRC Tools, you can have it for free. If you want the IDE, you pay. This strikes me as a very close parallel to Jeshua's project.

Now suppose I sit down and write a shell script to drive GRASS. That's certainly not a modification of GRASS (as defined in the GPL, paragraph 2). It's simply a new program. It's mine, I control the copyright and licensing, and I can sell it to anyone I can manage to convince to buy it.

But maybe I can't get the performance I need out of a shell script. So I write a C program to do the same thing. It's not as crystal clear as the previous example, but I think this is still a separate program (the GPL calls it "identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves"). Maybe it depends on how it's linked--or maybe not.

There's another phrase in the GPL that's relevant. "...it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program".

I don't see how a front-end can be considered a derivative work. It's a new work.

Finally, there's one more thing I hope folks will consider. If the GRASS community gets a reputation for throwing up obstacles to new software, that can only hurt the future of GRASS and the open-source movement in general. Of course, it will also put more money into ESRI's pockets.

----
Hal Mueller
Seattle, Washington hal@seanet.com

16

On Fri, Feb 22, 2002 at 04:01:20PM -0800, Jeshua Lacock wrote:

On Friday, February 22, 2002, at 07:34 AM, Bernhard Reiter wrote:

There will be distinct wording that the underlying "GIS-Engine" is the
Open-Source Grass Project, and MacGrass is our Proprietory GUI.

This is good, though I prefer the term "Free Software" as for freedom.

>Agree, but that does not mean you have to develop it non-free.

I cannot get funding for the project and give the source code away. From
an investment point of view - I agree.

You know it is about freedom and not about price.
I've done several commercial Free Software projects.

There are investors which do invest in this new model
of software business.

Please remember, that I spent months of my life porting Grass to Mac OS
X. I publish the binaries for Mac OS X -
for free and I will continue to do so.

Also remember that we donated money to the Grass project and we hope to
be able to generate larger donations in the future

There is no price tag which makes it okay to substract freedom.
I am also investing quite some money and time into GRASS.
Many people did. If everybody did it in a proprietory way
we would not have such a powerful GRASS as we have today.

I think an excellent example here is the Mac OS X Project Builder
application. It is a fancy GUI for developing projects - I love using
it. It's back-end is the Gnu Compiler Compilation. The GUI is Apple's
proprietary front-end for gcc. The gcc is obviously distributed under
the GPL. Now, I ask is that GUI a "bad thing" for the gcc team?

It does not help either.
The only part that was acutally really useful was the
Objective-C frondend to the compiler. This one Apple only released
under pressure and because the had to.

Apple made several attempts to lock users in, just as Microsoft
does today. Thus they are not a "good" company by this means.
The fact that they are the only hardware alternative to the Intel
monopoly makes them worth preserving in these days. But a "good" company?

Oh, btw there is a Free Software implementation of the project and
interface builder coming along nicely. www.gnustep.org

I want to do the same thing Apple has done to a Operating System to a
Geographical Information System. What is the difference? They are really
identical in spirit and vision. Is Apple a "bad company"? If Apple can
do it, why can't we?

Meanwhile I think that you are right and it is legal to do so.
I do not think it is a good idea, but we obviously disagree here.
Thus I hope that you will find out the value Free Software
some time in the future.

There is no point in repeating the long debate about
why it is not ethical to develop proprietory software.

17

On Fri, Feb 22, 2002 at 05:44:30PM -0800, Hal Mueller wrote:

But maybe I can't get the performance I need out of a shell script.
So I write a C program to do the same thing. It's not as crystal
clear as the previous example, but I think this is still a separate
program (the GPL calls it "identifiable sections of that work are not
derived from the Program, and can be reasonably considered
independent and separate works in themselves"). Maybe it depends on
how it's linked--or maybe not.

The linkage is key. Use system() or exec(), okay, use libraries, GPL
is violated. When/if GRASS libraries get reorganized where there's
something akin to what's been termed libgrassio (which is intended
to be LGPL), it will be easier for commercial outfits to do basic
read/write of data to GRASS format w/o LICENSE worries.

Finally, there's one more thing I hope folks will consider. If the
GRASS community gets a reputation for throwing up obstacles to new
software, that can only hurt the future of GRASS and the open-source
movement in general. Of course, it will also put more money into
ESRI's pockets.

No obstacles. We just ask that others share their developments with
us (as we have done with them). I get $0 dollars working on GRASS.
A large part of why I do it, is the for the challenge of solving
(or at least trying) to solve problems. When others hide what they
do, I can't learn from it. And that's no fun.

--
Eric G. Miller <egm2@jps.net>

18

Just for those interested in various categories of free and non-free software -
see this web page:

http://www.gnu.org/philosophy/categories.html

I hope this might help in recent discussions.

Jaro

Helena Mitasova wrote:

>
>
> > The Macintosh community is not used to free software. They are used to
> > paying for quality software on a CD in a box with manuals and support
> > that they can purchase from a store.
>
> But you can do this and let your frontend have all freedoms.
> It does not stand in contrast to Free Software.
> You also have the chance to educate them.
> Bernhard
>

I think that this statement just shows again that there is a misunderstanding
of what free
means for free software - free does not mean that you are not supposed to pay
for it
but that you have freedom to run, modifiy, etc. So selling

"quality software on a CD in a box with manuals and support
that they can purchase from a store"

is, as Bernhard says in no conflict with making it free - and here I cannot
help it-
the word Open is just more accurate (no matter how much the free and open
source
guys do not like each other). As I said before, for most people, not
intimately familiar
with the free software and open source world, free software means something
completely
different than what it is (often it is a proprietary software that is given
away for no charge).
So I can very much understand why Jeshua does not want their product to be
free, but may be
you could consider keep it Open?
And there are many Mac people who would love to buy a nice, easy to use GIS
(I know couple of them right here), but who would also like to modify it.

Helena

>
> ------------------------------------------------------------------------
> Part 1.2Type: application/pgp-signature

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

19

Dear all,

I am deeply convinced that Jeshuas plan of
a proprietary GUI frontend in the long run will bring
much more harm than help to the GRASS development.

We all have seen the fruitful development boost
after GPLing the code and with that protecting the freedom.
Proprietary addons are naturally are beyond
the control of the developer team.

Consider this scenario: Jeshua markets his GUI frontend
successfully and sponsors development of GRASS.
At some point the developers think it is a good
idea to change the infrastructure in a way that would
make it incompatible with the proprietary GUI frontend.
With the financial dependency, would the developers
be entirely free in technological decision making?
With a free GUI frontend they could decide on their
own e.g. whether to adapt the frontend or whether to
adapt the backend.

Another Scenario: Another desktop GUI occurs on the market
that is similar to the MacOS X. The developers would
like to support it, but not so Jeshua. In this case the developers
have to entirely reimplement the stable, nice, well fine-tuned GUI
for their product.

Another Scenario: A company would like to sell GRASS installation
at big companies or authorities. The company is paid for service only
of course and contributes a percentage to the GRASS development
team. Now the client want to have the nice GUI of Jeshua. Sure,
the conpany (or Jeshua himself) can sell it to the client but with
all the drawbacks of proprietary software, e.g. what if Jeshua dies
in a car accident, he looses interest, or is bought by a large company
(e.g. to discontinue competitive products) due to a unresistable offer?
The service company can't perform changes
to the GUI as wished by the client any more (it was by then already a pain
always asking and arguing with Jeshua - forced to accept any requested
price and conditions)!

Another scenario: After some time we have a number of proprietary
frontends for different desktops. If they have contradictive demands
for the backend, which one to follow (first)? For the one who
pays more or for the better technical solution?

These scenarios are just sketched, there can be many different flavours
in them.

All in all, the development would loose the freedom for a number of decisions.
The degree of substracted freedom might be low, but personally I don't
want to give up any.

Of course, this does not mean that I want to forbid the development
of a proprietary frontend (I can't - Jeshua has all freedom to do so).
I just want to make all aware on disadvantages I see opposing the
(financial) advantages Jeshua promised.

Jeshua, I hope you make a hell lot of money with a GUI frontend,
but please with a Free Software one. It makes sense and will work!
According to your initial statement, Mac users will buy the nice
colored box from the shelf where you have placed Free Software and
printed manuals rather then downloading the stuff and printing the manuals
on their own.

  Jan
--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

20

Jan-Oliver Wagner wrote:

Consider this scenario: Jeshua markets his GUI frontend
successfully and sponsors development of GRASS.
At some point the developers think it is a good
idea to change the infrastructure in a way that would
make it incompatible with the proprietary GUI frontend.
With the financial dependency, would the developers
be entirely free in technological decision making?

It would depend upon the extent to which GRASS was actually
*dependent* upon that sponsorship. Ultimately, anyone who wasn't happy
with decisions taken by the "official" maintainers would be free to
take a copy of the GRASS code and go their own way.

Jeshua, I hope you make a hell lot of money with a GUI frontend,
but please with a Free Software one. It makes sense and will work!
According to your initial statement, Mac users will buy the nice
colored box from the shelf where you have placed Free Software and
printed manuals rather then downloading the stuff and printing the manuals
on their own.

But if he released the front-end under the GPL (or any licence which
permits royalty-free redistribution), nothing would prohibit a third
party from downloading the code and documention, making their own CDs
and manuals, and selling them for less.

This is the entire reason why the concept of copyright exists.

I would suggest that anyone who would prefer to see a free (e.g. GPL)
front-end for GRASS would do better to actually start coding it than
to implore others to do so.

--
Glynn Clements <glynn.clements@virgin.net>