[GRASS5] Leaving

Thierry_Laronde · November 22, 2003, 11:47am

Hello,

We have some discussions (mainly monologues of my own) the past weeks
and it seems clear that I'm not on the very same wavelength with others.
And my tone has perhaps not always pleased people.
As we used to say when I was in the army: "lost, but grouped": it's
always less damaging to go grouped in a wrong direction than to be
scattered all around.

So the best method to see what is indeed the correct way is to test: I
will go my own way starting from the last CERL public release, since my
needs are not cutting edge ones and I have already done a fair amount
of cleaning (this means mainly deletions, and
standardisation/ansification is on the way ---and I have now a more
clear idea of the work done by Markus since, yes, one can not say that
if one wants to compile on a POSIX system with -Wall -Werror it does
compile out of the box!).

My plan are, too, to resurrect the X Window/Motif interface which is far
more challenging, at least for me: I know at the moment strictly nothing
about Motif programming and there has been a fair amount of changes
since 1991...

But open source is here precisely for people to learn and to adjust for
their exact needs.

Regards,
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

Bernhard_Reiter · November 22, 2003, 3:51pm

Hi Thierry,

On Sat, Nov 22, 2003 at 12:47:01PM +0100, Thierry Laronde wrote:

We have some discussions (mainly monologues of my own) the past weeks
and it seems clear that I'm not on the very same wavelength with others.

I've read some of your postings
and got the feeling that they were insightful
and thus helpful for the GRASS development community.

The problem might be a little bit the expectation you might
have about the GRASS community. GRASS is a huge beast and the community
is relatively fresh and small.

Some of my responses to your emails might have sounded
discouraging, but I am watching and doing my very little share
for GRASS for about four years and this I've learned a couple
of lesson (some bitter some sweet) about what is realistic with
GRASS or not.

We need people like you with technical expertise, needs
and motivation to drive further steps of GRASS developments.

Some other conversations about technical stuff
went in the direction about seeking consensus and this is always very hard
in a huge group like this.

The third type of emails I saw just demonstrated that you had been
digging deeply into some GRASS implementation and design problems.
If you don't receive and answer on those, just go ahead and try
to fix that stuff as you like. It mainly means that we do not have
a person that is really deep into those parts of GRASS.

So the best method to see what is indeed the correct way is to test: I
will go my own way starting from the last CERL public release, since my
needs are not cutting edge ones and I have already done a fair amount
of cleaning (this means mainly deletions, and
standardisation/ansification is on the way ---and I have now a more
clear idea of the work done by Markus since, yes, one can not say that
if one wants to compile on a POSIX system with -Wall -Werror it does
compile out of the box!).

Yes, why not. This is about Free Software and experiments
can only help.
I believe that quite some improvement have been made
since the last CERL release(s). Thus I would encourage you
to try another starting point, because the results might be more
helpful for the more mainstream GRASS development.

My plan are, too, to resurrect the X Window/Motif interface which is far
more challenging, at least for me: I know at the moment strictly nothing
about Motif programming and there has been a fair amount of changes
since 1991...

Wow. I wounder a bit why someone would try to do so.
Tcl/Tk is very stable,
though the current interfaces also have their drawbacks.
Motif or lesstif (Free Software) will not improve the look or
stability much.
If I had time for a shot on a GRASS interface, I'd use the wxPython.
Actually the interface descriptions can be used to easily contruct
something similiar to the current tcltkgrass with wxPython
and then you further.

But open source is here precisely for people to learn and to adjust for
their exact needs.

Yes, that is what Free Software is for.
Bernhard

Thierry_Laronde · November 23, 2003, 10:17am

Hello Bernhard,

On Sat, Nov 22, 2003 at 04:51:02PM +0100, Bernhard Reiter wrote:

> My plan are, too, to resurrect the X Window/Motif interface which is far
> more challenging, at least for me: I know at the moment strictly nothing
> about Motif programming and there has been a fair amount of changes
> since 1991...

Wow. I wounder a bit why someone would try to do so.

Yes, I'm a freak... But there is an explanation behind this. To
understand a choice, one has to know what the aim is.

I think that the major advantage that people could advertise about
Tcl/Tk is portability. I put it aside since I have more to say about
that below.

Efficiency? Tcl/Tk is interpreted, so no.

Maintainability-1? When one installs Tcl/Tk and see the dependencies and
amount of time needed simply to compile... On the other side, Motif for
example depends on X and that's all and Motif is a standard ( Motif X11
Toolkit (industry standard GUI (IEEE 1295)).

Maintainability-2? On the coder side. One advantage is to obtain a
result rapidly. Tcl/Tk is good for prototyping or for small applications
when you don't want to spend much more time on designing an interface
than on developing the core routines.
But the time "gained" initially is several times lost if the interface
is complex. These languages are not as good as more raw ones to
"rectify" the "need curve" (to approach as closely as possible a weird
need with small segments of code). Because the learning time has been
smaller, the coders understand less of the internals resulting in code
"not doing" what it was supposed to do.

Maintainability-3? Almost one half of the compiling/running problems
reported are due to the change in Tcl/Tk (8.3 -> 8.4).
The less dependencies you have, the most stability you can achieve.

Last but not least: portability? People have envisaged portability as:
one has a X machine with a Y OS, how can I make the software run on
(X,Y)? But there are revolutions (linked): free OSes and network.

