campbell@redsox.bsw.com (Larry Campbell) (07/08/89)
Until the pricing of cfront 2.0 was announced, we were seriously considering switching to C++ for all our development work. Now we can't, and I am really upset about it. There are two reasons we can't use g++. One is the copyleft. We can not and will not release source code to our products, yet if we use g++ to build our product, we'd be required to. The other, more important, reason we can't use g++ is also the reason we can't use Oregon's product, or Glockenspiel's, or anything other than cfront. It's because we work on, and port our code among, a wide variety of platforms. On VAXes, Suns, and 386es, there are C++ products available. But how about the Wang VS? How about HP MPE? How about Prime? DG? AS/400? All these systems have C compilers, and NONE of them have commercial C++ products (or g++ back ends) available. So cfront is our only alternative, and now it's priced out of our reach. Does anyone know how much the Modula-3 translator is going to cost? -- Larry Campbell The Boston Software Works, Inc. campbell@bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02146
schmidt@glacier.ics.uci.edu (Doug Schmidt) (07/08/89)
In article <799@redsox.bsw.com>, campbell@redsox (Larry Campbell) writes: >There are two reasons we can't use g++. One is the copyleft. We can not >and will not release source code to our products, yet if we use g++ to build >our product, we'd be required to. This is not entirely correct.... As with GCC, you can use the G++ *compiler* to compiler your code into binary, without having to release the source code. However, if you include the source or object code from the libg++ libraries (stream.h, Strings,h, etc.) with your product, then your work falls under the copyleft. Check out the InterViews distribution from Stanford (which supplies its own header files along with the G++ compiler) for one approach to this situation. InterViews applications compiled with their version of G++ and their InterViews header files don't fall under the copyleft. Doug -- Master Swordsman speak of humility; | schmidt@ics.uci.edu (ARPA) Philosophers speak of truth; | office: (714) 856-4034 Saints and wisemen speak of the Tao of no doubt; The moon, sun, and sea speaks for itself. -- Hiroshi Hamada
jima@hplsla.HP.COM (Jim Adcock) (07/11/89)
>This is not entirely correct.... As with GCC, you can use the G++ >*compiler* to compiler your code into binary, without having to >release the source code. However, if you include the source or object >code from the libg++ libraries (stream.h, Strings,h, etc.) with your >product, then your work falls under the copyleft. I've heard this before, but I've yet to see Stallman verify this in black and white terms. In any case, if one is doing commercial development on *anybodies* compiler one would be best served to review what one is doing with a competent software/copyright lawyer to make sure you're "dotting all you I's, and crossing all your T's." Witness recent major software lawsuits. It seems really unclear in software nowadays when a work is a derived work, and when it isn't. Better safe than sorry. Hate to have to get lawyers involved tho'..
bothner@decwrl.dec.com (Per Bothner) (07/11/89)
In article <6590190@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >>As with GCC, you can use the G++ *compiler* to compiler your code >>into binary, without having to release the source code. >I've heard this before, but I've yet to see Stallman verify this in black and >white terms. Stallman has verified this till (I assume) he is sick of it: Copyleft does not (and cannot) restrict the use of gcc (or emacs) as *tools*. That is, if you compile your program with gcc (or g++), it is still your program, as long as you only use "essential" run-time support, such as crt0, 32-bit multiplication on 16-bit machines, etc. However, if you link in libg++, Copyleft applies, and you must distrubute source to your entire application. The same will apply to the (unreleased) libgcc. There may be a fine line between these cases, but it should be a trivial exercise to stay on the paranoid side of the line. There are also various ways of circumventing Copyleft, but they make things slightly more inconvenient for your constomers. They also violate the spirit and moral intent of copyleft, but are perfectly legal. Note that NeXT uses gcc as their production compiler, releasing it as part of the system, and using it to compile their system. Jobs is a "software hoarder" who does not share RMS's ideals, and you may be sure their lawyers studied the ramifiactions is depth. (They also reportedly use one of the circumventions.) This is my personal analysis, having followed FSF for many years. -- --Per Bothner Western Software Lab, Digital Equipment, 100 Hamilton Ave, Palo Alto CA 94301 bothner@wsl.dec.com ...!decwrl!bothner
paul@dialogic.UUCP (Paul Bennett) (07/11/89)
In article <6590190@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >>release the source code. However, if you include the source or object >>code from the libg++ libraries (stream.h, Strings,h, etc.) with your >>product, then your work falls under the copyleft. > >I've heard this before, but I've yet to see Stallman verify this in black and >white terms. > Could someone from FSF give a definitive answer on this, please - or at least state their intent ... -- Paul Bennett, Dialogic Corp. VOX: (201) 866-4319 x 194 EMAIL: paul@dialogic.UUCP (..!uunet!dialogic!paul) SNAIL: Dialogic Corp, 129 Littleton Road, Parsippany, NJ 07054 "A quote, a quote - my kingdom for a quote ..."
grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (07/11/89)
It's been stated many times; compiler output is clean, using lib++ is not. What has not been stated is what will be done to protect libg++ and libc from abuse using one of several crafty tricks. I hope that people note that the high price of AT&T C++, coupled with the FSF copyleft has created a market for classes and libraries that can be distributed without compelling a complete source distribution. People with AT&T C++ compatible library products might wish to consider packaging those libraries to be compatible with G++ and selling them. This would erode a major market share for AT&T C++ and would probably make them drop the price quite a bit. Oregon Software? Glockenspiel? -- Dirk Grunwald -- Univ. of Illinois (grunwald@flute.cs.uiuc.edu)
jdchrist@watcgl.waterloo.edu (Dan Christensen) (07/11/89)
In article <1561@bacchus.dec.com> bothner@decwrl.dec.com (Per Bothner) writes: >Stallman has verified this till (I assume) he is sick of it: >Copyleft does not (and cannot) restrict the use of gcc (or emacs) as *tools*. >That is, if you compile your program with gcc (or g++), it is still >your program, as long as you only use "essential" run-time support, >such as crt0, 32-bit multiplication on 16-bit machines, etc. >However, if you link in libg++, Copyleft applies, and you must >distrubute source to your entire application. The same will >apply to the (unreleased) libgcc. Sorry if this is a stupid question, but I'm new to g++. When do you need to link in libg++? I am developing an application and am investigating using C++ as the language but am worried that if I use g++ I will have to distribute my source code. Thanks. ---- Dan Christensen, Computer Graphics Lab, jdchrist@watcgl.uwaterloo.ca University of Waterloo, Waterloo, Ont. jdchrist@watcgl.waterloo.edu
dricejb@drilex.UUCP (Craig Jackson drilex1) (07/12/89)
In article <1561@bacchus.dec.com> bothner@decwrl.dec.com (Per Bothner) writes: >In article <6590190@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >>>As with GCC, you can use the G++ *compiler* to compiler your code >>>into binary, without having to release the source code. >>I've heard this before, but I've yet to see Stallman verify this in black and >>white terms. > >Stallman has verified this till (I assume) he is sick of it: >Copyleft does not (and cannot) restrict the use of gcc (or emacs) as *tools*. >That is, if you compile your program with gcc (or g++), it is still >your program, as long as you only use "essential" run-time support, >such as crt0, 32-bit multiplication on 16-bit machines, etc. >However, if you link in libg++, Copyleft applies, and you must >distrubute source to your entire application. The same will >apply to the (unreleased) libgcc. I assume that this means that Bison cannot be used in conventional, "software hoarding" applications, until somebody re-invents the parser prototype and makes it truly "free"? >There may be a fine line between these cases, but it should be a >trivial exercise to stay on the paranoid side of the line. Paranoia comes in degrees; when many lawyers see something like copyleft, they blanch. Only the inoculated will look at it more closely. It's considerations like this which will continue to limit the utility of GNU stuff: it's all right for personal things, and even for tools, but as soon as you want to include libg*, or Bison prototypes, or something like that, you have to re-implement. The same thing goes for other software, such as network packet drivers, which get copylefted. That's fine, but if you want to make something a minor part of a major product (which you wish to "hoard"), your lawyers will probably prevent you from using it. ("Just in case") I've heard of lawyers not even wanting files to be edited with GNU Emacs, "just in case". -- Craig Jackson {bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
jima@hplsla.HP.COM (Jim Adcock) (07/13/89)
>What has not been stated is what will be done to protect libg++ and libc >from abuse using one of several crafty tricks. Gee, just what the computing world needs. Link in the wrong library and get a licensing virus in your program. Are standard libraries a part of C++ *the language* or not? Does a conforming C++ compiler have to provide streams? complex numbers? Standard C libraries? -- Kind of hard to do anything without these.
grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (07/13/89)
In article <6590194@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >What has not been stated is what will be done to protect libg++ and libc >from abuse using one of several crafty tricks. Gee, just what the computing world needs. Link in the wrong library and get a licensing virus in your program. not a virus, a legally defensible solution. A virus is simply clever, legal precedent is truely useful. -- Dirk Grunwald -- Univ. of Illinois (grunwald@flute.cs.uiuc.edu)
pat@wang.UUCP (Pat Knight) (07/13/89)
The general complaint about the copyleft applying to libg++ seems to be that you have to copyleft products linking the library. If you think about it, this is wanting to have your cake and eat it. libg++ is free, in the copyleft sense, and in the sense that you can obtain it for no or very low cost. As a developer, you've saved yourself the effort of developing all these neat classes because other people have donated them. That's exactly the way the copyleft is meant to work, in my understanding. Now you want to make money off these classes (as well as your application). Is it reasonable for you to profit from the efforts of others, without giving them anything? I think not. If you want to develop applications to hoard, develop a library to hoard. If you don't want everyone to have to develop a hoardable library, sell a g++ compatible library of your classes (not built from libg++) to other hoarders. Don't complain because FSF won't let you sell THEIR code. Pat Knight (obviously these aren't the opinions of my employer - they sell software)
rgr@cbnewsm.ATT.COM (robert.g.robillard) (07/13/89)
>>...if you compile your program with gcc ... it is still >>your program, However, if you link in libg++, Copyleft applies, and >>you must distrubute source >It's considerations like this which will continue to limit the utility >of GNU stuff: I think you're missing the point--the FSF doesn't want the GNU stuff to be of use to software hoarders. The whole copyleft was designed to make it impossible for the evil commercial software companies to use the stuff. Saying that this "limits the utility" of GNU is like saying that the fact that Boeing can't sell jet fighters to Libya limits the utility of the fighters. It may be true, but it's not a bug. -- | Duke Robillard | | Internet: rgr@m10ux.att.com | BITNET: rgr%m10ux.uucp@psuvax1 | | UUCP: {backbone!}att!m10ux!rgr | (maybe) |
jima@hplsla.HP.COM (Jim Adcock) (07/17/89)
> Gee, just what the computing world needs. Link in the wrong library and > get a licensing virus in your program. > >not a virus, a legally defensible solution. > >A virus is simply clever, legal precedent is truely useful. I don't consider this clever, nor useful, but rather destructive to society in general, and software writers in general. It is one thing to put legal restrictions on the use of one's product -- if you're honest and up front about those restrictions. It is a far worse thing to introduce hidden licensing restrictions into another's work. In the first case, one can see one made a mistake -- "oops, I linked in a forbidden library -- I meant to get that library from /usr/public_domain/CC, not /usr/copyleft/CC." In the second case -- when people are playing tricks to hide licensing restrictions in their code -- then one can never be sure one's code is in the clear -- because if you linked in the wrong library by mistake, that is never made clear to you. If there were some simple way of testing this -- like if one generated code based on restricted FSF stuff, and if doing so caused "FSF_copyleft_violated" to be defined in name space, then at least a user could always do a: nm mystuff | grep "FSF_copyleft_violated" or something, and make sure one has not accidentally linked in the forbidden fruits. As it now stands, people claim to be introducing hidden licensing restrictions in their code, so one can never be sure when this will come back to haunt you. Then other people get all paranoid about code that is offered "freely." So now, for example, when I offer code that I have written on this net, people write back and say: "What do I have to do to get it?", and I say: "just ask me for it" and they don't believe it. So people just keep rewriting the same code over and over again. How many copies of "streams" does the world need? How many copies of "complex" does the world need? How many copies of "matrix" does the world need? How many copies of "vector" does the world need? How many copies of "string" does the world need? How about all the .h files necessary to get C++ to talk to 15 year old C libraries? etc, etc, etc, etc. Can't we at least agree to make these base things *truly* public domain, and then get on with the more interesting work?