rms@ai.mit.edu (07/21/89)
A few weeks ago, I found out, along with the readers of this list, that NeXT was distributing proprietary code for the user to link with GCC. A while later, I told them this was not permitted and asked them to stop. Apparently, through a noisy communication channel with me, they had got the impression that I had said this was ok. They agreed to stop distributing the proprietary front-end, as I requested. They have written a new, free objective C front-end which will be released soon by them, and merged into the standard GNU C distribution when I have time.
grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (07/22/89)
Good news; will it: + be straight objective C + fall under the copyleft + be a native compiler or a translator? -- Dirk Grunwald -- Univ. of Illinois (grunwald@flute.cs.uiuc.edu)
dld@F.GP.CS.CMU.EDU (David Detlefs) (07/25/89)
Damn, my (I thought) carefully constructed understanding of what the copyleft does and does not allow is once again invalidated. I had thought that this kind of thing would be permitted, because: 1) The NeXT object code is not a derived work (unless the inclusion of GNU header files in it's source makes it one?) 2) If a user buys the NeXT object code and a makefile, what is to prevent him from executing that makefile? I can see that the user is not free to distribute the resulting program without distributing the source (including the NeXT source?), but why can't s/he use it? First, let me say that this is mostly a matter of intellectual curiosity with me; I'm not planning on trying to make money with such schemes.* If no one who's opinion really counts is willing to take the time to answer my questions, could someone point me to an archive for gnu.gcc, where I could reperuse RMS's comments on the copyleft to try to check where my understanding went awry? *I do happen to think that the world would become a better place in general if some way could be found for gnu compilers and libraries to be used by industry in the same way as gnu emacs can be. I think that the FSF's most effective strategy towards meeting it's political goals is to target specific pieces of system software, and produce a free portable version so good that it drives companies out of the business of making that tool. I think this is mostly working for editors, but not so for C compilers, mostly because of licensing fears that appear well-founded. *** But this belongs in the semi-promised gnu.politics. I for one would love to see such a group. I have my own views, but I would approach such a group with a sincere willingness to alter those views in the face of superior logic. -- Dave Detlefs Any correlation between my employer's opinion Carnegie-Mellon CS and my own is statistical rather than causal, dld@cs.cmu.edu except in those cases where I have helped to form my employer's opinion. (Null disclaimer.)
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (07/26/89)
In article <DLD.89Jul25124612@F.GP.CS.CMU.EDU> dld@F.GP.CS.CMU.EDU (David Detlefs) writes:
*** But this belongs in the semi-promised gnu.politics. I for one
would love to see such a group.
I just issued the newgroup for gnu.misc.discuss.jim@kaos.Stanford.EDU (Jim Helman) (07/27/89)
It's a fine line, but I don't see any reason for confusion. If the NeXT Objective C front end has to be linked with portions of GCC itself, it could reasonably be considered an extended version of GCC. Postings by FSFers have made it quite clear that this violates the spirit and letter of copyleft. One of their major goals has been to make improved versions (including source) widely available. The letting-the-user-do-the-link loophole allows the linking of unrelated code against a standard library such as libg++. To quote RMS (7-Jun-89) gnu.gcc: If these libraries are standard, then it would be hard to argue that the developer is doing anything which intrinsically relates to the GNU libraries in question. He might not even know whether users choose to link with GNU libraries or other libraries. So this must be permitted. The routines making up GCC are clearly not standard library routines. Jim Helman Department of Applied Physics P.O. Box 10494 Stanford University Stanford, CA 94309 (jim@thrush.stanford.edu) (415) 723-4940