[Info-ingres] Re: Ingres 2006... what the...
Karl & Betty Schendel
>
>Ingres 2006 is available under a dual licensing model. Under this model, users may choose to use Ingres under the GNU General Public License or under a commercial license. ISVs and Resellers, who are embedding and reselling Ingres as part of their own commercial solutions, can purchase a commercial license.
I don't think this is an irrevocable decision at this point. Call up
an Ingres rep (I don't know who, I don't keep track of that side, maybe
the EMEA support people?) and yell loudly now.
I am 99% sure that going GPL was chosen because it sounded good,
and if it's necessary or desirable to make some of it LGPL I don't
see why that can't happen.
Besides, if you are calling Ingres through any of the published API's
I don't see how it's any different from running Linux and calling it
through system calls. I.e. you're still OK.
So yes, I think you are overreacting.
Karl
Roy Hann
news:mailman.113934840...@cariboulake.com...
> >OK, so I see Ingres 2006 is available... under the GPL, and the download
page states:
> >
> >Ingres 2006 is available under a dual licensing model. Under this model,
users may choose to use Ingres under the GNU General Public License or under
a commercial license. ISVs and Resellers, who are embedding and reselling
Ingres as part of their own commercial solutions, can purchase a commercial
license.
>
> I don't think this is an irrevocable decision at this point. Call up
> an Ingres rep (I don't know who, I don't keep track of that side, maybe
> the EMEA support people?) and yell loudly now.
Dave Dargo would be the man to talk to (I'm sure you can guess his e-mail
address).
I was surprised to hear they'd opted for GPL too. Google informs me that it
was on November 11 last year that I hoped out loud that the CA-TOSL wouldn't
be replaced by the GPL. But here we are.
I am somewhat puzzled by the wording on the Ingres website regarding
licensing. It seems to be recommending a commercial license if you want to
use Ingres in a commercial product, and GPL otherwise. I can't make out if
that is just a serving suggestion or a legal requirement. According to my
reading of the GPL, the way one would normally use Ingres would not require
you to derive a new work from it, so your application and Ingres are
"independent and separate works", in which case the GPL states *explicitly*
that the GPL does not apply to your work. It also, for good measure, states
that "mere aggregation" (i.e. putting both on the same distribution medium)
does not extend the GPL to the other works.
I don't like the GPL, but it's not obvious to me why it would be a
show-stopper. Can you explain the problem in more detail Emiliano?
Roy
PS: My wife drank your wine. Sorry. I owe you.
Chip Nickolett
should be the approach that an open source "community" would favor.
I would personally be more concerned about the name "Ingres 2006",
especially if 3-4 years down the road it is not significantly different
and/or better. Even Microsoft learned this lesson several years ago.
Positioning it as "The new Ingres 2006" seems to push the product
further away from the established, enterprise quality product that
would probalby appeal to many new users and their management. At least
it is not Ingres-Ingres or anything goofy like that. ;-)
Just my $0.02.
Chip Nickolett (Ch...@Comp-Soln.com)
(US) Comprehensive Solutions - www.Comp-Soln.com
(UK) Comprehensive Solutions International - www.Comp-Soln.co.uk
Roy Hann
news:1139354418.2...@f14g2000cwb.googlegroups.com...
> At least
> it is not Ingres-Ingres or anything goofy like that.
I think it might have been Kitty Weaver who suggested what is still my
favourite name, back when OpenIngres was launched. She suggested "Ingres:
This Time We Really Mean It". :-)
Roy
Emiliano
> I was surprised to hear they'd opted for GPL too. Google informs me that it
> was on November 11 last year that I hoped out loud that the CA-TOSL wouldn't
> be replaced by the GPL. But here we are.
>
> I am somewhat puzzled by the wording on the Ingres website regarding
> licensing. It seems to be recommending a commercial license if you want to
> use Ingres in a commercial product, and GPL otherwise. I can't make out if
> that is just a serving suggestion or a legal requirement. According to my
> reading of the GPL, the way one would normally use Ingres would not require
> you to derive a new work from it, so your application and Ingres are
> "independent and separate works", in which case the GPL states *explicitly*
> that the GPL does not apply to your work. It also, for good measure, states
> that "mere aggregation" (i.e. putting both on the same distribution medium)
> does not extend the GPL to the other works.
>
> I don't like the GPL, but it's not obvious to me why it would be a
> show-stopper. Can you explain the problem in more detail Emiliano?
The problem is that the license as it stands does extend to our software
for (as far as I can see) anything but ODBC, and possibly JDBC (which we
don't use). There's no exclusion for the native API and the .Net
interface, which are both delivered by Ingres Corp, and which both
directly "touch" our source code. And ODBC is on the way out for us.
LGPL for the interface libs would be OK. GPL is decidedly not. Our
software *is* a derivative work of the interface libs; it's the same
reason why glibc (a GNU product) is licensed under the LGPL. It's the
same reason why e.g. the MySQL interface libs are being unbundled from
PHP, for example.
All that's hidden behind the interface libs can be delivered by any kind
of royalty free license as far as I care.
So the way I read it now, the statement that "ISVs and Resellers, who
are embedding and reselling Ingres as part of their own commercial
solutions, can purchase a commercial license" is right on the money, so
to speak.
> PS: My wife drank your wine. Sorry. I owe you.
That all depends on how good the wine was, but I hope she enjoyed it. I
consider it a very small sacrifice for a thoroughly enjoyable few hours
we spent. I hardly drink, anyway -- what you saw me drink there that
evening was probably close to 29.86501% of my yearly intake.
Emiliano Heyns
Emiliano
> This isn't really any different than the approach that MySQL uses,
Which is why MySQL was off our selection list within the first 3
seconds. Even before judging it on technical merits.
> and
> should be the approach that an open source "community" would favor.
No, it should be the approach that the Free Software community should
favor. The "open source" community has an entirely different agenda.
In any case, as great as this would be for the Free/Open Source Software
"community", from 9-5 I am not part of that community. I'm employed by
an ISV who pays me to build stuff and make sensible technology choices
for them. At night I can be as gung-ho about Free Software as I feel
like. At night I don't mind Ingres under the GPL.
> I would personally be more concerned about the name "Ingres 2006",
Believe me, I have good reason to be concerned over this. Our legal
department is pretty open-source friendly and savvy. But they hear GPL
and I have got some 'splainin to do, and rightfully so.
Had the next version of Ingres (whenever the Windows binaries are
finally updated) be called Ingres Slightly Soiled Platypus Edition but
was delivered under the CA-TOSL, or the BSD license, or the APL, or the
MPL, or any of a whole score of different licenses that Ingres Corp
could have picked, I'd have thought "silly rabbits" and gone on with my
work. We're an ISV. All our customers ever get to know about Ingres is
that it's Ingres (we don't display specific Ingres version in our
product) and that it's backed by a firm that can deliver solid support.
But Karl says I'm over-reacting, and that actually is a great relieve.
I'll be on the phone with Ingres Corp tomorrow to see if and how this
issue can be resolved or not.
Emiliano
Roy Hann
news:ec4a8$43e92eaf$3ec29fe3$54...@news.chello.nl...
> The problem is that the license as it stands does extend to our software
> for (as far as I can see) anything but ODBC, and possibly JDBC (which we
> don't use). There's no exclusion for the native API and the .Net
> interface, which are both delivered by Ingres Corp, and which both
> directly "touch" our source code. And ODBC is on the way out for us.
So you took the source code for the OpenAPI (and .Net) and used it to write
your own version of the OpenAPI and .Net? I guess if that's what you did
then yes, you are in the do-do. But I venture to say that is a very unusual
thing to do; your situation would be extremely rare (even unique).
But as the saying goes, I'm no lawyer. Maybe I'm getting this all
waaaaaaaaay wrong and the GPL is even more viral than I thought.
Roy
Emiliano
> "Emiliano" <Emil...@Iris-Advies.nl> wrote in message
> news:ec4a8$43e92eaf$3ec29fe3$54...@news.chello.nl...
>> The problem is that the license as it stands does extend to our software
>> for (as far as I can see) anything but ODBC, and possibly JDBC (which we
>> don't use). There's no exclusion for the native API and the .Net
>> interface, which are both delivered by Ingres Corp, and which both
>> directly "touch" our source code. And ODBC is on the way out for us.
>
> So you took the source code for the OpenAPI (and .Net) and used it to write
> your own version of the OpenAPI and .Net?
Good grief no. Certainly some of our engineers would have loved to do
so, but sanity prevails sometimes.
> I guess if that's what you did
> then yes, you are in the do-do. But I venture to say that is a very unusual
> thing to do; your situation would be extremely rare (even unique).
We haven't done that. But looking at
http://www.gnu.org/licenses/why-not-lgpl.html, it seems pretty clear
that the LGPL was specifically created to allow library-linking of
proprietary applications to GPL libraries.
http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins pretty much
says the same.
> But as the saying goes, I'm no lawyer. Maybe I'm getting this all
> waaaaaaaaay wrong and the GPL is even more viral than I thought.
We'd be in the clear if we wrote our own interface libs that spoke the
Ingres wire protocol directly. For those of our engineers that may be
listening in, this is *not* a suggestion to do so. Dynamic libraries
specifically are a legal gray area in the sense that the spirit of the
GPL wants to forbid it (and for confirmation, just ask Stallman if you
have a few days to spare), and that the letter may just allow it under
some circumstances. That's not something I'm going to bring to our legal
department, at least not for another 52 days.
Emiliano
Grant Croker
statically linked or dynamically linked implies that the application
also be GPL'd. From what I have read, even though there is a technical
distinction between static / dynamic linking it is the intention of the
GPL that carries - such that you should GPL your code too. I guess that
was why the LGPL was created.
my 0.02€ worth
grant
--
Grant Croker, gra...@php.net
Roy Hann
news:mailman.113938770...@cariboulake.com...
> AFAIK + IANAL etc.. Linking an application to a GPL'd product be it
> statically linked or dynamically linked implies that the application
> also be GPL'd. From what I have read, even though there is a technical
> distinction between static / dynamic linking it is the intention of the
> GPL that carries - such that you should GPL your code too. I guess that
> was why the LGPL was created.
Yes, the FAQs Emiliano pointed out seem very clear about that. I've always
had an instinctive aversion to the GPL, but I've never bothered to delve
into it beyond reading the license itself. I am left feeling the way I feel
after looking at an unappealing sculpture that only becomes more detestable
when you read the artist's statement of intent. :-(
There is at least one good outcome from this discussion though: the Ingres
Corporation business model now looks a lot less like voodoo or happy-clappy
altruism, and a lot more like real-world business!
Roy
Emiliano
> Yes, the FAQs Emiliano pointed out seem very clear about that. I've always
> had an instinctive aversion to the GPL, but I've never bothered to delve
> into it beyond reading the license itself. I am left feeling the way I feel
> after looking at an unappealing sculpture that only becomes more detestable
> when you read the artist's statement of intent. :-(
I personally have absolutely no problem with people using the GPL for
software they write. It's their work, they could license it to anyone
and state the condition that you must sing the Star Spangled Banner at
the top of your voice anytime you see someone taking off a green hat.
The problem is that the *change* in license changes the rules for us.
Had Ingres been GPLd all along, I would have *never* proposed it for
*this* particular application.
> There is at least one good outcome from this discussion though: the Ingres
> Corporation business model now looks a lot less like voodoo or happy-clappy
> altruism, and a lot more like real-world business!
That is true. Which is why I worry about it. It changes the rules. Under
the new flag, Ingres becomes a 'regular' commercial product. That the
source is available, pshaw. I looked at the source, it's a complex
beast. It's never going to be picked up by a serious non-IngresCorp group.
And the GPL licensing means that it will be hard to become a serious
Open Source player. As with MySQL (excuse me the comparison), you can
bundle the interface libs with PHP, but PHP won't do it for you, because
it doesn't want to be on the hook for the license incompatibility. The
only way you're going to build something with a GPLd Ingres is by having
an all-GPL software stack (good luck) or by wrapping the connection libs
with a separate *service* that disconnects your software from Ingres,
and releasing the wrapper service under the GPL. And who is going to
seriously do that?
Emile
J.F. Cornwall
This is an intersting conversation, even though most of the gory
technical details are a couple feet over my head :-) I do have a
question, though, which hopefully is an easy one to answer.
How does the license affect installations where just about all of the
applications are using embedded SQL (both C and Fortran 77) to
read/write/delete 'stuff'? We don't use Openroad, and there is a small
application coming online soon with a JDBC connection to the database.
Is embedded SQL coding affected?
Jim Cornwall
(PS - I'm an application programmer who has picked up bits of DB &
Ingres knowledge over the past few years, but I am *NOT* a guru or
well-versed in Ingres arcana...)
Roy Hann
news:IuDnp...@igsrsparc2.er.usgs.gov...
> This is an intersting conversation, even though most of the gory
> technical details are a couple feet over my head :-) I do have a
> question, though, which hopefully is an easy one to answer.
>
> How does the license affect installations where just about all of the
> applications are using embedded SQL (both C and Fortran 77) to
> read/write/delete 'stuff'? We don't use Openroad, and there is a small
> application coming online soon with a JDBC connection to the database.
> Is embedded SQL coding affected?
Dunno. Do you develop commercial software products? If not, then the
impact of the change is probably minimal. (But I'm no lawyer.)
Roy
J.F. Cornwall
No, we are US Gov't (Geological Survey). We are using Ingres to store
hydrologic data (stream gage readings, well measurements, water quality
sample info, lots of different stuff). Runs on Sun E450 boxes, Solaris
8/10, and there are about 50 installations scattered across the USA,
approximately 1 per state.
Jim
(required disclaimer: I'm speaking only for myself, not for the gov't)
Emiliano
> Roy Hann wrote:
>> "J.F. Cornwall" <JCor...@cox.net> wrote in message
>> news:IuDnp...@igsrsparc2.er.usgs.gov...
>>
>>> technical details are a couple feet over my head :-) I do have a
>>> question, though, which hopefully is an easy one to answer.
>>>
>>> How does the license affect installations where just about all of the
>>> applications are using embedded SQL (both C and Fortran 77) to
>>> read/write/delete 'stuff'? We don't use Openroad, and there is a small
>>> application coming online soon with a JDBC connection to the database.
>>> Is embedded SQL coding affected?
Yes. No. Maybe. The GPL comes into effect when you distribute your code.
If you don't distribute, targeted for in-house use only, you're OK. If
you distribute your code, ESQL apps are most definitely affected, since
they will include header files from Ingres, becoming part of your product.
>> Dunno. Do you develop commercial software products? If not, then the
>> impact of the change is probably minimal. (But I'm no lawyer.)
>
> No, we are US Gov't (Geological Survey). We are using Ingres to store
> hydrologic data (stream gage readings, well measurements, water quality
> sample info, lots of different stuff). Runs on Sun E450 boxes, Solaris
> 8/10, and there are about 50 installations scattered across the USA,
> approximately 1 per state.
The GPL doesn't really care whether the software is for-profit or not.
If it's distributed, it must be distributed under a GPL-compatible
license
(http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses).
How this deals with in-house software for multi-site deployment, I don't
know. I am not a lawyer, nor do I play one on TV.
Emile
OldSchool
Karl & Betty Schendel wrote:
> >OK, so I see Ingres 2006 is available... under the GPL, and the download page states:
> >
> Besides, if you are calling Ingres through any of the published API's
> I don't see how it's any different from running Linux and calling it
> through system calls. I.e. you're still OK.
You might want to check out the article "On the Docket" in the Feb '06
issue of "Linux Magazine". It goes in to some of the issues regarding
GPL, linking, and "derivative works". The author of said article is
Mark Webbink - Red Hat's deputy general council, so I assume he knows
whereof he speaks.
Scott