When you join a tech company, you usually end up signing some sort of employment agreement contract. Of you read carefully (you MUST read this thoroughly), probably states all sorts of restrictions on what you can or cannot do/own and the rights of the hiring company to own your work. Whether it is during working hours or in your spare time, the ideas you might have in the shower or anywhere else could be impacted. In many cases, this extends to open source contributions that you might make which might be unrelated to anything you do at work.
As we grapple with a rapidly changing software and hardware industry where the open source juggernaut slowly, but steadily, steam rolls over proprietary software, we are faced with difficult and contentious issues of what “belongs” to:
- The company
- The employee
So, it’s imperative a developer/contributor understands the variety of open source legal implications and open source licenses that exist, what it implies and how one should use those licenses.
The choice of the open source license for a new project can directly or indirectly affect how it grows, how many contributors and maintainers it has, how it is used, whether people can make money using it commercially or not and, eventually, whether the project is sustainable.
Here are a few things to think about for open source legal implications regarding licenses as you enter the world of open source:
1. Talk to the open source office at your company.
Ask them for clear guidelines on what is your intellectual property and what is the company’s. If you don’t have an open source office, locate the legal department and ask someone in that team. If they don’t know, talk to the legal department about your concerns and see if you can get some sort of guidance from them.
2. Read and re-read your employment agreement.
This will help y0ou understand what the implications are for your ideas and contributions to open source. Does the company own any contribution you make regardless of whether it’s related to work or not? Is it restricted to software, hardware, both? What about blogs, presentations at external conferences where you are not sponsored by your company, published articles in journals or technical magazines?
3. Read, re-read and completely understand the different types of open source licenses.
Start with this site opensource.org/licenses/category. Also, look at creativecommons.org/licenses/.
If you create open source software or hardware, ensure that you are clearly stating what license is used for contributions to that project. If you’re unsure about what license to use, ask around, go to open source-centric meetups and talk to speakers to increase your knowledge and get help online. Also, see gnu.org/licenses/license-recommendations.html.
If you contribute to existing open source software or hardware, ensure that you understand what license is used for your contributions and if you are allowed to share it, own it and use it as you and others intend.Your choice of license (whether you started the project or are contributing to an existing one) can have a significant impact on the culture of the project. MIT, Apache and BSD licenses are extremely open and allow contributors to share and contribute freely.
Projects that use these licenses might not, however, have stringent rules and oversight to vet the quality of the contributions since anyone can contribute – whether they have an appropriate background or not. This could also lead to many new contributors asking for help and maintainers being overwhelmed (and, therefore, quitting).
If you go the GPL route, the various versions have varying implications and your contributor/maintainer profile and personality might be quite different. What if it’s more litigious? Is this what you want for your project? Do you want your project to be commercially distributable with acknowledgement to the origins and contributions back to the original project?
I tend to use the MIT or BSD licenses for projects. CodeChix Technical Curriculums contain a series of technical curriculums spanning mobile, security, NLP and Big Data under the MIT license. We used the Apache license for the OFconnect SDN controller project.
What types of open source legal issues have you run into? Any advise for fellow readers? Share it in the comments and connect with us on Twitter @vmwopensource.
