Open source legal implications, licenses and their impact...

When you join a tech company, you usually end up signing some sort of employment agreement contract which, if 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 including ideas you might have in the shower or anywhere else.  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 (a proprietary, closed mindset) and what "belongs" to the employee that they can contribute towards during their spare time.  Especially for contributions which are unrelated to the employee's day job.

So, it's imperative a developer/contributor understands the variety of open source licenses that exist, what they imply and how one should use them.

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 regarding licenses as you enter the world of open source:

1. Talk to the open source office at your company and 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 to 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 what the different types of open source licenses are - start with this site https://opensource.org/licenses/category.  Also, look at https://creativecommons.org/licenses/.
4. 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 https://www.gnu.org/licenses/license-recommendations.html.
5. 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.

But, that may not be the case all the time, depending on what makes sense and how I would want to structure the impact of the project and what I call the "target market" - as in what types of developers do I want to attract to the project.  I'm still thinking about this a fair bit and pondering pros/cons and what would be most beneficial for my "target market" - women engineers in industry who typically have very little "free" time and energy.

On open source - scratching the surface

At CodeChix, we have always been strong proponents of open source in all it's forms - software, hardware, design, photography etc. It's a fundamental requirement for all programs that we run (tech talks, hands-on workshops and hacking sessions) and our conference, DevPulseCon only accepts talks and workshops targeting open source projects.

Over the years, it's been an eye-opening experience for me that there are so many companies that tout open source support on their websites and marketing verbiage and, yet, when you look closely or instigate an open source project that might "compete" with a proprietary product at said company, all "open source goodwill" goes out of the window in a flash.

This happened to me when I was building the CodeChix team to work on the Open Networking Foundation's OpenFlow Controller international competition consisting of 4 fantastic women engineers from 3 different companies. One of the companies, a behemoth of networking software and hardware which proclaimed huge support for open source on their website etc., denied two of their women engineers (CodeChix members) on the team from working on this competition project. Their argument was it was a "competing" effort to their proprietary controllers and they would not allow these two women engineers to participate in this effort that was being run by CodeChix. Naturally, I pointed out the discrepancy between what they were touting on their website and what they were telling me. Which resulted in complete silence and I suspect my queries were relegated to the proverbial bitbucket.

So, I pinged the ONF Executive Director, Dan Pitt, about it and mentioned this dilemma - I couldn't build a team without these two engineers - they would be doing all the work in their spare time (nights and weekends) just like the rest of the team and I really needed them in order to meet all the submission criteria for the competition.

After several email threads with the ONF, myself and the legal department at the offending networking company, it was finally agreed that as long as CodeChix would open source all the work (of course, that was the whole point after all from my perspective), said networking company would be "OK" with the two women engineers working on this project. The whole process took about a month and half to get resolved. With a lot of angst and stress and juggling on my part. And the team took a big hit since we couldn't really be fully productive until both these team members had the green light to join and start their work.

The moral of the story being, never give up. And call out the industry when they try to ignore their own policies. I'm not saying this will always work - it helps to have a heavyweight organization to back your efforts. But open source is the future - for the women engineers who are truly dedicated, brilliant, persistent and resilient. It's not for everyone, I think. It requires a very different mindset and attitude from what traditional proprietary product development entails as far as processes, accountability, collaboration and effectiveness. In some cases, it's much more difficult to make a mark in open source and get recognition for it. It's not like you have a manager/boss who's watching you or assigning you tasks. You are your own boss and that can be a good thing or a burden - depends on your personality and motivation.

But, if it is in your DNA to run things, open source is a potential path to success as you choose to define it - whether it's for contributing to solving hard problems, improving the world or teaching/learning.