7

I hope this is the right forum for this.

I do software work for clients and typically the client owns the code I write.

Now this work can include "utilities" i.e. useful code that I have already written but that isn't specific to the project. Examples would be a specific file parser or a nice graphing routine with lots of bells and whistles, a nice test framework etc. I could write it from scratch each time but it's a lot nicer and quicker if I use something I already have.

I'm perfectly fine with the client using these utilities but I want to retain ownership so I can reuse them in future projects.

What's the best way of shipping this type of code? How can one best delineate the client-owned-code and the me-owned-code in a way that keeps the client happy and protect my assets?

Improve this question
2
  • 4
    Why would the client ever know about some utility that you wrote for them and that you later write for a different client?
    – bharal
    Nov 22, 2020 at 23:57
  • @Hilmar - basic question - yes or no, do you have a written contract with them for this bit of work? In 99% of cases for ordinary software freelance at an individual level, there's no written contract.
    – Fattie
    Nov 23, 2020 at 14:11

3 Answers 3

Reset to default
12

What's the best way of shipping this type of code? How can one best delineate the client-owned-code and the me-owned-code in a way that keeps the client happy and protect my assets?

There are two ways to achieve this that I know of:

  1. Draw a licensing agreement (or better yet, have a lawyer do it) and have your employer sign it if you ever want to bring such code into their codebase.

This has the obvious downside of almost every employer going "what the hell" and the mere idea of signing such document swiftly dies in legal, assuming that it even gets that far. And I say assuming as what will likely happen is that this will be a non-starter, having agreements like this attached to product you create is a minefield, and the only reason they would consider anything like that if your project would save very substantial amount of money to justify the mess.

To make matters worse while employees are here for some amount of time, this mess would likely stay in forever - it's a proper minefield.

  1. Opensource your tools.

If it's opensource and with an appropriate license (MIT/BSD are the easiest ones, GPL will likely be a no-no in most companies) you can use it with any amount of employers, clients and projects you want while preserving authorship. You can then also make a pretty easy case of being able to contribute to your opensource tool during paid for work time whenever it would help the company achieve it's goals, so the tool can keep growing as you go through clients/employers.

Of course the downside is that then anyone can just grab your tools and use them, having to only satisfy license needs, but on the upside if the tool will turn out to be popular those things do tend to lead to actual workplace perk - including job offers and easier interviews.

Update: Just to clarify one thing. While you can license your work as opensource, that doesn't mean that you have to publish it on GitHub, you can just shove it together with your normal work package. Of course with permissive license there is nothing stopping anyone else from grabbing this code and putting it on GitHub, unless you will put such clauses into the license but then look at point 1 of all the complications that brings.

Improve this answer
11
  • 1
    Option #3 would just be to include all your utilities in the code you give to every client.
    – Kaz
    Nov 23, 2020 at 1:27
  • 5
    @meriton existing licenses are well known, so legal would be ok with them or the customer would be comfortable enough with them to not go to legal.
    – Matthew Gaiser
    Nov 23, 2020 at 5:10
  • 2
    @Kaz except you have no right to do so after giving the code to client number 1, unless somehow your contract doesn't transfer IP over to the client (but then what are they paying you for). Of course the chance that you will get into any trouble over it are minimal, but low chance of detection is not a good excuse to break contracts, at least in my world.
    – Aida Paul
    Nov 23, 2020 at 7:08
  • 2
    @Fattie: It's a 100% given that there will be a contract. Even a verbal contract is a contract. What might be lacking is complete evidence of the contract, but the fact that there's work being done for money is already partial evidence.
    – MSalters
    Nov 23, 2020 at 13:44
  • 2
    He's not an employee. He's a freelancer, so he can draft whatever contract he wants. Services companies do this all the time: we develop this product for you for X amount, but it costs Y if we can also retain the IP, where Y < X.
    – rolisz
    Nov 23, 2020 at 14:02
7

As part of your contract with the client, I'd add a clause that you are allowed to reuse utility code in future projects. To sweeten the deal, I'd offer them a discount for doing so (aka making them pay extra if they won't agree :-)

We used this approach in a previous company I worked for, and I don't recall a client balking at this. After all, they benefit from such an agreement too.

Improve this answer
4

It's all in the contract between the company and client. If you don't have one, then, even freelancing, you need to get one written up. You can find legal services online, and a basic one shouldn't cost you too much.

There are a few things you should do.

  1. Wrap up your utility code, and give it a name. Sell a license for it included with your quote. - This way you are protecting your utility/boilerplate code that you re-use in every project. It also prevents the client from white labelling it and re-selling copies of your work.
  2. Have a clause in your contract that says you own any IP that you or your team discover or create. - This allows you to re-use any code you've written however you like, but not to re-use any IP you were given by the client.

Pay for a legitimate legal service to write this up for you, so it can be worded properly and cover all bases.

All development companies I've worked for in the last 12 years have had these terms. You are providing the service, you should be setting the terms.

If you freelance there should be no difference however, as comments have pointed out, freelancers are perceived (wrongly so) more like employees, so you may get some resistance over signing it.

You'd have to try it and see what client's responses are. I've done some freelance work, but I setup as an LLC (so technically not freelance) and I've never had it questioned.

The easiest way to skirt the issue is the open source approach as mentioned in the other answer.

Improve this answer
6
  • "Have a clause in your contract that says you own any IP that you or your team discover or create. - This allows you to re-use any code you've written however you like, but not to re-use any IP you were given by the client." So anything that you create while in the process of the contract you can then take and sell to their competitor? I can't imagine any company in their right mind signing that, as they are paying You for Your ip so They will own and use it. Did you actually have someone agree to this? As normally you have the very opposite term in a contract - that they own it all.
    – Aida Paul
    Nov 23, 2020 at 13:30
  • 1
    Let's say you create a bespoke blog for a client, sure, you could build it as a module and re-sell the same module to another client. Minus anything that contained specific IP of the original client.... This is done all the time. You aren't selling IP, you are selling development time as a service, and yes, all clients of companies (agencies) I've worked for over the last 12 years have agreed to this... BTW, I am assuming the OP is the development business / company and the contract is between this and the client...
    – flexi
    Nov 23, 2020 at 13:48
  • 1
    I don't see a difference. The OP is a freelancer currently choosing to give away IP. OP doesn't want to give away IP, so my suggestion is to stop giving it away. As a freelancer you're a 1 man business, not an employee. Up to the freelancer to set their terms.
    – flexi
    Nov 23, 2020 at 14:00
  • 1
    The difference is that what's normal for B2B is not normal for freelancing. And you are making definitive and sweeping statements about freelancing based on normality of a B2B practice, and those two are different forms things entirely. I'll -1 until you can provide citation for any of the sweeping claims you've made, like that "it's uncommon" and that "most clients won't even question it" as that's the very opposite of my almost two decades of freelance experience.
    – Aida Paul
    Nov 23, 2020 at 14:04
  • 2
    I think you're viewing freelancers as employees. A freelancers (self employed) person is considered a Business. If they work for a business that is B2B and they can draft whatever terms they like it's no different. --- You are however correct, most freelancers work like employees and work like slaves for the clients, so in that situation, I would say either grow a backbone and set your own terms, or go with the open source approach.
    – flexi
    Nov 23, 2020 at 14:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .