Re: [Fwd: Re: [HACKERS] PG functions in Java: maybe use gcj?]
Barry Lind <[EMAIL PROTECTED]> forwards: > If we had to supply gcj along with PostgreSQL in order for PostgreSQL to > work, I guess that would mean gcj was incorporated in PostgreSQL - that > would mean PostgreSQL would become subject to GPL protection. Depends on how you define "work". pljava wouldn't work without a compiler, clearly, but is that Postgres? I don't think so; any more than I consider Perl, Tcl, or Python to be part of Postgres. One way to make the separation even clearer is to distribute pljava as a separate project under a GPL or LGPL license. However, that would be moderately annoying from a maintenance point of view, so I'd prefer not to. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [Fwd: Re: [HACKERS] PG functions in Java: maybe use gcj?]
Barry Lind <[EMAIL PROTECTED]> writes: > If we had to supply gcj along with PostgreSQL in order for PostgreSQL to > work, I guess that would mean gcj was incorporated in PostgreSQL - that > would mean PostgreSQL would become subject to GPL protection. Not true--"mere aggregation" (shipping two things together) does not require all the aggregated software to be GPL'd. And you're not linking to the gcj compiler, just running it. This particular part of the problem is a non-issue. -Doug ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[Fwd: Re: [HACKERS] PG functions in Java: maybe use gcj?]
Forwarding to hackers a discussion that has been happening off list. --Barry Original Message Subject: Re: [HACKERS] PG functions in Java: maybe use gcj? Date: 01 Nov 2002 19:13:39 + From: Oliver Elphick <[EMAIL PROTECTED]> To: Barry Lind <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <1036153748.24598.70.camel@linda> <[EMAIL PROTECTED]> On Fri, 2002-11-01 at 18:19, Barry Lind wrote: > Oliver, > > Thanks for the explaination. This makes sense. > > However I think the proposal Tom was suggesting would require linking in > more than just the runtime. Since create function would need to call > the compiler itself to compile the function into java bytecode or > directly to a .so. If we had to supply gcj along with PostgreSQL in order for PostgreSQL to work, I guess that would mean gcj was incorporated in PostgreSQL - that would mean PostgreSQL would become subject to GPL protection. If CREATE FUNCTION called a java compiler (which might or might not be gcj) that PostgreSQL did not supply, that compiler would not be incorporated. If there were no java compiler, java functions would not work, but otherwise PostgreSQL would be unaffected. It would be the same as any of the tools that get called in our shell scripts, many of which may be GNU utilities, including, of course, the shell itself. As for the virtual machine, I think that is what libgcj supplies, and it is specifically excluded from having GPL effects by its licence. (You didn't post to the list, so I haven't; but I have no objection to your forwarding this there.) -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "But they that wait upon the LORD shall renew their strength; they shall mount up with wings as eagles; they shall run, and not be weary; and they shall walk, and not faint."Isaiah 40:31 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PG functions in Java: maybe use gcj?
On Thu, 2002-10-31 at 18:27, Barry Lind wrote: > However in the proposal here we are talking about requiring a specific > jvm (gcj) and actually linking parts of it into postgres. To the extent > that GPL code is linked in the GPL extends to the entire code base. As > I said previously there are ways to work around this, but it becomes > tricky. Especially when a commercial product wants to bundle postgres > and pljava. That resulting bundle is probably entirely under the GPL > and then any changes to it are also GPL. So it could be the case that > this company would be prevented from submitting improvements they made > back to the core product because their improvements are GPLed as a > result of pljava. Nothing that company does can affect the licensing of PostgreSQL itself - it doesn't belong to them, so they cannot change its licence. Nothing in the GPL forces them to put GPL copyright on their own alterations. What they cannot do is to _distribute_ binary code that links to GPL code while giving fewer rights to their distributees than they themselves received with the GPL code, whether in respect of their own code or the GPL code. Therefore they would be required to make their source changes available to anyone to whom they gave a binary, and they would not be able to restrict the further distribution of those changes. They can contribute those changes to the project under whatever licence they wish that is acceptable to the project. Furthermore, gcj is part of the GNU compiler collection, like gcc, and using it does not in itself cause code compiled under it to be subject to the GPL. Linking to its runtime library would normally cause that, but the gcj-3.0 copyright contains the following text: The libgcj library is licensed under the terms of the GNU General Public License, with this special exception: As a special exception, if you link this library with other files to produce an executable, this library does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "But they that wait upon the LORD shall renew their strength; they shall mount up with wings as eagles; they shall run, and not be weary; and they shall walk, and not faint."Isaiah 40:31 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] PG functions in Java: maybe use gcj?
Tom Lane wrote: Barry Lind <[EMAIL PROTECTED]> writes: In either case I am concerned about licensing issues. gcj is not under a BSD style license. Depending on what you need you are either dealing with regular GPL, LGPL, or LGPL with a special java exception. I beleive (without giving it too much thought) that doing either 1 or 2 above would end up linking GPL code into postgres. This can be worked around by requiring the the necessary gcj libraries be installed separately and detected at configure time (like is done elsewhere). But is does (I think) present a problem for commercial products that would like to redistribute postgres with pljava. Good point, but unless you want to build a BSD-license Java implementation, there will never be a pljava that doesn't have different licensing restrictions than PG itself does. gcj is at least more free than either Sun's or IBM's JVM ... It depends on what you mean by more free. An architecture that interacts with an external jvm would let you use any jvm (free ones as well as others). From a licensing standpoint it is generally easy to redistribute a jvm or expect the user to have one installed (most java based products out there today do this). However in the proposal here we are talking about requiring a specific jvm (gcj) and actually linking parts of it into postgres. To the extent that GPL code is linked in the GPL extends to the entire code base. As I said previously there are ways to work around this, but it becomes tricky. Especially when a commercial product wants to bundle postgres and pljava. That resulting bundle is probably entirely under the GPL and then any changes to it are also GPL. So it could be the case that this company would be prevented from submitting improvements they made back to the core product because their improvements are GPLed as a result of pljava. Now having said all that, I have been monitoring the progres of gcj for some time because I think there are very interesting possibilities. And I am all for anyone who wants to look into it further and investigate the possiblities. I just want to raise the licensing issue because it can cause problems and it is better to think about them up front than after the fact. Another challenge here it that the java code is going to want to use the jdbc api when communicating with the database. Yes. I think we'd need a new implementation of jdbc that sits atop SPI (invoked via jni I guess) rather than a FE/BE connection. How well layered is our jdbc code --- would this mean a large rewrite, or just rolling in a new bottom layer? It isn't as well layered as it could be, but it isn't too bad. Overall it shouldn't be too much work, but not a little project either. One area that isn't well layered is the assumption that the raw data from the server is in text format, since that is what the FE/BE protocol provides. So all the conversion functions that convert to/from java datatypes do so in this format. This assumption runs deep into the code. As a first pass it would be easiest to get raw data from SPI convert to text and then convert to java datatypes instead of going directly from the internal SPI format directly to java datatypes. This could be improved upon later. regards, tom lane thanks, --Barry ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] PG functions in Java: maybe use gcj?
Barry Lind <[EMAIL PROTECTED]> writes: > I am not sure I follow. Are you suggesting: > 1) create function takes java source and then calls gcj to compile it > to native and build a .so from it that would get called at runtime? > or > 2) create function takes java source and just compiles to java .class > files and the runtime invokes the gcj java interpreter. > or I guess you could do both at the same time. The impression I had (after not looking very closely) was that you could expect to compile to bytecodes on the fly and then run the gcj interpreter. But the .so alternative might be a good fallback if that doesn't work. > In either case I am concerned about licensing issues. gcj is not under > a BSD style license. Depending on what you need you are either dealing > with regular GPL, LGPL, or LGPL with a special java exception. > I beleive (without giving it too much thought) that doing either 1 or 2 > above would end up linking GPL code into postgres. This can be worked > around by requiring the the necessary gcj libraries be installed > separately and detected at configure time (like is done elsewhere). But > is does (I think) present a problem for commercial products that would > like to redistribute postgres with pljava. Good point, but unless you want to build a BSD-license Java implementation, there will never be a pljava that doesn't have different licensing restrictions than PG itself does. gcj is at least more free than either Sun's or IBM's JVM ... > Another challenge here it that the java code is going to want to use the > jdbc api when communicating with the database. Yes. I think we'd need a new implementation of jdbc that sits atop SPI (invoked via jni I guess) rather than a FE/BE connection. How well layered is our jdbc code --- would this mean a large rewrite, or just rolling in a new bottom layer? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PG functions in Java: maybe use gcj?
I am not sure I follow. Are you suggesting: 1) create function takes java source and then calls gcj to compile it to native and build a .so from it that would get called at runtime? or 2) create function takes java source and just compiles to java .class files and the runtime invokes the gcj java interpreter. or I guess you could do both at the same time. In either case I am concerned about licensing issues. gcj is not under a BSD style license. Depending on what you need you are either dealing with regular GPL, LGPL, or LGPL with a special java exception. I beleive (without giving it too much thought) that doing either 1 or 2 above would end up linking GPL code into postgres. This can be worked around by requiring the the necessary gcj libraries be installed separately and detected at configure time (like is done elsewhere). But is does (I think) present a problem for commercial products that would like to redistribute postgres with pljava. Another challenge here it that the java code is going to want to use the jdbc api when communicating with the database. One difficulty here is getting jdbc to be part of the same transaction as the calling java function. Such that if the java stored procedure selects or updates data it is doing it in the same transaction as the caller of the function. Today the jdbc driver only knows how to communicate via the FE/BE protocol which will end up creating a new process and transaction. The jdbc driver would need to not use the FE/BE protocol but instead probably use jni calls. thanks, --Barry Tom Lane wrote: I had an interesting conversation today with Tom Tromey and Andrew Haley of Red Hat about how to implement "pljava" for Postgres. Rather than futzing with an external JVM, their thought is to use gcj (gcc compiling Java). It sounds like this approach would mostly just work, modulo needing to use a small amount of C++ code to call the defined APIs for gcj. This would not be a perfect solution: gcj isn't yet ported everywhere, and it would probably not play nice on machines where the standard C library isn't thread-safe. But it seems a lot more within reach than the approaches we've discussed in the past. I'm not volunteering to try to do this, but I wanted to toss the idea up in the air and see if anyone wants to try it. Tom and Andrew indicated they'd be willing to help out with advice etc for anyone who wants to take on the project. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
