IP Checks on ArcSDE, Oracle and DB2

[Jody Garnett]

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,