IP Checks on ArcSDE, Oracle and DB2

[Jody Garnett]

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,
>>
>