[A discussion with Michael Barton some days ago has been instructive on
this side]
The portability problem is now: one has a X machine and STOP! We can
provide an OS running on X. And that's all. This OS has not to be
installed even on the local storage of the machine (disk) because it can
be launched from a CD (see Knoppix) or even more importantly downloaded
from the network.
If you have a small application, used a couple of minutes every hour,
dual booting is not an option. With a complete work environment like
GRASS, this is not a problem.

The future, for GRASS as for others, is a network of workstation,
accessing SAN and able to be used as a cluster for heavy computing. And
who says network says, too, yes, thin clients. That is X and light
weight (have mercy for the servers!).
So Xt... but a "leettle" simpler would be best: Gtk, Qt? There
is Motif. So let's go for Motif.

Regards,
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

Markus_Neteler1 · November 23, 2003, 4:58pm

Hello Thierry,

On Sat, Nov 22, 2003 at 12:47:01PM +0100, Thierry Laronde wrote:

Hello,

We have some discussions (mainly monologues of my own) the past weeks
and it seems clear that I'm not on the very same wavelength with others.
And my tone has perhaps not always pleased people.
As we used to say when I was in the army: "lost, but grouped": it's
always less damaging to go grouped in a wrong direction than to be
scattered all around.

It's really sad to loose a new developer! Leftover are only a few
people who really need support (well, my point of view). You posted
quite a few suggestions so far - unfortunately with little
response.

Looking back to
http://grass.itc.it/pipermail/grass5/2003-November/016964.html
5.0/5.3: 2001: +5, -2 compared to 2000
2002: +1, -4 compared to 2001
2003: +3, -6 compared to 2002

Useless statistics, but it sheds some light on the situation:
We need to make GRASS programming more attractive.

So the best method to see what is indeed the correct way is to test: I
will go my own way starting from the last CERL public release, since my
needs are not cutting edge ones and I have already done a fair amount
of cleaning (this means mainly deletions, and
standardisation/ansification is on the way ---and I have now a more
clear idea of the work done by Markus since, yes, one can not say that
if one wants to compile on a POSIX system with -Wall -Werror it does
compile out of the box!).

Mhhh, time to fork the project? Maybe some developers would join you...
(recalling the license discussion). I agree with you that more radical
changes are needed, as already posted several times.
Maybe LGPL'ed libraries with GPL'ed application layer? Well, most
developers have posted their opinion on this already.

My plan are, too, to resurrect the X Window/Motif interface which is far
more challenging, at least for me: I know at the moment strictly nothing
about Motif programming and there has been a fair amount of changes
since 1991...

If Motif is a good choice, I am not sure. Looks a bit dated.

But open source is here precisely for people to learn and to adjust for
their exact needs.

Agreed.

Markus Neteler

Glynn_Clements · November 23, 2003, 9:36pm

Markus Neteler wrote:

> So the best method to see what is indeed the correct way is to test: I
> will go my own way starting from the last CERL public release, since my
> needs are not cutting edge ones and I have already done a fair amount
> of cleaning (this means mainly deletions, and
> standardisation/ansification is on the way ---and I have now a more
> clear idea of the work done by Markus since, yes, one can not say that
> if one wants to compile on a POSIX system with -Wall -Werror it does
> compile out of the box!).

Mhhh, time to fork the project? Maybe some developers would join you...
(recalling the license discussion). I agree with you that more radical
changes are needed, as already posted several times.
Maybe LGPL'ed libraries with GPL'ed application layer? Well, most
developers have posted their opinion on this already.

It's not clear to me exactly what Thierry's complaints with the
current direction are, but they don't appear to be related to
GRASS' licensing policy.

As for cleaning up, there's already a consensus that it needs to be
done; it just doesn't appear to be happening. Eliminating warnings and
converting to use ANSI prototypes are both tasks which can reasonably
be done in 5.3. [However, as I've said before, warnings shouldn't
simply be "made to go away". The wrong fix is worse than no fix, as it
almost completely eliminates the possibility of someone subsequently
making the right fix.]

Re-formatting is a bit more problematic, as it eliminates the
possibility of obtaining meaningful diffs between pre- and post-
versions. However, this isn't that critical, so long as "real" changes
aren't committed at the same time.

The one thing which shouldn't be done in 5.3 is to move or rename
files, as that resets the history. That doesn't apply to deleting
clones; if we delete a file, we no longer care about its history.

> My plan are, too, to resurrect the X Window/Motif interface which is far
> more challenging, at least for me: I know at the moment strictly nothing
> about Motif programming and there has been a fair amount of changes
> since 1991...

If Motif is a good choice, I am not sure. Looks a bit dated.

I don't think that Motif is a good choice here. And I seem to be one
of the few open-source programmers who hasn't succumbed to the Gtk/Qt
groupthink. I still think that Motif is a good choice for an
X-specific toolkit on technical grounds (in terms of acceptability, it
depends upon the target platform; Motif is a good choice on commercial
Unices, a poor one on Linux).

However, it definitely wouldn't be the right approach from a
portability perspective. Particularly given the licensing issues;
Motif is free for open-source platforms, but that doesn't apply to
MacOSX, and probably not to Cygwin (Cygwin is open-source, Windows
isn't). [Licensing isn't an issue for commercial Unices, as they
invariably include Motif with the OS.]

