The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It only takes a minute to sign up.
Sign up to join this community
I have been asked by my employer to integrate our software with a third party service. But as soon I started to work on it, I realize that there is no SDK to do the integration.
Question: Is it ok to build the SDK at home and open-source it and then use it at work to make the integration?
As a manager, this would be a non-starter if an engineer approached me with this idea. The conversation might go like this:
Me: How's that new project I assigned to you going?
Dev: I don't have all the code needed to complete the task.
Me: Well obviously, because if we had it, I would not have asked you to devise a solution and build it.
Dev: So I'm going to build my own framework at home during my spare time, then license it back to the company to integrate with.
Me: You mean, you're going to work from home as a salaried employee and then claim that you own some of the IP for the project you are on?
Dev: Hey, it's not that bad, I'm going to license it back to the company for free.
Me: And you're going to do what with this code you write at home?
Dev: Open source it and post it on GitHub.
Me: That's very noble Dev, but did you consider how that enables competitors to catch up to us faster or that it dilutes the IP of our company?
Maybe if there was already an existing open-source project we could fork, or if you had built this thing before coming on to this project, that would be one thing.
But you are basically saying your primary focus as a salaried employee will now be split between your side project and your real job.
And did you consider that you might be tainted with inside knowledge and insight of the 3rd party service that you learned about here?
Did you consider that you might be even be competing with this 3rd party company, who's our business partner, because they might be wanting or working on the same thing?
Also, their REST API may not be public and use of their service has its own licensing issues.
Did you consider that the SDK to the 3rd party service is something we might want to license as well?
Dev: Ummmm…
Me: Did you read your employee agreement regarding moonlighting and conflict of interest?
Dev: Ummmm…
Me: So what are you going to do during actual work hours in the office instead of building the components you need to complete the task?
Dev: I guess I'll mock out the code around a hypothetical SDK that doesn't exist yet. But that's the cool part, when I'm done with the open-source version, it would just plug-in.
Me: That's my point, you are building a software component, based on internal requirements. Your open source code would already be tainted.
Now, here's one thing you could suggest. That the company publishes the code you write as part of its open source strategy.
You could suggest that publishing the source code as open-source by the company, could be a strategic business move. It could be used to promotes the company, promote the product, or perhaps as a means to upsell something else. One common tactic: the published code is licensed on as GNU GPL for anyone that is willing to give away their integrated code. Everyone else pays a commercial license to use it.
I would suggest not doing this without discussing it with your manager/lead and taking approval for the same.
I have been asked by my employer to integrate our software with a third party service
Were you asked to write a separate component for this? Is there a timeline associated with the delivery that the company is choosing? Would you have been working on the SDK you are writing even if this project did not come your way? Are any of the third party services proprietary?
If the answer to any of the above is a no, it seems to me that you have a personal agenda (open sourcing a project) which is in direct conflict with the professional requirements (on time no risk delivery).
Is it ok to build the SDK at home and open-source it and then use it at work
Individually, all three of these steps look fine, however, it is when you use them in conjunction when the conflict begins. Since this SDK does not already exist - the company and project is at risk when using a (not so stable) (newly released) open source project written by its own employee.
Also, why should the individual take the glory when the company may want it? (In case the company wants to open source the project itself, it would make sense for it to do it)
Thus IMO, you should collaborate with your supervisor on how to modularize the project so that open sourcing the SDK is a simple ask later on. If you get a go ahead early on to write the component and open source it yourself, only then do so.
I had been in a similar situation; my main concern was actually that if I am using my open source (or personal) libraries and I use these at work, I would actually debug them. Let's say somethings doesn't work, you debug it in the office, and actually find out that it is a bug in your SDK/Library/Framework - should you fix the bug and re-submit it to yourself, should you wait in until you are at home?
Clearly there are constellations (consulting) where all of this is slightly less problematic, but I really don't like that IP which i worked on during office time "pollutes" my private projects.
You should discuss your plan with your manager. Regardless of the legality or ethical issues of your question, you should make your manager aware of the full scope of work needed to complete the effort and your plan to accomplish it.
Additionally, the relevance of the software to your work is sufficient to give your employer a legitimate interest in your efforts. Your employer either needs to give you permission to release the software source or to release the firm's claim on the SDK.
Your manager is likely to be fine with your plan of developing part of the tool as OSS from home and the proprietary piece at work. Even better, your manager may even give you time to develop the open-source SDK at work given it is necessary to complete your work.
Without An Agreement, That’s A Hard No
It is not OK without an agreement from your company (NOT just your manager). You have almost certainly signed an IP agreement that says everything you develop while employed at your company is their intellectual property, especially things directly related to its legitimate interests, as this would be. And even if you haven’t signed something like that, that’s supported by the law (in the US it is covered by the work for hire doctrine, in Brazil it is similar) so that’s the way the cookie is likely to crumble. At a bare minimum, if this was done secretly by you and you showed up and said “done! And I used this open source SDK” and I realized you had written the SDK and open sourced it on the job without disclosing it, I would fire you immediately for cause and then let the IP lawyers onto you.
Ask And Maybe You Shall Recieve
However, some organizations will be open to this, either you open sourcing it yourself (if it represents extreme additional off the clock effort) or it being open sourced through the company (like most open source that flows from the big tech companies). In either case you need to talk with your manager but you need more than “their approval.” In the former case your IP/moonlighting agreement should have a schedule of exceptions; you would work with HR to add an exception for the SDK and various people would need to sign off on it. In the second case, if they don’t already have an open source program it can be scary but if you research/talk to a friend whose company has open sourced something and get them some jump-start guidance, they could be motivated to do it by the prestige in the technical community.
There is a potential ethical problem any time you represent two different participants in the same transaction.
In this case, you would be involved in software selection, IP, and licensing arrangements both representing your own interests as an open source developer, and your employer's interests as a possible user of the software.
I suggest writing up the problem and possible solutions, including but not limited to your current idea, with costs and benefits. You should include developing the software on the job, with it fully owned by your employer. Give that to your manager, and ask for their decision. If they decide to go with your idea, you would represent only yourself in licensing discussions, and your manager would represent your employer.
Company X hired you to do some development work for them: they give you money, you give them the code. Money now belongs to you, code belongs to them .
Now, they want from you to connect their software with 3rd party services. You offered to build full SDK, they say they do not have time (and money) for that, and they expect from you to build only basic capability. From business perspective this is often the case - "quick and dirty" solution that works today is much better then neat and polished code after two months.
What you are proposing is to use your own time (time you didn't sell to company) to develop this SDK . From your economic perspective this is foolish (you are basically doing unpaid work), but ok, everyone has some favorite pastime or hobby. But from perspective of your employer there is another problem: what are you going to do at work ? Are you going to spend your working hours developing that SDK ? If yes, this code legally belongs to your employer, and you are not allowed to publish it under open-source license. If not, would you develop basic solution as ordered, and would parts of that basic solution become parts of SDK ?
From legal perspective, only thing you could do is to use completely different code in your basic solution at work, and your open-source SDK at home, which in this case could be impossible because after all you are using same third party service (and you are still same person). I'm not telling you to stop developing SDK , but mentioning it to the employer could have serious negative repercussions, and very unlikely positive response because you are already developing basic solution required by employer. Therefore, if you already firmly decided to create SDK, my advice is do not mention it at work.
