Re: Table Spaces

> >> >We've looked at it before. Apart from anything else I don't think
> >> >its license is compatible with PostgreSQL's.
> >>
> >> Well, people can still use it. We just can't distribute
> it... We can
> >> always link to it.
> >> But unless there is a GUI tool (actually, unless it shows up in the
> >> *default* GUI tool), expect there to be questions. An
> >
> > I assume we can just look at the source and write our own version
> > bypassing any license.
>
> I wouldn't be so sure about that. If this insane SCO crap has
> taught me anything, the PostgreSQL should have a defined and
> legally vetted process for duplicating functionality. ala'
> phoenix BIOS.

There is more than enough information om MSDN and other sites to make
this kind of tool without looking at the source. It's generic enough.

//Magnus

>> >> >We've looked at it before. Apart from anything else I don't think
>> >> >its license is compatible with PostgreSQL's.
>> >>
>> >> Well, people can still use it. We just can't distribute
>> it... We can
>> >> always link to it.
>> >> But unless there is a GUI tool (actually, unless it shows up in the
>> >> *default* GUI tool), expect there to be questions. An
>> >
>> > I assume we can just look at the source and write our own version
>> > bypassing any license.
>>
>> I wouldn't be so sure about that. If this insane SCO crap has
>> taught me anything, the PostgreSQL should have a defined and
>> legally vetted process for duplicating functionality. ala'
>> phoenix BIOS.
>
> There is more than enough information om MSDN and other sites to make
> this kind of tool without looking at the source. It's generic enough.

Let's just make sure we keep records of the generic sources of where we
find things. I get *really* scared when I see sentences like "I assume we
can just look at the source and write our own version bypassing any
license." That is categorically a false asumption and will create an
arguably derived product. The last thing we want is Oracle or Microsoft
trying to pull an SCO on Postgresql.

pgsql(at)mohawksoft(dot)com wrote:
> >> >> >We've looked at it before. Apart from anything else I don't think
> >> >> >its license is compatible with PostgreSQL's.
> >> >>
> >> >> Well, people can still use it. We just can't distribute
> >> it... We can
> >> >> always link to it.
> >> >> But unless there is a GUI tool (actually, unless it shows up in the
> >> >> *default* GUI tool), expect there to be questions. An
> >> >
> >> > I assume we can just look at the source and write our own version
> >> > bypassing any license.
> >>
> >> I wouldn't be so sure about that. If this insane SCO crap has
> >> taught me anything, the PostgreSQL should have a defined and
> >> legally vetted process for duplicating functionality. ala'
> >> phoenix BIOS.
> >
> > There is more than enough information om MSDN and other sites to make
> > this kind of tool without looking at the source. It's generic enough.
>
> Let's just make sure we keep records of the generic sources of where we
> find things. I get *really* scared when I see sentences like "I assume we
> can just look at the source and write our own version bypassing any
> license." That is categorically a false asumption and will create an
> arguably derived product. The last thing we want is Oracle or Microsoft
> trying to pull an SCO on Postgresql.

Usually we look at the source, find out how they do it, then find the
docs for the underlying functions, and use that.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

pgsql(at)mohawksoft(dot)com wrote:
> >> Let's just make sure we keep records of the generic sources of where we
> >> find things. I get *really* scared when I see sentences like "I assume
> >> we
> >> can just look at the source and write our own version bypassing any
> >> license." That is categorically a false asumption and will create an
> >> arguably derived product. The last thing we want is Oracle or Microsoft
> >> trying to pull an SCO on Postgresql.
> >
> > Usually we look at the source, find out how they do it, then find the
> > docs for the underlying functions, and use that.
>
> This makes me worried. That's the way we *used* to do things, but the
> sleazy IP lawyers are looking for anything with which they can create the
> impression of impropriety. The open source and free projects are ground
> zero for this crap.
>
> We *really* need to be careful.

I assumed this tool was GPL and we just needed to avoid the GPL issue.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> pgsql(at)mohawksoft(dot)com wrote:
>> >> >> >We've looked at it before. Apart from anything else I don't think
>> >> >> >its license is compatible with PostgreSQL's.
>> >> >>
>> >> >> Well, people can still use it. We just can't distribute
>> >> it... We can
>> >> >> always link to it.
>> >> >> But unless there is a GUI tool (actually, unless it shows up in
>> the
>> >> >> *default* GUI tool), expect there to be questions. An
>> >> >
>> >> > I assume we can just look at the source and write our own version
>> >> > bypassing any license.
>> >>
>> >> I wouldn't be so sure about that. If this insane SCO crap has
>> >> taught me anything, the PostgreSQL should have a defined and
>> >> legally vetted process for duplicating functionality. ala'
>> >> phoenix BIOS.
>> >
>> > There is more than enough information om MSDN and other sites to make
>> > this kind of tool without looking at the source. It's generic enough.
>>
>> Let's just make sure we keep records of the generic sources of where we
>> find things. I get *really* scared when I see sentences like "I assume
>> we
>> can just look at the source and write our own version bypassing any
>> license." That is categorically a false asumption and will create an
>> arguably derived product. The last thing we want is Oracle or Microsoft
>> trying to pull an SCO on Postgresql.
>
> Usually we look at the source, find out how they do it, then find the
> docs for the underlying functions, and use that.

This makes me worried. That's the way we *used* to do things, but the
sleazy IP lawyers are looking for anything with which they can create the
impression of impropriety. The open source and free projects are ground
zero for this crap.

We *really* need to be careful.

> pgsql(at)mohawksoft(dot)com wrote:
>
>> This makes me worried. That's the way we *used* to do things, but the
>> sleazy IP lawyers are looking for anything with which they can create
>> the
>> impression of impropriety. The open source and free projects are ground
>> zero for this crap.
>>
>> We *really* need to be careful.
>
> I assumed this tool was GPL and we just needed to avoid the GPL issue.

I'm probably just being alarmist, but think about some IP lawyer buying up
the entity that owns the GPL code, and suing end user's of PostgreSQL.

This is similar to what is happening in Linux land with SCO.

The best defense is to say, nope, we didn't copy your stuff, we
implemented it ourselves based on the documentation.

On Wednesday 19 May 2004 00:19, pgsql(at)mohawksoft(dot)com wrote:
> > pgsql(at)mohawksoft(dot)com wrote:
> >> This makes me worried. That's the way we *used* to do things, but the
> >> sleazy IP lawyers are looking for anything with which they can create
> >> the
> >> impression of impropriety. The open source and free projects are ground
> >> zero for this crap.
> >>
> >> We *really* need to be careful.
> >
> > I assumed this tool was GPL and we just needed to avoid the GPL issue.
>
> I'm probably just being alarmist, but think about some IP lawyer buying up
> the entity that owns the GPL code, and suing end user's of PostgreSQL.
>
> This is similar to what is happening in Linux land with SCO.
>
> The best defense is to say, nope, we didn't copy your stuff, we
> implemented it ourselves based on the documentation.

by that argument, the license of documentation should matter too.. Isn't it?

Shridhar

> On Wednesday 19 May 2004 00:19, pgsql(at)mohawksoft(dot)com wrote:
>> > pgsql(at)mohawksoft(dot)com wrote:
>> >> This makes me worried. That's the way we *used* to do things, but the
>> >> sleazy IP lawyers are looking for anything with which they can create
>> >> the
>> >> impression of impropriety. The open source and free projects are
>> ground
>> >> zero for this crap.
>> >>
>> >> We *really* need to be careful.
>> >
>> > I assumed this tool was GPL and we just needed to avoid the GPL issue.
>>
>> I'm probably just being alarmist, but think about some IP lawyer buying
>> up
>> the entity that owns the GPL code, and suing end user's of PostgreSQL.
>>
>> This is similar to what is happening in Linux land with SCO.
>>
>> The best defense is to say, nope, we didn't copy your stuff, we
>> implemented it ourselves based on the documentation.
>
> by that argument, the license of documentation should matter too.. Isn't
> it?

If the documentation is "proprietary and confidential" then maybe, but if
it is publically available and its purpose is to show you various
techniques, then probably not.

I'm not a lawyer, but I have had to be sensitive to some of these issues.
One of SCO's strategies is to liken source code with music. Arguing that
it is "like ours" so it is derivitive. I'm not sure if that will fly in
court, but it has worked in music suits.

All I'm saying is we should all be mindfull of the various IP law
land-mines currently planted in our industry.

pgsql(at)mohawksoft(dot)com wrote:

>>On Wednesday 19 May 2004 00:19, pgsql(at)mohawksoft(dot)com wrote:
>>
>>
>>>>pgsql(at)mohawksoft(dot)com wrote:
>>>>
>>>>
>>>>>This makes me worried. That's the way we *used* to do things, but the
>>>>>sleazy IP lawyers are looking for anything with which they can create
>>>>>the
>>>>>impression of impropriety. The open source and free projects are
>>>>>
>>>>>
>>>ground
>>>
>>>
>>>>>zero for this crap.
>>>>>
>>>>>We *really* need to be careful.
>>>>>
>>>>>
>>>>I assumed this tool was GPL and we just needed to avoid the GPL issue.
>>>>
>>>>
>>>I'm probably just being alarmist, but think about some IP lawyer buying
>>>up
>>>the entity that owns the GPL code, and suing end user's of PostgreSQL.
>>>
>>>This is similar to what is happening in Linux land with SCO.
>>>
>>>The best defense is to say, nope, we didn't copy your stuff, we
>>>implemented it ourselves based on the documentation.
>>>
>>>

The safe bet if we want to use junction points is to use clean room
techniques. I understand from other comments that it wouldn't be difficult.

cheers

andrew

pgsql(at)mohawksoft(dot)com wrote:
> I'm probably just being alarmist, but think about some IP lawyer buying up
> the entity that owns the GPL code, and suing end user's of PostgreSQL.

You cannot retrospectively change the terms of a license unless the
licensee agrees to it. If something is released GPL, then the GPL
applies to that code and subsequent derivatives - that's the point of
the GPL.

The new "owner" may change the terms of a license for new distributions
of a package, assuming they actually own all the IP, and this is what I
understand is the SCO issue. SCO claim that code that was distributed
was done so without permission.

For an opposite effect, see the origins of the OpenSSH project; to
summarise, folks found than an older version of a (at that time) vaguely
licensed ssh was BSD licensed ans it was used as a base for a new
product - namely OpenSSH.

rgds,
--
Peter

Peter Galbavy wrote:

> pgsql(at)mohawksoft(dot)com wrote:
>
>> I'm probably just being alarmist, but think about some IP lawyer
>> buying up
>> the entity that owns the GPL code, and suing end user's of PostgreSQL.
>
>
> You cannot retrospectively change the terms of a license unless the
> licensee agrees to it. If something is released GPL, then the GPL
> applies to that code and subsequent derivatives - that's the point of
> the GPL.
>
> The new "owner" may change the terms of a license for new
> distributions of a package, assuming they actually own all the IP, and
> this is what I understand is the SCO issue. SCO claim that code that
> was distributed was done so without permission.
>
> For an opposite effect, see the origins of the OpenSSH project; to
> summarise, folks found than an older version of a (at that time)
> vaguely licensed ssh was BSD licensed ans it was used as a base for a
> new product - namely OpenSSH.
>

The code in question is not covered by the GPL, IIRC, which makes this
somewhat moot. The README that comes with it says:

Terms of Use
------------

This software is provided "as is", without any guarantee made
as to its suitability or fitness for any particular use. It may
contain bugs, so use of this tool is at your own risk. We take
no responsilbity for any damage that may unintentionally be caused
through its use.

You may not distribute this tool without the express written
permission of Mark Russinovich.

cheers

andrew

> pgsql(at)mohawksoft(dot)com wrote:
>> I'm probably just being alarmist, but think about some IP lawyer buying
>> up
>> the entity that owns the GPL code, and suing end user's of PostgreSQL.
>
> You cannot retrospectively change the terms of a license unless the
> licensee agrees to it. If something is released GPL, then the GPL
> applies to that code and subsequent derivatives - that's the point of
> the GPL.
>
> The new "owner" may change the terms of a license for new distributions
> of a package, assuming they actually own all the IP, and this is what I
> understand is the SCO issue. SCO claim that code that was distributed
> was done so without permission.

Imagine this scenario:

OpenFoobar is released as GPL. Portions of his code are found in
PostgreSQL. The new owner of OpenFoobar is an IP lawyer. They claim
ownership of code "derived" from "his" code. There is now a valid, or at
least legally arguable, argument that PostgreSQL now demands GPL source
availability.

I use PostgreSQL as a database foundation or my search-engine. Much of my
system is open source, but there are portions which are not. If the IP
lawyer is a competitor, he can force me to release my code.

We do not want to open up the BSD vs GPL debate, but keeping PG as a BSD
license does take an amount of accounting.

> Peter Galbavy wrote:
>
>> pgsql(at)mohawksoft(dot)com wrote:
>>
>>> I'm probably just being alarmist, but think about some IP lawyer
>>> buying up
>>> the entity that owns the GPL code, and suing end user's of PostgreSQL.
>>
>>
>> You cannot retrospectively change the terms of a license unless the
>> licensee agrees to it. If something is released GPL, then the GPL
>> applies to that code and subsequent derivatives - that's the point of
>> the GPL.
>>
>> The new "owner" may change the terms of a license for new
>> distributions of a package, assuming they actually own all the IP, and
>> this is what I understand is the SCO issue. SCO claim that code that
>> was distributed was done so without permission.
>>
>> For an opposite effect, see the origins of the OpenSSH project; to
>> summarise, folks found than an older version of a (at that time)
>> vaguely licensed ssh was BSD licensed ans it was used as a base for a
>> new product - namely OpenSSH.
>>
>
> The code in question is not covered by the GPL, IIRC, which makes this
> somewhat moot. The README that comes with it says:
>
> Terms of Use
> ------------
>
> This software is provided "as is", without any guarantee made
> as to its suitability or fitness for any particular use. It may
> contain bugs, so use of this tool is at your own risk. We take
> no responsilbity for any damage that may unintentionally be caused
> through its use.
>
> You may not distribute this tool without the express written
> permission of Mark Russinovich.

Then by no means should *any* of that code be included into PostgreSQL. In
fact, comments should not even make reference to it.

pgsql(at)mohawksoft(dot)com wrote:
> Imagine this scenario:
>
> OpenFoobar is released as GPL. Portions of his code are found in
> PostgreSQL. The new owner of OpenFoobar is an IP lawyer. They claim
> ownership of code "derived" from "his" code. There is now a valid, or
> at least legally arguable, argument that PostgreSQL now demands GPL
> source availability.
>
> I use PostgreSQL as a database foundation or my search-engine. Much of
> my system is open source, but there are portions which are not. If the
> IP lawyer is a competitor, he can force me to release my code.

This is a common misconception. It ain't so. According to Eblen Moglen:

"The claim that a GPL violation could lead to the forcing open of
proprietary code that has wrongfully included GPL'd components is simply
wrong. There is no provision in the Copyright Act to require distribution
of infringing work on altered terms. What copyright plaintiffs are
entitled to, under the Act, are damages, injunctions to prevent infringing
distribution, and--where appropriate--attorneys' fees. A defendant found
to have wrongfully included GPL'd code in its own proprietary work can be
mulcted in damages for the distribution that has already occurred, and
prevented from distributing its product further. That's a sufficient
disincentive to make wrongful use of GPL'd program code. And it is all
that the Copyright Act permits."

I have mixed feelings about the GPL myself, but I hate seeing this FUD so
frequently.

In any case, the whole thing that kicked off this discussion is *not* GPL
software. So let's get on with our business.

cheers

andrew

Andrew Dunstan wrote:
> This is a common misconception. It ain't so. According to Eblen Moglen:
>
>
> "The claim that a GPL violation could lead to the forcing open of
> proprietary code that has wrongfully included GPL'd components is simply
> wrong. There is no provision in the Copyright Act to require distribution
> of infringing work on altered terms. What copyright plaintiffs are
> entitled to, under the Act, are damages, injunctions to prevent infringing
> distribution, and--where appropriate--attorneys' fees. A defendant found
> to have wrongfully included GPL'd code in its own proprietary work can be
> mulcted in damages for the distribution that has already occurred, and
> prevented from distributing its product further. That's a sufficient
> disincentive to make wrongful use of GPL'd program code. And it is all
> that the Copyright Act permits."
>
> I have mixed feelings about the GPL myself, but I hate seeing this FUD so
> frequently.
>
> In any case, the whole thing that kicked off this discussion is *not* GPL
> software. So let's get on with our business.

Of course, but the FSF has agreed to drop litigation in some cases if
the proprietary software is released as open source. He is right that
that moving to GPL isn't a legal remedy, but more of a negotiated
settlement. So that is why that idea gets thrown around, so I wouldn't
call it totally FUD.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

How much can we count on the type oid's remaining static from version to
version? It turns out there is a design decision in the jdbc driver that
could fail if they changed from one version to another and the client
connected to both versions.

Also for getUDT, we need to translate type oid's into java type values,
so if we can rely on the oids not changing then it would make it easier.

--
Dave Cramer
519 939 0336
ICQ # 14675561

Dave Cramer wrote:
> How much can we count on the type oid's remaining static from version to
> version? It turns out there is a design decision in the jdbc driver that
> could fail if they changed from one version to another and the client
> connected to both versions.

I don't think we have ever changed oids for existing data types, so you
should be OK.

> Also for getUDT, we need to translate type oid's into java type values,
> so if we can rely on the oids not changing then it would make it easier.

Right. There has never been a reason to change them, and there is a
downside if we were to change them.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

>>You may not distribute this tool without the express written
>>permission of Mark Russinovich.
>
>
> Then by no means should *any* of that code be included into PostgreSQL. In
> fact, comments should not even make reference to it.

May I point out that there is a heap of debate about whether or not we
can use a windows API call legally (yes we can), and a big lump of
not-testing-tablespaces patch going on :)

Chris

> I don't think we have ever changed oids for existing data types, so you
> should be OK.

Are you sure? If we remove a type, then its oid becomes up for grabs by
the unused_oids script.

We have removed a few functions in 7.4 (oidsrand, etc.) and I wouldn't
be surprised if we haven't _already_ reused those oids...

I think the core should mandate it as policy never to reuse oids and
perhaps make the unused_oids script "remember" what has been used...

Chris

pgsql(at)mohawksoft(dot)com wrote:

>> Peter Galbavy wrote:
>>
>> You may not distribute this tool without the express written
>> permission of Mark Russinovich.
>
> Then by no means should *any* of that code be included into PostgreSQL. In
> fact, comments should not even make reference to it.

Does anybody have that "written permission" to include this code into
PostgreSQL and redistribute it under the BSD license? If not, the code
has to be rejected at this moment.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

Christopher Kings-Lynne wrote:
> > I don't think we have ever changed oids for existing data types, so you
> > should be OK.
>
> Are you sure? If we remove a type, then its oid becomes up for grabs by
> the unused_oids script.

True, but have we ever removed types? I can't think of one.

> We have removed a few functions in 7.4 (oidsrand, etc.) and I wouldn't
> be surprised if we haven't _already_ reused those oids...

Yes, for functions that is very true.

> I think the core should mandate it as policy never to reuse oids and
> perhaps make the unused_oids script "remember" what has been used...

Oh, yea, we could do that. In fact, we are only use 25% of available
system oids (from unused_oids):

2546 - 9999

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> True, but have we ever removed types? I can't think of one.

Hmmm...perhaps.

>>We have removed a few functions in 7.4 (oidsrand, etc.) and I wouldn't
>>be surprised if we haven't _already_ reused those oids...
>
> Yes, for functions that is very true.

I wonder if that has any implications for future binary upgrade tools...

Chris

Christopher Kings-Lynne wrote:
> > True, but have we ever removed types? I can't think of one.
>
> Hmmm...perhaps.
>
> >>We have removed a few functions in 7.4 (oidsrand, etc.) and I wouldn't
> >>be surprised if we haven't _already_ reused those oids...
> >
> > Yes, for functions that is very true.
>
> I wonder if that has any implications for future binary upgrade tools...

I don't think so because we use the new system catalogs for upgrades and
just move the user data.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Thu, 20 May 2004, Christopher Kings-Lynne wrote:

> >>You may not distribute this tool without the express written
> >>permission of Mark Russinovich.
> >
> >
> > Then by no means should *any* of that code be included into PostgreSQL. In
> > fact, comments should not even make reference to it.
>
> May I point out that there is a heap of debate about whether or not we
> can use a windows API call legally (yes we can), and a big lump of
> not-testing-tablespaces patch going on :)

