IP Checks on ArcSDE, Oracle and DB2

[Jody Garnett]

David Adler wrote:
> Hi Jody,
>
> My approach to building the stub was quite primitive - compile without 
> the DB2 JDBC driver in the path, check the errors and build a class 
> with methods that eliminated the errors.
That is perfect. And a great defensible position from an IP point of view.
> I'm not sure who one would officially ask at IBM, although it would 
> certainly be fine with me if Chris wanted to ask.
We if you do think of someone let us know.
> What is it that you are actually looking for?  To include the DB2 JDBC 
> driver with the GeoTools distribution?
That would be great (only because it would save you effort), and if it 
was a PR win for IBM to be seen supporting OSGEO we would certainly 
accept permission to build against the DB2 driver.

For geotools we actually only need to build against the DB2 driver, and 
your stub approach has done that for us.  For QA we need to test against 
the DB2 driver, but a machine running cruise control can accomplish this 
need.  It would be more an advantage to GeoServer and uDig to distribute 
the driver, so we could offer DB2 support out of the box.
> I'd like to use GeoTools in some official IBM product work that I am 
> driving but the IP issues on our side are a real headache.
Fair enough, and thanks for creating the stub, we may need to you put 
the information on how you created this in the header (just in case).
Cheers,
Jody
>
> David
>
> At 07:19 AM 3/31/2006, you wrote:
>> Hi David, I have not bothered you much since your IP ducks were 
>> already in a row.  I should check how you made your stub, did you run 
>> a utility against the real db2 jar? Or make it up by hand as you 
>> needed it?
>>
>> If you think it would help we can ask Chris Holmes to contact someone 
>> officially at IBM?
>>
>> Thanks again for all your hard work,
>> Jody
>>> What is the question in terms of IBM support?
>>>
>>> For build purposes, I included a stub that defines the DB2 JDBC 
>>> class/methods that are referenced.
>>>
>>> A GeoTools user with DB2 would need to copy the JDBC driver 
>>> (db2jcc.jar, db2jcc_license_cu.jar) from the DB2 installation into 
>>> the path used by GeoTools.
>>>
>>> The uDIG dialog for a DB2 layer includes a window to specify the 
>>> location of the DB2 JDBC driver the first time a DB2 layer is 
>>> referenced.
>>>
>>> I did poke at this with DB2 development about having the JDBC driver 
>>> available more readily distributable or downloadable but didn't get 
>>> very far.
>>>
>>> These IP issues tend to be a real pain in the neck.
>>>
>>> David
>>>
>>> At 03:02 AM 3/31/2006, Jody Garnett wrote:
>>>> Introductions:
>>>> - David Adler - geotools DB2 module maintainer
>>>> - Frank - OSGEO fellow helping us figure out IP issues
>>>> - Gabriel Roldan - geotools arcsde module maintainer
>>>> - Jody Garnett - geotools PMC, representing geotools to the OSGEO 
>>>> committee
>>>> - Marc Risney - geotools oracle module maintainer
>>>>
>>>> Frank we are hackers, presented with the three options the ArcSDE 
>>>> module maintainer (Gabriel)  is going to reverse engineer the 
>>>> required API, and create the same thing with stubs...  To actually 
>>>> use the code the user will need to acquire the actual need jar 
>>>> themselves.  The situation is similar to the use of C++ header 
>>>> files in the mapserver community as I understand it.  Now that 
>>>> "reverse engineering" step rings alarm bells, so I need a better 
>>>> word that does not imply that we are taking their code ...
>>>>
>>>> So I will say "stubbing".
>>>>
>>>> Indeed we may be able to stub from our own code (only creating the 
>>>> api we use), and at a technical level avoid a process that involves 
>>>> their jars at all.  The only person using their jars would be the 
>>>> ArcSDE module maintainer, and he would only compile against the 
>>>> real thing as part of running test cases, indeed we could ask him 
>>>> to place his test cases in a seperate module that depends on the 
>>>> real jar, the test cases would be run by hand and not included in 
>>>> the normal build process used for nightly release.
>>>>
>>>> While you would think this would lower quality, this would not be 
>>>> the case. Nobody has made an ArcSDE install available for testing 
>>>> against in a legal sense. As I understand it they are shipped with 
>>>> user limits and are not suitable for being place out on the naked 
>>>> Internet.  My best bet for quality control is to ask the system 
>>>> that runs the nightly builds to have an ArcSDE install available, 
>>>> and have it run those test cases.
>>>>
>>>> Oracle is in a slightly better situation based on the fact that 
>>>> there is a will on both the geotools and oracle side to set thing 
>>>> sup so that they can work. Marc based on the arcsde experience 
>>>> above can you outline a scenario where both you and Frank can get 
>>>> along?  It seems Frank would like us to either stub sdoapi or to 
>>>> somehow get a click through, as far as I know a click through is 
>>>> not supported by maven 1 or maven 2?
>>>>
>>>> Our build system is too automatic, any warnings we put in the 
>>>> documentation would not be read ... could we set a pregoal on our 
>>>> oracle module that prints out a big warning? Wonder if we could set 
>>>> up an ant task that pops up a dialog of annoyance to fetch the jars 
>>>> once if they are not found in the local repository?
>>>>
>>>> We should also check with IBM about our DB2 support.
>>>>
>>>> Jody
>>>>> Jody Garnett wrote:
>>>>>> Chris Holmes wrote:
>>>>>>> Hmmm... They said the open source requirement basically meant 
>>>>>>> you can't provide it by GPL.
>>>>>>>
>>>>>>> They said they're interested in helping us out, so perhaps we 
>>>>>>> could see if they could distribute it to us in such a way that 
>>>>>>> we don't need an extra EULA?
>>>>>> As it is we give the user a program (the build system) that 
>>>>>> downloads the file ... does this count as distribution? My best 
>>>>>> solution would be oracle setting up a maven repository where were 
>>>>>> our build system can pick it up.
>>>>>
>>>>> Jody,
>>>>>
>>>>> Ideally the user would have to download it themselves interactively
>>>>> so they go through any "acceptance of terms" pages and so forth 
>>>>> themselves.
>>>>> Of course, if Oracle exposes the file for direct download, and it is
>>>>> the end user hitting the "build" button that fetches it, I suppose it
>>>>> would put the responsibility on them.
>>>>>
>>>>> But for a foundation project I don't think we should put users in a
>>>>> position of possible legal liability without their knowledge.
>>>>>
>>>>>> As a library figuring out what to do after this is kind of up to 
>>>>>> each project that uses geotools + oracle. I figure if they are 
>>>>>> looking at oracle already they have paid for the database and 
>>>>>> oracle is already happy...
>>>>>
>>>>> Well, it certainly is our problem to determine whether their license
>>>>> is valid, etc.
>>>>>
>>>>> Best regards,
>>
>