47

I'm a programmer. I love my job, I love it so much that I continue spending time programming when I'm at home in out-of-office hours like in the evening or at the weekend.

The language that I program in has to expose the source code, I can't just make a software that could be installed without showing source codes. I feel happy to share the code I write on my free-time with the company I work for. They are obviously very happy to accept my code and use it in internal procedures, making everything simpler and faster saving them hours by automating activities for them.

Yesterday they needed a change in one of MY procedures but I couldn't spend time on applying them because I am near a very strict and important (in the opinion of the project manager) delivery. So they gave this activity (changing MY code/procedure) to another programmer. I like her, she's a good programmer. But that's my code, I worked on it on my free time and I don't want them to change it without my supervision.

I asked to a pair of colleagues what they think about this, and they're with me. But my code was a gift and it seems that the company really needed those changes.

Is it stupid on my side being "jealous" of my code? Was it rude on their side, giving this activity to someone else? How can I say to them that I didn't like it, without being rude?

thank you.

edit: I'm speaking about stand-alone procedure, developed outside from the office, not part of my office work (but related with it)

Improve this question
17
  • 9
    By the way: just because code can be viewed, doesn't mean it is open source according to the OSI definition. Just having access to the sourcecode does not imply the right to modify it. Copyright still applies.
    – Philipp
    Sep 23, 2015 at 13:01
  • 22
    Short answer: no licence, no rights. Forget about it and move on.
    – Max Williams
    Sep 23, 2015 at 14:06
  • 4
    I don't know how it is with software, but typically, an employer will own any IP created by its employees that's applicable to its business, or created using company resources. That should be spelled out in the company's policy that was agreed to when accepting the job. That's why it's important to keep work and personal projects separate.
    – DLS3141
    Sep 23, 2015 at 16:20
  • 5
    In modern software development coding is a community activity and you should be glad that another developer will work on it. Collaboration is good for you, for the code and for your company.
    – Alessandro Teruzzi
    Sep 24, 2015 at 10:54
  • 5
    @MaxWilliams: The country you live in is not the world and not necessarily the asker's country. In Germany, you always have copyright to things beyond triviality.
    – phresnel
    Sep 24, 2015 at 12:40

8 Answers 8

Reset to default
133

Is it stupid on my side being "jealous" of my code?

I wouldn't use the word "stupid". But perhaps you are misguided in your jealousy.

You are trying to say to your company after the fact - "I gave you a gift of some code without any license. But now I don't want anyone else to ever touch it except me".

I'm guessing you didn't express your desire to be the sole maintainer, since I can't imagine any company agreeing to such a request.

Was it rude on their side, giving this activity to someone else?

Unless you explicitly stated ahead of time your desire to be the only one who ever touches this code, I don't see how their activity can be considered rude, disrespectful or unethical. I think you are wrong in your belief.

They needed something done in a timely manner, and you didn't have time to do it.

How can I say them that I didn't like it, not being rude?

You can just say it - I suspect it won't be "rude" but it may be confusing. If you want strings attached to your gift, you must make that clear up front. It doesn't sound as if you have done that so far.

If you want full control, I think you need to either license the code you wrote properly, and stop giving it away, or just sit down and have a talk with your manager, explaining your desire to maintain control over this code.

If you take the latter route, don't be surprised if your company decides not to use your code any longer. From a business point of view, many companies find that too restrictive and dangerous.

Improve this answer
13
  • 51
    thank you Joe, you're right. Maybe I should only stop being this childish and understand that a gift is a gift.
    – stats
    Sep 22, 2015 at 15:07
  • 3
    @JoeStrazzere: it's no more restrictive or dangerous than a binary, which plenty of companies use. But it would make it less atttractive. Otherwise spot on, so +1.
    – jmoreno
    Sep 22, 2015 at 15:11
  • 11
    @stats It's not being childish. But if you offer the code to a company, you should expect others to change it. If you are the only one that knows what the code is doing, and you are suddenly taken from this world (hope that doesn't happen), the company you have gifted the code to can't do much sense of your gift. Now, there's 2 routes (in case it happens): trash the code (rendering your gift useless) or someone else tries to learn it. If someone else is touching your gifted code, see is as a complement. Your code is really being useful. Now, spread knowledge on the code and be happy about it!
    – Ismael Miguel
    Sep 22, 2015 at 18:37
  • 3
    @jmoreno A good point to raise but keep in mind that such binaries will usually be production-ready and won't require any maintenance or recurring modifications, which doesn't seem to be the case for the OP's code.
    – Lilienthal ♦
    Sep 22, 2015 at 18:43
  • 2
    @zespri Check that this is OK before you do this. When you write a patch on the job, the changes you wrote belong to the company (even if you're patching onto a well-known open source project like Linux). Integrating them to your own personal project (which is public) without permission is potentially leaking proprietary company source code.
    – Brandin
    Sep 23, 2015 at 8:18
35

As long as they're modifying only their copy of the code, yes, you're being unreasonable. The point of (most) open source is that folks can maintain it themselves, and possibly contribute changes back to you for consideration in the next official release.

If you really want to, you can write a license which forbids modification... but then folks will be much less interested in it. You can write a license which forbids distributing modified versions; that helps maintain clarity about what is and isn't supported by requiring unofficial changes to be distributed as separate patch files. I recommend looking at the Creative Commons license, or those used by Apache and Eclipse if you want to be kinder to business users.

But the company already has a copy of your code, under whatever licensing you gave them at the time, and you can't change that retroactively.

Improve this answer
4
  • Thank you, but I don't want if possible to include law. Isn't it, in your opinion, a good idea to say to them something like "hey, please use my code but don't apply changes on it, at least since I'm in this company"? Is this so stupid?
    – stats
    Sep 22, 2015 at 14:57
  • 5
    @stats What happens if you quit the company, and then they they find a bug in your code? Do you want to forbid them from fixing it?
    – DJClayworth
    Sep 22, 2015 at 14:59
  • Nope I will not be in the company anymore, they can do everything they want at that time.
    – stats
    Sep 22, 2015 at 15:05
  • 17
    Yeah, it's unreasonable. If that was your intent, you should have made that clear from the beginning -- in which case they would have avoided using it. Businesses need supported code. If you can't provide support, or allow them to support it themselves, using it is a risk they can't afford to take. If you'd rather provide support and make the needed change yourself, and can promise to have it for them some time soon, I'm sure they'd rather take advantage of your expertise... but they really can't let themselves be held hostage to it.
    – keshlam
    Sep 22, 2015 at 16:01
25

If your code is in a public repository (github, bitbucket, etc) then you already have full control. Any changes your colleagues or others make to your source code will have to be in another branch and a pull request will have to be made to merge those changes with the master branch.

Feel free to put your open source code up on a public repository and send your colleague a link so they can branch their own version if you haven't already. This way you embrace the open-source workflow, declare ownership, and share all in one fell sweep.

Improve this answer
5
  • 4
    This is one of the best answers IMHO! It encourages collaborative tools like GitHub, which means that the OP can still control it - and other people can still contribute to it (which is, understandably, necessary sometimes when project schedules and workloads are taken into consideration). We all want to "do it ourselves" sometimes, but the GitHub PR model is really superior when it comes to "after-the-fact" review and control of contributions being made. +1
    – Per Lundberg
    Sep 22, 2015 at 20:03
  • 3
    This isn't always true. Even if the code is done outside the working hours it can still potentially belong to the customer they are working for. Some states don't allow this (IIRC California) but in the UK for example, the company can own that code. So posting it externally is not a good idea until you clarify your legal position.
    – Simon O'Doherty
    Sep 23, 2015 at 6:53
  • 3
    The tool is only part of the equation. You still need to give a license, as mentioned in JoeStrazzere's answer. For example, if your colleague forks your open source code and makes changes, then they are under no obligation to give the changes back to you. Your company could choose to keep the changes private. If you want to insist that changes to your code be released back to the public, then you have to state it as a condition of your license.
    – Brandin
    Sep 23, 2015 at 8:21
  • 1
    This doesn't give full control in the sense the OP asked. He can put his code in github but the company and colleague can just ignore it.
    – RedGrittyBrick
    Sep 23, 2015 at 11:22
  • Legalities aside, if you have ownership of the public repository you are faced with the same problems all open source projects have. You could have someone fork your work, the fork could become more popular than your own, people could choose to ignore your license, etc. It's up to you to maintain the project and keep it attractive.
    – TombMedia
    Sep 23, 2015 at 16:41
14

Based on the structure of your employment agreement, the company you work for may already own the code. Some employment documents claim all products related to your work, even if the product is developed off site, and after working hours.

If they go the route of claiming ownership, they could decide to restrict your ability to distribute the code elsewhere.

Even if they don't claim ownership, they can still decide to rip the code that doesn't meet their needs out of their systems.

Improve this answer
6
  • To avoid this, some people build their projects around code which has a strong license, like GPL. Then they can say the company couldn't 'own' the code even if the developer would be willing to give it to them.
    – Mario Trucco
    Sep 22, 2015 at 15:31
  • 2
    @Trucco: As the constraints are usually written, either the company owned it and has a seperate license to use it before you tried to put an infectious license on it, or you violated company policy by doing so unless you got approval first. Either way, this can be a career-limiting action; know what you're getting yourself into before you try it. And, again, he infectious nature of the GPL often means companies simply can't use anything under that license. Finally, since in this case the company already has an unrestricted license, changing it now doesn't help the OP.(
    – keshlam
    Sep 22, 2015 at 16:07
  • @keshlam - What do you mean "... infectious nature of the GPL ...".
    – Kevin Fegan
    Sep 23, 2015 at 3:24
  • 2
    The full GPL "copyleft" is enduring/reciprocal. Per the license, any works derived from copylefted code must be copylefted when distributed. The Wikipedia entry on GPL discusses this in the "Viral licensing" section. There are other Free Software Foundation licenses, such as Lesser GPL(LGPL), which are more acceptable; that's what makes using the gcc libraries in non-copyleft code acceptable even though gcc itself is copylefted. There are some other provisions for api use... but basically GPL is a can of worms most company's lawyers will tell them not to touch; LGPL may be acceptable.
    – keshlam
    Sep 23, 2015 at 4:05
  • 1
    Granted; they had to relax the output license after people pushed back against rms's idealism. Point remains: Not all open-source licenses are equivalent, some have terms that make them unsuitable (or merely uncomfortable) for business users, and when deciding which licence(s) to make your code available under you need to make an active decision about what is a d isn't essential to you. Good comparisons of the common licenses exist on the web; take the time to research. Law is an extremely buggy programming language; know the quirks.
    – keshlam
    Sep 23, 2015 at 12:40
14

You say

my code was a gift

and

Yesterday they needed a change in one of MY procedures

These sentences are contradictory. When you give a gift, it is no longer yours: it belongs to the recipient. Stop saying MY code. That's THEIR code now; you gave it away. If you give someone a car as a present, you don't get to then tell the recipient what colour they can paint YOUR car; it's THEIR car; you gave it to them.

You apparently want to both give a thing away and retain ownership of it. Since those are contradictory, this seems like a recipe for causing yourself mental distress. If you don't like the resulting distress then stop doing things that cause that distress. Either give up ownership when you do work for free, or stop doing work for free, or provide a license agreement that the company can sign that spells out who owns this artifact and what the rules are for it.

Improve this answer
1
  • UPDATE: Just to follow up on the middle para: I sold my lovely silver 2nd-generation MX5 Miata for a pittance to a friend a few years ago. It is now bright pink. I had no say in the matter.
    – Eric Lippert
    Dec 23, 2021 at 23:01
7

I appreciate what you are doing. I keep doing this as well. I will even go spending nights working on my code. And, I will share the tools and utilities with not only my office guys but with a whole bunch of community.

Well, in the policy of giving, you should not give halfheartedly.Just give it. But, in case you still want you keep your respect attached, make sure you develop a self template/copyright kind of header to your code which signifies your hard-work.

And, in case if any one needs to modify it, just ask them to add their name to the contributors in the header. Also, when they do the modifications, study it and see if you can come up with a better one.

I will also suggest you to let them study your code and if someone has a better solution, know it. Knowledge sharing is the best way to learn!!

Improve this answer
1

I think you are unreasonable about wanting to stay in control of code you considered something to take into the company for their use.

However, it is perfectly reasonable of you to either a) ask for permission to fold the modifications back into your own version, to be distributed as you consider fit. b) tell your managers that you are not going to consider the modified version your responsibility any more, so any upstream bugfixes you make to your own version in future will have to be integrated to their version by someone on the company clock

