Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
How much of your source code do you release?
Message
From
11/08/2000 17:06:54
 
 
General information
Forum:
Visual FoxPro
Category:
Contracts, agreements and general business
Miscellaneous
Thread ID:
00404146
Message ID:
00404161
Views:
13
Hi Brian,

In your agreement with your client, you can include a paragraph about the "background technology" which you will use in conjunction with software which you will develop for the client. Make it clear that the client will have the non-exclusive right to use the background technology in connection with their use of your software, but state explicitly that they do not get ownership of the background technology. Enumerate the background technology items in an appendix to the agreement - list each class library, FLL, DLL, OCX, or whatever - so there's no question later about what's theirs and what's not.

If you deliver source code, one way to protect your common class libraries is to strip the source code out of the copy you deliver to the client, leaving just the object code. You can do this by opening the VCX as a table and clearing out everything in the METHODS column. Before you do this, be sure to save a copy of the VCX with the source code for yourself!



>Just out of curiousity, those of you who are independant contractors and developers; how much of your source code do you normally give over to clients? Most people (prospective clients) I've talked to want rights to the code, which is understandable. But how do you protect your class libraries and other custom methods? If they "own" the source code as "work for hire", custom class libraries need to be turned over in addition to forms and .prg's, right? Otherwise they can't modify the application in the future.
>
>If a client hires you to develop an app, and then gets someone else to help out or build a different part, what's to keep the other developer from copying your stuff? Or is that just a part of the business?
>
>
>- Brian
Rick Borup, MCSD

recursion (rE-kur'-shun) n.
  see recursion.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform