Suggestion: remove s/sco[45].h etc.

Suggestion: remove s/sco[45].h etc.

[Kim F. Storm]

Considering recent events, I don't see any point in actively supporting
any of the SCO "owned" systems.

I suggest that we remove the corresponding support files, that is
s/sco4.h and s/sco5.h, as well as other s/*.h files for other
sysV / usg derivates created or owned by SCO.

WDYT?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestion: remove s/sco[45].h etc.

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Considering recent events, I don't see any point in actively
> supporting any of the SCO "owned" systems.
> 
> I suggest that we remove the corresponding support files, that is
> s/sco4.h and s/sco5.h, as well as other s/*.h files for other sysV /
> usg derivates created or owned by SCO.
> 
> WDYT?

It is one thing to actively support a system.  It is another to
actively sabotage any effort of people depending on that kind of
system to use free software.

It is my recommendation to free software maintainers not to spend any
effort of their own on supporting proprietary systems such as SCO
Unix variants.

But if people go to all the effort of providing all the work for
supporting a platform, I don't see the point in denying them access to
free software just because they are using (and perhaps compelledly so)
some unrelated proprietary software.

Please note also that Microsoft Windows is supported as an operating
platform for Emacs, and Microsoft certainly has been spreading as much
false information about free software as the current SCO-initiated
misinformation campaign is.

The way to spread freedom is not by denying it to people having to
live under restraints already.

Emacs use is contagious, anyway:  Emacs users on proprietary systems
basically fall into the two categories

a) works with free software whenever he can, is forced to work on
proprietary platforms at some time.
b) is getting infected with Emacs, will eventually migrate to a
platform where Emacs runs best, namely some GNU system.

People of category a) are often inspiring people to try out b).

So in short: I don't think it reasonable to block one of the
most compelling migration paths to free systems, for the sake of some
petty revenge thinking.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Suggestion: remove s/sco[45].h etc.

[Ted Lemon]

On Nov 20, 2003, at 5:26 PM, Kim F. Storm wrote:
> I suggest that we remove the corresponding support files, that is
> s/sco4.h and s/sco5.h, as well as other s/*.h files for other
> sysV / usg derivates created or owned by SCO.

I'm highly sympathetic, but don't think this is actually a good idea.   
There's a distinction between users and providers.   SCO users right 
now are in a bad situation - it's likely that SCO is going to go under 
and leave them high and dry.   They didn't start this lawsuit, and 
frankly I suspect a lot of them wish it had never happened, but their 
businesses depend on software they bought from SCO before the lawsuit 
started.   This would just make things worse for them, without 
materially affecting SCO itself.   The whole point of the GPL is to 
promote software freedom, and it seems to me that this sends the wrong 
message to SCO users - "go away."   We want them to come to us, not go 
away.   There's a decent chance that if we don't strive to prevent it, 
a lot of them are going to switch to GNU/Linux in the near future.

Given the present lawsuit against IBM, if SCO builds a copy of emacs 
either for their own use or for distribution, they are violating the 
copyright - they are not abiding by the terms of the GPL, so they have 
no right to make copies of GPL software.   So in fact, the people who 
this change would target aren't even legally permitted to use the 
software to which the change is being made.

So unless it would strengthen the FSF's legal position with respect to 
SCO to take these includes out, I think it would be a bad strategy.

Re: Suggestion: remove s/sco[45].h etc.

[Eric Hanchrow]

I agree with Kastrup and Lemon -- if SCO is worse than other
developers of proprietary systems, it is only in degree, not in kind,
and Emacs already supports lots of non-free systems.  I doubt that
denying SCO customers the latest Emacs will further the cause of
software freedom.
-- 
People studying literature rarely say anything that would be of the
slightest use to those producing it.
        -- Paul Graham

Re: Suggestion: remove s/sco[45].h etc.

[Kim F. Storm]

Eric Hanchrow <offby1@blarg.net> writes:

> I agree with Kastrup and Lemon -- if SCO is worse than other
> developers of proprietary systems, it is only in degree, not in kind,

I don't think any of the other developers have gone as far as
questioned the legality of the GPL -- even claiming it to be
non-constitutional.

I agree that M$ is trying its best to bad-mouth the free and open
software movements.  However, (except for the recent "dontation" to
SCO) I don't think they have gone as far as SCO.

> and Emacs already supports lots of non-free systems.  I doubt that
> denying SCO customers the latest Emacs will further the cause of
> software freedom.

I agree, it is a concern that my proposed move isn't friendly to SCO
users, nor does it promote the use of free software on SCO platforms.

The reason for my question is that there have been recent bug reports
(admittedly with fixes) for SCO-specific problems.

Personally, I don't want to spend any time on fixing such problems,
but others may feel differently.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestion: remove s/sco[45].h etc.

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Eric Hanchrow <offby1@blarg.net> writes:
> 
> > I agree with Kastrup and Lemon -- if SCO is worse than other
> > developers of proprietary systems, it is only in degree, not in
> > kind,
> 
> I don't think any of the other developers have gone as far as
> questioned the legality of the GPL -- even claiming it to be
> non-constitutional.

Oh come on.  Microsoft has called it against the values of the
American constitution or society or some stuff like that.
Repeatedly.  And I can't count the number of times communism has been
brought up by them.

They might not have gone all the way that the current suicide mission
of SCO permits: those at the helm can't lose: all their hype and talk
is putting them into the headlines and thus is driving the stock
market value up artificially and the key players will have sold out
long before the company crashes.

> I agree that M$ is trying its best to bad-mouth the free and open
> software movements.  However, (except for the recent "dontation" to
> SCO) I don't think they have gone as far as SCO.

Well, they are not on a Kamikaze spree, that's all.

> > and Emacs already supports lots of non-free systems.  I doubt that
> > denying SCO customers the latest Emacs will further the cause of
> > software freedom.
> 
> I agree, it is a concern that my proposed move isn't friendly to SCO
> users, nor does it promote the use of free software on SCO
> platforms.
> 
> The reason for my question is that there have been recent bug
> reports (admittedly with fixes) for SCO-specific problems.
> 
> Personally, I don't want to spend any time on fixing such problems,
> but others may feel differently.

It is fine with me if you don't feel like spending any time to fix
such problems.  In fact, I would not either.  But you were proposing
instead spending time on sabotaging the usability of Emacs on SCO
platforms completely.  And I object to that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Suggestion: remove s/sco[45].h etc.

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> It is fine with me if you don't feel like spending any time to fix
> such problems.  In fact, I would not either.  But you were proposing
> instead spending time on sabotaging the usability of Emacs on SCO
> platforms completely.  And I object to that.

Not completely!  Emacs 21.3 would still be an option...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Suggestion: remove s/sco[45].h etc.

[Richard Stallman]

    I suggest that we remove the corresponding support files, that is
    s/sco4.h and s/sco5.h, as well as other s/*.h files for other
    sysV / usg derivates created or owned by SCO.

    WDYT?

In the FSF we thought about this issue a few months ago, in connection
with another package (perhaps it was GCC), and decided that we would
gain nothing by desupporting these systems.  It would not help us, and
would not put any useful pressure on SCO.  So we decided to keep
supporting them.