The initial thought, at least of the commissioning party, is to demand that ownership in the bespoke software be assigned to it. At the most basic level, the typical thinking goes something like this: "I paid for it, so it should be mine", or, "It is my policy to own all of my software." Such a position makes some sense. It is true that ownership of the bespoke software itself, without more, will not enable the commissioning party to make use of it (see below). At the least, however, ownership will enable to commissioning party to dispose of it more easily in the event of a sale or acquisition. Whatever the reason, it would be an unusual circumstance in which the commissioning party would allow the developer to continue to own the bespoke software.
That is fair enough. But how does the commissioning party deal with the generic portion of the software that is necessary for the bespoke software to run? From the developer's point of view, unless the commissioning party is willing to simply buy him out--hook, line and sinker--he will will insist that ownership of the generic software remain with him. If so, that means that the commissioning party will likely receive a non-exclusive license to use the generic software.
Under that arrangement, the commissioning party should take special care to protect itself against the insolvency of the developer, especially if insolvency could lead to termination of the licence in bankruptcy. As well, provisions for escrow deposit of the source code with appropriate release instructions should be included. Moreover, a free right of assignability of the license is essential if the commissioning party is able to dispose of the bespoke software in a way that makes commercial sense. Whether all such clauses can be successfully drafted from the position of the commissioning party is far from certain.
Then there is the issue of overlap between the bespoke and generic software. While it is rhetorically easy to describe the situation in simple dichotomous terms, the reality may well be more complicated. Try as it may, the developer may not be able to completely separate the bespoke portion that belongs to the commissioning party and the generic portion that remains with the developer.
Finally, there is a related issue in connection with trade secrets. If the developer is required to disclose to the commissioning party proprietary knowledge related to the software--either bespoke or generic--how does the developer ensure that such trade secrets are not disclosed in an unauthorized fashion? Disclosure might not be critical if it is tied specifically to the bespoke software but, if the trade secret straddles the bespoke/generic divide, then the developer must be especially careful to protect its interests in this regard.
The upshot is that, in these circumstances, there is a degree of uncertainty that seems to be built-in. How readers have dealt with this uncertainty would be most edifying.
Then there is the issue of overlap between the bespoke and generic software. While it is rhetorically easy to describe the situation in simple dichotomous terms, the reality may well be more complicated. Try as it may, the developer may not be able to completely separate the bespoke portion that belongs to the commissioning party and the generic portion that remains with the developer.
Finally, there is a related issue in connection with trade secrets. If the developer is required to disclose to the commissioning party proprietary knowledge related to the software--either bespoke or generic--how does the developer ensure that such trade secrets are not disclosed in an unauthorized fashion? Disclosure might not be critical if it is tied specifically to the bespoke software but, if the trade secret straddles the bespoke/generic divide, then the developer must be especially careful to protect its interests in this regard.
The upshot is that, in these circumstances, there is a degree of uncertainty that seems to be built-in. How readers have dealt with this uncertainty would be most edifying.