Slashdot Mirror
FSF, GCC, and SCO Compiler Support
Ancipital was one of several who noted that a
special patch is going into GCC. The file is README.SCO, and it is a short writeup about the SCO situation written by the FSF. It stops short of demanding that GCC developers strip SCO support from the compiler, and says more will be announced before the next compiler release.
shameless karma plug for the coward:
The FSF has asked me to check in this file on both the branch and the
mainline.
Please direct any questions or comments to the FSF.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
2003-08-03 Mark Mitchell
* README.SCO: New file.
===
As all users of GCC will know, SCO has recently made claims concerning
alleged copyright infringement by recent versions of the operating
system kernel called Linux. SCO has made irresponsible public
statements about this supposed copyright infringement without
releasing any evidence of the infringement, and has demanded that
users of Linux, the kernel most often used with the GNU system, pay
for a license. This license is incompatible with the GPL, and in the
opinion of the Free Software Foundation such a demand unquestionably
violates the GNU General Public License under which the kernel is
distributed.
We have been urged to drop support for SCO Unix from this release of
GCC, as a protest against this irresponsible aggression against free
software and GNU/Linux. However, the direct effect of this action
would fall on users of GCC rather than on SCO. For the moment, we
have decided not to take that action. The Free Software Foundation's
overriding goal is to protect the freedom of the free software
community, including developers and users, but we also want to serve
users. Protecting the community from an attack sometimes requires
steps that will inconvenience some in the community. Such a step is
not yet necessary, in our view, but we cannot indefinitely continue to
ignore the aggression against our community taken by a party that has
long profited from the commercial distribution of our programs. We
urge users of SCO Unix to make clear to SCO their disapproval of the
company's aggression against the free software community. We will
have a further announcement concerning continuing support of SCO Unix
by GCC before our next release.
- 5. No Discrimination Against Persons or Groups
- 6. No Discrimination Against Fields of Endeavor
Does this mean the FSF is no longer open source compatible? For the knee-jerkers out there, this is not a troll, it is a serious question. The issue is that Free software should be free, warts and all. Unintended consequences aside, you can't just remove the right to use GCC of any organisation that uses SCO software, it's not right....The license must not discriminate against any person or group of persons.
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
People who think they know everything are a great annoyance to those of us who do.
If you had RTF message, you would have seen that the FSF used the exact same argument to NOT break GCC on SCO Unix.
this README dosnt say to strip support at all.. it just says its been urged.. and as such the README states this will only effect the end users not SCO..
moo
gcc is still Open Source. They would not be placing any additional restrictions on the use of gcc, so anybody could create a patch for gcc to make it work again. They would simply be choosing to remove support for SCO Unix from the mainline gcc source, so it would no longer work "out of the box". Besides, they havent actually removed support yet, though they have hinted they may do in the future if SCO continues its behaviour.
were you expecting to see a sig here? perhaps you'd rather see the inside of an ambulance!
did the submitter even read the README?? it says no such thing, and i quote:
You should look at this bug which was filed, PR11842.
People calm down, this is not really big news as FSF has done this before with Apple and other people so this should have not come as a big surprise.
The FSF used to boycott Apple in exactly the same way they have now decided not to boycott SCO, namely by removing (or refusing to add) explicit support for Apple configurations from their software.
The Apple boycott was motivated by Apple's "look and feel" lawsuit against HP. If look and feel was copyrightable, the GNU projeect itself was threatened since GNU very much look and feel like Unix.
Evcantually, the FSF dropped the boycott with the reason that it was not effective, the Apple management didn't care if they even knew about it.
I believe the same reason will apply to SCO, their management no longer have any interest in their own products, they are solely a litigation company these days.
I consider boycotts a legitime weapon, despite that it also hits innocents. Nobody have a moral obbligation to buy or support anything. However, such weapons should only be used when they are effective.
If you look at GCC's MAINTAINERS file you will see that SCO's Kean Johnston is the OS port maintainer for SCO's platforms. If you search through gcc-patches, you will see that he still is actively contributing, using his @sco.com address. So they seem to allow this to happen.
If you get rid of GCC on SCO, then you get rid of a cross platform migration utility.
:).
Oh, and I'm forced to use SCO at work because of a ton of legacy code and proprietary applications that SA refuses to port. We hate it, but what are you going to do? The cogs grind slowly
In my spare time I've introduced quite a few people and companies to Linux often using free setup and consultation to get them to use Linux. I'm currently helping a SCO reseller to move to a Linux based business.
So I am one of those clueless people ultrabot is complaining about.
Dyslexics Untie!
Quick, how many FSF programs run on pre-OS-10 MacOS? Think about how long it would take to implement a Cygwin-like Unix compatibility layer for the Mac before you answer that question.
Such a compatibility layer has existed for a number of years- you can even run X11 apps. It is called MachTen. With it, one can run almost any FSF program, although I'm sure there are some which need a bit of fixing- be it Makefile tweakage or something a little more.
Other than that, a handful of FSF programs have been ported to Mac OS. Most hadn't been needed, considering the fact that Mac OS classic had a wealth of decent applications for it covering the same functionality, although with a different interface. There is functionality on either side with no equivalent, that goes without saying.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
I'd never suggest that they do this. Just dropping support (without making special changes to do so) would be good enough.
What do you mean exactly?
The phrase "gcc drops support for SCO" means making specific changes to the GCC code such that gcc would not compile out of the box for the SCO platform. And, when it did compile, it wouldn't take advantage of SCO-specific features or optimize around SCO-specific quirks. In short, GCC would no run.
How else would they achieve this? GCC isn't a big software company- "support" doesn't mean "you buy our software an a service contract, and you can ask us technical questions and get us to do fixes for you." Support means "works on that platform." Are you proposing that the GCC folks just remove the lines stating that GCC works on various SCO-owned operating systems from a README somewhere? What would that accomplish? It's not like it would scare SCO users out of using it, if they knew that it'd continue to work just like it used to...
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
That is becuase it was brought to my attention that someone had posted about me and my involement with GCC. Today was the very first time I have ever read slashdot, and outside of this thread, most probably the last. I have a hard enough time keeping up with regular mail without being sidetracked here.
Kean