Thread: Readline use in trouble?
Here is something I read as part of the Alladin Ghostscript 6.0 beta release. I must admit I don't understand the logic of the issue. It seems the issue is that you can link non-GPL to GPL libraries, but you can't distribute the result. Maybe it doesn't apply to us because we don't copyright our code. It seems to suggest that we could be prevented from distributing readline in the future. Not sure though. It sounds like the old US crypto restriction where you couldn't distribute software that had hooks in it to add crypto. Removal of readline would certainly affect psql users. The actual file is gs5.94/doc/Make.htm.1 -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 GNU readline Aladdin Ghostscript does not include an interface to GNU readline. Even though the GNU License (GPL) allows linking GPL'ed code (such as the GNU readline library package) with non-GPL'ed code (such as all the rest of Ghostscript) if one doesn't distribute the result, the Free Software Foundation, creators of the GPL, have told us that in their opinion, the GPL forbids distributing non-GPL'ed code that is merely intended to be linked with GPL'ed code. We understand that FSF takes this position in order to prevent the construction of software that is partly GPL'ed and partly not GPL'ed, even though the GPL does not in fact literally forbid this (it only forbids distribution of such software). We think that FSF's position is both legally questionable and harmful to users, but we do not have the resources to challenge it, especially since FSF's attorney apparently supports it. Therefore, even though we added a user-contributed interface to GNU readline in internal Aladdin Ghostscript version 5.71 and had it working in version 5.93 (the next-to-last beta version before the 6.0 release), we have removed it from the Aladdin Ghostscript 6.0 distribution. GNU Ghostscript distributions will include support for GNU readline. As with other GNU Ghostscript components that are not included in Aladdin Ghostscript, Aladdin will not attempt to run, link, or even compile this code, or keep it current across changes in the rest of Ghostscript. We will, however, welcome bug fixes or updates, and distribute them with subsequent releases of GNU Ghostscript. The first GNU Ghostscript distribution that will include GNU readline support will be GNU Ghostscript 6.0, currently scheduled for release in the third quarter of 2000. Before that time, we may return the copyright of Ghostscript's GNU readline interface module, which the original author assigned to Aladdin Enterprises, to the author, so that users of GNU Ghostscript will have have access to it. However, since it requires internal changes that are not and will not be available in any released GNU Ghostscript version before 6.0, any user who gets this code and links it with Aladdin Ghostscript 6.0 will, according to FSF, be violating the intent (though not the letter) of the GPL. We have, in fact, put considerable work into making it possible for Ghostscript to use GNU readline, including the creation and/or adjustment of internal software interfaces specifically to serve this purpose. In principle, we should have undone this work in Aladdin Ghostscript as well, lest FSF object to it too as intended to facilitate linking Aladdin Ghostscript with GNU readline (as the U.S. government has been said to do for code that merely provides APIs where encryption may be added). However, we are willing to take this risk rather than spend the time to undo the interface changes. If you have comments or questions about this situation, please feel free to contact the Free Software Foundation, authors of the GPL and copyright holders of GNU readline, at gnu@gnu.org, and/or Aladdin Enterprises, author and copyright holder of Ghostscript, at ghost@aladdin.com.
> Removal of readline would certainly affect psql users.
afaik the Alladin product is not in the same licensing category as
Postgres (there are restrictions that, for example, prohibit RedHat
from distributing a recent version of gs with their package).
Not to worry...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Hello! On Tue, 19 Oct 1999, Bruce Momjian wrote: > Here is something I read as part of the Alladin Ghostscript 6.0 beta > release. I must admit I don't understand the logic of the issue. It > seems the issue is that you can link non-GPL to GPL libraries, but you > can't distribute the result. Maybe it doesn't apply to us because we > don't copyright our code. > > It seems to suggest that we could be prevented from distributing > readline in the future. Not sure though. It is second or third time I see this, so I think I understand. This is the way FSF protects GNU-licensed code - you can link with GNU code, but you cannot distribute non-GNU code in binary form linked with GNU code. If you want to distribute non-GNU code in binaryform only, either you must NOT to link it with GNU code; or link it with GNU code and provide a way to user to relink to other versions of GNU code; or just publish your sources. The second way means - publish your *.o for all platforms. The way number 3 means "give all users a way to compile and link it as they want, with or without GNU code". I think this applied to PostgreSQL - we have source code published, so I do not expect problems with readline. Binary-only programs are in GNUtroubles, really. Somewhereon www.gnu.org I saw a story about a company that made a program, linked it with libreadline and distributed it in binary-only form. FSF contacted the company asked to remove libreadline. The company instead published the whole sources. FSF considered it as a Big Win! BTW, readline is a special case here - it protected by GNU GPL, which is very restrictive. Most free/opensource libs are protected with GNU LGPL, which is less restrictive. GNU readline is the way FSF forces people to publsih sources! Sorry, my English is far from perfect, if you do not understand my explanations - we may raise a discussion here, and I'll try to find a better words... Oleg. ---- Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net Programmers don't die, they justGOSUB without RETURN.
Bruce Momjian wrote:
> Here is something I read as part of the Alladin Ghostscript 6.0 beta
> release. I must admit I don't understand the logic of the issue. It
> seems the issue is that you can link non-GPL to GPL libraries, but you
> can't distribute the result. Maybe it doesn't apply to us because we
> don't copyright our code.
>
> It seems to suggest that we could be prevented from distributing
> readline in the future. Not sure though.
>
> It sounds like the old US crypto restriction where you couldn't
> distribute software that had hooks in it to add crypto.
>
> Removal of readline would certainly affect psql users.
Now the time has come that the FSF has grown that big that
they try to redefine the meaning of "Free". Next they claim
"Free" is their trademark :-(
I think readline isn't our biggest problem. What about if
they notice that our parser can only be compiled when using
bison, and that we ship the generated output for the case
someone doesn't has bison installed?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Here is something I read as part of the Alladin Ghostscript 6.0 beta
> release. I must admit I don't understand the logic of the issue. It
> seems the issue is that you can link non-GPL to GPL libraries, but you
> can't distribute the result. Maybe it doesn't apply to us because we
> don't copyright our code.
Huh? We certainly do --- or have you missed that* Copyright (c) 1994, Regents of the University of California
that's plastered across all the source files?
The GPL does restrict the conditions under which GPL'd code can be
distributed; in particular it can't be distributed as part of a program
that is not all GPL'd (more or less --- I have not read the terms lately).
So, because we use BSD license rather than GNU, we cannot *include in
our distribution* any library that is under GPL.
Any end user who does not intend to redistribute the result can
certainly obtain our distribution and readline and build them together.
So it's no issue for source distributions, but I wonder about RPMs.
Our RPMs do not include the actual libreadline file, do they?
> Even though the GNU License (GPL) allows linking GPL'ed code (such as
> the GNU readline library package) with non-GPL'ed code (such as all
> the rest of Ghostscript) if one doesn't distribute the result, the
> Free Software Foundation, creators of the GPL, have told us that in
> their opinion, the GPL forbids distributing non-GPL'ed code that is
> merely intended to be linked with GPL'ed code.
As stated, this is ridiculous on its face. The FSF has no possible
right to prevent the distribution of software that they didn't write
and that doesn't fall under the GPL.
Although I haven't been paying close attention to the Ghostscript
situation, I suspect that the real story is either that the readline
interface code that someone contributed to Ghostscript was contributed
with GPL terms already attached to it, or that Aladdin is concerned
about being able to distribute full-featured precompiled binaries of
Ghostscript. (BTW, Peter Deutsch has a history of forcing the issue
when he thinks that someone else is being unreasonable, and I suspect
that he's deliberately overreacting in hopes of making FSF change
their position.)
Anyway, this sort of thing is why it's a bad idea to accept any GPL'd
code into Postgres --- the GPL does not play nice with other licenses.
I think the FSF is not doing the free software movement any service
with this foolishness, but they're entitled to distribute their code
with any terms they want, of course.
My inclination is to ignore the issue until and unless we hear a
complaint from the libreadline authors --- and if we do, we yank all
trace of readline support from psql. End of story.
regards, tom lane
> I think readline isn't our biggest problem. What about if
> they notice that our parser can only be compiled when using
> bison, and that we ship the generated output for the case
> someone doesn't has bison installed?
afaik this is explicitly covered as "conforming behavior" in the GNU
license for bison. It was not always so, but the license for bison was
recently updated to allow distributing generated code.
I should point out that rms himself is on speaking terms with us; he
recently referred someone here to ask about Postgres vis a vis Oracle
compatibility. I'm pretty sure we are one of "the good guys" in Open
Source. ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
On Tue, 19 Oct 1999, Jan Wieck wrote: > I think readline isn't our biggest problem. What about if > they notice that our parser can only be compiled when using > bison, and that we ship the generated output for the case > someone doesn't has bison installed? Until they make a significant change in their license we don't need to worry. GPL specifically states that the RESULTS of GNU-protected programs are not covered at all. These results can be used in any way you want, including commercial ways. Only program's code matter. Oleg. ---- Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net Programmers don't die, they justGOSUB without RETURN.
wieck@debis.com (Jan Wieck) writes:
> I think readline isn't our biggest problem. What about if
> they notice that our parser can only be compiled when using
> bison, and that we ship the generated output for the case
> someone doesn't has bison installed?
Non problem. From the Bison manual:
File: bison.info, Node: Conditions, Next: Copying, Prev: Introduction, Up: Top
Conditions for Using Bison
**************************
As of Bison version 1.24, we have changed the distribution terms for
`yyparse' to permit using Bison's output in non-free programs.
Formerly, Bison parsers could be used only in programs that were free
software.
The other GNU programming tools, such as the GNU C compiler, have
never had such a requirement. They could always be used for non-free
software. The reason Bison was different was not due to a special
policy decision; it resulted from applying the usual General Public
License to all of the Bison source code.
The output of the Bison utility--the Bison parser file--contains a
verbatim copy of a sizable piece of Bison, which is the code for the
`yyparse' function. (The actions from your grammar are inserted into
this function at one point, but the rest of the function is not
changed.) When we applied the GPL terms to the code for `yyparse', the
effect was to restrict the use of Bison output to free software.
We didn't change the terms because of sympathy for people who want to
make software proprietary. *Software should be free.* But we
concluded that limiting Bison's use to free software was doing little to
encourage people to make other software free. So we decided to make the
practical conditions for using Bison match the practical conditions for
using the other GNU tools.
regards, tom lane
Tom Lane wrote: > So it's no issue for source distributions, but I wonder about RPMs. > Our RPMs do not include the actual libreadline file, do they? No. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
>From GPL, section 0:
"Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope."
We are not copying, distributing, or modifying readline.
"The act of running the Program is not restricted, ..."
Writing
char * foo = readline("");
is the same as writing
int bar = system("/bin/gzip");
just that they chose to create their product in a way that you have to use
the former method rather than the latter.
"... and the output from the Program is covered only if its contents
constitute a work based on the Program"
I always thunk that the output of readline is a work based on the user.
Anyway, when the BSD folks get their libedit act together, we can easily
replace one with the other. That was one of the requests by the folks out
there, and I got it done.
-Peter
On Tue, 19 Oct 1999, Bruce Momjian wrote:
> Here is something I read as part of the Alladin Ghostscript 6.0 beta
> release. I must admit I don't understand the logic of the issue. It
> seems the issue is that you can link non-GPL to GPL libraries, but you
> can't distribute the result. Maybe it doesn't apply to us because we
> don't copyright our code.
>
> It seems to suggest that we could be prevented from distributing
> readline in the future. Not sure though.
>
> It sounds like the old US crypto restriction where you couldn't
> distribute software that had hooks in it to add crypto.
>
> Removal of readline would certainly affect psql users.
--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
On Tue, 19 Oct 1999, Tom Lane wrote: > Huh? We certainly do --- or have you missed that > * Copyright (c) 1994, Regents of the University of California > that's plastered across all the source files? Regarding which I have a question: at other locations I see (c) 1994-7 Univ. of California, or even (c) 1996-9 PostgreSQL Global Development Team. I am not an expert in any of this, but I'm just wondering: when did the involvement of the U of C end, when was the Global Development Team (tm) formed and do both copyrights exits in parallel? What if someone contributes something really major and fairly independent (say like pg_access) and wants to keep his own copyright (with compatible license of course)? And is the PostgreSQL Global Development Team any real entity that could theoretically enforce that copyright or is it just an alias for "whoever contributed"? -Peter -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
> > Removal of readline would certainly affect psql users. > > Now the time has come that the FSF has grown that big that > they try to redefine the meaning of "Free". Next they claim > "Free" is their trademark :-( > > I think readline isn't our biggest problem. What about if > they notice that our parser can only be compiled when using > bison, and that we ship the generated output for the case > someone doesn't has bison installed? > I always thought that was OK because we distribute full source code, right? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Yes, I head hear this. They basically said, "Our leverage isn't working." > As of Bison version 1.24, we have changed the distribution terms for > `yyparse' to permit using Bison's output in non-free programs. > Formerly, Bison parsers could be used only in programs that were free > software. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > I think readline isn't our biggest problem. What about if > > they notice that our parser can only be compiled when using > > bison, and that we ship the generated output for the case > > someone doesn't has bison installed? > > afaik this is explicitly covered as "conforming behavior" in the GNU > license for bison. It was not always so, but the license for bison was > recently updated to allow distributing generated code. > > I should point out that rms himself is on speaking terms with us; he > recently referred someone here to ask about Postgres vis a vis Oracle > compatibility. I'm pretty sure we are one of "the good guys" in Open > Source. ;) Wait until you read my preface. It makes us sound like heros. Maybe we are. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > > Here is something I read as part of the Alladin Ghostscript 6.0 beta > > release. I must admit I don't understand the logic of the issue. It > > seems the issue is that you can link non-GPL to GPL libraries, but you > > can't distribute the result. Maybe it doesn't apply to us because we > > don't copyright our code. > > Huh? We certainly do --- or have you missed that > * Copyright (c) 1994, Regents of the University of California > that's plastered across all the source files? Oh. I remember that now. :-) > > The GPL does restrict the conditions under which GPL'd code can be > distributed; in particular it can't be distributed as part of a program > that is not all GPL'd (more or less --- I have not read the terms lately). > So, because we use BSD license rather than GNU, we cannot *include in > our distribution* any library that is under GPL. But Alladin wasn't doing that either. They were just distributing source code that could use readline, like we do. > > Any end user who does not intend to redistribute the result can > certainly obtain our distribution and readline and build them together. > So it's no issue for source distributions, but I wonder about RPMs. > Our RPMs do not include the actual libreadline file, do they? I think we dynamically load libreadline, which is OK, maybe. > > > Even though the GNU License (GPL) allows linking GPL'ed code (such as > > the GNU readline library package) with non-GPL'ed code (such as all > > the rest of Ghostscript) if one doesn't distribute the result, the > > Free Software Foundation, creators of the GPL, have told us that in > > their opinion, the GPL forbids distributing non-GPL'ed code that is > > merely intended to be linked with GPL'ed code. > > As stated, this is ridiculous on its face. The FSF has no possible > right to prevent the distribution of software that they didn't write > and that doesn't fall under the GPL. Totally true, as far I an can figure. The US government stupidly tries to do this under an existing export law. Don't know of any FSF laws. > Although I haven't been paying close attention to the Ghostscript > situation, I suspect that the real story is either that the readline > interface code that someone contributed to Ghostscript was contributed > with GPL terms already attached to it, or that Aladdin is concerned Oh, that is an interesting issue that I never considered. Reminds us we can't use GPL code. > about being able to distribute full-featured precompiled binaries of > Ghostscript. (BTW, Peter Deutsch has a history of forcing the issue > when he thinks that someone else is being unreasonable, and I suspect > that he's deliberately overreacting in hopes of making FSF change > their position.) Good for him. > My inclination is to ignore the issue until and unless we hear a > complaint from the libreadline authors --- and if we do, we yank all > trace of readline support from psql. End of story. Agreed. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> On Tue, 19 Oct 1999, Tom Lane wrote: > > > Huh? We certainly do --- or have you missed that > > * Copyright (c) 1994, Regents of the University of California > > that's plastered across all the source files? > > Regarding which I have a question: at other locations I see (c) 1994-7 > Univ. of California, or even (c) 1996-9 PostgreSQL Global Development > Team. > > I am not an expert in any of this, but I'm just wondering: when did the > involvement of the U of C end, when was the Global Development Team (tm) > formed and do both copyrights exits in parallel? What if someone > contributes something really major and fairly independent (say like > pg_access) and wants to keep his own copyright (with compatible license of > course)? > > And is the PostgreSQL Global Development Team any real entity that could > theoretically enforce that copyright or is it just an alias for "whoever > contributed"? Now there's a good question. How long does the BSD imprint remain. I assume forever. It is still on BSD/OS files. Only the ones they right from scrath get a BSDI imprint. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 19 Oct 1999, Bruce Momjian wrote:
> > On Tue, 19 Oct 1999, Tom Lane wrote:
> >
> > > Huh? We certainly do --- or have you missed that
> > > * Copyright (c) 1994, Regents of the University of California
> > > that's plastered across all the source files?
> >
> > Regarding which I have a question: at other locations I see (c) 1994-7
> > Univ. of California, or even (c) 1996-9 PostgreSQL Global Development
> > Team.
> >
> > I am not an expert in any of this, but I'm just wondering: when did the
> > involvement of the U of C end, when was the Global Development Team (tm)
> > formed and do both copyrights exits in parallel? What if someone
> > contributes something really major and fairly independent (say like
> > pg_access) and wants to keep his own copyright (with compatible license of
> > course)?
> >
> > And is the PostgreSQL Global Development Team any real entity that could
> > theoretically enforce that copyright or is it just an alias for "whoever
> > contributed"?
>
> Now there's a good question. How long does the BSD imprint remain. I
> assume forever. It is still on BSD/OS files. Only the ones they right
> from scrath get a BSDI imprint.
So, should we be extending the Date of the BSD license? Like, is there no
copyright *after* 1997? Or, can we do something like:
* Copyright (c) 1997-9* PostgreSQL Global Development Team* Copyright (c) 1994-7* The Regents of the
Universityof California. All rights reserved.
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > > And is the PostgreSQL Global Development Team any real entity that could > > > theoretically enforce that copyright or is it just an alias for "whoever > > > contributed"? > > > > Now there's a good question. How long does the BSD imprint remain. I > > assume forever. It is still on BSD/OS files. Only the ones they right > > from scrath get a BSDI imprint. > > So, should we be extending the Date of the BSD license? Like, is there no > copyright *after* 1997? Or, can we do something like: > > * Copyright (c) 1997-9 > * PostgreSQL Global Development Team > * Copyright (c) 1994-7 > * The Regents of the University of California. All rights reserved. Beats me. BSDI stdio.h has: /*-* Copyright (c) 1990, 1993* The Regents of the University of California. All rights reserved.** This code is derivedfrom software contributed to Berkeley by* Chris Torek. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > > > Huh? We certainly do --- or have you missed that
> > > > * Copyright (c) 1994, Regents of the University of California
> > > > that's plastered across all the source files?
> > > Regarding which I have a question: at other locations I see (c) 1994-7
> > > Univ. of California, or even (c) 1996-9 PostgreSQL Global Development
> > > Team.
> > > I am not an expert in any of this, but I'm just wondering: when did the
> > > involvement of the U of C end, when was the Global Development Team (tm)
> > > formed and do both copyrights exits in parallel? What if someone
> > > contributes something really major and fairly independent (say like
> > > pg_access) and wants to keep his own copyright (with compatible license of
> > > course)?
I'm the one who started slapping new copyright notices around (in the
docs, mostly). imho UCB's involvement ended when they released source
code, with copyright provisions designed to retain acknowledgement of
their work while releasing them from any liability resulting from any
and all uses of the code.
We certainly *can't* simply extend UCB's copyright dates, since they
are not involved in that process. imo we *should* apply a new
copyright which enforces UCB's original provisions, which are designed
to keep the code in play while deflecting liability.
> > > And is the PostgreSQL Global Development Team any real entity that could
> > > theoretically enforce that copyright or is it just an alias for "whoever
> > > contributed"?
> > Now there's a good question. How long does the BSD imprint remain. I
> > assume forever. It is still on BSD/OS files. Only the ones they right
> > from scrath get a BSDI imprint.
We'll decide if PostgreSQL Global Development Team is a real entity
for copyright purposes when we need to ;) Really, the BSD-style
license has *no* restrictions, so what are we going to enforce? But we
*should* put some mention of things in the code to avoid cases like
the idiot American yahoo who tried to lay claim to "linux".
> So, should we be extending the Date of the BSD license? Like, is there no
> copyright *after* 1997? Or, can we do something like:
> * Copyright (c) 1997-9
> * PostgreSQL Global Development Team
> * Copyright (c) 1994-7
> * The Regents of the University of California. All rights reserved.
I'm not a lawyer, and I don't even play one on TV. But y'all can't
extend a UCB copyright arbitrarily. We're a work derived from the
original Berkeley distribution, and we are complying with the UCB
copyright in all respects afaik. What happens after that is up to us,
not UCB...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Peter Eisentraut <e99re41@csd.uu.se> writes:
> Regarding which I have a question: at other locations I see (c) 1994-7
> Univ. of California, or even (c) 1996-9 PostgreSQL Global Development
> Team.
> I am not an expert in any of this, but I'm just wondering: when did the
> involvement of the U of C end, when was the Global Development Team (tm)
> formed and do both copyrights exits in parallel?
Judging from the historical messages recently posted, Berkeley had
control of the code up to about '96. I suppose '94 was the last major
release made from Berkeley. (Another Berkeley project that I've been
involved with, Ptolemy, has always made a point of updating its
copyright boilerplate to current year just before each major release.
Perhaps the Postgres guys were less punctilious about copyright dates,
but anyway it's clearly been several years since Berkeley was in
charge.)
If we were really doing this with full legal care, we'd probably have
something like this in every source file:
* Copyright (c) 1986-1994* The Regents of the University of California. All rights reserved.* Copyright (c)
1996-1999* PostgreSQL Global Development Team
(or whatever the exact date ranges should be). The Berkeley copyright
will never lapse as long as there is visible Berkeley heritage in the
code, but the Postgres group can also claim copyright on the
modifications and additions we've made. As long as we are happy with
distributing our work under the BSD license terms, there's no conflict.
Now a lawyer would immediately point out that the "PostgreSQL Global
Development Team" is not a legally existent entity and so has no ability
to sue anyone for copyright violation. If we thought we might have to
enforce our wishes legally, we'd need to form an actual corporation.
(Perhaps the core team has already quietly done that, but I sure don't
know about it...)
> What if someone contributes something really major and fairly
> independent (say like pg_access) and wants to keep his own copyright
> (with compatible license of course)?
I've noticed that Jan and a couple of other people have put copyright
notices in their own names on files that they've created from scratch,
but I feel uncomfortable with that practice. The Ghostscript/readline
fiasco illustrates the potential problems you can get into with
divergent copyrights on chunks of code that need to be distributed
together. My personal feeling is that if you're a member of the team,
stick the team copyright on it; don't open a can of legal worms.
(If we were building in a green field it might be profitable to debate
what that team copyright should be --- but unless we want to start from
scratch, BSD is it, for better or worse.)
Disclaimer: I'm not a lawyer, I don't play one on TV, yadda yadda...
regards, tom lane
>>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes: TL> The GPL does restrict the conditions under which GPL'd code can TL> be distributed; in particular it can't be distributedas part of TL> a program that is not all GPL'd (more or less --- I have not TL> read the terms lately). So,because we use BSD license rather TL> than GNU, we cannot *include in our distribution* any library TL> that is underGPL. [All IMHO, I'm not a lawyer etc. too.] I think that from the point of GPL there is basically no problem with PostgreSQL license, since it contains no restriction incompatible with GPL. The situation with Aladdin Ghostscript is quite different, it is under non-free license, its license is in conflict with GPL and so it clearly can't use GPLed code. However, including GPLed code into PostgreSQL, though I think it's fully legal, means that third party can't take the PostgreSQL as a whole and distribute it under license violating GPL, e.g. as a proprietary product without available sources. If it is important for you to support *more* restrictive licensing than GPL, then you should avoid inclusion of GPLed code into PostgreSQL. Milan Zamazal
>>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes: TL> The GPL does restrict the conditions under which GPL'd code can TL> be distributed; in particular it can't be distributedas part of TL> a program that is not all GPL'd (more or less --- I have not TL> read the terms lately). So,because we use BSD license rather TL> than GNU, we cannot *include in our distribution* any library TL> that is underGPL. [All IMHO, I'm not a lawyer etc. too.] I think that from the point of GPL there is basically no problem with PostgreSQL license, since it contains no restriction incompatible with GPL. The situation with Aladdin Ghostscript is quite different, it is under non-free license, its license is in conflict with GPL and so it clearly can't use GPLed code. However, including GPLed code into PostgreSQL, though I think it's fully legal, means that third party can't take the PostgreSQL as a whole and distribute it under license violating GPL, e.g. as a proprietary product without available sources. If it is important for you to support *more* restrictive licensing than GPL, then you should avoid inclusion of GPLed code into PostgreSQL. Milan Zamazal
On Wed, 20 Oct 1999, Tom Lane wrote: > If we were really doing this with full legal care, we'd probably have > something like this in every source file: > > * Copyright (c) 1986-1994 > * The Regents of the University of California. All rights reserved. > * Copyright (c) 1996-1999 > * PostgreSQL Global Development Team That's what I thought. Perhaps one should also add to the actual copyright notice, that, besides that U of C, no member of the PostgreSQL Global Development Team will assume any liability for nuttin', etc. > Now a lawyer would immediately point out that the "PostgreSQL Global > Development Team" is not a legally existent entity and so has no ability > to sue anyone for copyright violation. If we thought we might have to > enforce our wishes legally, we'd need to form an actual corporation. > (Perhaps the core team has already quietly done that, but I sure don't > know about it...) What about Pgsql, Inc.? Perhaps they should trademark the product name and act as the legal guardian. Isn't that sort of what the Apache Software Foundation does? Of course, I don't recall the project being in legal trouble lately, but who knows how fast it can happen. The FSF could get anal, or [commercial db vendor] files senseless claims, or [joe idiot] trademarks "PostgreSQL", etc. Once you're in the spotlight, the weirdos come out. And we want to be in the spotlight, don't we? -Peter -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
On Wed, 20 Oct 1999, Tom Lane wrote: > Now a lawyer would immediately point out that the "PostgreSQL Global > Development Team" is not a legally existent entity and so has no ability > to sue anyone for copyright violation. If we thought we might have to > enforce our wishes legally, we'd need to form an actual corporation. > (Perhaps the core team has already quietly done that, but I sure don't > know about it...) I don't know how things work in Canada - where Marc is - but in the US a simple DBA would be all that's necessary for an entity to copyright in their own name. Many clubs and user groups do this regularly. A form that's filled out every five years is all that's needed to maintain the business name. (DBA = Doing Business As) > Disclaimer: I'm not a lawyer, I don't play one on TV, yadda yadda... Same here, but I have filed and received a copyright for one of the above unmentioned clubs when I was a member. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h> Have you seenhttp://www.pop4.net? Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On Wed, 20 Oct 1999, Thomas Lockhart wrote: > We'll decide if PostgreSQL Global Development Team is a real entity > for copyright purposes when we need to ;) Really, the BSD-style At least the Global Development Team was entity enough to register the domain postgresql.org: Registrant: PostgreSQL Global Development Group (POSTGRESQL-DOM) 203-112 Highland Ave Wolfville, Nova Scotia B0P 1X0 CA -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
> > something like this in every source file: > > * Copyright (c) 1986-1994 > > * The Regents of the University of California. All rights reserved. > > * Copyright (c) 1996-1999 > > * PostgreSQL Global Development Team > That's what I thought. Perhaps one should also add to the actual copyright > notice, that, besides that U of C, no member of the PostgreSQL Global > Development Team will assume any liability for nuttin', etc. Here is what we already have in the docs: (from http://www.postgresql.org/docs/postgres/copyright.htm) Copyrights and Trademarks PostgreSQL is Copyright © 1996-9 by the PostgreSQL Global Development Group, and is distributed under the terms of the Berkeley license. Postgres95 is Copyright © 1994-5 by the Regents of the University of California. Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies. In no event shall the University of California be liable to any party for direct, indirect, special, incidental, or consequential damages, including lost profits, arising out of the use of this software and its documentation, even if the University of California has been advised of the possibility of such damage. The University of California specifically disclaims any warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The software provided hereunder is on an "as-is" basis, and the University of California has no obligations to provide maintainance, support, updates, enhancements, or modifications. I wrote the minimalist "me too" copyright notice as the first paragraph above to avoid making claims or statements that the group would find a problem. But istm that our copyright notice should probably be a bit more wordy, perhaps mimicing the whole UCB copyright statement. Comments? > > Now a lawyer would immediately point out that the "PostgreSQL Global > > Development Team" is not a legally existent entity and so has no ability > > to sue anyone for copyright violation. If we thought we might have to > > enforce our wishes legally, we'd need to form an actual corporation. > > (Perhaps the core team has already quietly done that, but I sure don't > > know about it...) istm that we "operate" in more countries than most any real company, and it would be prohibitive to preemptively file for legal status everywhere it might matter. The copyright is intended to keep the code available *and* to deflect liability; we only need to invoke it if someone comes after us (maybe we'll all end up living with Marc on some island in Canada, hiding from the US lawyers :) Perhaps it is better to do The Right Thing developing software with an appropriate copyright and leave the rest... btw, Marc has already run into domain name pirates/speculators, who snagged postgresql.com. They would be happy to sell the name back to us :((( - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
Milan Zamazal wrote: > >>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes: > > TL> The GPL does restrict the conditions under which GPL'd code can > TL> be distributed; in particular it can't be distributed as part of > TL> a program that is not all GPL'd (more or less --- I have not > TL> read the terms lately). So, because we use BSD license rather > TL> than GNU, we cannot *include in our distribution* any library > TL> that is under GPL. > > [All IMHO, I'm not a lawyer etc. too.] > > I think that from the point of GPL there is basically no problem with > PostgreSQL license, since it contains no restriction incompatible with > GPL. > > The situation with Aladdin Ghostscript is quite different, it is under > non-free license, its license is in conflict with GPL and so it clearly > can't use GPLed code. > > However, including GPLed code into PostgreSQL, though I think it's fully > legal, means that third party can't take the PostgreSQL as a whole and > distribute it under license violating GPL, e.g. as a proprietary product > without available sources. If it is important for you to support *more* > restrictive licensing than GPL, then you should avoid inclusion of GPLed > code into PostgreSQL. Please clear this up one way or another. I was looking to include PostgreSQL into my companies proprietary software package. I was going to make all of the arrangements to follow the PostreSQL Copyright. I can not include source code of my companies software, since it is to copyrighted to my company. Please list the steps i would need to comply with PostgreSQL's Copyright. (I was under the impression that the Copyright from the Regents of U of CA was it) List any modules that is would need to include/execlude to avoid voilating other Copyrights used by PostgreSQL. Your scaring me guys. P.S. You guys have a great product from what i have seen so far. I am realy looking forward to release 7. John Ingram Senior Software Engineer > > > Milan Zamazal
Milan Zamazal <pdm@debian.cz> writes:
>>>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:
TL> The GPL does restrict the conditions under which GPL'd code can
TL> be distributed; in particular it can't be distributed as part of
TL> a program that is not all GPL'd (more or less --- I have not
TL> read the terms lately). So, because we use BSD license rather
TL> than GNU, we cannot *include in our distribution* any library
TL> that is under GPL.
> I think that from the point of GPL there is basically no problem with
> PostgreSQL license, since it contains no restriction incompatible with
> GPL.
Actually it's the other way around: BSD-type license doesn't care about
GPL'd stuff in the same distribution ... but GPL license does. The GPL
insists that all its terms, including its restrictions, apply exactly
to the whole of any program containing any GPL'd code. So we'd be
violating the GPL if we had parts of Postgres under GPL and parts under
BSD, because BSD is *less* restrictive than GPL (it puts fewer
requirements on a recipient of the code than GPL does). And we can't
just arbitrarily change the Berkeley-derived code from BSD to GPL.
In practice this is probably all just nit-picking; the Postgres group
itself isn't doing anything with Postgres that doesn't fall within the
terms of the GPL. But from a legalistic point of view the two licenses
are not compatible.
regards, tom lane
On Tue, 19 Oct 1999, Bruce Momjian wrote: > Removal of readline would certainly affect psql users. > > The actual file is gs5.94/doc/Make.htm.1 One could always switch to libedit, which is BSD licensed. Its not yet ported to as many platforms as readline though... -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever |