de5@STC06.CTD.ORNL.GOV (SILL D E) (08/14/90)
In article <WS35XWE@ficc.ferranti.com> peter@ficc.ferranti.com writes: >In article <1990Aug10.035033.2122@murdoch.acc.Virginia.EDU> gsh7w@astsun.astro.Virginia.EDU (Greg S. Hennessy) writes: >> # There are people out there who have taken >> #free code I have written and put it into commercial programs. I'm proud of >> #them as well... for taking a program and putting the time and effort needed >> #to make it part of a real product. If I'd have used the GNU copyleft, they >> #wouldn't have been able to do that. > >> I would call the Next a "real" product, and they use GNU. > >They use separate, individual GNU programs. That's a small subset of the >possible ways someone can use my code. They can use it as a library routine, >for example (in fact, that's how they're using it). With GNU code if you >can't somehow package it into a separate executable you lose. That's an acknowledged flaw in the GNU Public License. From the recently-posted GNUs Bulletin: Possible New Terms for GNU Libraries ************************************ by Richard Stallman We are considering changing the distribution terms for some GNU libraries, such as `libg++' and the (as yet unreleased) C library. The GNU General Public License was designed for utility programs, such as Emacs and GCC. It makes a sharp distinction between using the program and copying any part of it: Any program containing any significant portion of the GNU program must be freely redistributable to be permitted at all. However, merely using the program (for example, an editor) imposes no restriction on the work that is done with it. Libraries blur the distinction between modifying or adding to a program and simply using it. Linking a program with a library, without changing the library, is in some sense simply using the library, and analogous to running a utility program or application program. However, in a textual and legal sense, the linked executable is a combined work which is a derivative of the original library, and the ordinary General Public License treats it as such. As a result, developers of proprietary software have not used the GNU libraries. The goal of the Free Software Foundation is to promote the freedom to share software, for software developers and for users; we develop software for sharing as a means to this end. As a pragmatic matter, if the conditions for use of this software are such that most developers choose not to use it, then we don't achieve the goal. At the same time, if the conditions are so loose that people can use the software without much additional sharing, then we don't achieve the goal. It seems that the ordinary General Public License is too restrictive for libraries, and is discouraging their use rather than encouraging further sharing. However, it would not be best to do what proprietary software developers ask us to do---to permit completely unrestricted use of our libraries in proprietary software---because then the end users of that software wouldn't get a jot of additional freedom as a consequence of the use of our library. We need to find a proper middle ground. Our idea is to require the distributor of the proprietary executable to make the source to our library available along with the object files for the rest of the application. The user could then recompile the library (perhaps with changes) and relink to get a usable program. This way the user will, in some sense, get the benefit of the free status of the library within the executable. However, not all the details are settled, so we aren't announcing the precise new library terms just yet. >> #Some people *need* shrink-wrapped turnkey systems... and they >> #*do* cost money to produce. > >> I agree that there are people who need turnkey systems, but I don't >> see why they *need* a shrink-wrapped system. Also, you are prefectly >> allowed to charge for GNU products, you just can't restrict >> distribution of the sources. > >People need to be able to go into a computer store, put down money, and >take a box home that they are reasonably assured of being able to load and >run first time. That takes a lot of effort to produce from the typical >component-stereo sort of freeware. Why go to that effort if someone can just >take the sources, type "make", repackage it, and undercut you? Why, indeed? Isn't that a risk in any venture? Perhaps you could add value to the freeware. You could fix bugs, add enhancements, provide support, etc. -- Dave Sill (de5@ornl.gov) These are my opinions. Martin Marietta Energy Systems Workstation Support
peter@ficc.ferranti.com (Peter da Silva) (08/15/90)
(this is crossposted to alt.sources.d purely to get it distributed past a news bottleneck. It seems a reasonable topic of discussion, nevertheless) In article <9008141435.AA21010@stc06.CTD.ORNL.GOV> de5@STC06.CTD.ORNL.GOV (SILL D E) writes: > Our idea is to require the distributor of the proprietary > executable to make the source to our library available along with > the object files for the rest of the application. The user could > then recompile the library (perhaps with changes) and relink to get > a usable program. This way the user will, in some sense, get the > benefit of the free status of the library within the executable. Those seem perfectly reasonable terms, and if the GPL was modified to allow for free use of libraries I, for one, would drop most of my objections to it. I would probably continue to use less restrictive licenses on my own freeware, simply because I have different goals. I realise that this is still up in the air, but if you feel like answering questions: What about things like the Bison skeleton? Does that constitute a library? What about GNU getopt, and other already-released software? How about libraries distributed as part of another GPL-protected program, but are useful in their own right? [ the spectre of unfair competition ] > Why, indeed? Isn't that a risk in any venture? Perhaps you could add > value to the freeware. You could fix bugs, add enhancements, provide > support, etc. That can only go so far. When you have payments on a major loan you took out to finance development you can be undercut quite substantially, and your competitors can still do all the value-added things you're trying to beat them with. -- NAME: Peter da Silva. WOLF: `-_-' PSTN: +1 713 274 5180. 'U` DNS: peter@ferranti.com BITNET: Oavzgsz@AcadiaU.CA