I wouldn't take your GPLed code and try to make it PD, thats clearly a
copyright violation. I might reimplement the same idea into the PD source,
but I doubt I will (see below.)

Had Duel stood on its own (it requires a debugger), or supported multiple
debuggers, this would probably be different. Should I decide to enhance the
"new" gdb (including duel, if this ever happen) myself, I'll probably
do the same thing I have doe with it in the first place,
namely write a [new] PD enhancement to gdb. Since I care for the
usefulness of my work to the public (and this is my main, if not
the only concern I have when I write code for free), I would try to avoid
having competing, confusing and similar versions on the market (i.e.,
avoid what the FSF seems to have done to ispell.)

Had you worked in the MS-DOS, OS/2 or Windows world (and I dont want to
start a flame war about this), I can assure you that you could
find many proprietary programming packages whose source is available.
For example, see the Borland C++ compiler, which includes source for
libc.a and their application framework, within the normal package.

You can't give that source to others, but you CAN distribute patches
to it (unlike GPLed libraries) and you CAN build binaries with it
and have control over their copies (again, unlike the GPLed libs.)
Literally 1000's of other programming products for MS are available
with source. You can even sell a completely modified source if you
purchase a copy of the original for each copy you sell (kind'a pay
royalties this way.)

Me, I'll take a the licensed libc.a from Borland any day of the week
rather than use the horribly restricting license of GPL or LGPLed libc.a,
even if the initial cost is a little higher for Borland's code.

At least when my source uses Borland's clreol() or gotoxy() or other
Borland-only functions, Borland doesn't come after me claiming they
have some rights on my source! Imagine if rms's claims were found
valid by the court, and Borland (and everyone else) did.

-- Michael

  Microsoft (MS?) doesn't release public domain software - I thought we
were discussing GNU vs PD for source released software?  Nobody but Microsoft
can maintain Microsoft code - sounds like a taking away of a freedom
to me.

: >There is no motivation to myself to ever release software
: >into the public domain  (At least not with my name on it - I don't have
: >the time for support questions for software that will never be of any
: >return benifit for myself).
:
: Thats a fine attitude taken by most people who release proprietary
: software, be it MS or the FSF (or me, in another life :-)

  Get real - I am offering software where users are free to choose their
own support avenue (IE: Destroying a software monopoly).  Do you not see
that as drastically different than propriatary sofware where you have
no choices, no freedoms, and often no support?

: I'd say you clearly work in the UNIX world, which is too small and

  No, I work with AmigaDOS at the moment, ultough I will be upgrading
to a Unix varient of some sort in the future.

: Had you worked in the MS-DOS, OS/2 or Windows world (and I dont want to
: start a flame war about this), I can assure you that you could
: find many proprietary programming packages whose source is available.

  I have used these platforms, and the amount of source released software
