incubator-connectors-dev mailing list archives

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

On Feb 8, 2010, at 3:46 PM, Karl Wright wrote:

> Grant Ingersoll wrote:
>> Inline
>> 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?
> 
> Yes, I asked legal-discuss, although I did not get much of a response.  In the end, we
granted code plus directions as to how to obtain the proper wsdls.  If non-response in legal-discuss
is acquiescence, then we're good.

I think there was finally a positive response that it was all right.


> As for Meridio contacts, that would probably best happen through me@metacarta.  But we
don't have very good MS contacts.

OK, how about you ask Meridio and I'll try to track down some MS contacts.

> 
>>> (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 possible.
> 
> Once the generated java code is checked in, then anyone can work on it, no?  The only
time it would need updating is when MS or Meridio releases a new version.
> 
>>> (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.
> 
> Agreed.
> 
>>> 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 those.
>> 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.
> 
> I think it is fine to try this.  I am somewhat cynical, however, that this will work.
;-)

Over time, it will, but short term, likely not.  Once the project is established and has people
using it, then it will be more likely to happen, especially when they see how easy it is to
connect to SharePoint and other competitors who aren't closed.
Mime
View raw message