Hello
We have been asked to write a module that will connect to a 3rd party API on a separate server, using SOAP. The API is part of a closed source .NET application. The module cannot function (or even be installed) unless it retrieves data from the 3rd party API.
The license agreement for the 3rd party software strictly prohibits distribution and/or unlicensed access to the API, documentation etc.
The Drupal module that we are planning to build will contains code that would identify all of the 3rd party API function names, arguments, expected returned data and other protected information.
We will give ('distribute') to the client the Drupal source code along with any modifications we have made, contributed modules etc, however, would I be right in saying that due to the license restrictions of the 3rd party API, our module cannot be covered by GPL and therefore must not be distributed?
Thanks, Mark
Comments
Are you retaining copyright
Are you retaining copyright on the custom Drupal module that contains the API information, or doing it as work for hire? If you're building the custom module as work for hire, then you're not actually distributing the module because it's fully owned by your client, and the GPL potentially would only come into play if they decided to distribute that code to any other party.
If you are retaining copyright on the module, than my understanding is that it should be licensed and distributed to your client under the terms of the GPL - whether either you or your client chooses to distribute it beyond that is up to you, but such distribution would need to under the terms of the GPL.
Without knowing the terms of the API's licensing terms, it's difficult to say whether or not it's GPL-compatible (although it certainly doesn't sound like it from your description). I will say that in my experience, one of the major reasons you have an API is to allow other applications which may be distributed under different licensing terms to interact with your program, so to keep all of the API function names protected under such tight terms seems counter-productive to me.
We'd be retaining copyright
We'd be retaining copyright as we'd like to use this module with other clients who use the same 3rd party application. The 3rd-party API is part of a very expensive CD-install application - let's call it "ABC" that exposes the API only to those who are on an list of approved developers chosen by the software licensee (our client). So function names, return values, documentation etc., are important to the company that sells "ABC" because it would contain information that they would not want out in the public domain.
Are we allowed to install Drupal, themes, modules and modifications on their web server (thereby correctly distributing everything as GPL) but encrypt or make unreadable the single module that interacts with "ABC" over SOAP? Does our client's use of the module on their website constitute 'distribution' if they do not have access to the actual file? If this isn't 'distribution' then GPL would not apply?
Thanks for any help.
No obfuscation
The GPL expressly says that you must provide the "form preferred for editing". So you certainly could obfuscate encrypt the code, but anyone who receives a copy of the obfuscated code would absolutely be within their rights to demand an unobfuscated version from you, making the effort to obfuscate the code a total waste of time.
Whether or not installing it for a client on a server they don't have access to counts as distribution gets into the area where you want to talk to a lawyer. Of course, I can't imagine a client being smart to agree to such an arrangement as then they're entirely beholden to you.
While you are under no obligation to distribute the code to anyone, the GPL would apply to the module code in this case so anyone who receives a copy of it through any legal means cannot be prevented from sticking it on a public FTP site. If that's a deal-breaker for ABC, Inc., then to be frank ABC needs to rethink their business model because their API is badly designed.
In either case, the module being under the GPL has no implications for the code on the other end of the SOAP connection. So there's no concern there.
If that's a deal-breaker for
If that's a deal-breaker for ABC, Inc., then to be frank ABC needs to rethink their business model because their API is badly designed
Yes, it is a deal-breaker for ABC Inc. I don't think they're going to rethink their business model.
If the license that protects the ABC Inc is such that we cannot allow the contents of the module to be released, are we saying that we cannot use Drupal?
Lawyer time
At that point, you should refer the matter to your legal staff. The GPL requires that anyone who receives a copy of the module be permitted (but is not required) to distribute it, no exceptions. If ABC Inc. feels that compromises their system, then that may well be a fatal problem. But again, that's a question for a licensed copyright attorney.
Thanks for your time on
Thanks for your time on this, much appreciated.
One option perhaps is that we distribute the module to our client but ensure that the code does not reveal anything specific about the API that ABC Inc. might consider worrisome. We then build our won simple API interface that does actual lower level work of calling the appropriate functions etc. This protects ABC Inc., but also means that we're able to freely distribute the module as GPL. I guess this would be the 'bridge' mechanism that's been discussed in the Legal group before, and my understanding is that if performed via SOAP/GET/POST etc, then there should be no problems with this approach?
Thanks again.
Depends on the bridge
It depends at what level your extra wrapper works. If it's in PHP and is sharing data structures with Drupal code, then the number of layers of indirection you add doesn't matter; the GPL still applies across the entire PHP process. If you're talking about some intermediary server that you talk to over SOAP that then talks to the ABC server over SOAP, that would be weird but probably not have any legal issues. (Again, IANAL, I just talk to them.)
Or ABC could just improve their API to not expose any sensitive information, so the API itself becomes "safe". Then you can talk to it directly from a GPLed Drupal module with no risk of information leakage.
I'm still unclear on what it is they're worried about; If simple knowledge about their API calls is a threat to the security of their system, then they're already running a horribly insecure API. If the API allows too much internal data to leak out if you issue the right calls, then they need to have a more robust set of API calls so you don't need that sort of direct access. If the API doesn't have any authentication beyond not telling people about the API unless they agree to not be evil with it, then they need to fire their developers for writing something so insecure. :-)
Looking for a good copyright attorney
Does anyone have a name and contact information for a good copyright attorney. Our web developer suggested that we ask someone in this group. He is developing a website for us using drupal and because of the expense we do not want our competitors in our area to be able to get ahold of it, and are considering marketing it to similair businesses outside of our area.
Missing the point
If you build a site with Drupal and distribute it to a client, then they receive it under the GPL. That means neither you nor they are under any obligation to distribute it to anyone else, but neither can you bar them from doing so. There is really no way around that, no matter how good your attorney is.
There is an attorney here in
There is an attorney here in Dallas who specializes in open source licensing. His name is Steve Thrasher, steven.thrasher@thrasherassociates.com.
Website: www.leveltendesign.com
Twitter: @levelten_tom
Learn Drupal: Tutr.tv