Both are valid options, and depending on how you feel about this issue and the code, you may also give management the choice between either. It's also an option that you tie your continued care for this code to being able to refactor or rewrite this stuff on the company clock when your schedule allows for it.

That way, there is a tangible long-term benefit to management letting you have your way with the code. Which makes it easier to negotiate. Because make no mistake: threatening to withdraw permission for using the code would be totally misplaced and may backfire heavily.

Improve this answer
0

I hope that you are on equal footing with your company, and that they are as willing to give gifts to you as you are to them. If this is the case, then it would only be reasonable for them to extend you the courtesy of permitting you to be the sole maintainer of your code even if it is just a personal preference for you.

Realistically, however, your company will not be willing to extend to any courtesy not required by law. Without a legally enforceable license (and probably even with one), they will feel that there is no reason to delay their own actions in order to show you some consideration. More likely is that you actually got off easy. The company could have pursued you with litigation for providing a piece of software for a given purpose which did not fulfill its purpose. The work being done by a coworker, and the expense the company incurs in tasking her with it, to modify the code could be seen as damages caused by you which you are liable for.

'Giving gifts' like this to companies is a bad idea for a host of reasons. It creates ethical problems for both sides. And at the end of the day, if you are on even footing with the company, the company would be more than willing to pay you for the software under a contract which protects both parties.

Improve this answer

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