[GRASS5] Grass Projection Parameters

[Jeshua Lacock]

--Apple-Mail-2--734500510
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed


(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
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_


--Apple-Mail-2--734500510
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII


(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:


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

<excerpt>Radim Blazek wrote:

<excerpt><excerpt><excerpt><excerpt>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.

</excerpt>

Just out of curiosity:


What programming facilities are you using?

Is there any schedule for the release of the source code?

</excerpt></excerpt></excerpt></excerpt>

<excerpt><excerpt><excerpt>We are developing the software using
Apple's Project Builder in Cocoa

(objective-c based), as a commercial, closed-source project.

</excerpt></excerpt></excerpt>

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

</excerpt>

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


<excerpt><excerpt><excerpt><excerpt>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.

</excerpt></excerpt></excerpt>

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.

</excerpt>

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.


<excerpt><excerpt><excerpt>What you are doing is exactly what is not
allowed. I consider 

your work to be "work based on the Program"

</excerpt>

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.

</excerpt>

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).

</excerpt>

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.


<excerpt>Please note that there is also commerical Free Software.

High quality software done by professionals for money,

but still granting all necessary freedoms.

</excerpt>

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

<underline><color><param>1A1A,1A1A,FFFF</param>http://OpenOSX.com</color></underline>          
Fax:        760.935.4845

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_



--Apple-Mail-2--734500510--