wxWindows has reasonable portability. Its use of C++ presents some
issues regarding binary compatibility, but then the same is true for
using Tcl/Tk.

FWIW, I have managed to get non-trivial Gtk programs working with the
Windows port of Gtk, which doesn't require Cygwin or an X server. I
presume that Gtk works fine on MacOSX with an X server.

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

Bernhard_Reiter · November 24, 2003, 2:21pm

On Sun, Nov 23, 2003 at 11:17:11AM +0100, Thierry Laronde wrote:

I think that the major advantage that people could advertise about
Tcl/Tk is portability. I put it aside since I have more to say about
that below.

The second major one is stability. Tcl/Tk is very stable.
Also Tcl/Tk is Free Software.

Maintainability-1? When one installs Tcl/Tk and see the dependencies and
amount of time needed simply to compile... On the other side, Motif for
example depends on X and that's all and Motif is a standard ( Motif X11
Toolkit (industry standard GUI (IEEE 1295)).

As Glynn explained in another thread,
Motif is not a nice Free Software player.

Maintainability-2? On the coder side. One advantage is to obtain a
result rapidly. Tcl/Tk is good for prototyping or for small applications
when you don't want to spend much more time on designing an interface
than on developing the core routines.
But the time "gained" initially is several times lost if the interface
is complex. These languages are not as good as more raw ones to
"rectify" the "need curve" (to approach as closely as possible a weird
need with small segments of code). Because the learning time has been
smaller, the coders understand less of the internals resulting in code
"not doing" what it was supposed to do.

I cannot judge this efficiently.
Some studies and major application in Tcl/Tk suggest
that it is a power and easy enough language.
Personally I prefer Python by a wide margin and never leared Tcl/Tk.

Maintainability-3? Almost one half of the compiling/running problems
reported are due to the change in Tcl/Tk (8.3 -> 8.4).
The less dependencies you have, the most stability you can achieve.

The latter sentence is a general truth.
If you use it, you have to see the other side, too:
There is a tendency to reinvent the wheel
if you don't use components.
I agree that the Tcl/Tk maintainers could be more careful
with some of their language changes.

Last but not least: portability? People have envisaged portability as:
one has a X machine with a Y OS, how can I make the software run on
(X,Y)? But there are revolutions (linked): free OSes and network.

[A discussion with Michael Barton some days ago has been instructive on
this side]
The portability problem is now: one has a X machine and STOP! We can
provide an OS running on X. And that's all. This OS has not to be
installed even on the local storage of the machine (disk) because it can
be launched from a CD (see Knoppix) or even more importantly downloaded
from the network.
If you have a small application, used a couple of minutes every hour,
dual booting is not an option. With a complete work environment like
GRASS, this is not a problem.

I disagree here.
My company created a Free Software version of Knoppix (the original
containts proprietary software). It is nice to experiment with stuff,
but basically useless on real workplaces.
For once there is the costs in speed, next you get the problem
of getting your data in and out, including your configuration.

The most important point though is, that people spend a lot
of perceived learning time in front of their windowing system.
They don't feel okay when they have to change it
and won't be happy.

The future, for GRASS as for others, is a network of workstation,
accessing SAN and able to be used as a cluster for heavy computing. And
who says network says, too, yes, thin clients. That is X and light
weight (have mercy for the servers!).
So Xt... but a "leettle" simpler would be best: Gtk, Qt? There
is Motif. So let's go for Motif.

Thierry_Laronde · November 25, 2003, 11:19am

On Mon, Nov 24, 2003 at 03:21:06PM +0100, Bernhard Reiter wrote:

On Sun, Nov 23, 2003 at 11:17:11AM +0100, Thierry Laronde wrote:
> example depends on X and that's all and Motif is a standard ( Motif X11
> Toolkit (industry standard GUI (IEEE 1295)).

As Glynn explained in another thread,
Motif is not a nice Free Software player.

Funny enough, what is, today, reproached to OpenMotif is that it
requires the kernel to be an open source one. That is Motif is discarded
because you can't freely run it on not free kernels.

This could be a problem if there were _machines_, architectures with
which open source can not deal with. But this is not the case.

> The portability problem is now: one has a X machine and STOP! We can
> provide an OS running on X. And that's all. This OS has not to be
> installed even on the local storage of the machine (disk) because it can
> be launched from a CD (see Knoppix) or even more importantly downloaded
> from the network.
> If you have a small application, used a couple of minutes every hour,
> dual booting is not an option. With a complete work environment like
> GRASS, this is not a problem.

I disagree here.
My company created a Free Software version of Knoppix (the original
containts proprietary software). It is nice to experiment with stuff,
but basically useless on real workplaces.
For once there is the costs in speed, next you get the problem
of getting your data in and out, including your configuration.

I don't suggest that such a feature should be the standard. I see it as
a fallback (for example in schools/universities).

For "industry", one has to install the really (whether locally or
remotely via a boot server).

--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

Thierry_Laronde · November 25, 2003, 11:37am

On Sun, Nov 23, 2003 at 09:36:06PM +0000, Glynn Clements wrote:

Markus Neteler wrote:

