nate@hobbes.intel.com (Nate Hess) (08/22/89)
In article <1311000001@upba>, damon@upba writes: [Someone who damon didn't mention writes:] >> I hope this alpha testing finishes soon, and the freed MACH kernel can >> be shipped to FSF and the world! >I hope they finish soon also. A freely distributable kernel is a much >desired thing. However, I am wondering about what restrictions FSF will >place on it. I can just see the ideologues puting a copyleft on it >requiring any program run on the OS to be freely distributable. I sincerely doubt that the FSF will do this; in fact, I don't think they would be able to do it, just like they can't require that all files edited with GNU Emacs be under the terms of the copyleft. --woodstock -- "What I like is when you're looking and thinking and looking and thinking...and suddenly you wake up." - Hobbes woodstock@hobbes.intel.com ...!{decwrl|hplabs!oliveb}!intelca!mipos3!nate
pardo@uw-june.cs.washington.edu (David Keppel) (08/23/89)
In article <1311000001@upba> damon@upba.UUCP writes: >[I hope that CMU finishes alpha test of the freely-distributable Mach > kernel soon. I am wondering about the restrictions FSF will place > on such a kernel. I can see a copyleft that requires any program > run on this kernel to be freely distributable. This is the problem > with gcc.] GNU will require that ``their'' version of the Mach kernel be freely distributable. They will not require all programs run on it to be freely distributable, because the programs will not be derived from the GNU Mach kernel. The `problem' with gcc is often misunderstood. A program compiled with gcc is not considered to be a ``derived'' work, and therefore is not subject to the copyleft. A program that uses part of gcc (for example is linked with the compiler) *is* derived from gcc and IF it is distributed at all, it must be freely distributable. A program that is distributed *linked* with the GNU runtime libraries must be freely distributable. If the program is distributed unlinked, then the user can linke with *any* standard libraries, and the program is not derived. Whew, I hope that was clear! Followups to gnu.misc.discuss. ;-D on ( To the appropriate GNUs group ) Pardo -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
baud@eedsp.gatech.edu (Kurt Baudendistel) (08/23/89)
In article <9056@uw-june.cs.washington.edu> pardo@june.cs.washington.edu (David Keppel) writes: >... A program that uses part of gcc (for >example is linked with the compiler) *is* derived from gcc and IF it >is distributed at all, it must be freely distributable. A program >that is distributed *linked* with the GNU runtime libraries must be >freely distributable. Please define ``freely'' as used in this paragraph. -- Kurt Baudendistel --- GRA Georgia Tech, School of Electrical Engineering, Atlanta, GA 30332 internet: baud@eedsp.gatech.edu uucp: gatech!gt-eedsp!baud
jbw@eyebeam.UUCP (Jeremy B. Wohlblatt) (08/23/89)
nate@hobbes.intel.com (Nate Hess) writes: >In article <1311000001@upba>, damon@upba writes: >>I hope they finish soon also. A freely distributable kernel is a much >>desired thing. However, I am wondering about what restrictions FSF will >>place on it. I can just see the ideologues puting a copyleft on it >>requiring any program run on the OS to be freely distributable. >I sincerely doubt that the FSF will do this; in fact, I don't think they >would be able to do it, just like they can't require that all files >edited with GNU Emacs be under the terms of the copyleft. i think f.s.f. legally could do this. those who sell binaries often prevent you from disassembling; there are many restrictions on use that the owner could place on a product when distributing it, and even restricting use of documents edited with gnuemacs would probably be legal. it would, however, be manifestly stupid to do so. very few people outside outside f.s.f. and academia would use a product that has virtually no role in a commercial environment. -- jeremy these opinions might not be those of my employer. they might not even be mine. jeremy b. wohlblatt: samsung software america, inc. uucp: {decvax!{gsg,cg-atla},uunet,ulowell}!ginosko!jbw internet: jbw@ginosko.samsung.com
pardo@uw-june.cs.washington.edu (David Keppel) (08/23/89)
>pardo@june.cs.washington.edu (David Keppel) writes: >>... A program that uses part of gcc (for >>example is linked with the compiler) *is* derived from gcc and IF it >>is distributed at all, it must be freely distributable. baud@eedsp.UUCP (Kurt Baudendistel) writes: >Please define ``freely'' as used in this paragraph. In the FSF sense of `freely'. That is, IF you distribute a `thingy' that is or needs to be linked e.g., with gcc, then you must agree to provide all recipients with sources for a `reasonable' copying fee. You must also agree to let all recipients of the sources give away those sources. Case in point: NeXT created an Objective-C compiler that links with GNU CC. They were distributing .o files that the user linked with `gcc' .o files. FSF said ``under the copyleft, you must either not distribute your Objective-C compiler, or you must agree to provide sources for a nominal copying charege.'' NeXT will be giving their Objective-C compiler to the FSF, to be incorporated in future releases of `gcc', much like `g++'. Note that LINKING something with `gcc' is different from compiling something with `gcc'. If you COMPILE something with `gcc', the result is not considered a derived work. You can do with it what you will. (a) I hope this is clear. (b) I represent neither the FSF or the lawyer's guild. ;-D on ( Or the liawyer's guild ) Pardo -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
jeff@aiai.uucp (Jeff Dalton) (08/24/89)
In article <1311000001@upba>, damon@upba writes: >I hope they finish soon also. A freely distributable kernel is a much >desired thing. However, I am wondering about what restrictions FSF will >place on it. I can just see the ideologues puting a copyleft on it >requiring any program run on the OS to be freely distributable. Of course, they will copyright their changes. But everyone will still be able to take the original instead. I don't want another GNU flame war, but I must point out that the restrictions imposed by the GNU copyright are for many purposes less severe than those imposed by companies who take CMU code and make commercial products out of it.
drake@ibmarc.uucp (Sam Drake) (08/24/89)
At the Denver C++ conference someone (presumably the author) gave a presentation on the G++ class library. He did a good job of getting the audience all excited about the functions in the library, but then burst the bubble by pointing out that since the library came under the copy-left, any programs that used the library would also have to come under the copy-left's provisions. As I recall, the author seemed dismayed at this implication of the license. Is that still the case? In this case, there IS no other library that could be linked in, and so shipping the application un-linked doesn't work. just curious, Sam Drake / IBM Almaden Research Center
mellon@zayante.pa.dec.com (Ted Lemon) (08/26/89)
Michael DeCorte sez, >The result is that I can BUY a version of TeX that will have support. >I can not do that with Gnu Emacs. Nobody can sell it and things tend >to get done fairly slowly if ever. Yes, you can. The difference is that the company that's supporting Emacs for you must give you the source code. This means that if you aren't satisfied with their support, you can fix it yourself. The GNU Public license doesn't forbid you to sell GNU Emacs for whatever price you want. It just forbids you to distribute the binary executable without also making the source available, and it forbids you to restrict the way those to whom you distribute the software may redistribute it. Also, as I and others have pointed out, there's no reason why GNU should be the sole distributor of Mach. If you want to hoard your changes, just use the CMU version of Mach. And if nobody buys your version of Mach because the GNU version is better, than the FSF's point is proven. If everybody flocks to buy your version, you can consider yourself the winner. I've redirected followups to gnu.misc.discuss. I don't think there's any reason to continue this discussion in comp.os.mach, since it seems to be degenerating into a ``Copyleft isn't fair'' vs ``Copyleft is god'' jihad. _MelloN_
scs@itivax.iti.org (Steve Simmons) (08/26/89)
mellon@zayante.pa.dec.com (Ted Lemon) writes: >Michael DeCorte sez, >>The result is that I can BUY a version of TeX that will have support. >>I can not do that with Gnu Emacs. Nobody can sell it and things tend >>to get done fairly slowly if ever. >Yes, you can. The difference is that the company that's supporting >Emacs for you must give you the source code. This means that if you >aren't satisfied with their support, you can fix it yourself. I think you're confusing 'can' (are permitted to) with 'can' (here's where you get it). Yes, there is no provision that forbids one from selling a support GNU emacs per se. I can (have a source for) TeX with a support contract, preprinted manuals, and a precompiled pre- configured easy-to-install (well...) binary. Is there such a place for GNU emacs? -- Steve Simmons scs@vax3.iti.org Industrial Technology Institute Ann Arbor, MI. "Velveeta -- the Spam of Cheeses!" -- Uncle Bonsai
mrd@sun.soe.clarkson.edu (Michael DeCorte) (08/26/89)
>it forbids you to restrict the way those to whom you distribute the >software may redistribute it. Which means that my changes have fallen under that FSF licencing agreement and anybody can sell or give away my changes. The end result I won't ever make anything other than trival changes to anything owned by FSF because to make a non trival change I would have to quit my job but because I won't be able to make any money off of my changes I won't be able to pay my bills. For your information: I have written software that is freely distributable but I use the licencing agreement used by TeX and I will NEVER let it fall under FSF's licencing. -- Michael DeCorte // H215-546-0497 W386-8164 Fax386-8252 // mrd@clutx.bitnet 2300 Naudain St. "H", Phil, PA 19146 // mrd@sun.soe.clarkson.edu --------------------------------------------------------------------------- Clarkson Archive Server // commands = help, index, send, path archive-server@sun.soe.clarkson.edu archive-server%sun.soe.clarkson.edu@omnigate.bitnet dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server ---------------------------------------------------------------------------
nate@hobbes.intel.com (Nate Hess) (08/28/89)
This has gotten a tad far-afield from taking about MACH, and so I've redirected followups to gnu.misc.discuss In article <MRD.89Aug25170616@sun.clarkson.edu>, mrd@sun (Michael DeCorte) writes: [Talking about MACH.] >I hope that Gnu doesn't get hold of it. I have a problem with the Gnu >licence basically it says that if I make changes to their program >those changes become theirs. This is simply not true. You can take programs that the FSF has written and distributes, hack them to your heart's content, and never tell another soul that you've done so. You certainly are under no obligation to inform the FSF of any changes or additions you make to any of their programs. >If I spend a year and port Gnu emacs to >the mac making a really cool port those changes are the preoperty of >FSF and I can't sell this version of Emacs. The result is that I >won't ever so anything with anything of FSF. I have written programs >that are freely distributable but I will never give them to FSF for >these very reasons. You can sell a modified version of GNU Emacs at whatever price you want to whomever you want. You are simply required to also supply source code to the version that you're selling. And, you can't tell the people you sell it to that they can't do whatever they want with it. The FSF massively encourages the sharing of software. You seem to desire the same thing, and yet you find the FSF's policies distasteful. I don't understand your position. >I prefer the licencing of TeX much more. It basically says that TeX >belongs to Knuth but if you make changes to TeX those changes are >yours and you can do with them as you please (including selling them). >The result is that I can BUY a version of TeX that will have support. >I can not do that with Gnu Emacs. Nobody can sell it and things tend >to get done fairly slowly if ever. Once again, you are wrong. There are companies that have added to and/or changed GNU Emacs, and are now selling their version of it, along with support. In addition, I know there are many consultants who would be willing to provide support for GNU programs. I find your impression of "things tending to get done fairly slowly if ever" rather puzzling; GNU Emacs is added to by thousands around the world. I've seen more new and useful changes for Emacs being posted to the net every six months than I've seen out of nearly any commerical product in years. Necessity is indeed the mother of new Emacs code. --woodstock -- "What I like is when you're looking and thinking and looking and thinking...and suddenly you wake up." - Hobbes woodstock@hobbes.intel.com ...!{decwrl|hplabs!oliveb}!intelca!mipos3!nate
steve@nuchat.UUCP (Steve Nuchia) (08/29/89)
In article <3072@itivax.iti.org> scs@itivax.iti.org (Steve Simmons) writes: >selling a support GNU emacs per se. I can (have a source for) TeX >with a support contract, preprinted manuals, and a precompiled pre- >configured easy-to-install (well...) binary. Is there such a place >for GNU emacs? Well, yes, I'll sell a support contract for anything I can get the source to freely. I'm a bit mystified as to how I should price these contracts though. I'm leaning towards a subscription covering everything, to keep the bookkeeping down. How much would you pay for support for GNU emacs? For a suite of ~100 packages of various sizes? Are you authorized to spend the money, or are you talking through your hat? I've got the library, I've got the staff, I've been supporting this stuff for my employers and consulting clients for years. All I need now is a couple of serious sales so I can switch the emphasis from consulting to support contracts. Takers? This isn't supposed to be an ad by the way; I really would like to hear feedback on this from any and all, but particularly from anybody in a position to actually buy such a service. -- Steve Nuchia South Coast Computing Services uunet!nuchat!steve POB 890952 Houston, Texas 77289 (713) 964 2462 Consultation & Systems, Support for PD Software.