incubator-connectors-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Connector building and distribution under Apache
Date Mon, 08 Feb 2010 19:21:43 GMT

On Feb 6, 2010, at 6:02 AM, Karl Wright wrote:

> Hi all,
> I have been thinking long and hard in terms of how, exactly, we may deliver all of the
connectors in a manner compatible with Apache principles, and without violating copyrights/license
agreements of all parties.  The proposed strategy would be for Apache to provide the sources
and ant build scripts that would produce all the proper connector jars, but only if the prerequisite
non-Apache client jars or wsdls were supplied to ant.  So, the ant build would conditionally
detect whether it could indeed build each connector, based on what it was supplied.
> Some background first... As Grant is aware, the connectors fall into three basic categories:
(a) those that are completely independent of any encumbered software from the system they
are meant to connect to, (b) those that rely only on wsdls and xsds from the system they are
connecting to, and (c) those that require compilation against client libraries that the target
system vendor actively sells its clients for money.  For the record, the connectors in category
(a) are: file system (a test connector), jcifs connector (Windows share connector), jdbc connector,
web connector, rss connector, and the lucene, gts, and null output connectors.  The connectors
in category (b) are the SharePoint connector and the Meridio connector.  Category (c) contains
connectors for LiveLink, Documentum, FileNet, and Memex.
> Obviously, the connectors in each class need to be handled in a manner consistent with
that class's legal requirements.
> It seems clear that class (a) connectors will need no special handling.
> Class (b) merits much further discussion because SharePoint is a very popular repository
these days.  It seems to me that our choices for handling SharePoint or Meridio are as follows:
> (1) We get special permission from Microsoft and/or Meridio to distribute their wsdls
and xsds - or we decide that we don't in fact need such permission, because we decide we can
already distribute such interface specifications freely.

You asked this over on legal-discuss@ right?  I think the thinking was it was OK, right? 
That being said, we can likely contact the companies as well to get clarification.  I know
there are some MS contacts here at the ASF, so we can reach out to them.  I can do this. 
Does anyone have Meridio contacts?  Do you have links to the actual license agreements for
these two connectors?

> (2) We purchase development licenses for Apache for such systems, make them open enough
so that the wsdls can be accessed by anyone, and point maven and/or our build documentation
at the appropriate urls.  (In case you are unaware, in .NET development wsdls and xsds that
a web service implements can be downloaded via http from the web service in question.)

Not ideal due to the fact that it limits development to only committers.

> (3) The developers obtain the appropriate wsdls and xsds themselves, through whatever
means available to them, and use axis and castor to generate appropriate java code, and then
check the java code that was generated into apache svn.

This could work, but has the same issue as #2.  We should make as much of it automated as

> (4) We treat the wsdls just like client libraries - see below.
> For class (c) connectors, we have the following realistic choices:
> (1) We release sources for the connectors, and instructions for populating the appropriate
build areas with the required client jars.  For this to work, developers for these connectors
will need licensed access to the appropriate client jars themselves,

This is the only short term solution.

> and the details of the Apache release cycle for the connector may require purchase or
donation of a target system development license for Apache itself.

I doubt we will want to purchase these, as that won't be cost-effective.

> (2) We do a clean-room implementation of the client libraries in question, and distribute

This is a last resort to me.

I'd add #3 as another long term solution:
Contact the various companies and make our case for why they should allow us to compile our
connectors, since it will make it easier for people to use their solution.

> It would be good to start thinking about what approach we want to take for each class
of connector, because I believe we will shortly be in a position where we will need appropriate
decisions as to how to proceed, both short-term and long term.  In particular, I'm wondering
about some of the implied legal questions posed by some of the possible class (b) connector
possibilities.  Thoughts, anyone?

View raw message