Posted on 4th April, 2013 by LEO Learning Web Team
This post was written by Mark Arbedour and first appeared on the Epic blog on 4th April 2013.
Do the software programmers in your business know which code they can reuse and which they cannot? Do your programmers see all open source code as fair game? What are all these open source licenses and what do they actually allow you to do with the code? How is an Apache license different from the GPL? Why should I even care?
Most organisations will struggle with one or more of these questions. It’s a fact that all good programmers look to the internet for code, whether their purpose is to reuse open source code or just to get ideas. It’s one of the fantastic things about the web and open source code that programmers can do this.
But while it’s good practice to make use of publicly available and well tested code, programmers don’t necessarily want to get bogged down in licensing law in order to understand whether they can legally use a particular code library or snippet. There are a number of commercial tools available to help you identify reused code in your products, and these certainly have their place, but doesn’t it make sense to educate your programmers about best practice for code reuse in the first place? We think so, so that’s just what we did at Epic last month when I ran a training session for our programmers on best practice guidelines for reusing third-party code.
We have shared the presentation on Slideshare for programmers and organisations to make use of. I’ve been looking for an easy-to-understand reference to open source licenses for a few years – I have a book on the subject and numerous bookmarks to complicated articles, but I never found anything easy enough that I felt I could pass on more widely. Our Slideshare presentation encapsulates the key information I’ve found from many sources, and I hope you find it useful as a simple reference guide to reusing third-party code.
This is not aimed at lawyers but at programmers, so the aim is to cover the key points that will keep programmers on the right side of the law. My feeling is that as a company we have a duty of care to ensure our programmers understand this – not just for the company’s benefit but also for their own, because as with all employees, they are personally liable for their own actions. It’s an often ignored area of software development, but an increasingly important one to understand the basics of.
Of course I am keen to hear about any improvements to the information, provided it remains easy to understand! I’ve worked in open source nearly 10 years now but I’m no lawyer, so please mail me if you can improve on the slides in any way: email@example.com.