>
> Mhhh, time to fork the project? Maybe some developers would join you...
> (recalling the license discussion). I agree with you that more radical
> changes are needed, as already posted several times.
> Maybe LGPL'ed libraries with GPL'ed application layer? Well, most
> developers have posted their opinion on this already.

It's not clear to me exactly what Thierry's complaints with the
current direction are, but they don't appear to be related to
GRASS' licensing policy.

I think that Markus is looking forward: it's clear that by starting with
the Public Domain code, the licence of the future work has to be
decided. The licence impacts:
- The availability of the source enhancements
- The attractivity to developers
- The possibility for developers, and primarily the GRASS developers to
make a living with GRASS (that is to have time to work on it because
they get incomes from it);

The third point discards GPL: if once you have made a work, everybody
can take it and do whatever one wants, a developer has no incitative and
no means to be paid for what it actually does. Bu this impacts the
userland level which is typically a domain for custom applications.

If one wants to make a GPL userland stuff, one has to be able to. But if
one wants (or simply needs) to make a userland stuff not GPLed, one has
to have the ability to do so.

For the core, there are two major options: BSD (_with_ advertisement
clause) or LGPL. At first sight LGPL seems better since it imposes to
contribute back the source enhancements. But on a pratical level,
BSD with the obligation to advertise the fact that you use code you have
not developed (but what developed by such and such) and the
impractibility to maintain a CVS tree too diverging from a code you rely
on, make it possible.

For the moment, I don't know if I will choose BSD or LGPL for the core
(the libraries). But I will not choose GPL for that.

> > My plan are, too, to resurrect the X Window/Motif interface which is far
> > more challenging, at least for me: I know at the moment strictly nothing
> > about Motif programming and there has been a fair amount of changes
> > since 1991...
>
> If Motif is a good choice, I am not sure. Looks a bit dated.

I don't think that Motif is a good choice here. And I seem to be one
of the few open-source programmers who hasn't succumbed to the Gtk/Qt
groupthink. I still think that Motif is a good choice for an
X-specific toolkit on technical grounds (in terms of acceptability, it
depends upon the target platform; Motif is a good choice on commercial
Unices, a poor one on Linux).

However, it definitely wouldn't be the right approach from a
portability perspective. Particularly given the licensing issues;
Motif is free for open-source platforms, but that doesn't apply to
MacOSX, and probably not to Cygwin (Cygwin is open-source, Windows
isn't). [Licensing isn't an issue for commercial Unices, as they
invariably include Motif with the OS.]

The fact to impose the use of an open source kernel is for me not a
problem, since one can provide a free kernel on almost any kind of
hardware architecture. And the Unix orientation of GRASS (as expressed
in the progman of at least 4.1.5) has to be retained.
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

Bernhard_Reiter · November 25, 2003, 1:03pm

On Tue, Nov 25, 2003 at 12:19:25PM +0100, Thierry Laronde wrote:

On Mon, Nov 24, 2003 at 03:21:06PM +0100, Bernhard Reiter wrote:
> On Sun, Nov 23, 2003 at 11:17:11AM +0100, Thierry Laronde wrote:
> > example depends on X and that's all and Motif is a standard ( Motif X11
> > Toolkit (industry standard GUI (IEEE 1295)).
>
> As Glynn explained in another thread,
> Motif is not a nice Free Software player.
>

Funny enough, what is, today, reproached to OpenMotif is that it
requires the kernel to be an open source one. That is Motif is discarded
because you can't freely run it on not free kernels.

This could be a problem if there were _machines_, architectures with
which open source can not deal with. But this is not the case.

This is twisting my argument around ab bit.
Motif itself is proprietary software and does not have
an open developer community (of the core software itself).
This is why lesstiff exists.

> > The portability problem is now: one has a X machine and STOP! We can
> > provide an OS running on X. And that's all. This OS has not to be
> > installed even on the local storage of the machine (disk) because it can
> > be launched from a CD (see Knoppix) or even more importantly downloaded
> > from the network.
> > If you have a small application, used a couple of minutes every hour,
> > dual booting is not an option. With a complete work environment like
> > GRASS, this is not a problem.
>
> I disagree here.
> My company created a Free Software version of Knoppix (the original
> containts proprietary software). It is nice to experiment with stuff,
> but basically useless on real workplaces.
> For once there is the costs in speed, next you get the problem
> of getting your data in and out, including your configuration.

I don't suggest that such a feature should be the standard. I see it as
a fallback (for example in schools/universities).

For "industry", one has to install the really (whether locally or
remotely via a boot server).

But this also means that there is some merit to the portability problem
and you cannot dismiss with a simple argument like that.

Buchan_Milne · November 25, 2003, 1:44pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thierry Laronde wrote:

On Sun, Nov 23, 2003 at 09:36:06PM +0000, Glynn Clements wrote:

Markus Neteler wrote:

Mhhh, time to fork the project? Maybe some developers would join you...
(recalling the license discussion). I agree with you that more radical
changes are needed, as already posted several times.
Maybe LGPL'ed libraries with GPL'ed application layer? Well, most
developers have posted their opinion on this already.

It's not clear to me exactly what Thierry's complaints with the
current direction are, but they don't appear to be related to
GRASS' licensing policy.

