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?"

Ask a lawyer

sheesh.

Re:Ask a lawyer

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.

Re:Ask a lawyer

I agree.

Make A List

of the rights you want to retain, and what rights you'd expect a customer to want, then rank them from most important to least important. Then take these to an IP attorney. Seriously. There's too much case law around that deals with IP that you'll never

None

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.

Addendum

Obviously you need to talk to a lawyer too. Open-source licenses aren't EULAs, and you don't seem to be talking about EULAs anyway, but contracts put in place before work begins. They don't need any EULA to install or use your software, at least in the

DMCA gives EULAs teeth

They don't need any EULA to install or use your software, at least in the USA

You're referring to 17 USC 117 [bitlaw.com], correct? In practice, section 117 has been superseded by section 1201 [bitlaw.com], which allows a copyright owner to attach arbitrary restrictions to the d

Re:None

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

But what if the project reuses code to which you already hold copyright?

That's no different to if the code required any other proprietary library. Such a dependency would either be described ahead of time with appropriate licensing terms, or it woul

Re:None

I think we're basically in agreement in substance. It (should) be spelled out in the contract before any work begins. Although you didn't say it explicitly, yes, the vast number of such contracts are work for hire, with no special rights reserved by the co

Re:None

You're confusing one way things can be arranged with how they must be. Yes, one arrangement is the work-for-hire arrangement in which all rights are acquired by the employer and the developer gets nothing but his salary or the fee agreed for writing the s

Re:None

Don't get me wrong, I didn't mean to imply that this was the default state of affairs legally. I'm just saying that if you are hired to produce a specific tool, then it's pretty sleazy to lock it away and claim that it's yours even after you've been paid

Re:None

Well the sleaziness is in the apparent desire to strip the customers rights.

I find nothing at all sleazy about the developer wanting to retain his copyright and the ability to reuse the code, as long as he doesn't attempt to cheat the customer to do it. It

Re:None

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,

Re:None

"it's pretty sleazy to lock it away and claim that it's yours even after you've been paid for it"

Well, what does exactly mean "you have already been paid for it"?

Does this mean they will pay me for the hours it effectlively took me to write down the progra

Re:None

If he's developing this is as something he wants, and preferably is working on for other clients, then he should be licensing this to his customer then he sholud maintan the copyright but expect to support this for the forseeable future. If he is designing

Re:None

The two can agree that this is to be a work-for-hire but they need not, and it is not the default arrangment.

Well, really it's a bit more complicated than that. Sometimes you can agree that a work is a work made for hire, and sometimes you can't. I would s

Re:None

In this situation by default the developer owns the rights and what rights are to be transferred to the client must be negotiated. The two can agree that this is to be a work-for-hire but they need not, and it is not the default arrangment.

Are you sure abo

Re:None

the vast majority of work-for-hire contracts

"Work-for-hire" nor "contracts" is "default".

