Re: Windows?

[Sergei Steshenko]

--- On Wed, 5/13/09, Francesco Potorti` <address@hidden> wrote:

> From: Francesco Potorti` <address@hidden>
> Subject: Re: Windows?
> To: "Sergei Steshenko" <address@hidden>
> Cc: "Qianqian Fang" <address@hidden>, "John W. Eaton" <address@hidden>, 
> "dmelliott" <address@hidden>, address@hidden
> Date: Wednesday, May 13, 2009, 7:49 AM
> >> >FOSS movement is known
> for consistently shooting itself in the foot.
> >> 
> >> While it does certainly makes sense to speak about
> "Free and Open
> >> Source Software" (FOSS) when dealing with licence
> issues, it does
> >> make a difference when speaking about aims and
> priorities.  If you
> >> speak about free software, then your priority is
> freedom.  If you
> >> speak about open source, then your priority is
> convenience.
> >> 
> >> I think that, while trying to interpret the GPL in
> the specific case
> >> at hand, the maintainers simply chose to err on
> the side of freedom
> >> rather than err on the side of convenience, at
> least until the legal
> >> issue can be assessed with more certitude.
> >> 
> >> At least, this is how I read it, sorry if I
> misunderstood.
> >
> >And could you please elaborate on freedom in this
> context in layman terms ?
> 
> The reason why GPL programs cannot be linked with non-free
> programs is
> to preserve freedom and diffuse it.  This aim is
> sometimes inconvenient.
> 
> To me, it looks like in this case it is not very clear
> whether and how
> the MSVC libraries can be linked with Octave: maybe it is
> possible,
> because the rules say that freedom is preserved to a
> satisfying extent,
> maybe it is not, because the rules say that freedom is not
> preserved
> enough.  Being on a boundary, the maintainers are
> trying to understand
> what is the correct position.  In the meantime, one
> can err on the side
> of freedom or else on the side of convenience, and they
> chose the first
> option.
> 
> Again, this is how I see it, but I myself was not involved
> in this
> decision in any way, so I may be wrong.
> 
> -- 
> Francesco Potortì (ricercatore)       
> Voice: +39 050 315 3058 (op.2111)
> ISTI - Area della ricerca CNR       
>   Fax:   +39 050 315 2040
> via G. Moruzzi 1, I-56124 Pisa     
>    Email: address@hidden
> (entrance 20, 1st floor, room C71) 
>    Web:   http://fly.isti.cnr.it/
> 

If I understand correctly, the MSVC library in question is not static, but
a DLL.

If it's the case, nothing prevents a GPL from being dynamically (i.e. at
runtime) linked. Look at all the proprietary SW running under Linux -
Oracle, SYNOPSYS, Cadence, etc.

Again, if I understand correctly, the question was about distributing in
the same tarball 'octave' and MSVC DLL which are _not_ statically linked
to each other.

This whole thing is getting ridiculous because there are whole DVD-size
media (SUSE, Mandriva) distributing free and non-free programs and 
libraries/programs in the same .iso file; the free and non-freeitems are 
also not statically linked.

So, the counter-example of SUSE/Mandriva, as well as already mentioned
'inkscape', sparked my genuine interest in the issue of freedom in the
light of consistent shooting itself in the foot.

Since it is possible/allowed to distribute instruction on how to get MSVC
DLLs, it is also possible to write code which implements these
instructions.

And someone will probably do it, spending his/her energy on nothing instead
of spending it to do really useful things. This an example of shooting
itself in the foot - spending time to please ideologists instead of
spending it on something useful.

I'm glad 'inkscape' developers were smart enough to stick to "don't ask,
don't tell" policy.

I am really disturbed by the fact GNU folks dare to interpret motivation
of SW developers dynamically/on the fly, essentially (IMO) changing the
rules during the game.

People want convenience, and they also want _not_ to be harassed; the
answers JWE got from GNU licensing engineer looks like effective
harassment.

Freedom is needed to avoid harassment, not to encourage it.


Regards,
  Sergei.