I think that Markus is looking forward: it's clear that by starting with
the Public Domain code, the licence of the future work has to be
decided. The licence impacts:
- The availability of the source enhancements
- The attractivity to developers
- The possibility for developers, and primarily the GRASS developers to
make a living with GRASS (that is to have time to work on it because
they get incomes from it);

- - The possibility for grass to be included in free software distributions.

The third point discards GPL: if once you have made a work, everybody
can take it and do whatever one wants, a developer has no incitative and
no means to be paid for what it actually does. Bu this impacts the
userland level which is typically a domain for custom applications.

But if you go with a license which doens't require changes to be
contributed back, a developer has no incentive to provide those changes
back to the community. If the license does require it, the incentive is
the ability to use the software in the first place.

If one wants to make a GPL userland stuff, one has to be able to. But if
one wants (or simply needs) to make a userland stuff not GPLed, one has
to have the ability to do so.

For the core, there are two major options: BSD (_with_ advertisement
clause) or LGPL. At first sight LGPL seems better since it imposes to
contribute back the source enhancements. But on a pratical level,
BSD with the obligation to advertise the fact that you use code you have
not developed (but what developed by such and such) and the
impractibility to maintain a CVS tree too diverging from a code you rely
on, make it possible.

AFAIK, BSD with the advertisement clause is not GPL compatible, and not
considered suitable for use in free software distributions (I may be
wrong but I think the original BSD does not comply with the Debian
requirements for free software).

I don't think that Motif is a good choice here. And I seem to be one
of the few open-source programmers who hasn't succumbed to the Gtk/Qt
groupthink. I still think that Motif is a good choice for an
X-specific toolkit on technical grounds (in terms of acceptability, it
depends upon the target platform; Motif is a good choice on commercial
Unices, a poor one on Linux).

However, it definitely wouldn't be the right approach from a
portability perspective. Particularly given the licensing issues;
Motif is free for open-source platforms, but that doesn't apply to
MacOSX, and probably not to Cygwin (Cygwin is open-source, Windows
isn't). [Licensing isn't an issue for commercial Unices, as they
invariably include Motif with the OS.]

The fact to impose the use of an open source kernel is for me not a
problem, since one can provide a free kernel on almost any kind of
hardware architecture. And the Unix orientation of GRASS (as expressed
in the progman of at least 4.1.5) has to be retained.

Well, grass currently runs on platforms which would possibly not be
supportable if you use Motif (Cygwin and Mac OS X).

Using Motif basically makes grass less attractive on all the most
popular platforms ...

BTW, wxWindows uses native widgets on all platforms (Mac OS 9, OS X,
GTK2 on Linux, Motif on legacy Unix, native controls on Windows), and is
LGPL (with an exception allowing for easier commercialisation).

IMHO, the better strategy would be to make a MDI desktop (ie documents
instead of monitors) application in wxWindows (or wxPython), licensed
under GPL, basic grass libraries (enough to write proprietary modules)
LGPL, grass modules (and possibly some libraries) GPL. But I haven't
(yet) contributed code to grass (I have to check with the University
Intellectual Property office before I let anyone have binaries of my
module:-/).

Regards,
Buchan

- --
|--------------Another happy Mandrake Club member--------------|
Buchan Milne Mechanical Engineer, Network Manager
Cellphone * Work +27 82 472 2231 * +27 21 8828820x202
Stellenbosch Automotive Engineering http://www.cae.co.za
GPG Key http://ranger.dnsalias.com/bgmilne.asc
1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/w1zSrJK6UGDSBKcRAvGnAJ9Du1UXUT2MFd43B7oaHLjLcZqqpACgp2w/
x5t4xbLLyM8qUgGr70jllm0=
=utDD
-----END PGP SIGNATURE-----

Jan-Oliver_Wagner1 · November 25, 2003, 2:49pm

On Tue, Nov 25, 2003 at 12:37:39PM +0100, Thierry Laronde wrote:

I think that Markus is looking forward: it's clear that by starting with
the Public Domain code, the licence of the future work has to be
decided. The licence impacts:
- The availability of the source enhancements
- The attractivity to developers
- The possibility for developers, and primarily the GRASS developers to
make a living with GRASS (that is to have time to work on it because
they get incomes from it);

The third point discards GPL: if once you have made a work, everybody
can take it and do whatever one wants, a developer has no incitative and
no means to be paid for what it actually does.

I strongly object to this statement!
It has already been proven to be wrong as there are people out there
making a living based on Free Software licensed under GNU GPL.
Free Software in general means that you make the money with honest
consulting and contracted development - "service provider" to put it into
a job-description and opposing it to 'product license-to-use seller'.

Of course, we are in a transition phase of product-license-to-use oriented IT
industry to service-oriented IT industry. Thus it is sometimes not easy
to sell the idea. However, it is done successfully more and more often.
And I am working hard on improving this situation further

Also, I regard it unfair to implement little thingies on a huge software
and selling licenses-to-use for the whole stuff. The unfairness will
make developers more and more reluctant to contribute to a BSDish
(=non-protected) software base. In the mid-term this concept will
fail for many software application types, Full-GIS being one of them.

The special thing about GRASS is that we have to deploy it in various
industries and authorities for daily use. Once this is done,
a permanent revenue flow will even be able to pay for the base works
currently done on voluntary basis. Be patient

Best

Jan

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

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

Thierry_Laronde · November 25, 2003, 10:48pm