is EXTREMELY MINIMAL (That of course is only part of the reason I would
not buy into yet another propriatary O.S. - I'm dumping AmigaDOS because
of it's SINGLE support company).

  For me, the GNU licence talks to the issue of support monopolies, and
it is because I am not willing to put up with monopolies that I don't
buy into propriatary software, and don't release propriatary software.
PD softwre to me says 'This version is Free, but derivative work will be
propriatary and thus defeat the intent of releasing it
"freely distributable"'.  It's only one step away from me actually
releasing propriatary code which doesn't help the
advancement of the tools.

: At least when my source uses Borland's clreol() or gotoxy() or other
: Borland-only functions, Borland doesn't come after me claiming they
: have some rights on my source! Imagine if rms's claims were found
: valid by the court, and Borland (and everyone else) did.

  A different debate, but one that I don't think is as clear cut as
you seem to be trying to push.  GNU Software is released for a reason,
and using it in order to produce propriatary code defeats the intent
of the use of the licence (At least it woould defeat the intent of my
use of the licence).  Does every author have to put out a 200 page
document describing their licence in order to more obviously
explain the intent of their licence?

  It's all a question of intent.

  I'm not 'giving away' software, I'm 'liberating' software in the hopes that
I will get the same in return.  Propriatary software in no way helps my work,
so since they have no way to reciprocate the help my software might give
them, I'm not willing to help them.  I provide support for my software
with the 'trust' that this support of others will lead to more support
of the software (In a number of ways).

[ Only commenting to some side issues, Russell McOrmond is doing a
fine job in the main thread. ]

I think the competition between FSF Emacs and Lucid emacs is a good
example of how GPL'ed competition works.  While both FSF and Lucid are
trying to create the best GNU Emacs, they are constantly `stealing'
code from each other.  This accelerates the development of both
variants.  This seldom happens with `truly proprietary' code.

Michael> I would try to avoid having competing, confusing and similar
Michael> versions on the market (i.e., avoid what the FSF seems to
Michael> have done to ispell.)

Ispell 4 is so inferior to ispell 3 that it is hardly competing.  The
only advantages of ispell 4 is a better configure script and a
slightly less restrictive license (read the ispell 3 license and tell
me if commercial use is allowed).

I'm thinking that theoretically, I could under OS/2, segregate the
GPL code into a DLL and release that under the GPL and then it would
allow me to use it in a commercial product. Or will the GNU people
find some way to make that unpalatable as well?

You're trying to create a derivative work of Emacs.  You propose to do it
in two stages, by first turning Emacs into a DLL and then shipping your
proprietary code to link to it.  Under copyright law, FSF gets to decide
who makes derivative works under what conditions.  They haven't given you
permission to do what you're proposing to do.  Don't like it?  So sorry.
This trick doesn't work.  There is no way that you could legally assert
that your code that's designed to dynamically link to Emacs and have Emacs
do most of the work isn't a derivative work of Emacs.  FSF's lawyers
aren't incompetent, and they wrote this thing (the GPL) to work the way
they wanted it to work.

This is *exactly* the subterfuge that the FSF prohibits.  Such a thing
is a derivative work.  Merely separating it into two pieces and using
different commands doesn't make it somehow less of a derivative work.

This is *exactly* why the FSF considers "user does the link" not to
change the derivative nature of a GPL'd-code-using program; and
considers dynamic libraries to a technical optimization on "user does
the link".  Moreover, the FSF has made this clear since the LGPL was
announced.

Would the following REXX program also be GPL'd?

/* */
arg line
'EMACS f:\lib\foo\'line

In this instance the program does not do anything without EMACS.

If not, what if the interface were via calls through the .dll
mechanism rather than via a command line call as above.

And if not in that case, what distinguishes my REXX program from
the program described above?

If DLL-access to GPL software is allowable, then the universe
of use for FSF software would be greatly enhanced. I make my
money making computers do things. I don't have so much resource
available that I can afford to reinvent the wheel on fairly
major things (if I actually cared, I suppose I could, say
make my own ls clone or somesuch, but if I could obtain
tightly integrated editor support, say, by using EMACS,
that would improve my ability to make more money in less time.
Not everybody has the luxury of institutional support. Without
creating proprietary programs, I cannot make money (yes, nobody
forces me to be a programmer, but I seem to do what I do well
and enjoy it, so why change). GPL'd software does not hurt
me (although I've made a point of avoiding looking at GNU
source because I don't want to take the chance of being
accused of stealing GNU code), but better ability to use it
would help me.

As for the derivative works issue, if the EMACS front-end were
trivial, given the DLL and interface someone could duplicate
it fairly easily and the market would punish me. If it were
not, I would think that I deserve a return on my investment
of time, no?

        1. I publish an article arguing that there is a need for a common
        windowing library to allow easier porting of code between X, Mac,
        MS Windows, and Amiga.

        2. In the article, I include my proposed library.  I also
        do whatever one does to try to get ANSI to consider something
        as a standard.

        3. To illustrate how it would be used in a real program, I make
        a version of Emacs that expects to find this library in a DLL.
        (This is a derivative work).  I do not implement the library.

        4. I make the source for this Emacs freely available under terms of
        the GPL.

Have I violated GPL?  I think not.  I can't find any clause that I've
violated.  I've made a derivative work of Emacs, so FSF gets to say how
it's distributed.  They have spoken, and what they said was that if I
follow GPL, I get to distribute my derivative work.  I'm following
GPL, so I get to distribute.

Let's continue.  Some company comes along, and reads my article.  They
decide that my library is a good idea, and decide to implement it for
X, Mac, MS Windows, and Amiga.  They do so, and start selling it, sans
source code.

It may be true that FSF can limit your use and distribution of actual
GNU code, but the idea that they have control over programs which
are compatible with GPLed code (and all compatibility implies
additional functionality of some sort) is frankly wrong.

Now the FSF is in the same position as the companies that it loathes:
it is using fear, uncertaintly, and doubt to slow down independent
authors. We would all be served by a law suit to straighten this
matter out.

|   In article <CA2Jps....@news.claremont.edu> dho...@jarthur.claremont.edu (D Hosek) writes:
|
|      I'm thinking that theoretically, I could under OS/2, segregate the
|      GPL code into a DLL and release that under the GPL and then it would
|      allow me to use it in a commercial product. Or will the GNU people
|      find some way to make that unpalatable as well?
|
|   This is *exactly* the subterfuge that the FSF prohibits.  Such a thing
|   is a derivative work.  Merely separating it into two pieces and using
|   different commands doesn't make it somehow less of a derivative work.
---

I don't believe this is a derivative work within the meaning of the act,
but neither my opinion nor yours matters much until a court determines
how the act applies to something the authors of the act weren't thinking
about.  Software is not like a book or a record.  The notion of "linking
with" a piece of software is qualitatively different from anything you
can do to a book.

My own guess is that a court would hold that a work which merely "fits
around" another work is not infringing; that the derivative work limits
are intended to prohibit derived things that stand alone (and include
value derived from another work), not things that work with another
work.

As analogies, I don't think a court would find that any of the following
were "derived works":

        > a musical score providing  added instrumention to an existing
          score, so long as the new part does not quote themes or figures
          from the existing piece (that is, the new part is original, but
          when played at the same time as the other score, fits in)

        > a game that refers to a specific published dictionary for
          answers to questions or for play directions ("move forward as
          many spaces as there are words in the definition of "quoin")

        > a new chapter for a high school mathematics textbook, covering
          a topic not covered in that textbook and designed to be
          read between two specified chapters of the existing book

        > a high school mathematics workbook that refers the student
          to specific chapters of a specific textbook for explanations
          and exposition but does not quote the language of the textbook
          and presents the material in a different sequence and structure
          [there would be danger here if the workbook directly
          paralleled the textbook, since the authors could
          claim copyright on the structure and interrelation of topics
          as expression]

The key is that in all these cases the user of the new work must have a
copy of the original work.  The new work is not a derived work, but an
independent work that refers to or works with the original and requires
the user to obtain her own copy of the original.

---
|   This is *exactly* why the FSF considers "user does the link" not to
|   change the derivative nature of a GPL'd-code-using program; and
|   considers dynamic libraries to a technical optimization on "user does
|   the link".  Moreover, the FSF has made this clear since the LGPL was
|   announced.
---

The problem is that the FSF really wants to control the use of its
software, not just its distribution.  That's not what the copyright laws
are for.  None of the FSF folks has pointed to a qualitative difference
between using the services of GPLed code through a pipe and using them
through a library call.  I don't believe there *is* any qualitative
difference.  The FSF is clinging to the linking example because it's the
only hope they have of fending off the fate worse than death of letting
other software developers use their work freely.  They don't see that
they have gotten to the point where the tail seems more important to
them than the dog.

Michael Bushnell, in another note, divided the world into FSF supporters
and those who wanted to break the GPL.  I do support the FSF, right up to
the point of the GPL, the point at which any nobility they might have
otherwise claimed is discarded and they raise the banner of their
dogma.  I hate dogma.

Dump the GPL!  Write, instead, a software provider's pledge that says
the same thing and publish lists of vendors who do and don't accept the
pledge.  Reward, by accolade, vendors who behave in noble ways and
punish, by scorn, those who don't.  Stop trying to use the intellectual
property laws to support your fight against intellectual property laws;
the effort is twisting your minds.  Your idee fixe is making you look
petty and petulant and not helping your cause at all.

scott

If you have legal backup and would like to release code "clearly" in
violation of the FSF claims in order to force a lawsuit or a change in
FSF claims, lemme know. I can help you setup the code. A proprietary
version of Duel would make an excellent case (Duel gets linked in with
gdb, using gdb as a front/back end. The current code is PD but making
a proprietary enhanced version will be easy. I should note that Duel
was written to improve debugging under all debuggers it gets hooked
to, not to bring lawsuits against anyone :-) Legal backing probably
means your university would protect you from a lawsuit if you release
the code under its copyright and assigns it the income.

The fact that the GPLed part is free shouldn't confuse you. the court would
decide the same if the GPLed required $1 to be sent to the FSF for every
use. And it that case, somehow it seems everyone finds it very reasonable!
The fact that the FSF gains nothing from such use is the FSF's problem,
not the author of the code.

A question for the proponents of a Public-Domain Software Foundation:
What would such an organization accomplish, beyond what has already been
done by the existing mechanisms for collecting and distributing PD code?

In this case Ms. Hacker owns copyright the moment she writes the
program. If she waives her rights (i.e., places the program into the
public domain), that doesn't let other people ``snap up'' the rights.

Now, a company _can_ take the PD code and stick ``Copyright 1993 Us'' on
the top, thus creating a (marginally) modified work, which they can  
register with the copyright office under the rule of doubt. But this
doesn't affect the PD status of the original work, which anyone can
freely copy and use.

Consider my kstuff package. I released an alpha version into the PD.
People have sent me fixes and enhancements which I intend to distribute
in the beta version. I can maintain all the derivatives which I release.

There are quite a few copyrighted programs running around based on
pieces of kstuff. Some of them give proper credit; some don't. Some have
revised versions of my libraries; some use the originals. Sure, I can't
maintain these programs, but that's fine: the copyright holder has that
responsibility. As far as I can tell, if I had used GPL for kstuff,
those revisions wouldn't exist, and kstuff wouldn't have received as
much publicity and porting and debugging as it has so far.

What's beneficial is source code distribution. The more distribution of
source code, the better. (``More'' includes ``less restrictive.'')

GPL is better than PD to the extent that GPL encourages more source code
distribution. PD is better than GPL to the extent that PD encourages
more source code distribution.

A lot of people here are violently arguing ``GPL has the advantage
because [there's some good effect of more source code distribution].''
But nobody denies the good effects. The question is whether GPL leads to
those effects better than PD---i.e., whether GPL encourages more source
code distribution.

Some people say yes. Some people say no. There are examples to support
both sides.

  [ Software ]

What I, and I believe the FSF, objects to is that these sed-weilding
entities would be able to distribute this program, and it's users
wouldn't have the code to make custom changes or bug corrections to.
Sure, they could hunt up the original, if they knew it existed, and if
they had access to an archive site that carried it.

The Society for Free Software would do similar things that
the FSF does, but using PD code and w/o a political agenda.
That is, ask for donations and fund specific PD projects,
and act as a clearing house for all PD code/modifications, etc.

Are there any?

Dan> A question for the proponents of a Public-Domain Software Foundation:

Dan> What would such an organization accomplish, beyond what has already been
Dan> done by the existing mechanisms for collecting and distributing PD code?

Name recognition.  Part of the key to FSF's success is that they
enforces a certain quality for the software they release.  There are
other free software of a high quality, but to find it you have to wade
though lot of trash.  The PDSF could act as a quality stamp.

Michael> The Society for Free Software would do similar things that
Michael> the FSF does, but using PD code and w/o a political agenda.

Do you feel that the name SFS is less political and polemic, and more
precise than the PDSF?  

I am the author of a shared library that runs on the AmigaOS operating
system.  This library cannot easily be considered as part of the OS,
and therefore does not fall under the special exemption for linking
to GPLed OSes.

Now, just to make sure we get this straight, there is no "linking"
required for a client to use my library.  An Amiga shared library
constructs a jump table in memory, and passes clients a pointer to it.
Clients make calls by jumping to offsets from that pointer.

I wrote this library with the following intention: Since the library
is under the GPL, you can't profit from my code by selling it and
keeping it proprietary, but since the library is a separate binary,
you CAN create proprietary clients and distribute them any way you
like.  That was my intent.  I specifically mentioned my intent in the
documentation, and I also specifically mentioned that the include files
that are required to build a program that uses the library were in
the public domain.  In short, your client is NOT encumbered.  My goal
was to promote use of the library, and to do so, I do not want any
restrictions placed on other people's code.

Is this allowed by the FSF?  To preserve my intent, do I now have to
re-release under a different license?

--
 David Jones          FreeNet: (preferred) aa...@freenet.carleton.ca
 6730 Tooney Drive    NotSoFreeNet:        d...@qpoint.ocunix.on.ca
 Orleans, Ontario     Fidonet:             1:163/109.8
 K1C 6R4, Canada      POTS: (voice only)   1-613-830-1437