Surely one of the most common reasons for creating a piece of open source software is … ’cause you need it at work.
I’ve never been very comfortable with that — when I’ve had to fix/patch OpenSource software for work, I’ve tended to just sort of do it and hand it back.
But what is the relationship between an employer-user and an employee-vendor when the software is Open Source. The company is paying you to write software which is copyright by the company.
I’m thinking about using DBA within BE. I’ll have to do some work before it’s properly ready for that. But that’s OK. Gives me a goal.
PlayNet have OKed that, but I’d like to go into Jim’s office with a piece of paper bearing my scrawl that says “Hey, I’m not going to embrace & destroy; I’m not going to put bits of BE into my project and then post them on the intratubes; and I’m not going to see a chance to make money out of it and change the licensing on you…”
Any of you ever used any kind of boiler-plate “I’d like to share this bit of code so that from time to time someone else can fix my shit?” – erm – I mean open-source-under-employ-contract license?
kfsone's pittance 
3 Comments
I open-sourced my code written as an employee of the University of California. It turns out that under UC policy, the employee (with a few exceptions) has copyright to software written, so they just said: it’s yours, do what you want with it. That’s clearly different from your scenario.
In the case of you using it in BE, what would the potential issues be? Worst case scenario: open-source project dies but since their in-house programmer has intimate knowledge of how it works, Playnet just continues supporting it as if it were their own. With a suitable license there would be no difference from code that was actually owned by Playnet. And if you change the licensing, they can continue using the old version under the old license (and presumably order you to work on it, too… ;-)
I do develop some Open Source code inside my company and also have experience as community manager of a OS forge, but in any case, the first advice is that if you want to be sure, you should check with a lawyer :).
Having said that, usually, except in cases like Lutorm mentions, the copyright owner is the company, not you, so they have all the rights to the software and they can change the license as they see fit, so there’s no danger for them except for other people to see the source code, if that is a problem.
Apart of that, the usual problem is to choose the appropriate license for your purposes and what you want other people to be able to do or not. If you want to use the same software inside BE in the servers, it does not matter the license you use as you are distributing the software so OS clauses do not apply. If you used it in the client, the distribution thing applies but as copyright owner of the software, you can use the software under a different license and all is good for you. The problem would be in that case the contributions, as unless the contributor gives you the rights, you cannot re-license their piece (we are talking about something “major” like a plugin, not a fix/patch) so you wouldn’t be able to use it in the BE client with a different license. That’s why some “enterprise” open source projects make contributors go through the pain of sending a “copyright will be yours” signed letter before they can contribute. Usually when there is a dual licensing model (OS/comercial).
All in all, it depends on what you want to do.
Some advice from experience would be to do it, at least inicially, “for the ride”, as the possibility of someone contributing back is slim, unless you hit a sweetspot and you can find a bunch of developers with the same interests. Most projects, if used, just get user support emails, moderately successful ones get bug reports and just a few ones get fixes “out of the blue” from non-core members.
It is good also to mention that doing it “right” is quite a bit of work, as preparing a project to be built by “anybody” from source, taking care of licesing details, documenting it so people can get started, keeping it updated is easier said than done. In any case, it’s quite an experience :).
A good side of it is that many tool vendors (wikis, issue trackers, profilers, IDEs..) these days will offer you a free license to work with their tool in your OS project, and just for that purpose, which allows you to evaluate tools extensively and then decide if you want them or not with experience on your side. At least one of the platforms that I work with.
Good luck with it.
I should clarify: Playnet have OK’ed me to include the code; I’m not really expecting anyone to use it (until I start adding asynchronous features to it, at which point it might elicit some interest).
But I want to give Playnet something in return so that they/the investors aren’t saying “why is a part of the software we’re paying to develop not our own IP?” – so I’m trying to find some kind of basic minimal-reassurance contract or document I can give them.