On Tue, Nov 25, 2003 at 03:44:50PM +0200, Buchan Milne wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> The third point discards GPL: if once you have made a work, everybody
> can take it and do whatever one wants, a developer has no incitative and
> no means to be paid for what it actually does. Bu this impacts the
> userland level which is typically a domain for custom applications.

But if you go with a license which doens't require changes to be
contributed back, a developer has no incentive to provide those changes
back to the community. If the license does require it, the incentive is
the ability to use the software in the first place.

The incentive for giving code is to be rewarded by recognition
(that's why a BSD licence _without_ the advertisement is a non sense),
and by the strong feeling that he belongs to a community (a developer
community) from which he benefits (he's not the only one to work; the
principle "Hey, give me your watch and in exchange, to be fair, I will
tell you what time it is" has never attracted anybody).

AFAIK, BSD with the advertisement clause is not GPL compatible,

If I'm not mistaken, the BSD licence, with or without the clause, as the
MIT licence have always been considered free by the FSF.

And please note that whether this will be the case or not, it's not a
problem: I'm so free, that I even do not consider that the FSF or Debian
(I'm the organizer of the 2 first Debian conferences BTW :-^) have the
absolute truth in this domain.

>
> The fact to impose the use of an open source kernel is for me not a
> problem, since one can provide a free kernel on almost any kind of
> hardware architecture. And the Unix orientation of GRASS (as expressed
> in the progman of at least 4.1.5) has to be retained.

Well, grass currently runs on platforms which would possibly not be
supportable if you use Motif (Cygwin and Mac OS X).

Using Motif basically makes grass less attractive on all the most
popular platforms ...

So I keep on saying: GRASS is a world by itself, it's not a five minutes
application, so it can run as an application, hiding the kernel (a user
has _no_ obligation to see something else than what he wants to use),
i.e. dualboot or remote boot is a serious option.

Deal with the machine: yes. Deal with whatever OS: no.

But that's only my options. "There are several houses in the house of
the Father".

Cheers,
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

Thierry_Laronde · November 25, 2003, 11:00pm

On Tue, Nov 25, 2003 at 03:49:50PM +0100, Jan-Oliver Wagner wrote:

>
> The third point discards GPL: if once you have made a work, everybody
> can take it and do whatever one wants, a developer has no incitative and
> no means to be paid for what it actually does.

I strongly object to this statement!
It has already been proven to be wrong as there are people out there
making a living based on Free Software licensed under GNU GPL.

I don't plan to fight against these assumptions since this will be an
absolutely sterile discussion, and too many electrons have already been
wasted with such threads.

On can make a leaving with Free Software as long as it is only
installation, configuration, maintenance or very particular
customisation (but a customisation that is not a "general" solution).

There are enough enterprises already dead to know that.

This plus the fact that irresponsibles have advertised as a sole
advantage: free software is free i.e. gratis. And they have added: you
have no more need to for developers since what you need is already
downloadable!

And the result (this is an evidence, I have lived this situation!) is
that a developer is considered a guy who _costs_ money and not an
indispensable part of an enterprise focused on software...
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

Glynn_Clements · November 26, 2003, 3:33am

Thierry Laronde wrote:

> But if you go with a license which doens't require changes to be
> contributed back, a developer has no incentive to provide those changes
> back to the community. If the license does require it, the incentive is
> the ability to use the software in the first place.

The incentive for giving code is to be rewarded by recognition
(that's why a BSD licence _without_ the advertisement is a non sense),
and by the strong feeling that he belongs to a community (a developer
community) from which he benefits (he's not the only one to work; the
principle "Hey, give me your watch and in exchange, to be fair, I will
tell you what time it is" has never attracted anybody).

I don't think that's an accurate analogy. In fact, it's probably the
exact opposite. Any derivative work is more likely to be 95% GRASS and
5% contribution than the other way around.

IMHO, expecting the authors of the 5% to allow their work to be used
under the GPL is more reasonable than expecting the authors of the 95%
to allow their work to be used under a proprietary licence.

I'm not concerned with a committed proprietary software developer who
will either:

a) use GRASS, but give us nothing in return, or
b) not use GRASS.

Neither possibility provides any benefit to us.

IMHO, a more plausible scenario is an academic department that extends
GRASS primarily for their own purposes, then has to decide what to do
with the derivative work. If we allow proprietary derivatives, they
may choose (or even be required, e.g. by institutional policy or
financial pressures) to take that route. If we don't allow that, their
best alternative may well be to release the code in the hope that
others will extend it to their benefit.

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

Jan-Oliver_Wagner1 · November 26, 2003, 5:46am

On Wed, Nov 26, 2003 at 03:33:59AM +0000, Glynn Clements wrote:

IMHO, a more plausible scenario is an academic department that extends
GRASS primarily for their own purposes, then has to decide what to do
with the derivative work. If we allow proprietary derivatives, they
may choose (or even be required, e.g. by institutional policy or
financial pressures) to take that route. If we don't allow that, their
best alternative may well be to release the code in the hope that
others will extend it to their benefit.

I can not stress this strategic thought enough! Well explained, Glynn!
And it is a similar scenario for companies.

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

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

Jan-Oliver_Wagner1 · November 26, 2003, 5:58am

On Wed, Nov 26, 2003 at 12:00:58AM +0100, Thierry Laronde wrote:

On Tue, Nov 25, 2003 at 03:49:50PM +0100, Jan-Oliver Wagner wrote:
> > The third point discards GPL: if once you have made a work, everybody
> > can take it and do whatever one wants, a developer has no incitative and
> > no means to be paid for what it actually does.
>
> I strongly object to this statement!
> It has already been proven to be wrong as there are people out there
> making a living based on Free Software licensed under GNU GPL.

I don't plan to fight against these assumptions since this will be an
absolutely sterile discussion, and too many electrons have already been
wasted with such threads.

It is never a waste of electrons to clearify wrong statements for
Mailing List archives.

On can make a leaving with Free Software as long as it is only
installation, configuration, maintenance or very particular
customisation (but a customisation that is not a "general" solution).

Many people earn their money with development of Free Software.

There are enough enterprises already dead to know that.

Yeah, most of the IT enterprises that died since IT exists have been
proprietary companies.
Come on, many companies die. The reasons mostly are more complicated
than just "their business model was all stupid".

This plus the fact that irresponsibles have advertised as a sole
advantage: free software is free i.e. gratis. And they have added: you
have no more need to for developers since what you need is already
downloadable!

I am telling every client that he has to think about Freedom,
Control over IT-Decisions etc. etc.
A job well done should be paid well.
No business man will object to this.

Best

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

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

Thierry_Laronde · November 26, 2003, 9:02pm

On Wed, Nov 26, 2003 at 03:33:59AM +0000, Glynn Clements wrote:

I don't think that's an accurate analogy. In fact, it's probably the
exact opposite. Any derivative work is more likely to be 95% GRASS and
5% contribution than the other way around.

IMHO, expecting the authors of the 5% to allow their work to be used
under the GPL is more reasonable than expecting the authors of the 95%
to allow their work to be used under a proprietary licence.

I'm not concerned with a committed proprietary software developer who
will either:

a) use GRASS, but give us nothing in return, or
b) not use GRASS.

Neither possibility provides any benefit to us.

The important word here is: _developer_. As I'm not a total arsehole, I
feel the _necessity_ for me to give back to the developers what they
have offered to me. I use Linux and *BSD, a whole bunch of software
(mainly developer tools) that I'm happy to have so I want to pay back
my debt. My debt to the developers. I have taken and not given a lot
(organisation of the Debian conferences, Howtos, code for GNU GRUB, some
patches here, articles against the patents and that's all).

So the question is: what is the best licence for _developers_. And the
question is still open, and I don't think there is one and only one
answer.

For the libraries: LGPL? Today the most interesting.
BSD? perhaps but needs more thinking. GPL? No.

But now it's coding time. I put this aside until I have something
working.
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

Radim_Blazek · November 27, 2003, 6:37pm

On Tuesday 25 November 2003 14:44, Buchan Milne wrote:

Thierry Laronde wrote:
> On Sun, Nov 23, 2003 at 09:36:06PM +0000, Glynn Clements wrote:
>>Markus Neteler wrote:
>>>Mhhh, time to fork the project? Maybe some developers would join you...
>>>(recalling the license discussion). I agree with you that more radical
>>>changes are needed, as already posted several times.
>>>Maybe LGPL'ed libraries with GPL'ed application layer? Well, most
>>>developers have posted their opinion on this already.
>>
>>It's not clear to me exactly what Thierry's complaints with the
>>current direction are, but they don't appear to be related to
>>GRASS' licensing policy.
>
> I think that Markus is looking forward: it's clear that by starting with
> the Public Domain code, the licence of the future work has to be
> decided. The licence impacts:
> - The availability of the source enhancements
> - The attractivity to developers
> - The possibility for developers, and primarily the GRASS developers to
> make a living with GRASS (that is to have time to work on it because
> they get incomes from it);

- The possibility for grass to be included in free software distributions.

AFAIK, BSD with the advertisement clause is not GPL compatible, and not
considered suitable for use in free software distributions (I may be
wrong but I think the original BSD does not comply with the Debian
requirements for free software).

I'am currently looking for a way how to make available my work I have done
on GRASS vectors, under some lincense, allowing to build proprietary
applications for GRASS. BSD with advertisement realy seems to be GPL incompatible
and problematic. The only reasonable license, I know about, is MIT/X.
I am not opposed to some restrictions like an obligation to publish
modified versions, but LGPL has too many unnecessary restrictions.

Do you intend to keep format compatibility with the current and future GRASS 5.0/5.7
versions, i.e. follow changes done by this team?

What are your other plans for development, new features etc.?

Do you have xgrass compiled?
I tried to compile xgrass now (first time) but without success.
(http://grass.itc.it/pipermail/grassuser/1997-June/000669.html)
(http://grass.itc.it/pipermail/grassuser/1998-July/001394.html)

It seems that the version in 5.0 is different from 4.3
(and 4.3 is maybe better).
Lesstiff (--enable-build-12) is probably better than Open Motif.

There are many inconsistencies between standard and _NO_PROTO
definitions and compilation with _NO_PROTO seems to be easier.
In any case, I cannot get over:

gcc -O -D_NO_PROTO -Wall -I../include -I/usr/X11R6/include/ -I/amd/ssi0/ssi/blazek/inst/lesstif/lesstif-0.93.91/include/Motif-1.2 -I/amd/ssi0/ssi/blazek/grass4.3src/src/include -DUSE_TERMIO -c grammar.c
In file included from /amd/ssi0/ssi/blazek/grass4.3src/src/include/std_incs.h:33,
from ../include/xgrass.h:7,
from grammar.y:6:
/usr/X11R6/include/X11/Intrinsic.h:73: parse error before numeric constant

Radim

Thierry_Laronde · November 28, 2003, 11:21am

On Thu, Nov 27, 2003 at 07:37:46PM +0100, Radim Blazek wrote:

I'am currently looking for a way how to make available my work I have done
on GRASS vectors, under some lincense, allowing to build proprietary
applications for GRASS. BSD with advertisement realy seems to be GPL incompatible
and problematic. The only reasonable license, I know about, is MIT/X.
I am not opposed to some restrictions like an obligation to publish
modified versions, but LGPL has too many unnecessary restrictions.

Do you intend to keep format compatibility with the current and future GRASS 5.0/5.7
versions, i.e. follow changes done by this team?

No decision taken at this moment. It could theorically be as simple as
an import module or, more involved, a compat library. But I will look at
this after. My "program" is the following (this answers some of your
questions):

1) Start from 4.1.5 (done)

2) Initial cleaning: remove all duplicates, back-ups, SAVE, support for
anything else than ps (paint), removing the main of the contributions
(userland stuff, licencing problems, non usefull stuff, etc...)
-> done

3) Fix the code (C99 and POSIX) and document the problems found
(function overheads (function just calling another function), automatic
variables not initialized (fixed but tagged))

[I have made only one "major" change: G_malloc and family have been
suppressed since they were duplicating malloc, calloc and realloc
and since the modules where G_allocating and allocating mixing
memory allocations from to separate tools which is a main source
of problem]

-> work in progress

4) Fix xgrass which doesn't compile due to various problems one (big)
being that the Motif version used is not the current one and that
changes have been made. But I have now the doc (O'Reilly has released
online the manuals).

