> I am right there with you in terms of recognizing the need to provide a
> profit-incentive for Sun (and ALL companies!) to use/advocate Perl.
For anyone other than Sun: sell training and support as an alternative
to Java.
> Here was the catch: Because our work is work-for-hire, we had to have a
> separate license with our clients just for these libraries. We were not
> charging them for the code -- we just wanted to use it without giving them
> ownership. It saved us money, and it saved them money as a result -- a
> win-win if I ever saw one!
Look more carefully at the Artistic License. It is specifically designed
to allow your retaining control of works created in Perl. You might
find that simply handing the client some code in AL will be sufficient.
Getting them to look at it may be another problem...
In general even if you can not re-sell the same code noone can keep
you from re-writing the same solution. This means that there is no
reason not to keep useful portions of the code you sell in house as
"training tools" or examples. After a job is done simply show the useful
portions to someone in the company and have them re-write the same
thing. Viola, re-usable code is born.
> Much to my surprise, some clients couldn't accept the fact that they didn't
> own every bit of code we wrote for them. (Never mind the fact that they
> didn't own the RDBMS or the web server or the operating system we used!)
> This became a sticking point with those types of clients. Ultimately, we
> would be forced to charge them more to create a "license-free" version of
> their software. Kind of silly. We basically would be ripping off our own
> work to re-do something we had already done. We weren't thrilled at the
> situation.
Clients want to feel that what they are buying gives them some
competative advantage. So, complete ownership is their way of
making sure that noone else uses the same code againsed them.
Again, they cannot keep you from learning useful things from
your work and applying them to new jobs. If you sell the re-used
code as part of an "in-house library" of stock code they'll usually
buy into it on the grounds that it (a) makes your work faster/cheaper
and (b) is internal "stuff" that doesn't take away from the particular
solution you've written for them.
> At some point, the idea occurred to me that these clients also didn't raise
> an eyebrow about all the OPEN-SOURCE code in their software, either! If we
> released the modules we most valued, we would have the benefit of their use
> while effectively side-stepping the whole ownership issue. We've released a
> number of modules since then, and nobody has heard a complaint since! Of
> course, we also have gained all the other benefits of releasing software
> (too numerous to recite). Our libraries have improved in the past couple
> years as a result, as has our ultimate work-product and our business
> bottom-line.
The harder thing is to show the client why they benefit from your action
in releaseing the code. better support is one, but your management may
not be pleased at giving away the notion that other companies can support
(or even write) the code using the same sources that you did. Double-edged
sword time. if your company's pitch is currently that you have better
insight into the problems/solutions then this plays back into your hands.
It's just hard[er] to sell this line than faster/cheaper/better these days.
sl
