Open Source Licensing: Can it Burn You?
Jens Eckels
August 02, 2007
Licensing. What you don't know CAN hurt you.
Open source licenses come in all shapes and flavors, none of which are inherently evil or devious. Rightfully so, the licensing varieties are selected by the creators/owners of software code, and reflect their own desires for the projects that are being open sourced.
So far so good.
Now that open source is enjoying widespread adoption (especially in the development world) in the form of platforms, plugins and professional projects, there are many types of distributions popping up that allow you to select multiple open source projects and incorporate them into a single download for ease in time and bandwidth.
Again, great news.
But as all roads to hell are paved with good intentions, so it seems is the decision of many companies to allow developers their own choice in tooling. As more and more enterprises are allowing individual developers to operate completely free of oversight in how they complete their OSS downloads and the tools they are using, many are becoming oblivious to their development teams utilizing open source in their project's code base. While most developers are cautious/conscientious, not all are, and this could have some consequences for the enterprise.
As stated, open source projects have varying licensing requirements that require certain behaviors by the user of the software. Some give free rein to the developer, placing little or no restriction on use or inclusion of the software in any way seen fit by the user. Others are a bit more restrictive, requiring that any changes made to the code be contributed back to their original authors and/or be made public (often referred to as copy-right). Others go so far as to require that if a developer places any code from the OSS project into their own work, the entire resulting work must be released into open source as well; also known as copy-left. These licensing models all boil down to a key point: the level of reciprocity required by the user.
These different levels of responsibility all have pluses and minuses from varying points of view. The problem comes when convenience trumps due diligence as developers choose to utilize a piece of software because it is open source, without considering the consequences.
For example, a developer from an “Eclipse-only” shop decides that, in order to not reinvent the wheel, he will speed his development by utilizing source code he found in the OSS space, not realizing (or taking the time to realize) that it's bound under the GPL (General Public License). He finishes his project in record time and delivers his work to his boss, who is pleased with the progress and not necessarily the wiser that some of the code is under this license. Through no intent of malice or theft, the developer thought he had discovered a great workaround, the boss thought he had a great employee, and the project was nice and stable.
Problem is, now their product, if distributed in any form, is out in the open. Their entire, mostly proprietary software is now legally bound to be open sourced under the GPL as well, potentially ruining their business. This poses a true challenge to many “OSS-only” shops who are not on the ball with everything being used by their developers.
So in the age of OSS bundles and convenient downloads (sometimes with little supervision), how can corporations be sure they are protecting themselves from this type of occurrence?
Historically, the most common way enterprises have solved this problem is by obtaining a commercial solution. Environments that charge a fee often have their own set of licensing restrictions and manage any third-party driven components (including open source) for you, freeing up the headache of manging the licenses yourself. This also allows you to standardize your environment across the board rather than developers rolling their own, sometimes incompatible solutions.
Sounds good, right? While this may solve your licensing woes, the oft-perceived downside of the commercial environment is twofold:
You are locked in to a vendor
Cost
Unfortunately, these two barriers often keep individuals and companies from easing their licensing pain by looking into commercial solutions. However, many consumers are now turning to low-cost, lock-in free options like MyEclipse ($30/year) to get the best of both worlds of license management and open source compatibility. Some slightly-higher cost solutions like BEA Workshop will also incorporate open standards into their final product and keep you well under $1000 per seat.
With several options that keep your company in the open source space but alleviate headaches, there's no excuse to not try out a couple of the better commercial models. Some, like MyEclipse, even offer a money-back guarantee if you are not satisfied 100% with the product.
So the next time you see a convenient bundle of OSS tools, be sure to take a hard look at the licensing requirements of each product and be sure you know what you are using before it touches your code base. If you have questions about the individual licenses, I would recommend contacting your legal or software management departments.
More simply, I would recommend you give some commercial solutions a spin to see if they work for you or your company. With some, you can get freedom from worry, freedom from vendor lock-in and freedom from high cost tooling, while still getting your favorite open source tools in a fully-supported environment.
Open source is a great thing, and can be the most valuable initiative adopted by your company. Just be sure to know what you're getting into before you hit the “download” button.
Open source licenses come in all shapes and flavors, none of which are inherently evil or devious. Rightfully so, the licensing varieties are selected by the creators/owners of software code, and reflect their own desires for the projects that are being open sourced.
So far so good.
Now that open source is enjoying widespread adoption (especially in the development world) in the form of platforms, plugins and professional projects, there are many types of distributions popping up that allow you to select multiple open source projects and incorporate them into a single download for ease in time and bandwidth.
Again, great news.
But as all roads to hell are paved with good intentions, so it seems is the decision of many companies to allow developers their own choice in tooling. As more and more enterprises are allowing individual developers to operate completely free of oversight in how they complete their OSS downloads and the tools they are using, many are becoming oblivious to their development teams utilizing open source in their project's code base. While most developers are cautious/conscientious, not all are, and this could have some consequences for the enterprise.
As stated, open source projects have varying licensing requirements that require certain behaviors by the user of the software. Some give free rein to the developer, placing little or no restriction on use or inclusion of the software in any way seen fit by the user. Others are a bit more restrictive, requiring that any changes made to the code be contributed back to their original authors and/or be made public (often referred to as copy-right). Others go so far as to require that if a developer places any code from the OSS project into their own work, the entire resulting work must be released into open source as well; also known as copy-left. These licensing models all boil down to a key point: the level of reciprocity required by the user.
These different levels of responsibility all have pluses and minuses from varying points of view. The problem comes when convenience trumps due diligence as developers choose to utilize a piece of software because it is open source, without considering the consequences.
For example, a developer from an “Eclipse-only” shop decides that, in order to not reinvent the wheel, he will speed his development by utilizing source code he found in the OSS space, not realizing (or taking the time to realize) that it's bound under the GPL (General Public License). He finishes his project in record time and delivers his work to his boss, who is pleased with the progress and not necessarily the wiser that some of the code is under this license. Through no intent of malice or theft, the developer thought he had discovered a great workaround, the boss thought he had a great employee, and the project was nice and stable.
Problem is, now their product, if distributed in any form, is out in the open. Their entire, mostly proprietary software is now legally bound to be open sourced under the GPL as well, potentially ruining their business. This poses a true challenge to many “OSS-only” shops who are not on the ball with everything being used by their developers.
So in the age of OSS bundles and convenient downloads (sometimes with little supervision), how can corporations be sure they are protecting themselves from this type of occurrence?
Historically, the most common way enterprises have solved this problem is by obtaining a commercial solution. Environments that charge a fee often have their own set of licensing restrictions and manage any third-party driven components (including open source) for you, freeing up the headache of manging the licenses yourself. This also allows you to standardize your environment across the board rather than developers rolling their own, sometimes incompatible solutions.
Sounds good, right? While this may solve your licensing woes, the oft-perceived downside of the commercial environment is twofold:
You are locked in to a vendor
Cost
Unfortunately, these two barriers often keep individuals and companies from easing their licensing pain by looking into commercial solutions. However, many consumers are now turning to low-cost, lock-in free options like MyEclipse ($30/year) to get the best of both worlds of license management and open source compatibility. Some slightly-higher cost solutions like BEA Workshop will also incorporate open standards into their final product and keep you well under $1000 per seat.
With several options that keep your company in the open source space but alleviate headaches, there's no excuse to not try out a couple of the better commercial models. Some, like MyEclipse, even offer a money-back guarantee if you are not satisfied 100% with the product.
So the next time you see a convenient bundle of OSS tools, be sure to take a hard look at the licensing requirements of each product and be sure you know what you are using before it touches your code base. If you have questions about the individual licenses, I would recommend contacting your legal or software management departments.
More simply, I would recommend you give some commercial solutions a spin to see if they work for you or your company. With some, you can get freedom from worry, freedom from vendor lock-in and freedom from high cost tooling, while still getting your favorite open source tools in a fully-supported environment.
Open source is a great thing, and can be the most valuable initiative adopted by your company. Just be sure to know what you're getting into before you hit the “download” button.
Print
Email
