Thread: responses to licensing discussion
Thanks to all for their thoughts and comments on the proposed license language I posted yesterday. I'll try and respond to all the points I heard in this one mail, rather than fill everyone's inbox with more replies. And I'm also sending this only to -general, to cut down on cross-posting... Two major concerns that a lot of people seem to have are the Virginia jurisdiction question and the line about seeing the license before you can download/install/etc. These both relate to the UCITA statute, which as Rusty said in his introduction, is intended to exempt you the developers from any future liability by people using PostgreSQL. (Well, actually it was written to exempt commercial developers, but the same protections apply to open source hackers...) I know there's a lot of FUD out there about UCITA, and there may even be some legitimacy to some of the consumer end-user fears about what evil Microsoftish companies might do to people that buy their software (er, that is, *rent* their software). But the reason we're so interested in applying UCITA protections to PostgreSQL developers is that, duh, we plan on contributing to the code base as well, and we don't want to get sued. As someone mentioned in an earlier post, the bad guys (Oracle, MS, etc.) will increasingly see PostgreSQL as a threat - it just seems prudent, and in everyone's interest, to tighten up what a number of legal eagles have observed to be liability risks for the developers. So I'll take each of the two points separately: The non-US folks, who I'll grant may well be a majority ;-), are concerned about the jurisdiction in Virginia. The reason we suggest this is that *naming* a jurisdiction is better than leaving it empty - any lawyer will tell you that - so you try and claim jurisdiction somewhere you think will be friendly to the people you want to protect. With all due respect to the rest of the world, the UCITA provisions in Virginia and Maryland, soon to make their way across the rest of the US, lead the world in protecting developers from liability - and that's our goal. Without a specified jurisdiction, the aggrieved party can shop around for where *he* thinks he has the best shot of screwing you. Chris Bitmead said he's "not bound by" UCITA, but that's not the point ... we're trying to bind the users, who might decide to try and sue him. That chose of law/jurisdiction, BTW, is different from choice of *venue* - Sevo Stille worried that he might have to travel to Virginia for his day in court. The two things are separate. On a related note, if PostgreSQL is being marketed in the US, it will be subject to US law - regardless of where the project says it's "based." Did anyone see the BBC report that Microsoft was going to move to Canada to escape US antitrust action? Despite being totally false (but funny), it also wouldn't have mattered for the same reason- Microsoft products sold in the US would be subject to US law, regardless of where the company was based. The second point, forcing a click-through or some other mechanism before a user downloads/installs the software, gets at the same issue. As a developer, you only get the protection of UCITA if the user *agrees* to the license... right now, just having it in the tarball or on the CD doesn't meet that test. There needs to be some proactive mechanism that signifies user acceptance of the terms, or else the license is just words. The recent passage in the US of digital signature legislation affirms the various mechanisms by which you can do that. Some other threads that I'll try and respond to: BSD vs. GPL: As per usual, there's a great deal of misinformation out there about what exactly the GNU Public License does. For starters, for all of you who are concerned about lawyerliness, length, etc., have you ever read the dang thing? (http://www.opensource.org/licenses/gpl-license.html) It's also worth noting that the GPL has not yet had its day in court - and there are a fair number of legal experts out there who say that it might not hold up. To us at Great Bridge, the BSD language is much more likely to survive the next few years. I said in my first note that we want to make sure the code to PostgreSQL stays open in perpetuity; several people said, well, GPL does that, so why don't you go GPL? The answer is, we're not trying to be GPL - as several of the CORE members reiterated. We think this is still very much a BSD license, and I guess at some point, we ought to drag the OSI into it to get their view. I agree with those who have said the last thing the world needs is another open source license. The Mozilla PL, and its imitators such as our friends at Interbase, are one good argument there (blecch- http://www.mozilla.org/MPL/MPL-1.0.html). Previous contributions: A couple of people asked, ok, so this is a proposed solution for future code contributions - what about the existing stuff? We'd suggest that anyone who is currently contributing patches could say, in effect, "this goes retroactively for everything else I've committed in the past" - which granted wouldn't get us all the way there, but probably close to 80%. Again, the goal is indemnifcation of the developers who aren't coverered as Berkeley-era contributors. Our lawyers tell us this is do-able if people want to do it. Thoughts? Finally, a note to all of those who might be suspicious of Great Bridge's role in all of this. Clearly we have an agenda - we want to make sure that in addition to its technical near-parity with Oracle et al (getting nearer every day), PostgreSQL has the business underpinning to survive in the commercial world. Or better yet, survive at the intersection of the open source and commercial worlds. We believe, as an article of faith, that PostgreSQL and other open source projects are only going to get better, and eclipse their closed/proprietary counterparts in performance, functionality, user base, etc. We intend to build a business that will further and support that process - and we have every intention of being responsible, proactive members of the open source community in so doing. We're not asking you to trust us, to take our word for anything, etc.; we realize that we'll have to prove ourselves, as hackers *and* as marketers before anyone necessarily believes a word we say. But we are asking you to keep an open mind, and not to jump to conclusions about us. In the spirit of open source, we've started this discussion as kind of a proposed "legal patch" - and seriously encourage as much qualified peer review as is possible. So I'd second Tom Lane's suggestion that other people's lawyers look at this- particularly those of you outside the US. But remember that all things being equal, the lawyers (hisss....) are in fact the equivalent of the hackers here. Just as you wouldn't expect them to comment intelligently on your code, the arcana of license agreements (and to a lesser extent, copyrights) are their domain - and it will be other peoples' lawyers that make trouble in the future, if there ever is any. So I'd urge everyone to take a deep breath and let's get as much *qualified* comment on this as we can. Also, if anyone wants to talk lawyer to lawyer to our corporate counsel, I'd be happy to arrange that; please contact me privately off-list. Thanks, Ned
Ned Lilly wrote: > > > The second point, forcing a click-through or some other mechanism > before a user downloads/installs the software, gets at the same > issue. As a developer, you only get the protection of UCITA if the > user *agrees* to the license... right now, just having it in the > tarball or on the CD doesn't meet that test. There needs to be some > proactive mechanism that signifies user acceptance of the terms, or > else the license is just words. The recent passage in the US of > digital signature legislation affirms the various mechanisms by > which you can do that. How does this affect the presence of PostgreSQL on RedHat distributions, where no such agreement is made? Would it require an interface (like Netscape) where the first time psql is started the terms are presented? How would that work if I justed wanted the server (started like any other service - sendmail, httpd, etc. through linuxconf) and used Access/ODBC as a frontend? Is this requirement something new? Just curious, Mike Mascari
Ned Lilly wrote: > > That chose of > law/jurisdiction, BTW, is different from choice of *venue* - Sevo > Stille worried that he might have to travel to Virginia for his day > in court. The two things are separate. In the US. In Europe, you usually cannot choose a jurisdiction other than that of the venue. A choice of jurisdiction could be considered an acceptance of the accompanying venue. This may not matter much in a liabilities case, as consumer protection rights will often grant them a local court whatever the license may say. But I am wary of the consequences for any situation where I might want to sue an American company. > On a related note, if PostgreSQL is being marketed in the US, it > will be subject to US law - regardless of where the project says > it's "based." Indeed it will be subject to local law whereever it is "marketed", if the latter can apply to freeware. But the opponent might have the right to accept my choice of venue as stated in the license, and I'd rather not make any statement that could imply that to be overseas. > Previous contributions: A couple of people asked, ok, so this is a > proposed solution for future code contributions - what about the > existing stuff? We'd suggest that anyone who is currently > contributing patches could say, in effect, "this goes retroactively > for everything else I've committed in the past" - which granted > wouldn't get us all the way there, but probably close to 80%. > Again, the goal is indemnifcation of the developers who aren't > coverered as Berkeley-era contributors. Our lawyers tell us this is > do-able if people want to do it. Thoughts? The contributors certainly could release their hold on any rights they may still have. But while you can waive your rights retrocatively, you usually cannot reclaim a right you've already given away, without the explicit consent of the other side. We might end up with all disadvantages the change brings holding up in court, while the changes to our advantage might be ruled out on the base of the previous license. Sevo -- Sevo Stille sevo@ip23.net
Mike Mascari wrote:
> Ned Lilly wrote:
> >
> >
> > The second point, forcing a click-through or some other mechanism
> > before a user downloads/installs the software, gets at the same
> > issue. As a developer, you only get the protection of UCITA if the
> > user *agrees* to the license... right now, just having it in the
> > tarball or on the CD doesn't meet that test. There needs to be some
> > proactive mechanism that signifies user acceptance of the terms, or
> > else the license is just words. The recent passage in the US of
> > digital signature legislation affirms the various mechanisms by
> > which you can do that.
>
> How does this affect the presence of PostgreSQL on RedHat
> distributions, where no such agreement is made? Would it require
> an interface (like Netscape) where the first time psql is started
> the terms are presented? How would that work if I justed wanted
> the server (started like any other service - sendmail, httpd,
> etc. through linuxconf) and used Access/ODBC as a frontend? Is
> this requirement something new?
Seems to be something new in the open source world. Most
commercial software I've seen doesn't install if you don't
accept the license terms in such a click-through way (did you
ever install some MS products?).
As a developer, I like to get the protection. So if the
wording in the tarball doesn't buy it for me, it's wasted
bandwidth and we should better remove it.
For source distributions I think it's easy to add such a step
to the configure process. A switch like --accept-license that
just suppresses the y/n question (not the displaying of the
license itself) should do it for the hackers.
So the problem left are binary distributions.
I'm in doubt why none of the other open source projects ever
felt the need to enforce license agreement in this way while
most commercial players do. Maybe it's something we don't
have to worry about, but what if so? What if we all have
already one foot in jail and just don't know? Oh boy, what
about all the patches, modules, whatnot I contributed to
other open source projects during the past 20 years? Can I
sleep well tonight?
Well, most of the things I've done in the past 20 years don't
made it that far that they became a threat for some big
player. This time it's different and I welcome any real
lawyers advice. If it means we cannot distribute binaries
unless the install procedures provide a license-click-through
feature, that might be it until they do.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
At 02:36 5/07/00 +0200, Jan Wieck wrote:
>
> So the problem left are binary distributions.
>
There might be a technical solution here; I *think* RPM allows pretty
flexible running of scripts. We could only make binary distributions for
architectures that support RPM.
We could also pop up a message on 'initdb', or the first time the
postmaster is started etc etc.
We might even want to be really paranoid, and warn each user when they
first go into psql...I provide WWW services, and part of that service is
access to PG. My agreements always limit my liabilities, but these users
never see the BSD waiver of PG...
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
Philip Warner wrote: > There might be a technical solution here; I *think* RPM allows pretty > flexible running of scripts. We could only make binary distributions for > architectures that support RPM. > > We could also pop up a message on 'initdb', or the first time the > postmaster is started etc etc. > > We might even want to be really paranoid, and warn each user when they > first go into psql...I provide WWW services, and part of that service is > access to PG. My agreements always limit my liabilities, but these users > never see the BSD waiver of PG... Then what happens if I fork the project and remove all these printf's from the code? Read the GPL and LGPL - they have thought of these issues. It just shows you can't "fix" the BSD licence with a couple of quick-fix add-ons. I propose the exclusion clause in COPYRIGHT be widened to include everyone in the universe and leave it at that. In reality it's the only change that is going to get up.
Chris Bitmead wrote: > > Philip Warner wrote: > > > There might be a technical solution here; I *think* RPM allows pretty > > flexible running of scripts. We could only make binary distributions for > > architectures that support RPM. > > > > We could also pop up a message on 'initdb', or the first time the > > postmaster is started etc etc. > > > > We might even want to be really paranoid, and warn each user when they > > first go into psql...I provide WWW services, and part of that service is > > access to PG. My agreements always limit my liabilities, but these users > > never see the BSD waiver of PG... > > Then what happens if I fork the project and remove all these printf's > from the code? > > Read the GPL and LGPL - they have thought of these issues. It just shows > you can't "fix" the BSD licence with a couple of quick-fix add-ons. I > propose the exclusion clause in COPYRIGHT be widened to include everyone > in the universe and leave it at that. In reality it's the only change > that is going to get up. Yes. It should read (in a nutshell): Do whatever the hell you want with this software, but use it at your own risk. Mike Mascari
At 14:38 5/07/00 +1000, Chris Bitmead wrote:
>
>Then what happens if I fork the project and remove all these printf's
>from the code?
Then I'd guess that the organization that removed them becomes liable.
That's why they're there.
>Read the GPL and LGPL - they have thought of these issues. It just shows
>you can't "fix" the BSD licence with a couple of quick-fix add-ons. I
>propose the exclusion clause in COPYRIGHT be widened to include everyone
>in the universe and leave it at that. In reality it's the only change
>that is going to get up.
I agree. But I'd like to propose a further addition to the exclusions
regarding limiting liabilities. I'll send it to the list ASAP.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
Philip Warner wrote: > > At 14:38 5/07/00 +1000, Chris Bitmead wrote: > > > >Then what happens if I fork the project and remove all these printf's > >from the code? > > Then I'd guess that the organization that removed them becomes liable. > That's why they're there. Putting aside that I don't think anybody is liable anyway... I could fork postgres, then sit on pgsql-patches applying them all as they come along, and go around claiming that my postgres is the "one true". Tenuous I know, but then the whole idea of getting sued by someone you have no contract with is pretty tenuous.
At 15:11 5/07/00 +1000, Chris Bitmead wrote:
>
>Putting aside that I don't think anybody is liable anyway... I could
>fork postgres, then sit on pgsql-patches applying them all as they come
>along, and go around claiming that my postgres is the "one true".
>Tenuous I know, but then the whole idea of getting sued by someone you
>have no contract with is pretty tenuous.
>
They key issue here (I'd guess) is where the software came from.
But I agree - it's just a total nightmare when you start getting into this.
eg. one of the questions I am waiting on an answer for if whether Marc can
be sued because he provided the software from his server.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
Hi,
I have some problem to understand why you have to change the PostgreSQL
Licence
agreement. You are really making confusion into my mind. For me I have this
licence
come with all my distributions :
PostgreSQL Data Base Management System (formerly known as Postgres,
then as Postgres95).
Copyright (c) 1994-7 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.
etc...
This the most open licence you can do, isn't it ?
It just come a commercial company and things must change, why ? There's
already companies
saling PostgreSQL as a commercial product (see Adabas or Ingres it's looks
like Postgres !).
If you do OSS and give all the code to the community for free, what do you
have to be protected from
that is not done ?
Your discussion seems to applies to all current programmers of PostgreSQL,
but what about
the olders, are they agree with this ? And if the copyrigth belong to the
University of California
what programmers can do to protect their works ?
Apology my poor understanding but it smell something wrong for me. Is
PostgreSQL Inc. have
the same need than Landmark/Great Bridge concerning this licence migration
?
Regards,
Gilles DAROLD
On Wed, 5 Jul 2000, Gilles DAROLD wrote: > Hi, > > I have some problem to understand why you have to change the PostgreSQL > Licence > agreement. You are really making confusion into my mind. For me I have this > licence > come with all my distributions : > > PostgreSQL Data Base Management System (formerly known as Postgres, > then as Postgres95). > > Copyright (c) 1994-7 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. > > etc... > > This the most open licence you can do, isn't it ? > > It just come a commercial company and things must change, why ? There's > already companies > saling PostgreSQL as a commercial product (see Adabas or Ingres it's looks > like Postgres !). > > If you do OSS and give all the code to the community for free, what do you > have to be protected from > that is not done ? > > Your discussion seems to applies to all current programmers of PostgreSQL, > but what about > the olders, are they agree with this ? And if the copyrigth belong to the > University of California > what programmers can do to protect their works ? > > Apology my poor understanding but it smell something wrong for me. > Is PostgreSQL Inc. have the same need than Landmark/Great Bridge > concerning this licence migration ? Nope ... this is purely a perceived problem by the Landmark/Great Bridge folk ... one that I can't count how many OSS projects out there don't/haven't felt a need for *shrug*
Philip Warner wrote: > > At 02:36 5/07/00 +0200, Jan Wieck wrote: > > > > So the problem left are binary distributions. > > > > There might be a technical solution here; I *think* RPM allows pretty > flexible running of scripts. We could only make binary distributions for > architectures that support RPM. RPM does allow this. But it does sort of screw up the distribution process to have all these dialogs in the RPMS. With redhat, I fire up the installation and walk away because redhat has been pretty religious about suppressing dialogs. With debian, I fire up the install, then keep comimg back to the machine every 15 minute because one package or another is waiting for me to enter a few keystrokes (NOTE to distribution partisans - there are things I like better about each distribution - I'm not advocating one over the other here) > We could also pop up a message on 'initdb', or the first time the > postmaster is started etc etc. On initdb seems reasonable, and gets around the issue above. > We might even want to be really paranoid, and warn each user when they > first go into psql...I provide WWW services, and part of that service is > access to PG. My agreements always limit my liabilities, but these users > never see the BSD waiver of PG... Why don't they? The installer accepts the license. It is then the role of the installer to ensure that all the people he/she supports understand how the software may be used, IMHO. For instance, unless I am the installer of M$ Office, I don't see the shrink wrap. Which means nearly all users in an office don't see the shrink wrap. But that seems okay to M$. I would urge that this issue of actively acknowleging license not be carried too far. In the extreme, imagine connecting to a MS IIS web server, it checks afor a unique cookie on your machine and says "Hmm - I don't know that this user has ever connected to IIS before - they have not been to my site - so I'd better pop up a dialog first" IMHO, it is your responsibilty os the provider of services to make your users aware of the various licenses that apply. If PG adopts something like the above mechanism, then you may well want to have a dialog for your users to do just that. But PG should not dictate how I interact with my users. Instead of disturbing my web users, maybe there should be an additional requirement in the license that says people who repackage postgres, or make it available through other means, are responsible for ensuring that the users are aware of the license requirements. Then a RedHat type vendor can add the PG license to their intro screen, or they can leave a message in initdb active. PG could provide tools to make notification on first connect easier, but I do not believe that needs to be enforced by PG. Come to think of it, this sort of propagation clause may be needed anyway. Otheriwse, I could download PG by clicking through your license screen on the website, then post it to an ftp repository somewhere. Once I've done that, it seems to me that someone downloading from my ftp site would never acknowlege the license, and there you are on the hook again. Right now the BSD handles this passive for the passive case - the license stipulates that the license must appear in derivative products. If active acknowlegement is required (not that I like the idea, but if it is required to protect developers) then that active aknowlegement must somehow stipulate that all deriviative products need to include some similar form of active acknowlegement. Otherwise you will never be able to distribute source, and it won't be open source anymore. -- Karl DeBisschop
Philip Warner <pjw@rhyme.com.au> writes: > At 02:36 5/07/00 +0200, Jan Wieck wrote: > > > > So the problem left are binary distributions. > > > > There might be a technical solution here; I *think* RPM allows pretty > flexible running of scripts Yes. But it is designed to be a non-interactive backend. -- Trond Eivind Glomsrød Red Hat, Inc.
The Hermit Hacker <scrappy@hub.org> writes:
> On Wed, 5 Jul 2000, Gilles DAROLD wrote:
>> Is PostgreSQL Inc. have the same need than Landmark/Great Bridge
>> concerning this licence migration ?
> Nope ... this is purely a perceived problem by the Landmark/Great Bridge
> folk ... one that I can't count how many OSS projects out there
> don't/haven't felt a need for *shrug*
Au contraire --- we have had repeated discussions in the past about the
license, and quite a few folks have expressed concern that we need to
alter the pure Berkeley language we inherited. This particular proposal
is from Great Bridge and has some stuff in it that was never proposed
before, but please don't claim that there's not been any perceived
problem. There has been.
I'm not sold on adopting Great Bridge's proposal as-is, but this is a
fine opportunity to fix those concerns that have come up again and
again. We should do *something*, preferably something that looks
good to real lawyers (as many as we can get to look at the problem).
As Ned pointed out, you don't want lawyers hacking on the guts of
Postgres, and you shouldn't want hackers hacking on the license either.
We don't know what we're doing in that sphere.
regards, tom lane
Ned Lilly writes: > With all due respect to the rest of the world, the UCITA provisions in > Virginia and Maryland, soon to make their way across the rest of the > US, lead the world in protecting developers from liability - and > that's our goal. Considering that you, AFAICT, don't know anything about the laws outside of the U.S., I'll take that as speculation. > Without a specified jurisdiction, the aggrieved party can shop around > for where *he* thinks he has the best shot of screwing you. That is definitely false. > The second point, forcing a click-through or some other mechanism > before a user downloads/installs the software, gets at the same issue. I'll tell you right now, you might as well forget about that. PostgreSQL would be laughed out of the building if we did that. > The recent passage in the US of digital signature legislation affirms > the various mechanisms by which you can do that. The PostgreSQL servers are in Canada, thankyouverymuch. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
On Wed, 5 Jul 2000, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > On Wed, 5 Jul 2000, Gilles DAROLD wrote: > >> Is PostgreSQL Inc. have the same need than Landmark/Great Bridge > >> concerning this licence migration ? > > > Nope ... this is purely a perceived problem by the Landmark/Great Bridge > > folk ... one that I can't count how many OSS projects out there > > don't/haven't felt a need for *shrug* > > Au contraire --- we have had repeated discussions in the past about the > license, and quite a few folks have expressed concern that we need to > alter the pure Berkeley language we inherited. This particular proposal > is from Great Bridge and has some stuff in it that was never proposed > before, but please don't claim that there's not been any perceived > problem. There has been. Oops, sorry ... I *do* like the extra BOLD stuff, as I like the fact that it extends the license to cover non-UNIVERSITY developers ... hadn't meant to make it such an 'all-encompassing' statement ... as you state, there are bits of it that I do like ... But, I am also firmly of the opinion that if the BSD license "as is" was such a big problem legal, projects like the *BSDs would have long changed theirs ... the FreeBSD folks have their own 'retained legal counsel' that they've been workign with through the whole cryptography debate, so I don't think that they would have overlooked this if it was a problem ... Personally, I'd like the whole thing weeded down to ... get rid of the 'juristiction of ...' (which nobody outside of the US will agree to, from what I've been seeing on the list) ... and get rid of "Any person who contributes ..." paragraph, which several ppl have voiced a concern about, and we might have something that non-US developers can agree to ... can someone also explain to me what ", NEED, OR QUALITY, AND ANY IMPLIED WARRANTY FROM COURSE OF DEALING OR USAGE OF TRADE. IN ADDITION, THERE IS NO IMPLIED WARRANTY AGAINST INTERFERENCE WITH ENJOYMENT OR AGAINST INFRINGEMENT." is supposed to mean? what the hell is "INTERFERENCE WITH ENJOYMENT OR AGAINST INFRINGEMENT"? =============== PostgreSQL Data Base Management System (formerly known as Postgres95) This directory contains the _______ release of PostgreSQL, as well as various post-release patches in the patches directory. See INSTALL for the installation notes and HISTORY for the changes. We also have a WWW home page located at: http://www.postgreSQL.org ------------------------- PostgreSQL is not public domain software. It is copyrighted by the University of California but may be used according to the following licensing terms: POSTGRES95 Data Base Management System (formerly known as Postgres, then as Postgres95). Copyright (c) 1994-8 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 MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. ------------------------- Copyright ( 1996, 1997, 1998, 1999, 2000 by various contributors (as identified in HISTORY) (collectively "Developers") which may be used according to the following licensing terms: Worldwide 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, on a non-exclusive basis, provided that the above copyright notice, this paragraph and the following paragraphs appear in all copies: IN NO EVENT SHALL ANY DEVELOPER BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE DEVELOPER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THE DEVELOPERS SPECIFICALLY DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NEED, OR QUALITY, AND ANY IMPLIED WARRANTY FROM COURSE OF DEALING OR USAGE OF TRADE. IN ADDITION, THERE IS NO IMPLIED WARRANTY AGAINST INTERFERENCE WITH ENJOYMENT OR AGAINST INFRINGEMENT. THE SOFTWARE AND DOCUMENTATION PROVIDED HEREUNDER IS ON AN "AS IS" BASIS. NO DEVELOPER HAS ANY OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS OR MODIFICATIONS TO OR FOR THE SOFTWARE OR DOCUMENTATION. BY USING THIS SOFTWARE YOU AGREE TO THESE TERMS AND CONDITIONS. IF YOU DO NOT AGREE TO THESE TERMS AND CONDITIONS, YOU SHOULD NOT USE THIS SOFTWARE.
>But, I am also firmly of the opinion that if the BSD license "as is" >was such a big problem legal, projects like the *BSDs would have long >changed theirs ... the FreeBSD folks have their own 'retained legal >counsel' that they've been workign with through the whole >cryptography debate, so I don't think that they would have overlooked >this if it was a problem ... > >Personally, I'd like the whole thing weeded down to ... get rid of >the 'juristiction of ...' (which nobody outside of the US will agree >to, from what I've been seeing on the list) ... and get rid of "Any >person who contributes ..." paragraph, which several ppl have voiced >a concern about, and we might have something that non-US developers >can agree to ... > Why not check with some FreeBSD people to get their opinion in any case. Can't hurt, and it might add quite a bit to an understanding of what should/shouldn't be changed. This is especially true since FreeBSD-BSDI relationship seems to be so similar to the Postgresql-GreatBridge relationship. If the BSD license is faulty, BSD license users should fix it once and as a group, not piecemeal. >can someone also explain to me what ", NEED, OR QUALITY, AND ANY >IMPLIED WARRANTY FROM COURSE OF DEALING OR USAGE OF TRADE. IN >ADDITION, THERE IS NO IMPLIED WARRANTY AGAINST INTERFERENCE WITH >ENJOYMENT OR AGAINST INFRINGEMENT." is supposed to mean? what the >hell is "INTERFERENCE WITH ENJOYMENT OR AGAINST INFRINGEMENT"? > I am not an attorney, but I think that COURSE OF DEALING AND USAGE OF TRADE refers to affected transactions or potential transactions in e-commerce-like trade, and that INTERFERENCE WITH ENJOYMENT is for the hackers and hobbyists who love to toy with Postgresql and might be deprived of that enjoyment for whatever reason, and that INFRINGEMENT refers to the user's liability for using code that infringes on patents or copyrights. John ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Jan Wieck wrote: > I'm in doubt why none of the other open source projects ever > felt the need to enforce license agreement in this way while > most commercial players do. Maybe it's something we don't > have to worry about, but what if so? What if we all have > already one foot in jail and just don't know? This is exactly the the kind of sentiment that the UCITA proponents sought to make as widespread as possible. > Oh boy, what > about all the patches, modules, whatnot I contributed to > other open source projects during the past 20 years? Can I > sleep well tonight? They thought about that, too. UCITA is designed to be applied retroactively, so you can sleep well knowing that there's nothing you can do to prevent the Maryland residents from suing you for the damages they suffered from your code over the last 20 years. Now if it is true that the UCITA was meant to be a weapon of intimidation, it seems to have started working: everybody is at least concerned, if not scared. But it definitely goes overboard with its retroactive capability, which actually makes it less intimidating: what's the use in worrying about the future if we all have one foot in jail because of our deeds in the past? Back to work, folks ... --Gene
At 02:19 PM 7/5/00 -0500, selkovjr@mcs.anl.gov wrote: > >Jan Wieck wrote: > >> I'm in doubt why none of the other open source projects ever >> felt the need to enforce license agreement in this way while >> most commercial players do. Maybe it's something we don't >> have to worry about, but what if so? What if we all have >> already one foot in jail and just don't know? > >This is exactly the the kind of sentiment that the UCITA proponents >sought to make as widespread as possible. > >> Oh boy, what >> about all the patches, modules, whatnot I contributed to >> other open source projects during the past 20 years? Can I >> sleep well tonight? > >They thought about that, too. UCITA is designed to be applied >retroactively, so you can sleep well knowing that there's nothing you >can do to prevent the Maryland residents from suing you for the >damages they suffered from your code over the last 20 years. Now if it >is true that the UCITA was meant to be a weapon of intimidation, it >seems to have started working: everybody is at least concerned, if not >scared. But it definitely goes overboard with its retroactive >capability, which actually makes it less intimidating: what's the use >in worrying about the future if we all have one foot in jail because >of our deeds in the past? > >Back to work, folks ... > >--Gene > not being from maryland but, i would think that the constitution's prohibition against ex post facto laws would prevent retro-active applications of laws, if the usa actually followed the constitution; but that's another topic... mikeo
Hi Postgresql Colleagues,
I have been a user of Postgresql for a long time and seldom post here, but
after reading the recent fray over license changes, I feel compelled to
post this.
Just to add my miniscule .02 to this discussion.... As a contributor to
open source (and also a commercial developer) for many years, I lament the
fact that lawyers of whatever stripe now seek to both advise and capitalize
on the creativity and generosity of the worldwide technical community who
contribute freely to develop and make available programs like Postgresql.
What a pity! We (at least in the US) live in such a litigious society
(nearly everyone seems unwilling to take responsibility for their own
actions) that we now need legal advice and opinions on how to protect
individuals who give freely of their own time and creativity.
I guess this is why people (and even medical professionals) in the US will
seldom stop to help someone who is in need anymore. (they might get sued
for doing a good deed!!!)
If you are employed by someone like M$ your corporate profits can afford
these high priced prostitutes to keep you safe from law suits by people and
organizations too ignorant to know what they are doing and who are
unwilling to accept responsibility for their own actions. However, if you
are an open source contributor and are intelligent and creative and
contributing to something worthwhile to humanity for zero personal gain...
(such as developing code that overall benefits society), you must still
consort with these vultures for fear you may lose your livelihood to one of
the people you sought to help.
Call me naieve, idealistic, stupid, unrealistic or whatever... but I find
the whole discussion simply an amazing (and also deplorable) commentary on
the current state of affairs.
BTW...are the people who write the VB (aka virus builder) programs such as
the recent "love bug" covered under UCITA?? Perhaps this would be a good
new business venture for the lawyers? I think I remember hearing some FBI
people lamenting the fact that Phillipine law would not permit prosecution.
Maybe we can get them covered under Virginia law also! After all, these
people did slightly more damage in one day than all the bugs in the history
of open source programs like Postgresql. Along the same lines...is
MicroSoft liable for having released VBA? I have not seen any lawsuits
aimed at Bill and the VBA developers for having provided such easily
abusable "functionality" in their product?
Sorry for the rant...
Regards,
Jim
,-,-. ,-,-. ,-,-. ,-,-. ,-
/ / \ \ / / \ \ / / \ \ / / \ \ / /
\ \ / / \ \ / / \ \ / / \ \ / /
`-'-' `-'-' `-'-' `-'-'
--------------------------------------------------------
FSC - Building Better Information Technology Solutions-
From the Production Floor to the Customer's Door.
--------------------------------------------------------
Jim Jennis, Technical Director, Commercial Systems
Fuentez Systems Concepts, Inc.
1 Discovery Place, Suite 2
Martinsburg, WV. 25401 USA.
Phone: +001 (304) 263-0163 ext 235
FAX: +001 (304) 263-0702
Email: jjennis@fuentez.com
jhjennis@shentel.net
Web: http://www.discovery.fuentez.com/
---------------------------------------------------
>not being from maryland but, i would think that the constitution's >prohibition against ex post facto laws would prevent retro-active >applications of laws, if the usa actually followed the constitution; >but that's another topic... Ex post facto seems pretty one way. If you drop a cigg butt on the ground today, and tomorrow your town votes to make it illegal to throw cigg butts on the ground, you aren't held liable unless you do it again, AFTER the law was passed. I'm curious tho - if you sue Oracle today, and UCITA is passed tomorrow, does UCITA wipe out your suit? Rob Nelson rdnelson@co.centre.pa.us
The Hermit Hacker writes: > Personally, I'd like the whole thing weeded down to ... get rid of the > 'juristiction of ...' (which nobody outside of the US will agree to, from > what I've been seeing on the list) ... and get rid of "Any person who > contributes ..." paragraph, which several ppl have voiced a concern about, > and we might have something that non-US developers can agree to ... > > can someone also explain to me what ", NEED, OR QUALITY, AND ANY IMPLIED > WARRANTY FROM COURSE OF DEALING OR USAGE OF TRADE. IN ADDITION, THERE IS > NO IMPLIED WARRANTY AGAINST INTERFERENCE WITH ENJOYMENT OR AGAINST > INFRINGEMENT." is supposed to mean? what the hell is "INTERFERENCE WITH > ENJOYMENT OR AGAINST INFRINGEMENT"? It means if you don't enjoy it, you can't sue. :-) I don't see any point for not using the same BOLD (or the same text, for that matter) that the UCB used, as has been suggested a hundred times before. We'd make the extra point of "Licenses are so stupid, they make us write this twice." -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden