Thread: Re: Table Spaces
> > Alternative database location: > > > > Should this code be removed now? > > Yes, I believe we agreed on this. One of the committers will > take care of that. > > The only downside to removal is that folks without symlinks (I believe > Win32 only) will loose that functionality with nothing to replace it. > However, I think the clarity of removing it is worth it. > Also, I think someone had a special way to do symlinks on > Win32 and we should look into that. If we're talking *directory symlinks only*, it can be done on Win32. It's pretty ugly, the native UI doesn't support showing them etc, but it can be done. (This is only Windows 2000+, not NT4, btw) I still would like a non-symlink solution on Unix as well, but I've noticed I'm with the minority side there, and this is still a lot better than nothing... //Magnus
>>>>The only downside to removal is that folks without symlinks >(I believe >>>>Win32 only) will loose that functionality with nothing to >replace it. >>>>However, I think the clarity of removing it is worth it. >Also, I think >>>>someone had a special way to do symlinks on Win32 and we should look >>>>into that. >>>> >>>> >>>> >>>> >>>Windows 2000 and later support mount points - you can attach a new >>>partition as C:\pgsql\data\xlog instead of D:\. That might >be enough for >>>most users. IIRC there was a tool to create arbitrary links, >but it was >>>removed just before W2K final. >>> >>> >>> >>If you run NTFS, it's still possible to use arbitrary links. >In the Windows >>world, they are called junctions. Microsoft does not provide >a junction tool >>for some reason (perhaps because it's limited to NTFS). A >good tool, free >>and with source, can be found here >>http://www.sysinternals.com/ntw2k/source/misc.shtml#junction >I use this tool >>myself. Works like a charm. >> >> >> > >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 >Also, IIRC NTFS junctions also have some severe limitations. The main being they can't do files, and there are few tools for them. Also, most win32 admins are *NOT* experienced with them. Sure, they are used for the NETLOGON directory, but how many admins know that... //Magnus
Magnus Hagander wrote: > >>If you run NTFS, it's still possible to use arbitrary links. > >In the Windows > >>world, they are called junctions. Microsoft does not provide > >a junction tool > >>for some reason (perhaps because it's limited to NTFS). A > >good tool, free > >>and with source, can be found here > >>http://www.sysinternals.com/ntw2k/source/misc.shtml#junction > >I use this tool > >>myself. Works like a charm. > >> > >> > >> > > > >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. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> >If you run NTFS, it's still possible to use arbitrary links. In the Windows > >world, they are called junctions. Microsoft does not provide a junction tool > >for some reason (perhaps because it's limited to NTFS). A good tool, free > >and with source, can be found here > >http://www.sysinternals.com/ntw2k/source/misc.shtml#junction > I use this tool myself. Works like a charm. > > We've looked at it before. Apart from anything else I don't think its > license is compatible with PostgreSQL's. The tool was suggested for use as is, not for inclusion in pg source. It can be used to e.g. symlink xlog manually. If you want something in pg source, the relevant lines (about 20) can be copied from MSDN. Andreas
> Magnus Hagander wrote: >> >>If you run NTFS, it's still possible to use arbitrary links. >> >In the Windows >> >>world, they are called junctions. Microsoft does not provide >> >a junction tool >> >>for some reason (perhaps because it's limited to NTFS). A >> >good tool, free >> >>and with source, can be found here >> >>http://www.sysinternals.com/ntw2k/source/misc.shtml#junction >> >I use this tool >> >>myself. Works like a charm. >> >> >> >> >> >> >> > >> >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. What would be good is a "contaminated" developer specifying functionality, and detailing the various APIs needed (documenting the undocumented ones as nessisary) while someone else writes the code. It is the *only* legal unemcumbered methodology that will work.
> >> >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@mohawksoft.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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> pgsql@mohawksoft.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@mohawksoft.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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> pgsql@mohawksoft.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@mohawksoft.com wrote: > > pgsql@mohawksoft.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@mohawksoft.com wrote: >> > pgsql@mohawksoft.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@mohawksoft.com wrote: >>On Wednesday 19 May 2004 00:19, pgsql@mohawksoft.com wrote: >> >> >>>>pgsql@mohawksoft.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@mohawksoft.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@mohawksoft.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@mohawksoft.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@mohawksoft.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@mohawksoft.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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
>>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@mohawksoft.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@Yahoo.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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> 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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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
>>>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.
Christopher Kings-Lynne <chriskl@familyhealth.com.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
> pgsql@mohawksoft.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@mohawksoft.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