incubator-connectors-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <karl.wri...@metacarta.com>
Subject Connector building and distribution under Apache
Date Sat, 06 Feb 2010 11:02:18 GMT


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.

(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.)

(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.

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

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

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?

Thanks,
Karl


Mime
View raw message