If you’ve ever traded in an aging workstation for a new machine, you probably already understand, software licensing can be oblique and confusing without an advanced degree. Open source licensing seemingly even more so, with all the options to consider.
Most developers have become acquainted with software licensing through a proprietary lens. That monolithic copy of Windows someone bought in the mid-90s couldn’t be transferred to another machine without jumping through some inconvenient hoops, and certainly wouldn’t include updates for the new version a few years later. In reality, open source licensing predated proprietary models by several decades.
AT&T’s UNIX operating system got the ball rolling in the 1970s, developed by Bell Labs as the world’s first general-purpose operating system. From there, the University of California, Berkeley (BSD), Microsoft (Xenix), IBM (AIX), and Sun Microsystems (Solaris) and other organizations developed their own versions of the OS.
Now nearing its 50th birthday, UNIX is also still in use as a portable C-based programming language, currently supporting other languages and applications like:
Both open source and proprietary licensing models, as well as product design supporting those models, have evolved since the early days of UNIX. Now, repositories like GitHub make it easy to see every line of an open source code base, Meanwhile, “closed source” code like Apple’s OSX is shrouded by even more layers of encryption and legalese.
It can be confusing, but it doesn’t have to be intimidating. At the highest level, open source licenses comply with the Open Source Definition, providing that the software can be freely used, modified, and shared.
Software engineers at DornerWorks commonly use open source tools to build products, and contribute regularly to the open source community through development on Xen Project hypervisors like Virtuosity, the seL4 microkernel, and embedded Linux applications. Subsequently, they need to know their way around open source licensing definitions. The following summaries will help you learn how to bring the same understanding to your next project.
The Open Source Initiative lists the following licenses as “popular or widely used,” or having “strong communities”:
There are even more choices outside of this list, but choosing the right open source license for your next project is simpler than you may think. GitHub offers a 3-branch chart to help product developers understand how licensing may affect their products, and which licenses will align with certain design goals.
The permissive MIT License is the simplest form of open source licensing. It gives others permission to add, delete, or otherwise alter your code for their own use, as long as they provide attribution back to you and don’t hold you liable for any issues with their product.
Examples:
The permissive Apache License 2.0 is similar to the MIT License, but allows users to develop and register their own patents with the code.
Examples:
BSD licenses are even less restrictive than the others. The New BSD License/Modified BSD License permits users to redistribute media for any purpose, so long as copyright notices and disclaimers of warranty are maintained. It also prohibits users from including the names of the media’s contributors for any endorsements without permission. The Simplified BSD License/FreeBSD License is much the same, except without the non-endorsement requirement.
Perhaps the most “public” license of all, the Unlicense is based on a copyright waiver and no-warranty statement. Unlicense.org maintains this as a template for dedicating software to the public domain, “to opt out of the copyright industry’s game altogether and set your code free.“
Open source licensing is also available for non-software systems, like media, documentation, fonts and mixed projects. GitHub provides a full index of the various open source licenses available, their advantages and limitations, here: https://choosealicense.com/appendix/
You can own the copyright on open source code you’ve modified for your own project, but if you release it using a GPL license, your rights end there. The customer can distribute your source code any way they like, and you can’t take it back.
This is a point of contention for some companies and a reason why they may seek other forms of licensing. Ironically, releasing a work under no license at all results in an automatic copyright. It’s only through one of the open source licensing models that a product will be maintained in the public domain.
Deciding on the right open source license or combination of licenses, for a particular project isn’t a casual exercise. Product developers need to take care in understanding the implications of the license model they choose. Some, like the Unlicense, involve just a few lines of rhetoric. The GPL, in contrast, has quite a bit more to parse.
If you are considering building your next project with open source technology, contact DornerWorks for a free brainstorming session, meet an experienced team of engineers, and lay out a plan for success.
