Commercial Security versus Open Source Ideals

I have a client whom makes use of a proprietary banking and transactional gateway through our systems, supplied by a third-party whom provided no source, only details on CLI methods of interface. To facilitate a more accessible method of interface for the software package, I wrote up a fairly comprehensive Perl module which offered a secure and vetted manner by which to interface the package CLI - It should be noted that this module was not written specifically for the client (nor was the client charged for the use of it), but developed rather as an 'in-house' project to improve the functionality of this system for both ourselves (we also use this banking and transactional system) and our clients.

(Note : The third-party company which supplied the banking and transactional software did also provide a Perl package to interface this script upon delivery, but the script was so haphazard and poorly written, it was quite obvious that the author did not know a great deal about Perl. This too factored into my motivation to rewrite a more flexible and secure interface API.)

Why is aspect of code quality and product ownership important? Well ...

This system has run smoothly for the last 6-12 months or so, with a few small patches written along the way to improve functionality or clean up return values. Anyhow, today I have been asked for a copy of all template pages and scripts associated with this client's account (this transactional interface was not the only code built for this client) and while the client has little to no programming knowledge or skill, I have no problems complying with this, except for the banking/transactional interface module. There are a number of reasons for my hesitancy to provide the banking/transactional interface Perl module to this client, some commercial and some simply practical reasons:

The first reason is commercial - It is quite likely that this client may be looking for a new web host, partly due to their (IMHO, unrealistic) scheduling demands which would explain the request for all files and scripts for migration to the new web hosting provider (there are technical limitations of this which I will explain).

The second reason is also in part commercial - This banking/transaction interface Perl module was not built specifically for this client, but rather developed 'in-house' for our own interface and use. The client has never been charged any development time for this interface or access fee for use of it (barring those charges levied by the banking gateway itself). It does not seem to be fair or justified to provide this code in its entirity to this client, particularly given that they have little programming expertise or contribution that they could add to the project independently.

The third reason is more practical than anything else - Even if the client was supplied with this interface module, despite their lack of programming or technical knowledge, they would be very little use for it, as it is dependent upon the proprietary banking and transactional software supplied originally by the third-party in this scenario. Without this banking gateway, the interface module is useless. This banking/transactional gateway is both machine and IP locked so that there is no way, short of reestablishing their account with the banking gateway, that this interface module could be used elsewhere.

So now I am left torn ... Do I provide the client with this code and follow the ideals of open-source which I (purported) believe so greatly in? Despite the fact that it was never written specifically for them and its commerical dependency upon other elements for operation? Or do I refuse to provide this code, supplying them instead with everything but this module? I am especially upset that this scenario involves Perl, a language and community which I have grown to embrace so strongly and appreciate the open nature omnipresence throughout.

This is my dilemma - Your thoughts, ideas and even flames are welcomed as I grapple to come up with the fairest and most just solution for all (including my client).

Ooohhh, Rob no beer function well without!

Comment on Commercial Security versus Open Source Ideals

Replies are listed 'Best First'.
Re: Commercial Security versus Open Source Ideals by Moonie (Friar) on Jul 31, 2001 at 10:31 UTC
This is an interesting situation. First, I agree with cforde. If there are any contracts that state that they may have a right to this software, then unfortunately your hands are tied. But, if this is not the case then there are possibly a few options open. Some of these options are: They pay for the software and license They purchase a license agreement to utilize this module in their new environment You open open the code on CPAN or what not and they can d/l and configure it to meet their needs More than likely, if they are requesting the code and all the templates - they will most likely get around and gather their own relationship with the Third Party software. I'm assuming (I know, bad habit) that their Tech. Dept. must understand what needs they have in order for their system to run properly. You could always just hand them the software, that is another choice. If you do that, will you be able to use it for another client(to solve possibly a future problem)? Or will it be legally theirs to do as they please with it? This may or may not be an issue. You did mention that giving the software to the client would promote open-source - but another question would be.. would it remain open source? The way it sounds to me, is that the module that you've written is proprietary, in which you utilize it to improve and meet your clients needs. Maybe the question is, do you wish to open it up to everyone? to just your clients? or sell it? Although, it would be great if there was an open source module for many banking companies out there. :) -Moon	[reply]
Re: Commercial Security versus Open Source Ideals by cforde (Monk) on Jul 31, 2001 at 10:01 UTC
The first thing I think you need to do is to read the contract very carefully. What does it say about code and interfaces? What constites their web site and what is your supporting infrastructure? The first they can have, the second they can't, or so the contract should read. The question then becomes on which side of the line does the module in question fall? Have fun, Carl Forde	[reply]
Re: Commercial Security versus Open Source Ideals by fmogavero (Monk) on Jul 31, 2001 at 19:22 UTC
My thoughts: Once again making money is the reason to own and conduct a business. Unfortunately, in this scenario you have "personal" reasoning that can be used. It must all be weighed out impartially with "the business" first and foremost in mind. The one point that I don't think you addressed directly, is the issue of "proprietary" code. If your "business" uses this code, and you "give" it to the client, they could then claim it as their own and stop you from using it. Management needs to be alerted to this fact and quickly. Since the client has not paid for the development of the code, it would be a really poor business decision to "give" it to them. They should be charged for it. It would also be a bad business decision to allow someone else to use your code to cripple your operation, which is one of the concerns I believe you have. Evaluate your code and decide what percentage is client related. Then once you know that you can easily deduce what percent is "the business's" and you can make a better decision from there. This has always been an interesting subject for me, so I would like to see what the final outcome is. GOOD LUCK!	[reply]
Re: Commercial Security versus Open Source Ideals by Mungbeans (Pilgrim) on Jul 31, 2001 at 19:11 UTC
Tricky. If they haven't paid for the code, and it includes no GPL'd modules, and it is not mentioned in any contract then I don't think you have to disclose. Ethically: should you? Your company privately developed this code at it's own expense, as I see it you have every ethical reason to refuse to release this. It's private property. It could potentially financially harm your company. They may want it for ESCROW purposes (e.g. in case your company tanks) but you can satisfy that by supplying the code to a trusted third party (talk to the company lawyer if this is in fact what they want). I see nothing wrong with people making money out of Perl - I'm all in favour of it. While all the free contributions to Perl have helped me immensely, I'd be very reluctant to release commerically sensitive code without a lot of thought. I don't see this as parasitism, I will contribute what I can to the community, but I will not feel obliged to do so other than through my own free choice. My 2p, hope this helps. "The future will be better tomorrow." ... from the collected wisdom of George W Bush.	[reply]
Re: Re: Commercial Security versus Open Source Ideals by IDStewart (Acolyte) on Jul 31, 2001 at 22:50 UTC
If they haven't paid for the code, and it includes no GPL'd modules, and it is not mentioned in any contract then I don't think you have to disclose. I don't think there is any requirement for disclosure, even if the code does use GPL'ed modules. The GPL requires that if you distribute software, and that software is a derivative of GPL'ed software or the software links against a GPL'ed library, then the source for the software must be made available. The GPL does not require you to distribute software you otherwise would not	[reply]