Attached is a more recent version with fixes for some memory errors as
well as additional functionality, such as the ability to create
tablespaces with owners other than a superuser.

Thanks,

Gavin

Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> I don't think we have ever changed oids for existing data types, so you
>> should be OK.

> Are you sure? If we remove a type, then its oid becomes up for grabs by
> the unused_oids script.

But if we remove a type then it's a bit moot whether the OID for it
stays constant. For types that have remained present across all
versions I don't think we have ever changed the OID assignment.
I'd be willing to promise that this will stay true for the types
that are "manually" declared in pg_type.h. (As a counterexample,
I think that information_schema.sql creates some domain types, and
those types aren't going to have frozen OIDs.)

> I think the core should mandate it as policy never to reuse oids and
> perhaps make the unused_oids script "remember" what has been used...

Absolutely not worth the trouble. If we were to guarantee not to remove
types, then there might be some value in making such a promise, but we
haven't and won't. (Precedent: the SQL spec itself has added and
dropped datatypes.)

regards, tom lane

>>>You may not distribute this tool without the express written
>>>permission of Mark Russinovich.
>>
>>
>> Then by no means should *any* of that code be included into PostgreSQL.
>> In
>> fact, comments should not even make reference to it.
>
> May I point out that there is a heap of debate about whether or not we
> can use a windows API call legally (yes we can), and a big lump of
> not-testing-tablespaces patch going on :)
>

You can use Windows API calls on Windows just fine. Any debate about that
would be focused on running PostgreSQL (compiled for Windows) under wine,
on some other platform, and that would be focused on the Wine project.

More to the point. If you designed a feature of PostgreSQL for Windows,
and kept the Windows API call and syntax, but coded it for Linux and BSD
using the Windows API, then you may be violating copyright.

> pgsql(at)mohawksoft(dot)com wrote:
>> Imagine this scenario:
>>
>> OpenFoobar is released as GPL. Portions of his code are found in
>> PostgreSQL. The new owner of OpenFoobar is an IP lawyer. They claim
>> ownership of code "derived" from "his" code. There is now a valid, or
>> at least legally arguable, argument that PostgreSQL now demands GPL
>> source availability.
>>
>> I use PostgreSQL as a database foundation or my search-engine. Much of
>> my system is open source, but there are portions which are not. If the
>> IP lawyer is a competitor, he can force me to release my code.
>
>
> This is a common misconception. It ain't so. According to Eblen Moglen:
>
>
> "The claim that a GPL violation could lead to the forcing open of
> proprietary code that has wrongfully included GPL'd components is simply
> wrong. There is no provision in the Copyright Act to require distribution
> of infringing work on altered terms. What copyright plaintiffs are
> entitled to, under the Act, are damages, injunctions to prevent infringing
> distribution, and--where appropriate--attorneys' fees. A defendant found
> to have wrongfully included GPL'd code in its own proprietary work can be
> mulcted in damages for the distribution that has already occurred, and
> prevented from distributing its product further. That's a sufficient
> disincentive to make wrongful use of GPL'd program code. And it is all
> that the Copyright Act permits."
>
> I have mixed feelings about the GPL myself, but I hate seeing this FUD so
> frequently.

This isn't FUD, I release GPL code. Maybe I detailed a specific
"conclusion" instead of a process. One of the obvious remedies for GPL
"damages" would be to open the code.

>
> In any case, the whole thing that kicked off this discussion is *not* GPL
> software. So let's get on with our business.

Agreed, but, PostgreSQL is a great product/project, it has the ability to
challenge *big* database companies, and *big* companies have blood sucking
IP lawyers. A little care and attention now will pay down the road.

pgsql(at)mohawksoft(dot)com wrote:
> We do not want to open up the BSD vs GPL debate, but keeping PG as a BSD
> license does take an amount of accounting.

I was using GPL as an example, as it was mentioned earlier in the
thread. My comments hold for *any* license, including (at least in the
UK; unfair contracts legislation) licenses that say that they can be
changed by the licensor at a later time without agreement of the licensee.

Peter