===> First step: a GRASS, slimmed down, and compiling on any POSIX +X
+Motif compliant system with (gcc) -Wall and -Werror

5) Redefine the directory tree and the build system (BSD sources like)
extracting clearly what is architecture dependant and so on

===> Second step: this very same GRASS compiles and installs cleanly
from the new tree scheme.

TAG: first public release of (development name) YAG (Yet Another Grass
based GIS) under ??? licence.

And then begin to improve GRASS (DB management first priority to have a
usefull GIS). Then vector changes and so on.

The guidelines for me are:

0) Primitives not policies: YAG must provide a reliable framework for
custom application. It doesn't focus on the user level (only a small
well designed set of userland tools, no particular application), it does
focus on the system level;

1) Portability on the architecture level

2) Portability on the code level: C99 and POSIX

3) Portability of the results: use of a well documented text format for
importations and exportations for graphic and attributes (a TEXT format
for DB too)

4) Accuracy: the results shall be correct

5) Efficiency: the correct results shall be obtained with the minimum of
code, time and maintenance -> well documented code, primitives and not
policies, an orthogonal base of graphic primitives; a line debugger
allowing to inspect files and elements and allowing too scripting (for
v.digit/xdigit for example [this should allow too "undo" functions,
scripting of a user session, customization].

Note: the focus on _maintainance_ doesn't mean that the correct code
will be the smallest set of lines; it will be the smallest correct,
efficient and undestandable piece of code...

6) Scalability: YAG must be able to run on clusters
  -> All non strictly interactive tools MUST run in batch mode
  -> Client/server architecture
  -> Multithreading (not a priority, but must be thought about)

