Ideal EULA for Custom Software?

Tiger4 asks: ""End User License Agreements (EULA) for custom developed software present a nasty problem for both developers and the customer. What rights does should the developer grant to the user, and what rights should be retained by the developer to capitalize on their effort? Similarly, the customer, who is paying for the work, wants all the rights possible to maximize their investment, but probably only needs a small subset of them, such as maintenance and upgrades. The developer probably wants to be able to re-use and resell chunks of the code; the customer doesn't want single source lock-in, so they want re-use and alteration rights too. The Open Source licenses don't solve all ills, because some processes and data may be trade secrets, or at least closely held in an industry. So what terms should definitely be in a EULA, to provide both maximum flexibility and protection for both developers and customers?"

Comments

Ask a lawyer

[j1mmy]

sheesh.

Re:Ask a lawyer

[Ohreally_factor]

Exactly. And if you're developing custom software, at least some, if not most, of the issues will be spelled out in the contract. You might or might not want a license agreement of some sort, but it depends on the contract you negotiate.

A EULA is for when it's not custom work, when you are not negotiating anything, but selling or distributing your code to an unknown (at the time of the transaction) party.

Again, as the OP stated, ask a lawyer, not slashdot.

None

[Bogtha]

what rights should be retained by the developer to capitalize on their effort?

None whatsoever, the client should retain the copyright. The developers have already capitalised on their effort by being paid. Rephrased, the question is more like "What's the most profitable way to avoid giving the client what they paid us to create?"

Similarly, the customer, who is paying for the work, wants all the rights possible to maximize their investment, but probably only needs a small subset of them, such as maintenance and upgrades.

And what if they want to sell licenses to others to offset the cost they incurred?

The bottom line is if somebody pays you to create something to their specifications, then it's a work-for-hire, and they should get the copyright. If you want to re-sell the work that they've already paid you for, then you should pay them for a license.

Re:None

[Ohreally_factor]

You've brought up an excellent point, but it's not always so black and white. Ownership of the copyright can (and should be be) subject to the negotiations of the contract before any work begins. If the agreement is work for hire, then you are absolutely right. But what if the project reuses code to which you already hold copyright? See, it can get a little ambigious, which is why it's important to examine all possible angles during negotiation and then spell it out in the contract.

I might be assuming too much, but it sounds like the OOP, Tiger,

1) Doesn't know what the hell he is talking about;

2) Thinks he can backdoor some rights into the software after-the-fact with a EULA.

Re:None

[SpacePunk]

Tell this to photographers.

Re:None

[belmolis]

I agree that this is sleazy if it isn't up front. One situation in which it makes a lot of sense for someone to be hired to write a program but retain the rights to it is one in which the purchaser doesn't have a lot of money and the program is one which, perhaps with adaptation, will be useful to lots of people. In this case, it makes a lot of sense for the developer to charge a relatively modest fee for writing the program and granting the client a license for it, while retaining the ability to provide the program to others.

Re:None

[hazem]

None whatsoever, the client should retain the copyright. The developers have already capitalised on their effort by being paid. Rephrased, the question is more like "What's the most profitable way to avoid giving the client what they paid us to create?"

That's not necessarily the case. Suppose the developer has built a library of routines that are particularly suited to a common job, such as a database for doing a "balanced scorecard". I'm contracting with them now and they'd like to use their core library to make the project go faster with fewer bugs. Sure, I get rights to the code they produce, but they don't want to allow me to distribute their library code to others.

This is pretty much the situation I'm in right now. The agreement we have is that we are co-owners in the IP of the project. The basics are:
- neither of us can release the code to the outside world without approval from the other
- we can use the code without restriction in our corporation and our subsidiaries
- they can use the code in other projects with permission and as long as there is no connection or mention of us
- they cannot use us in any promotional material ("___ corp used us, and you should too")

It keeps us from going to into business against them, and it keeps them from taking our "trade secrets" to our competitors.

It works well for both of us because there is actually some co-development going on with the project.

The only question is copyright

[stinerman]

EULAs violate the doctrine of first sale. You can't license software any more than you can license a book. The GPL, BSD, and other such distribution agreements are not EULAs and are certainly fine.

Now, your only problem is to whom the copyright will go. The law says that a work for hire should go to the person who did the hiring. I don't agree with that, but its pretty much settled.