self developed modules for client use

[arc_of_descent]

Hello,

What would be the best way to deal with the following scenario?

A coder has been developing her own modules for use in her soon to be released product/service. Along comes a client (the coder is a freelancer), and wants a program which could benefit greatly from one of the modules.

In short, the client would want all code delivered as his own property. Now I could very well put some subroutines of the modules inside the Perl script, but then its more work for me, and I would love to deliver the script along with the modules exactly as I wrote them. This solves the client's problem as well as mine, as I would just need to write s simple script to access the module.

Any legal stuff to watch out for here?

The above module is just a small example and the bigger question deals with my codebase of modules, snippets, and utilities. I save my time by reusing my code libraries, but still don't want them to be delivered to a client as a module, but then extra work for me.

Sorry for not being very clear about this.

[Tanktalus]

Any legal stuff to watch out for here?

IANAL, and, even if I were, I don't know what country you're in. That said, I would suspect that there are legal things to concern yourself with. For starters, if you sell your code to the client, you no longer have ownership of it to continue using it in your other product (without licensing it back from the client). I'm talking about an ethical ownership here - which may or may not line up with legal ownership in your jurisdiction.

Your best (legal/ethical) bet is to offer that module as "licensed" (whether it's open source or not is up to you) so that you retain ownership while your client gains the ability to do whatever they want with it (as agreed to by both parties ahead of time).

If the client is not amenable to such licensing, then instead charge the correct rates for you to redevelop your module from the ground up again, with consummerate increases in schedule as well. Most people will be ok with licensing as it reduces their cost as well as reducing the schedule, but you need to know what your fallback position is if the client is obstinate.

[xdg]

In short, the client would want all code delivered as his own property

Licensing or open-sourcing (which is a form of licensing) is probably the right answer for the common, reuseable bits of code. That said, if I were in your shoes, I'd try to understand what the client is concerned about with respect to the code. Some possibilities include:

• Access to source code and ability to modify it over time for bug fixes and feature enhancements

• Ability to freely sell a product/service that uses your code without restriction

• Ability to create derived works without restriction (e.g. "viral" licensing)

• Whether the license is limited or in perpetuity

While consulting a lawyer is always recommended before selling your rights to a work product, you may want to read up on some options/ideas at The Open Source Initiative. In particular, see the OSI Definition -- the commentary is particularly good at explaining some different rationales. (Update: also Understanding Open Source and Free Software Licensing, an O'Reilly Open Book)

What you should be careful about is incremental things you develop for specific clients that have reusability and that you want to retain. If you already have your code library and you make it clear to the client that you are utilizing that library under an appropriate open source license -- it's really no different than them using Perl or anything else on CPAN.

On the other hand, if you develop something for them and get paid for it and then want to open source the reusable parts to save you time on future jobs, that's a greyer zone unless you explicitly include that in your contract with them. While IANAL, I think you'd be on safer legal (and business) ground if you didn't charge directly for the development of parts of your library -- that's an investment in yourself/your company that you recover later in the premium you can charge for faster delivery. It would be appropriate to charge for the integration of parts of the library into their custom code, however.

Put differently, if part of your work means customization or extension of your own library, your contract needs to be clear that they are paying for that and that you retain the rights to that library -- though you will make it available to them under a license which addresses their concerns. The custom code you develop for them is probably something that becomes their property -- or possibly, that you retain ownership of, but that you license to them on an exclusive, perpetual basis. This kind of hair-splitting is where you really do want to consider hiring a lawyer, particularly if you live in, or work in, or have clients in a more litigious countries (like the USA).

[dragonchild]

While this may not help your specific situation, what we tend to do is the following:
• If the code contains anything that's client-specific or client-provided, it's closed-source for the client. Period. There is NEVER an exception to this.
• If the code is general-purpose that just happened to be developed as part of work for a client, we opensource it, usually by releasing it to CPAN.

Our clients understand this process and have no problems with it. You might want to work out a similar understanding with your clients.

[Fletch]

I've had Web & Software Development: A Legal Guide (ISBN 1413300871) from Nolo recommended as a good guide to at least get you up to speed enough to talk to a real lawyer. I've not gotten around to picking it up myself, but it has good reviews on Amazon and I've been satisfied with other Nolo published books (my wife used one on getting a small business started). They've also got online information at nolo.com.

But yeah, this is really a case where you want to listen to the people saying "IANAL" and talk to a real L.

[spiritway]

Personally, I think it's probably a bad idea to sell your code, since you lose control over it. IANAL, either, but it seems to me that you could wind up getting sued for using code you created yourself, if you sell it to someone and then try to use the modules, even if you recreate them. Chance are, the code will look similar, which might leave you vulnerable.

Probably the best suggestion is to talk to a real lawyer if you can afford it. Especially if you can afford it, because that makes it more likely that suing you would pay off.

[salva]

take the obvious way: ask your customer what he prefers you to do!!!
• to use your already made libraries and get his program cheeper and faster at the cost of not owning the intellectual property for that parts (you should agree in an adecuate license).
• a program completelly written from scratch

[hesco]

Neither am I an attorney, but here is a snippet of a canned memorandum of understanding I gain agreement on when I start work for a new client:

15. Any custom scripts or forms developed for the client's web sites or server shall be jointly owned and copyrighted by the vendor and the client and the actual author(s) retained by the vendor to develop such scripts. Such scripts shall be licensed under the Gnu Public License and may be released by the vendor or the client under such terms to the general public, unless the subject of a seperate agreement prior to the development of such scripts.

Folks who know nothing about gpl focus on the hours, rates, deliverables. Folks who know about oss licensing issues focus on the hours, rates, deliverables. I have developed in house software that handled client specific applications in highly competitive, limited markets. That business logic was proprietary. And I agree with the comments above about the need to respect those boundaries if one expects the trust and continued business of a client.

But my stock contract, the point from where I start negotiations, is that I may, but am not required to release code developed under gpl, leaving me free to reuse code. The three days I spent on code for a previous client becomes the two hour solution for a new client.

-- Hugh