[GRASS-dev] GRASS inefficiency and FFTW

stefano de paoli dplsfn at yahoo.it
Tue Feb 27 16:24:27 EST 2007


Hi Daniel,

it is a very interesting this discussion.

I wish I'm not wasting your time :-)


--- Daniel Calvelo <dca.gis at gmail.com> ha scritto:

> On 2/27/07, stefano de paoli <dplsfn at yahoo.it>
> wrote:
> [...]
> > Many humanistic studies on licensing simply
> neglect
> > that developers have to solve problems because of
> > licenses. Free Software is usually thought in an
> > idealistic way,probably due to Eric Raymond idea
> of
> > Bazaar.
> 
> I'd say that most *developers* think of Free
> Software much more from a
> Stallmanian point of view. 


I'm not sure about that. Probably many *developers*
but not most.
There have been important counterexamples also in
GRASS (e.g. vector lib discussion).


> 
> > Probably my mistake is to think that this solution
> is
> > necessarily related to the "freedom" of software.
> > While many GRASS developers have pointed out that
> > other issue are far more important, such as the
> amount
> > of developer effort required to make the change .
> 
> You could frame that considering freedom as ultimate
> goal, constrained
> by resources availability. The freedom-as-goal would
> entail both the
> individual freedoms (explicit and prominent in the
> GPL and much of
> FSFs discourse) and the social freedom (more
> explicit in the Creative
> Commons or Open Access discourses).


Yes, I share the idea that "freedom" is the result. 
My point is that free software is the results of the
process and not the starting point.
But I take a different approach, I cannot consider
freedoms as goals. 

My basic idea is that there is no freedom as such. 
You can only account for the process of "freedom",
which also makes "freedom" debatable. 

For example in the v.in.dwg discussion what is
freedoms-as-goal was questioned. The following passage
is from that discussion:

> Open DWG license gives more freedom to distribute 
> v.in.dwg for free than GPL.


If I take freedom-as-goal then I must face the issue
that some developers have a different concepts of
freedom both individual and social.

But if I take the process as the standing point I can
observe something different: which version of freedom
is the winner in the v.in.dwg case. 
In other words I observe that the matters of
discussion is not freedom as such but instead whether
it is possible or not to distribure v.in.dwg with
GRASS.

It makes sense for me to say that freedom has more to
do with  linking at compilation time of libraries and
modules, than with freedom as an ultimate goal of
"humanity".

In other words there is no free software without the
GRASS controversies on v.in.dwg, Numerical Recipes,
LZW , the old copyright.txt and so on.


My observations of GRASS tell me that
every single technical particular account for the
freedom as a process.
That's why I was interested in the FFT issue. I
figured out that "freedom" had to do with the data
strucutures of the e.g. i.fft() Vs FFTW.

 
> GPL is an operational device that bridges both, in
> the best
> tocquevilian perspective, using individual licensing
> decisions to
> orient a whole corpus of knowledge embodied in code
> to become
> non-alienable patrimony.


I support this idea of GPL as an operational devices,
but the GPL doesn't say nothing about Tocqueville
:-)).

It is true that the GPL speaks about how the knowledge
becomes a non-alienable patrimony. As an operational
devices the GPL imposes is own weltanschaaung, but not
without introducing technical problems or conflicts:
removing for example LZW or NR from GRASS, the long
conflict/discussion about the vector lib and so on.

I also think that the fact that GRASS is GPL, is due
to a series of contingencies. The story might have
gone in a different direction. Baylor had probably a
different plan for GRASS copyright. What if Baylor was
able to impose his plan?

thank you

Stefano



	

	
		
___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html




More information about the grass-dev mailing list