|
harold aptroot wrote:
Ok, but then surely the problem is that you stole
IP from the company, and not that you dared to be so bold as to write code in
your free time?
Could be but they are going to claiming that you stole code and IP. After all the fact that the code is not in the work code base doesn't mean that you didn't write it during a time period when you should have been writing code from them.
And fair or not it is a matter of tracking what time was spent where and what ideas were used where. Unless someone keeps extensively detailed records then the subjective nature of the determination can be very detrimental in a number of ways to the individual.
|
|
|
|
|
Oh well I guess you're right. I'll make sure to read my contracts with that in mind.
|
|
|
|
|
I haven't signed an agreement like that. Obviously, what is created during work hours is theirs. However, if I have a business on the side of writing an IOS app that has nothing to do with my employer I doubt there would be any court that would try to argue that it belongs to the company I worked for. With, or without, a signed agreement.
Joel Palmer
Data Integration Engineer
|
|
|
|
|
Your employer would probably not bother, so long as your iOS app isn't minting money. Let it be known that it does, and then they _could_ argue that it belongs to them. My opinion is that anything can be made to stand in court so long as you have a "good enough" lawyer  , especially if there is a signed contract.
Happiness will never come to those who fail to appreciate what they already have. -Anon
|
|
|
|
|
ChandraRam wrote: I also know of company rules that say anything developed during your employment with them, whether or not during office hours, belongs to the company.
I worked for a large well-known software company for 20 years that had such a policy, though they did have a process by which you could get permission to do personal projects that were not on company time or resources if the project was not related to the company's business and didn't cause a conflict of interest. I went through the process once - IMHO it was more painful than it need to be, so then so are most things that involve lawyers.
|
|
|
|
|
Using personal code in company code can be a legal minefield. There are many things that have to be taken into consideration and you really need to run this by the legal team.
1. If there is a problem with the code, where does liability lie? Does it lie with the company or with you?
2. What license agreement do you have in place on your code? If your code is GPL3 (for instance), and your company gives your code to the client, then they should be bound by GPL 3 as well if they included this code in one of their applications.
3. What does the contract between your client and your company say?
|
|
|
|
|
This is the first entry that gave me some logic. Thank you. You've helped correct my thinking.
Mainly, #1. If I claim the code as my own then I could be liable. By working for a company that takes on that liability, it protects me from litigation. So, I don't want to claim the code as my own.
I've always had the thought that code is in a legal grey area because it is the product of my knowledge but it is not the end-product. The end-product is the .dll or the .exe that is compiled in the end and the company owns the end product. They definately don't own my knowledge and code is somewhere in between.
Of course I know that the stuff I write on company time is definately theirs. But, as I said in the original post, these libraries have been developed over my entire career. I may even have some that I made in school that proved to be useful (a long, long time ago).
So, these libraries are my bag of tricks. The company I work for at the time gets my bag of tricks when I incorporate them into the solutions I produce. At that point, the code is theirs.
#2 - I work for a small company that hasn't bothered making me sign anything.
#3 - I'm not privy to that.
Joel Palmer
Data Integration Engineer
|
|
|
|
|
Joel Palmer wrote: My boss was okay with giving them the code because we were paid dearly for the project. However, like most of the developers I know, I have a set of "helper" libraries that I have developed over the years. Many of them were started prior to this employer and I'll take copies of them with me when I go on to my next employer. They will continue to evolve over my career.
So, when we sold the code, I insisted that only the compiled .dlls of the helper files be given to them. They can have their soltion specific code but not my libraries. My boss was understanding and we moved forward.
Great! However, what happens when you leave the current company and the client asks your old company to upgrade the code? Will you be leaving your helper code with your currently-on-good-terms-with boss so he can have your replacement continue to build on what you did? If so, then he may be able to "sell" them later and you may continue to build upon "your" code. This would obviously be forking the code. If on the other hand you're not leaving him "your" code and the code is needed to continue to build their project, then you're probably at fault since your company was probably under assumption that your work (helper code included) can continue without you. Like you said, it is a gray area. However, when you leave, you might get a call a few weeks later and, in which case, you'll either have to send them (your company) the code or burn bridges.
|
|
|
|
|
I am pretty sure he implied the source stays with his current employer if he leaves, I know one of my libraies started life as a VB5 calls in the mid 90s, it has been rewritten many times and is currently in c# servicing Silverlight apps. At least 12 organisations that I know of have had copies of the source in one form or another and all of them have the source.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: I am pretty sure he implied the source stays with his current employer if he leaves,
To me it implied he kept his code everywhere he went and only left DLLs and EXEs behind. Otherwise, every employer of his would have a copy of his code up to the day he left and he would be building on his copy at every new company, similar to your 12 organizations' copies. In this case, the point is moot since his employer could always share his code once he leaves.
|
|
|
|
|
I always find this puzzling as it points to a different mind set, I can only work x number of hours in a day and I NEVER intend to sell software ever again so I'm happy for other to benefit from my code if they choose.
Others wish to "own" their code and see no benefit in sharing with others, I created this it's mine you hear all mine, you can use the DLL but the source is all mine. I don't consider this greedy or negative, just different to me.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
If I use my own libraries in the solutions I provide to my employer then at that point I believe I give up all rights to them. At that point, I've made a program that will not run unless those libraries are there. So, by including them with the solution I've given up any rights to them.
I'm now more convinced of this than ever because of a comment made above about liability. The company I work for takes on the risk and liability if my program goes terribly wrong for a customer. In that case, I don't want my name anywhere near the code... especially if they accuse us of doing something malicious.
Because the company takes on the liability they have the entire code base.
Joel Palmer
Data Integration Engineer
|
|
|
|
|
That is usually the safe approach for an individual.
For third-party code (commercial businesses), they usually put some disclosure on the top of each file to the effect of "not being liable if something fails due to the use of their code" and "others not being able to resell the code for the purpose of selling the code, but being able to modify it for their own customizations without selling the modified code as stand-alone code".
You can always add something similar to yours when you give it up. Or you can just let them keep it if you're not actually making money independantly from them (royalties).
|
|
|
|
|
Like so many others, you seem to be closing the gate after the horse has bolted, or whatever the saying is.
If you write code for an employer, then that code is owned by the employer.
If you already had some code and you used that in your employer's code base then, essentially, you wrote that code for your employer. You just did it VERY fast.
What you needed to do, if you didn't intend giving the rights to your employer, is make an agreement before you used your source code.
If you left your job tomorrow, would you delete the source of the code you had used from your library? If not, then what difference does it make? If so, then what is your current employer meant to do if they need to make a change?
I have had many an agreement to sign saying all the source code I develop while employer will belong to the company; I always make a change so that it defines the exact terms (e.g. code developed for their applications, during working hours.
Only ever had one company argue the point, as they were concerned I could duplicate their processes in my own software and so compete - so we worded it appropriately that I wouldn't work on any competitive product.
Frankly I have many many routines I use and have used in different jobs that make my life easier - and I have also learned from other devs code that they might have brought in from elsewhere.
I'm not making money directly from selling my code, so I'm more than happy to let people have it - in fact it gives me a buzz when I find that companies I have never worked for are using my code!
MVVM # - I did it My Way
___________________________________________
Man, you're a god. - walterhevedeich 26/05/2011
.\\axxx
(That's an 'M')
|
|
|
|
|
I solved this problem years ago by first granting full source rights to my employers (or those with whom I was contracting.) I got tired of this about ten years ago and just made all my bag-o-tricks libraries open source with a license very similar to ZLib. I put this on every non-disclosure and am very careful about what code is marked with the notice. I also make sure that I never mix company IP with these libraries.
Technically, you own the copyright, but you also likely modified your own libraries on your employer's dime and made it entangled. Moreover, if you didn't notify your employer that your software was covered by copyright, that would be highly deceptive, if not downright dishonest. To make it more complicated, since you likely wrote some of that code while in the employ of others, they could make an assertion that you stole their intellectual property, as could your current boss. (Even if all you did was improve your code on the side, you are still operating within the bounds of your employment duties.)
|
|
|
|
|
I hope you've obfuscated the DLL before giving it otherwise its a gone-with-the-gorilla case.
I too have a Data Mapping DLL that simplifies all of the database activity. I first learnt idea
from my college roommate but he was unable to complete it. I completed it at first job and
actually demonstrated that lib at an interview to get the job. Initially it was in C. then in
Borland C++, then MFC and lastly it is now in C#.
Only Problem is that it is good productivity tool but it cannot be sold as tool especially to
the company you are working for.
|
|
|
|
|
For "my stuff" that falls in this category, I treat it as share-able code (ie, open source). Of course, this differs from your approach but I do "take it with me" and I don't think there can be an issue because I keep a notice at the top of each source. Eg:
// The contents of this file are subject to the Mozilla Public License Version 1.1 (the "License") .....
I also make sure that when I tweak it, I do so on my machine[s].
However, IANAL ...
|
|
|
|
|
Joel,
Unless there's specific law, this is a grey area. Ownership of the code ought to depend on the contract under which it is written. If you wrote it in your own time or under a contract where you retained IP (there are such contracts!) and can prove it then the "gorilla" comapny can't claim ownership; although they might be able to sue your employer if an attempt was made to charge them a licence (and your employer might be able to sue you!).
I advocate 2 things: Agree with your employer that you can use open source/ free licence code, including code that you yourself have written previously; comment your code to indicate that you wrote it and when and the licence terms under which you are prepared to share it (e.g. "freely use and alter" "not fit for any purpose", "hold free from damages", "retention of these comments"). You might refer to the GNU licence if that's appropriate.
Under any jurisdiction that I know, that would protect your future and ongoing use and prevent anyone suing you if there's a bug!
In practice, it's unlikely that you would ever get in to hot water over commonly used utilities that would look almost identical if you were to write them again from scratch!
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
|
|
|
|
|
Joel Palmer wrote: do I have any legal standing over the ownership of this code?
No.
Long answer: It will be difficult, specially if you didn't signed anything saying that the code was yours or theirs, otherwise your contract should clearly specify this.
|
|
|
|
|
Joel Palmer wrote: When is the code I write mine?
Depending on the laws that cover your jurisdiction, the code you wrote is yours when you write it entirely at your own expense, on your own equipment, and on your own time, and sometimes not even then. Once yours, it remains yours as long as you do the correct things to retain that ownership. Giving copies of the source to an employer without a written agreement isn't generally one of those things that helps you retain ownership.
Whatever you do, don't make a stink about it. Nothing good will come of it, and the big customer may even decide to bail from the project, and from your company altogether, if there's the slightest hint of legal issues with the code.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Joel Palmer wrote: However, like most of the developers I know, I have a set of "helper" libraries
that I have developed over the years. Many of them were started prior to this
employer and I'll take copies of them with me when I go on to my next employer.
They will continue to evolve over my career.
Not like most of developers I know - there are red flags all over that statement.
Code that you create belongs to someone. Either you or the company. If you are an employee UNLESS you have a specific contract then ALL of the code that you write for the company, even out of the office (related to their product), belongs to them. There can be restrictions on the out of the office part but in general even if you want to do something for fun completely different than the business of the company you should not agree to be employed until you have a contract that states you can work on such outside projects.
If you are a contractor and unless your contract states it, then ALL of the code that your write belongs to you. However MOST of the time the contract will give ownership to the company.
If it belongs to the company you cannot take it. You cannot use it. It cannot be used by another company. You have no control nor say in how it is used.
If it belongs to you and you switch companies with an existing code base then you MUST have contract that stipulates ownership before using it at the new company. Although not essential it prevents potential legal problems from arising.
And none of the above is by convention. It is by law. You can be sued for violating the above. In some case you can be criminally prosecuted. And the companies involved can be sued as well. And any such legal proceedings is not going to help in the future.
|
|
|
|
|
Clearly written. What is hard is that I don't know anyone's background and if they are throwing around what they have heard or if it is something that they have studied and read for themselves.
Assuming you are representing the later, now I'm curious how this compares to other professions. So, let me play with this for a moment with a few more hypotheticals. ...and keep in mind, I generally agree that what you state is true, but I'm exploring. Just because someing IS doesn't mean that it SHOULD BE.
If I were a journalist working for the New York Times and I wrote a book on the side, does that book, by default, belong to the NYT? Do they have similar contracts that says everything you write is ours unless stated in this contract?
Also, if I were a musician and I wrote a song while employed by Sony, by default would I also have no rights unless I had a contract that specifically stated it?
It seems like this could be comparable scenarios (he said naively).
What I'm driving at is the words "by default". Do the laws by default protect the corporation or do they protect the individual? Or, is there some "employee bill of rights" that actually does protect the individual and would apply to those who CREATE for a living? Or, is this just about working for the MAN?
Joel Palmer
Data Integration Engineer
|
|
|
|
|
Joel Palmer wrote: If I were a journalist working for the New York Times and I wrote a book on the
side, does that book, by default, belong to the NYT? Do they have similar
contracts that says everything you write is ours unless stated in this contract?
Never worked for them so I don't know.
Joel Palmer wrote: Also, if I were a musician and I wrote a song while employed by Sony, by default
would I also have no rights unless I had a contract that specifically stated it?
That is an inexact analogy. All employees that have a musical relationship with Sony have some sort of contract stating specifics. If you are contract star then it is very likely that Sony does in fact own everything that you write. If you are a studio musician then it is likely they do not. And if you are a bookkeeper you do not. However the later two presume you do it on your own and the work is not derivative of anything you might have been exposed to while on the job.
Joel Palmer wrote: What I'm driving at is the words "by default".
Start with the following and research it further as you will...
http://en.wikipedia.org/wiki/Work_for_hire[^]
|
|
|
|
|
Here is Bing's next strategy.[^]
I want Bing to win the search engine wars - or at least put in a respectable showing. However, they seem to be taking this thing in the wrong direction. When I look at the proposed new Bing what I see a complex mess. Hey, I'm just looking for a piece of example SQL code - I don't want to be presented with a really busy screen full of tons of interactive features.
I don't know why Microsoft insists on doing this when so many other companies make huge profits off keeping things as absolutely simple as possible. Compare the DrudgeReport with CNN.com - the reason I use the DrudgeReport is because I don't want my browser locking up because of crap flying around all over the screen.
Is the art of the simple, functional, informative web page dead?
I really think the best way for Bing to make in-roads is to become simpler than Google and then remain that way for a couple of decades.
I hear people complaining about this sort of thing in the trenches all of the time. They are getting tired of things flying around the screen, stuff crammed into every little corner, the lag, the learning curve, the busy menus - just stop already.
|
|
|
|
|
I refer the learned gentleman to my recent comment[^] on this kind of thing.
It looks nice and flashy on a tablet, but is actually completely bleeding useless to most users.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
