Do you tend to write your own name or your company name in your code?

Question

I've been working on various projects at home and at work, and over the years I've developed two main APIs that I use in almost all AJAX based websites. I've compiled both of these into DLLs and called the namespaces Connell.Database and Connell.Json.

My boss recently saw these namespaces in a software documentation for a project for the company and said I shouldn't be using my own name in the code. (But it's my code!)

One thing to bear in mind is that we're not a software company. We're an IT support company, and I'm the only full-time software developer here, so there's not really any procedures on how we should write software in the company.

Another thing to bear in mind is that I do intend on one day releasing these DLLs as open-source projects.

How do other developers group their namespaces within their company? Does anyone use the same class libraries in personal and in work projects?

Also does this work the other way round? If I write a class library entirely at work, who owns that code? If I've seen the library through from start to finish, designed it and programmed it. Can I use that for another project at home?

Thanks,

Update

I've spoken to my boss about this issue and he agrees that they're my objects and he's fine for me to open-source them. Before this conversation I started changing the objects anyway, which was actually quite productive and the code now suits this specific project more-so than it did previously.

But thank you to everyone involved for a very interesting debate. I hope all this text isn't wasted and someone learns from it. I certainly did.

Cheers,

Answer 1

(Standard disclaimer - I'm not a lawyer...)

From your profile you appear to be in the UK.

In that instance it depends on how you're employed. If you're a permanent member of staff then almost certainly your employer owns the works. You wrote them and have the rights to be identified as the author (that is you can tell people that you wrote them) but the ownership of the code and the intellectual property therein resides with your company.

If you're a contractor then there might be a case that you have some claim to them but it would depend on the nature of the contract. Generally speaking most UK IT contractors are classed as workers for hire which means that again the IP rests with the company rather than the individual. Certainly talk of a standard employment contract suggests that this will be the case whether you be permanent of contract.

Under these circumstances you have no right to release them as open source (or indeed to take them on to your next employer) and you should think about them in the same way you think about any other piece of proprietary software and act accordingly - they're not yours, you just happen to have access to the source code.

EDIT: Regarding the fact that you developed some of it in your own time. The minute you started using it at work without asserting your rights and licensing it to the company in advance you made it very murky as it's now very hard to show what was done when. From what you're saying the code libraries have been tested, debugged and fixed in work time (and the company owns anything done in their time), plus the obvious overlap with work you were doing for them (as evidenced by the fact that they fulfilled a requirement the company had which you were working on) means that they do have a claim and probably a pretty strong one.

The Unite Union has a piece on this. The key section appears to be:

"There are express statutory provisions:

· Section 11 (2) of the Copyright, Designs, and Patents Act (CDPA) 1988 and

· Section 39 of the Patents Act 1977

dealing with ownership of employee works. Under these provisions, employers essentially gain ownership of intellectual property rights in respect of any works created by an employee which he/she

· was required to produce under the terms of their employment contract or

· could reasonably be expected to produce under the terms of that contract.

Obviously, the wider the job description of the individual employee, the more difficult it will be for him/her to avoid the effects of Sections 11(2) and 39 above.

Even if the work is created by the employee in their own time and using their own resources, the employee will not necessarily be able to claim any rights in that work, if the employer shows that the nature of the work created was that which could be reasonably contemplated as part of the employee’s duties. This is demonstrated by the case of Missing Link Software v Magee [1989]FSR 361. There, the court held that copyright in a software programme written by an employee outside his work time and on his own equipment was made in the course of employment, as it fell within the scope of the tasks that Mr Magee was employed to carry out."

Basically because these libraries met a specific requirement on a project that you were working on for them, they have a claim on them.

EDIT 2: You need to understand that the fact that there are two versions of the code is probably irrelevant. The code meets a need the company has on a project you were working on and you wrote it while employed by the company (even if it was in your own time). That gives them a strong claim on the "core IP" of the code, not just on a specific copy of it you happened to implement on their project - viewing it as two branches doesn't change that.

It's worth noting that even rewriting it would be termed a derivative work and the IP would still sit with the company, even on a new version.

I think you have an idea of what you want to be true and you're trying to twist things to make that so but from what you're saying I believe the company has pretty strong claim to the code that you're not going to be able to work around.

Answer 2

If your company is paying you to code, it's their code. I wouldn't release it as an open source project unless you have their permission.

Answer 3

There have been cases where code written at home whilst working for a company was considered owned by the company. I'm not sure if that was ever tested in court but I think its pretty obvious that any code you write using company equipment, during company time (ie time you are sitting at your desk being paid by the company to write code) and for company software belongs to the company. You entered into an agreement with them (check your contract of employment) that says they will give you money in return for you to write code for them. You wouldn't be impressed if they said that they would withhold your salary becuase they intended to give it charity instead.

So, in short, it isn't your code. You do not own it. The namespaces should the company name because it belongs to them. They paid someone to write it! (ie you).

---

• caveat: you need to check your contract, or terms of employment to determine if the above really is true in your case, I would say it is anyway as they could easily sack you for doing your own thing on company time at the very least, and then claim it belongs to them anyway. the best advice for the future is to keep what you do for yourself and what you do for your employer totally separate.

Answer 4

I think there is a place where you made a mistake. The problem is that you wrote code at home in your own time, and then found that the code would be useful at work, so you just started using it there as well. What probably would be the proper thing to do in this case, is not incorporate the code that was done outside work into your company's code. You would either have to use company time to rewrite the functionality you already wrote, so their could use it. "But that's a big waste of time" you say. So the other option is that they license/buy the code from you for a price or for free so that they know they are legally allowed to use the code. I think what might be going on in your employers mind is that they are wondering what happens to that code when you leave? Do they still have the right to use that code?

Many programmers work on stuff in their spare time that would probably be useful to their employers, but you shouldn't start mixing the code without approval from the company.

Answer 5

Future programmers need to know who wrote the code in case the level of documentation is inadequate (which is sadly often so).

I always sign my name for this reason. And it also reminds me that I need to make sure I do a great job, because I know that if I don't some angry colleague will call me in the middle of the night! :)

Answer 6

As almost everyone has said, it is probably the case that the company has some claim on the code (with phrases like "I've written probably 90% of this project at home." it's murky).

One of the things to consider in the future is to carefully review employment contracts and either get a blanket 'own time, own kit -> own ownership' or get a per-project waiver from the company. That is of no help at the moment, unfortunately.

Answer 7

What is wrong with using some other name? The name of your son/daughter/cat/dog/hamster? Then you don't have to have these difficulties - you have just chosen a 'friendly' name.

Answer 8

All answers seem to concentrate on ownership.
But ownership and authorship (authors and owners, resp) are different notions.
Author is linked to moral, or inalienable, rights which are:

• perpetual
• inalienable
• Imprescriptible right
• Unsizeable
  If a work already created, and the proceeds of its exploitation, are liable to be seized by creditors, as the case may be, the latter may not demand that said work be divulged for the purpose of recovering the moneys due by its author.

Moral, or inalienable, author rights cannot be waived under most jurisdictions.

While ownership is related to Economic, aka property, rights.

Why not just to follow the practice of how scientific articles are being signed, when workers are frequently work as visiting researcher/professor, employed /financed nu multiple entities. or under independent financing of 3d parties: author name + where is the work had been done + credits who financed the work.

Note that these are many to many relationships (one author, anв his work, can have multiple affiliations and financing).