Ask HN: Using a side project at my day job
29 comments
One thing to consider: if the capabilities of your side project would be useful to $dayjob, a sufficiently aggressive company lawyer would be likely to argue that that makes it "related to our business". (And most of the lawyers I've met would be at least that aggressive, if the company was their client.) If you wind up using that code on the job, the case becomes even more clear cut.
So, if you want to keep releasing this code on the side, having something from them explicitly disclaiming (i.e., renouncing) exclusive rights would be very good to have. You've gotten some suggestions about things to look at. There are also open-source projects whose contributor paperwork includes standard employer disclaimers. As to which of these (if any) best fits your situation, you'd probably be best consulting a lawyer of your own.
So, if you want to keep releasing this code on the side, having something from them explicitly disclaiming (i.e., renouncing) exclusive rights would be very good to have. You've gotten some suggestions about things to look at. There are also open-source projects whose contributor paperwork includes standard employer disclaimers. As to which of these (if any) best fits your situation, you'd probably be best consulting a lawyer of your own.
License it to them. Have a legal contract drawn up that says they are licensing it from you for a fee. The fee can be nominal, $1 even. But that is the most formal way to protect your IP.
I'm going to expand a bit on this. I am not a lawyer, but I see 2 possible scenarios:
1) You want to retain sole the rights to the IP and possibly license it for money to others some day. In this event, you should license it to your employer for a fee. However, this presents quite a tricky proposition of how you allocate time to spend on the tool vs time on your other work. If there is work to be done on the tool, you'd have to completely separate that from normal working hours, which may be impractical once the company is relying on said tool. The best way I can see to do that would be switching from employee to some kind of contractor role, where you could allocate time spent separately. As you can see this gets complicated.
2) You just don't want to give up the ownership completely to your company, but have no interest in ever charging for the tool. In that case, I'd suggest releasing it under an open source license prior to using it in your work. There are a variety of open source licenses available, and I feel like the pros and cons of each are well-worn territory already which can be examined with a simple Google search.
It seems like open source might be the way to go from your description above. In any case, you definitely need some kind of legal license in place, be it paid or open source.
1) You want to retain sole the rights to the IP and possibly license it for money to others some day. In this event, you should license it to your employer for a fee. However, this presents quite a tricky proposition of how you allocate time to spend on the tool vs time on your other work. If there is work to be done on the tool, you'd have to completely separate that from normal working hours, which may be impractical once the company is relying on said tool. The best way I can see to do that would be switching from employee to some kind of contractor role, where you could allocate time spent separately. As you can see this gets complicated.
2) You just don't want to give up the ownership completely to your company, but have no interest in ever charging for the tool. In that case, I'd suggest releasing it under an open source license prior to using it in your work. There are a variety of open source licenses available, and I feel like the pros and cons of each are well-worn territory already which can be examined with a simple Google search.
It seems like open source might be the way to go from your description above. In any case, you definitely need some kind of legal license in place, be it paid or open source.
Great points.
I would add to #1 that since the tool is clearly related to the line of business of the company, even working on it outside the work hours may not be enough to keep it isolated.
So if some agreement is worked out with the employer on use of this tool, the same agreement may further include provisions for keeping it isolated.
For #2. Not sure how this would help, but it is also possible to release the source of the tool while still retaining full rights to it (i.e., release without a FOSS license). This can prevent the third parties from using the tool, and "may" provide some protection from the employer as evidence of what was developed before using it for work.
Note: IANAL.
I would add to #1 that since the tool is clearly related to the line of business of the company, even working on it outside the work hours may not be enough to keep it isolated.
So if some agreement is worked out with the employer on use of this tool, the same agreement may further include provisions for keeping it isolated.
For #2. Not sure how this would help, but it is also possible to release the source of the tool while still retaining full rights to it (i.e., release without a FOSS license). This can prevent the third parties from using the tool, and "may" provide some protection from the employer as evidence of what was developed before using it for work.
Note: IANAL.
#2 is mostly in case you want to make sure the tool is released to the general public and not just absorbed by the employer into their own IP.
This is great advice. If the op hasn't done contracts before the Nolo press series is a great place to start. Contracts are a lot like programming with English(or insert native tongue here) and a lot less scary than people make them out to be. Hire a lawyer to review it before hand and know that contracts are a negotiation.
As an aside, the mobile interface for this site makes it damn near impossible to make sure you are voting correctly. Sorry about the mistaken downvote.
As an aside, the mobile interface for this site makes it damn near impossible to make sure you are voting correctly. Sorry about the mistaken downvote.
No its rather poor advice IP and labour law law is complex and Nolo themselves that they only deal with simple matters.
Agreed. Nolo books are very basic.
The following is much better and does talk about many corner cases. It also is written specifically for the software-development case.
http://www.amazon.com/Intellectual-Property-Open-Source-Prot...
The book is written by software developers turned lawyers, and provided me with some fresh perspectives on the nature of the law itself.
The following is much better and does talk about many corner cases. It also is written specifically for the software-development case.
http://www.amazon.com/Intellectual-Property-Open-Source-Prot...
The book is written by software developers turned lawyers, and provided me with some fresh perspectives on the nature of the law itself.
You have very specific legal questions. You absolutely 100% need to talk to a lawyer.
I'd worry that your side project is indeed free of work IP. If you have been working on something that ties directly into your work project, but on your own time, your workplace has a pretty strong claim to at least make you not distribute it.
But if it is indeed completely stand alone, and you would be comfortable publishing it open source regardless, do that, then convince the team to use your project. This happened at a previous job with no problems.
But if it is indeed completely stand alone, and you would be comfortable publishing it open source regardless, do that, then convince the team to use your project. This happened at a previous job with no problems.
It doesn't really tie directly into it, besides insofar as the company I work for builds a web application and this thing would be directly useable by a web application. Think of something like analytics services - they're useful to a wide variety of companies but not to any one specifically unless they're involved in analytics.
Put it this way - my company would be a great client for this tool, but would never want to sell it themselves.
Put it this way - my company would be a great client for this tool, but would never want to sell it themselves.
Very dangerous if your side project is related to your job (which it appears to be) your in danger of losing any IP.
Check your contract and applicable state law you may already have lost your IP - lets hope your employer will act in good faith.
I would make sure as part of negotiations that your employer pays for an independent lawyer to write up a new contract and to make sure that you license your IP to your employer and maintain your rights.
Check your contract and applicable state law you may already have lost your IP - lets hope your employer will act in good faith.
I would make sure as part of negotiations that your employer pays for an independent lawyer to write up a new contract and to make sure that you license your IP to your employer and maintain your rights.
At the end of the day, it's all about the trust between you and your employer. Unless you know the people well, I won't be mixing code this way - with or without a written permission. Just too much hassle. Even if your direct manager approves it, the legal team etc. might have a different view.
Related question: If I choose not to license / sell / whatever this code to my company, they're going to build it anyway. We're a small team and I'm in a fairly senior position - it would be impossible for me not to be involved in those discussions. Does that create legal issues if I continue to hold onto my side project (and potentially develop it further?)
It would most likely create legal issues [1]. Start by reading the employment agreement contract you signed with them when joining. More likely than not, and depending on where you are located, you already have an issue now since your side project is related to the employers line of business.
If the side project is of significant value to you, I would recommend pulling out your employment agreement, reading it yourself [2], and consulting a lawyer.
I think a win-win situation here would be for you to license the project to the company, where the license terms specifically limits their rights to what they need to solve their current problem at hand, and allows you to continue working on it. This can also save them time and effort.
[1] Note: IANAL, though am generally very aware of IP issues. Have read two books on the subject.
[2] These agreements are notable for using very long sentences, but are always very well crafted to be precise. You should not have an issue interpreting them right if you are a good software developer. They also use some specific terms though that you may need to learn. Wikipedia does a good job of explaining all of these. A term "related to the business" is amongst ones that are relatively undefined, i.e., it remains unclear from the agreements what is related and what is not [3].
[3] The term may be used in a much broader way than you think. Everything computers and electronics may be considered related as it all falls under the same trademark code. Yet, related may be used to imply only that that competes with the business.
If the side project is of significant value to you, I would recommend pulling out your employment agreement, reading it yourself [2], and consulting a lawyer.
I think a win-win situation here would be for you to license the project to the company, where the license terms specifically limits their rights to what they need to solve their current problem at hand, and allows you to continue working on it. This can also save them time and effort.
[1] Note: IANAL, though am generally very aware of IP issues. Have read two books on the subject.
[2] These agreements are notable for using very long sentences, but are always very well crafted to be precise. You should not have an issue interpreting them right if you are a good software developer. They also use some specific terms though that you may need to learn. Wikipedia does a good job of explaining all of these. A term "related to the business" is amongst ones that are relatively undefined, i.e., it remains unclear from the agreements what is related and what is not [3].
[3] The term may be used in a much broader way than you think. Everything computers and electronics may be considered related as it all falls under the same trademark code. Yet, related may be used to imply only that that competes with the business.
Best answer is - consult a lawyer! ;)
You need to take your employment contract to a lawyer and get legal advice before doing anything. Depending on the contract, you may or may not have rights to what you developed in your side project, especially if you are a salaried employee. In my case, my employer owns all IP I develop while in their employment. Happily, my employer has no commercial interest in the code I develop to automate my data analysis and management permits me to distribute it under an Open Source license. They understand the value both they and I receive from a collaborative community of analysts. By the way, each year I must sign a statement that I have no conflicts of interest and if I suspect I might have one, I must disclose it to management.
I was in a similar situation at a previous company - they knew of my side project, and wanted to use some of the concepts of it in the work I was doing. As karterk mentioned, it really came down to trust - I explained that I would not be signing over rights to my software and that I would continue selling it on the side, without the modifications being made to it for them. They were fine with this and it never became an issue. I don't think a simple handshake would be sufficient in most cases, but I was trusting enough of my manager (I was there for over 4 years) and went that route. If you are truly concerned about the IP, then you should get both your manager, but also legal to approve it in writing.
Do this but definitely get it in writing because managers are not forever aand do not have the final say.
Note that some employment contracts already say that if you use any of your own IP at work, then the employer gets full rights to that IP including ability to use it in any way they want, sell it, or sub-license it.
Trust does go a long way though.
Trust does go a long way though.
IANAL so take the following advice with a pinch of salt: get a lawyer.
Another alternative: if your company can work with GPL or other viral licenses, you could GPL your software and let them work off that. Then you still retain full rights to the code.
Another alternative: if your company can work with GPL or other viral licenses, you could GPL your software and let them work off that. Then you still retain full rights to the code.
I'm not a lawyer and the advice listed below is just my common sense, I would advise you to consult with a lawyer regarding your question.
By the way you mention having an employment that is relatively lenient which is good.
As an employer I would still advise you to either include an appendix or send an email to your legal department listing your side projects, open source projects you contribute to and/or anything else you think should be included there. It is probably being over cautious on your side but remember than employment is like a marriage; everything is fine and nice when they get you to sign on that contract but you never know what will happen when you leave your job to seek your next opportunity.
Additionally if you are in the US, you probably signed on some sort of PIIA (ROPRIETARY INFORMATION AND INVENTIONS AGREEMENT) which will assign anything that you've developed or invented back to the company, some will make it lax and some will be stricter, I would guess most employers will be stricter in order to avoid any potential IP problem in the future.
However if you are in California, know your rights. There's the California Labor Code Section 2870 which states the following:
(a) Any provision in an employment agreement which provides that an
employee shall assign, or offer to assign, any of his or her rights
in an invention to his or her employer shall not apply to an invention
that the employee developed entirely on his
or her own time without using the employer’s equipment, supplies, facilities,
or trade secret information except for those inventions that either:
(1) Relate at the time of conception or reduction to practice of the
invention to the employer’s business, or actual or demonstrably anticipated
research or development of the employer; or
(2) Result from any work performed by the employee for his
employer.
(b) To the extent a provision in an employment agreement purports to require
an employee to assign an invention otherwise excluded from being required to be
assigned under subdivisionOn the California Labor Code:
Note that this specifically mentions "inventions". Inventions are clearly distinct from copyrights, to which software is subject to. It is unclear if the labor code was intending to mean all forms of IP including copyrights.
Also, in this case now, the side project is clearly related to the employers line of business.
Note: IANAL
Note that this specifically mentions "inventions". Inventions are clearly distinct from copyrights, to which software is subject to. It is unclear if the labor code was intending to mean all forms of IP including copyrights.
Also, in this case now, the side project is clearly related to the employers line of business.
Note: IANAL
Prior to starting work, there should have been a document signed whereby you listed all pre-existing IP. Mingling this code with the employer's app does indeed make it theirs, but not exclusively theirs.
If possible avoid any cut-n-paste mingling, incorporate your IP as a separate re-write, and maintain a github history of your own IP for future reference to prove ownership.
If possible avoid any cut-n-paste mingling, incorporate your IP as a separate re-write, and maintain a github history of your own IP for future reference to prove ownership.
Make sure to double-check your contract with the company to make sure there is no clause stating that any work created (in the office or not) belongs to them; if so, double-check to ensure your project was listed as prior art.
If the contract has something along these lines, you're in a tough position.
If the contract has something along these lines, you're in a tough position.
The simple solution can be the permissive license. You may give him the code on the bases of MIT or Apache license.
another good option can be give him code and have signed the work done in office as WTFPL license(you will have all rights on the code).
Perhaps an option, if it's not something you're planning on selling, would be to open-source it, and then let the employer use it like any other user.
I'm not interested in charging anyone for anything, but I would like to retain the IP rights to my software. My employment contract is relatively lenient in this regard - anything done on my own time, with my own equipment, unrelated to our business I still have rights to.
Some questions I have:
1. What do I need to watch out for from an IP perspective? If using this means that I spend some work time working on it, would getting something in writing acknowledging that this is my IP be enough?
2. Has anyone done anything like this in the past? How was it receieved by your employer? I don't want to give the impression that I'm planning on quitting and pursuing this anytime soon, and being labeled as a flight risk, but on the other hand I don't want to throw away the rights to something I've spent a lot of time on.