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.
Import Notes
Reply to msg id not found: PhilipWarner'smessageofWed05Jul2000141803+1000
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
Import Notes
Resolved by subject fallback
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