--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

H_B · December 1, 2003, 1:07pm

it's clear that by starting with the Public Domain code, the licence
of the future work has to be decided. The licence impacts:

...
...

- The possibility for developers, and primarily the GRASS developers
to make a living with GRASS (that is to have time to work on it
because they get incomes from it);

The third point discards GPL: if once you have made a work, everybody
can take it and do whatever one wants, a developer has no incitative
and no means to be paid for what it actually does.

I don't agree with that at all. My job is to run models, make maps,
analyze the resultant data, and present it. I expect this is the same
for most of the mapping consultants and other university people out
there who contribute to GRASS. The GIS is just a tool I use to get
things done as is Matlab, Linux, gcc, or even RS-232. I'm not paid to
work on GRASS, for me it just gets the job done better than
Arc/BrickWall does so I use it. When I find something I need to get my
job done that doesn't work or exist, I try and get it to work so I can
move on. Submitting any [clean] results to CVS is just easier than
maintaining a personal patch archive ;). I consider the GPL aspect as
bonus altruism, and a guarantee that things will slowly improve without
my help alone.. things of great value to me at the end of the day.

If one wants to make a GPL userland stuff, one has to be able to.

...of course

But if one wants (or simply needs) to make a userland stuff not GPLed,
one has to have the ability to do so.

You can do that now and use it internally. The GPL allows that. You just
have to provide your customer with the source changes & GPL notice.

seems to me like a lot of time that could be better spent fixing bugs &
reorganizing things for 5.7/6.0... but hey, if you want to or need to
use the ancient code, go for it. Just seems like a waste of your
talent to me.

regards,
Hamish