What Would I Tell Developers About Using Open Source Software?

  

 Email Article  

Tweet  

  

In the first two weeks of April, I attended four distinct open source related events in three different cities and two countries. It will take months to ponder, absorb, and follow-up on all of the thought-provoking presentations, conversations, and feedback I participated in or received. In spite of the range of topics and agendas being covered along the way, there were a couple themes that reverberated.

One theme involved the idea that open source license compliance is not a legal problem, but an engineering and software problem. Discussions around SPDX touched upon this; specifically, that compliance in the supply chain must begin with creating a bill of materials that can be read and understood upstream and down. In order to create such a bill of materials, the work must be done before the product enters the supply chain, ideally during the development process. Those doing license enforcement discussed how the most common non-compliance scenario entails a failure to provide the correct corresponding source code - be it incomplete, the wrong version, or source code that doesn't match the distributed binary. Again, this information is best tracked early on, not after the fact. This is not to blame developers, but highlights the reality that processes to prevent or address compliance from the get-go are often lacking.

The other theme I heard in a variety of forms had to do with education. The best development processes are useless if training is lacking, not grounded in a practical rationale, or not backed by management. Of course, before we can talk about the quality of education, this presumes there is a policy to train employees on. Not so much, as it turns out research by Gartner showed that in spite of widespread adoption of open source software, most organizations lack an open source policy or framework. Meanwhile, at universities and other educational institutions, computer science students are steeped in the use of open source software, but are not getting any training on licensing issues.

This led me to think. If good compliance habits begin at the development stage; yet developers are not really getting educated on best practices until working in a company that provides such education; and the percentage of companies that institute open source policies trails behind open source software use, then we are left with a big gap in terms of dealing with compliance before it becomes an issue. What steps can we, as individuals, take in the meantime? If I could have the undivided attention of developers, what lessons have I observed as an attorney that I would I pass along about using or creating open source software? What could developers begin doing right now?

Here are three simple, yet crucial things that can be done regardless of whether your company has yet to implement an open source policy:

1) Do NOT strip out license notices, copyright notices, or any other such information.

I know, this sounds like stating the obvious, but it happens. The thing is, someone wrote that code, someone perhaps a lot like you. They deserve credit, they chose a particular license for a reason, that's why they included such notices. If they chose an open source license, they have given you some broad rights for using their software, so you have no reason to obfuscate where it came from or, worse yet, pass it off as your own. Stripping out this information also makes it very difficult for anyone else who uses that code to understand who the copyright owner is and what license it is released under.

If you are creating an open source project, then this tip becomes: include a copyright and license notice in your code. Preferably in each file. This does not need to be extensive and you can refer to the license text elsewhere if you want to save space, but be clear. You may not care so much about which license your code is under, but if that code achieves widespread use, the people using it will care and they will want to do the right thing according to your wishes, so make it easy for them to do so.

2) If you are using only part of a file or package or modifying it, keep the notices with the code.

This is a really a variation on the first point, but takes it a step further. For example, say you want to use one portion of a file that is licensed under BSD. You may take that portion and insert it into the file you are writing, but you still must comply with the BSD license, namely by retaining the license text and the copyright notice. The best way to do this would be to include a notice stating that this file contains some code by the original author and the BSD license in the same place that you put your own copyright notice and licensing information. Conversely, say you have modified the original BSD file. Add a notice along with the author's copyright and license notice stating so. Yes, I know, BSD does not require notice of modifications and maybe you don't care about having attribution for your contribution, but wouldn't it be useful to track that information for your internal reference? And if you were a person using that file down the road, wouldn't it be helpful from a development standpoint to know how it differs from the original file?

3) Determine what the license is, really.

You are in a hurry. You go to Google Code and download a project that is exactly what you are looking for. Google Code says it's under MIT which you know is a permissive license. 'Great,' you think. Not so fast. Sometimes Google Code, SourceForge, GitHub, etc. are wrong. In fact, sometimes the project's own website contradicts what is found in the code. It only takes a few minutes longer to look inside the files and check the actual license contained with the code. If it doesn't match the license stated on the website (especially if it is the project-maintained website), then you will want to make a note of this or even contact the project authors if the contradiction is stark. If you end up having to do a little research, record your findings in a way so that you or someone else can retrace those steps. Trust me, you won't remember and that website, that version, or even that project may not be available still later when someone else wants to know.

At this point, a developer reading this might challenge back as to why she should take the time and initiative to do these things if it's not required? The thing is, good compliance efforts align with good engineering habits. If you don't believe me, listen to what OpenLogic director of engineering and co-founder, Eric Weidner, had to say on this topic. In the big scheme of things, a small amount of time in the development process can go a long way on a number of fronts.

What other tips would you add here?

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic

Follow @cloudswing

Follow @jilaynelovejoy

View Jilayne Lovejoy's profile

This work is licensed under a Creative Commons Attribution 3.0 Unported License

.