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 > m...@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.