AFAIK (USA+IANAL perspective), WFH status occurs when you are an employee of the company, and involves considerations above and beyond just "I pay you, you work" (I'm

Re:None

Thanks for the in sight. IANAProgrammer, although I do work as a freelancer/independent contractor in a creative field. Almost invariably, everything gets spelled out in the contract (or deal memo, in my case), and very rarely do I hold any creative rights

Re:None

Tell this to photographers.

Re:None

I actually had photographers in mind when I wrote that. I think keeping copyright on photos you are hired to take is pretty sleazy too.

Re:None

I agree on this point, I would never hire another photographer unless I owned the exclusive and complete rights to the pictures. But for software, the developer might bring in their own library that they made over the years to simplify often-coded tasks,

Re:None

Apparently you are unfamiliar with the entire photographic industry.

What makes you say that? I never claimed it was unusual for photographers to do this, merely that I think it's pretty sleazy.

Do you also think it's sleazy to retain the rights t

Re:None

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.

Re:None

Right, but I imagine what's really needed here is a contract, not a EULA. This looks like a single developer making software for a single customer.

Of course, there are plenty of companies that like to think that a click-through EULA has the same strength

Re:None

"None whatsoever, the client should retain the copyright"

Why? In any case, the client will know, not you.

Probably the computer you sent you message is full of software you don't own the copyright for (probably you don't have any single piece of software w

Re:None

The bottom line is if somebody pays you to create something to their specifications, then it's a work-for-hire...

In your opinion: yes. Ethically: there's an argument to be made for this position, depending on the specific circumstances. Under copyright la

The only question is copyright

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.

Agreed, don't use EULAs

In addition to what the parent said, they're insulting to your customers. Do you really want to be a bully?

Re:The only question is copyright

You're thinking of shrink-wrap or click-thru EULAs. There's no problem with a legally binding EULA if you put it on paper and have the customer sign it before they purchase the product. (Been there, done that.)

Re:The only question is copyright

I'm not sure of the actual law regarding EULAs if it is an actual contract.

My point is that any copyrighted work should be subject to the doctrine of first sale. Short of copying and then distributing the work in question, I should be able to do anything

Works for hire, EULAs

From 17 USC 101:

A "work made for hire" is--

(1) a work prepared by an employee within the scope of his or her employment; or


(2) a work specially ordered or commissioned for use as a contribution to a collective work, as a part of a motion pictur

Re:Works for hire, EULAs

As to EULAs though, they would indeed have to be contracts to be binding, but they fail so many tests of a contract they can't be that.

What makes you think so? Generally courts uphold EULAs. Some courts don't, but the pro-EULA side is winning. I would sugg

Re:Works for hire, EULAs

Laws regarding software are so incredibly complex. You can copyright software; you can also patent specific algorithms contained in it. You can also distribute it with an attached EULA (in some jurisdictions, as you state).

Why is it that I cannot also pa

Re:Works for hire, EULAs

Why is it that I cannot also patent a story?

There's a guy who is attempting this. Of course, novelty, nonobviousness, and utility are serious hurdles, but the big one is subject matter. It's difficult to see how a plot falls within the realm of the useful

Re:Works for hire, EULAs

> Who said you can't? Remember, the first sale and fair use doctrines merely say that the
> copyright holder lacks authority over copies and works under certain circumstances on the
> grounds of copyright. They don't bar the establishment of indepen

Negotiate it up front

This seems like exactly the sort of thing that should be negotiated when the contract with the client is made to develop the software in the first place. Tell the company what rights to the software you want when you're approached about the job, see what

Sorry, but...

...nobody reads them anyway. Why don't you just copy the EULA off of a similar product? Make sure the lawyers read it first.

Biggest issue:

Readability.

If at all possible, use an established, recognized license. The GPL, something from Creative Commons -- hell, I love the Unreal licenses for simple brevity and readability, but chances are, you'll want something written in 20 pages of pure leg

Re:Biggest issue:

EULA - end user license agreement

notice the key word?

Re:Biggest issue:

Nobody has to agree to a license. If you don't, you cannot distribute the work, but otherwise you are fine.

No, if you don't agree to the license under which it is released, you can not legally use a piece of software.

After all, most of them outline the res

Issues raised but no answers?

I'm facing a similar situation myself right now and read with interest the comments to this post - I saw lots of issues raised and opinions debated, but very few concrete responses. Obviously, contacting a software licensing attorney at some stage of the

Re:Issues raised but no answers?

"but have no idea how to even begin to put stuff on paper"

Don't you read your own words?

That's exactly the point when the software licensing attorney comes in. You already know what would you want to do with the software and know what the other part expec

Re:Issues raised but no answers?

> Don't you read your own words?

No, I have people for that.

You're right as far as you go; I could've been more specific. We want to use the attorney as little as possible - there's a very limited and specific market for my software, and my employer is

Re:Issues raised but no answers?

I think I don't get you.

"my employer is a nonprofit which gets much of its project-specific funding from taxpayer dollars"

And your company is still doing this _for_a_profit_?

Now: The work is not yours, but your employer's (it's a "for hire"). Your employe

Best EULA?

How about "All your base are belong to us"?

I think that's what Sony is using on CDs nowadays.

Easy

"consumer has no rights after accepting this agreement"

Let me get this straight...

You get payed to develop custom software for people, then you go ahead and develop it, keep ownership, and graciously provide the customer with a restrictive license to use your code?

In case you hadn't noticed, you are not Microsoft. Fucking over your cus

GPL works

Haven't done it many times but I use the GPL. Reasoning thus:

Look Mr Client, I ain't writing a work for hire, at least not unless you add a zero to the check. Because I'll be cutting and pasting code in from my own stash and from other Free/Open code und