The rest

Intellectual Property Rights 101

contracts, ipr

This is a related to the earlier IT security 101 blog post.

Consulting companies approach intellectual property rights (IPR) differently: some companies keep all rights themselves and only grant a license to use the work they have done. Some – including Futurice – take a different approach, and explicitly agree that all IPR belongs to the client. On one hand, this is fairer and simpler: our client is paying us to do the work, so they should own what we produce. Also, there is no hard vendor lock-in: as the client owns everything (source code, documentation, graphics, plans etc.), they can switch to another vendor if they want to. On the other hand, as Futurice does not own IPRs for the work we have done, we can’t reuse source code or other resources between different clients. This does not mean we start from scratch every time – there are a plenty of libraries and frameworks that are reusable, and in the end experience gained from previous projects matters a lot.

For our employees, an employment contract specifies that all IPR are transferred to Futurice, and then the project contract with our client transfers the IPR to them. For our subcontractors, we have both formal contracts and informal agreements. Our employees learn the same things during our onboarding camp.

IPR 101

Rule #1: The customer owns all project work.

Rule #2: Never copy-paste, publish, talk about, or reveal in other ways any customer sensitive information outside Futurice or in another project.

Rule #3: Any and all exceptions to the above rules only apply if you have a written permission from Futurice.

What is customer sensitive information? Code, conversations, customer’s business goals and plans, financial information, budgets, prices… Basically anything that is not already common knowledge. Legal definition for this can be found in your NDA.

What about solutions? Can I reuse what I’ve learned? Yes, if it’s about the technologies, frameworks or such. You cannot implement the exact same large-scale solution, but usually “don’t copy-paste” is enough as a rule of thumb. If in doubt, talk with your Futurice project lead or legal department.

With the Spice program we aim to support the open source community. That includes offering bug fixes to the frameworks and libraries we use. Remember rule #3: if you make a fix or improvement to an open source library in your project, you need written permission to publish it. We aim to have the necessary clauses in our contracts that permit fixes and additions to open source libraries, but you always have to be aware whether such clauses are present in your project’s contract, and what the exact contents of that clause are.

I hereby declare that I’ve understood and will follow what is stated above:


Name, date