Re: Running Octave from Fink?

On 11/10/12 11:26 AM, Richard Stallman wrote:
>     This discussion started with Gnu Octave. Octave is an interpreter, so there
>     are no downstream products. In what way can Apple's shenanigans on OS X
>     create issues for users here? They are executing their code on the same
>     non-free machine it was compiled on, and they have already agreed to said
>     non-free environment.
> 
> We cannot allow people to add nonfree code to GPL-covered programs.
> If that were allowed, people could release nonfree code to extend
> GPL-covered programs, which is tantamount to making nonfree extended
> versions of them.
> 
> I designed the system library exception carefully to avoid opening up
> that danger.
> 
> That the code runs on a nonfree platform is no excuse for respecting
> the users' freedom less.  The system library exception is meant to
> cover the code that belongs to the system itself.  If we allowed
> anything more, could we distinguish it from an arbitrary proprietary
> add-on?
> 
> I have not finished reading all the mail you've sent, because it is
> too much!  So I don't know how these points apply to the current
> situation, and I don't have any conclusion to state about this case.
> 

Executive summary:

1) The Xcode development tools package, whatever you think of its
license, installs compiler executables, since none come with the OS,
other executables useful to developers which don't come with the OS, and
headers.
(I _did_ find some libraries, but they are specifically for svn, which
comes with Xcode rather than being part of the OS.  We aren't talking
about Octave linking to those--which would indeed be a problem)

2) The proprietary libraries that are linked by one of the OS X source
packaging tools ship as part of the OS, and are installed by default.
They're standard components.  No additional proprietary runtime
component is required.  And we always strive to make sure that packages
are compliant with the various licenses we work with, even when the
upstream developers seem not to get it:  for example, gnuplot is
manifestly not GPL-compatible, yet its build defaults to using GNU
readline if present, so I explicitly make it avoid using GNU readline as
distributed in Fink.

3) All of the various distributions discussed--Fink, Homebrew, and
Macports--are source-based.  In fact, for Fink on OS 10.6 and later,
users only start with Xcode and source scripts, and there is _no_ binary
component.  And we make them install Xcode because they need _something_
to start with to build packages.
3A) Nobody seems to know of a fully libre self-consistent build toolset
for current OS X, so we're not insisting on Xcode to be (unpaid) Apple
shills.
3B) If such a toolset did in fact exist, even if the Fink Project didn't
switch to use it because we build a wide range of packages, including
some that require access to Apple's proprietary libraries and therefore
need Xcode to build, our code and package build prescriptions are free
for anybody to examine, make a fork from, make change requests upon, etc...

So basically, we're trying to do as right by everybody as circumstances
permit.  Barring somebody presenting us with a build tool solution that
will do the job, we're left with only the Xcode option.
--
Alexander Hansen, Ph.D.
Fink User Liaison
My package updates: http://finkakh.wordpress.com/

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
fink-core mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.core
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-core