Why is it so hard?

Understanding and interpreting open source licenses is not always an easy task. Open source licenses are essentially unilateral; if you use the software, you agree to the terms of the license. There is no protracted negotiation process in which you ruminate and refine terms, as is often the case for custom-developed software. Open source licenses may not track on U.S. Copyright Act statutory language or use accepted license wording. Alternative language or definitions may be used instead of legal terms of art or expanded to encompass a global perspective.  All of this can cause ambiguity when it comes time to interpret the license for compliance.

Making it even more difficult, the more troublesome compliance terms have yet to be litigated, most notably the derivative works question in regards to the GNU General Public License.  However, that does not mean there is no guidance; organizations that have authored or maintain a license often provide a frequently-asked-questions resource to proselytize their interpretation.  Whether a court would agree with their interpretation may be debatable, but so long as there is no judicial opinion regarding specific compliance terms it is wise to pay attention to these resources. For the more common and established licenses, seasoned open source attorneys can also rely on community-accepted practice for compliance.

Interpretation Made Easy

It should go without saying that open source licenses are no different than any other intellectual property license; that is, there are conditions or requirements that need be met and restrictions that need to be minded. A helpful starting point is to break down the requirements into an if/then statement.  For example, if you distribute the code - the triggering event or use of the code - then you must provide a copy of the license - the requirement or obligation.



How you use the code - the triggering event - will determine what conditions or requirements need be met.  By identifying your usage model for the open source software in question, you can then start to filter which license requirements are needed for compliance.  Keep in mind that some triggering events may demand further analysis.  Does the license define "distribution" based on copyright case law?  Does the definition of distribution or conveyance include access to the software via a web-based platform?  Is it possible that how you use the use of the software will change over time, thus changing what requirements or obligations are triggered?

Once you know how you are using the open source software and thus, what license requirements you must comply with, then you must ask "how"?  How must you provide the copy of the license?  Sometimes the devil is in the details; for example, is it enough to retain the license in the header of some of the source files or do you need to have some kind of license notice in every file?  Where does the license go if you are distributing the work in binary form?  Some licenses may have specific guidance on how a condition must be met and some are vague, requiring you to decide what seems reasonable.

Once you have sorted out what you need to do to comply with the open source licenses, then you need to consider if there are any conflicts between the licenses or their terms. Sometimes there can be conflicting obligations and two licenses end up incompatible. Typically this occurs when there is a derivative work involved. For example, if you have created a derivative work by combining two projects, each under a different license that requires you to release a derivative work under the original license, it would be impossible to comply with both licenses. Depending on the open source license, you may also have a licensing conflict with your end-user license agreement (EULA); for example, if an open source license disallows imposing further restrictions on the open source software and your EULA includes restrictions on the number of users or prohibits reverse engineering, you need to include a "carve-out" that the open source license applies as to the open source software.

At the end of the day, when it comes to complying with open source licenses, there is often no definitive answer. Because there is no established jurisdiction interpreting, for example, whether dynamic linking creates a derivative work, you may simply have to make a determination based upon your interpretation of the license. How you make that call may hinge on the risk profile of your company or how your product is engineered and therefore involve discussions among your business and development teams.

 

What open source license clause would you most like to see a court opinion on?

 

Do you have any tips you can share regarding how you approach open source license interpretation?

Crossing the Chasm, by Geoffrey A. Moore, was not written about Cloud Technology.  In fact, the book was originally published in 1991 when a reference to "The Cloud" most probably would have had people looking out their windows at the sky.

Cloud technology and cloud based solutions are having an impact on all stages of the current technology adoption life cycle, and although the book was published in 1991, the principles and characteristics defined appear to be solution agnostic and still resonate 20 years later with recent references in articles like, 5 More Books for the Aspiring Funnelholic, Crossing the Content Chasm, and Will Google+ Cross the Chasm?.

So what exactly are the stages of the technology adoption life cycle, and where do you stand when it comes to cloud solutions?

The 5 Stages of the Technology Adoption Life Cycle described in Crossing the Chasm:

The Innovators: Technology Enthusiasts

These are the people who can "see the light" when no one else can.  They are the people like Bill Gates and Steve Jobs, who understand a market demand for a product that hardly exists.  The innovators are few and far between, but are the first ones to take something out of the box, throw away the instructions, and see what it does.

Early Adopters: The Visionaries

Mr. Moore hit the nail on the head when he said, "Visionaries are that rare breed of people who have the insight to match an emerging technology to a strategic opportunity, the temperament to translate that insight into a high-visibility, high-risk project, and the charisma to get the rest of the organization to buy into that project."

Early Majority: The Pragmatists

This group is known to be that which makes up the majority of the market volume when it comes to new technology adoption.  Pragmatists rely on data and benchmarks to make their decisions, not the new shiny toy coming out of the box.  The pragmatist characteristically relies on trusted advisors, and the influence of the early adopters to help make their decisions.  Pragmatists are just that, they are pragmatic.  They care about the quality of the product, the goings on in the company who provides the product or solution in question.

Late Majority:  The Conservatives

Mr. Moore interestingly describes this group's characteristics to be similar to the great football coaches of Mike Ditka, Chuck Knox, George Allen, and John Madden.  To give this analogy some perspective, Bill Walsh, the legendary coach of the San Francisco 49ers, was referred to as the visionary and Sam Wyche of the Cincinatti Bengals was the technology enthusiast.


Late Adopters & Laggards:  The Skeptics

These are the anti-sponsors for the adoption of a new technology.  "What skeptics are struggling to point out is that new systems, for the most part, don't deliver on the promises that were made at the time of purchase."  The influence a skeptic might carry with their words could possibly end any hope that you have of adopting a new technology into your organization.

Although the book is primarily written from a marketing point of view, the real value proposition, and the reason it is still receiving references 20 years later, is that no matter which hat you wear in your organization, whether you provide a solution or might be looking for a solution, the principles and detailed depiction of the life cycle, can help identify the best way for you to reach your technology adoption goal.

Where are you in the technology adoption life cycle when it comes to cloud technology?

 

We'd like your input!

We are going to be creating a few LinkedIn groups to cover the topics that we discuss here on the blog, but in a more forum type of environment, Q&A setting, to run in conjunction with our posts.  We will also be hosting upcoming Hangouts on Google+.  Be sure to add us to your Google+ circles at the top of this page on the right hand side to receive updates on "whens" and "whats" of these upcoming Hangouts.

If you have suggestions for the The LinkedIn group's topics for discussion, or topics you'd like answers around in an upcoming Hangout, please submit them in the comments section below!

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic

Follow @AaronMandelbaum

View Aaron Mandelbaum's profile

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

.

Many people in the business world prefer to use proprietary software instead of open source software due to the misconception that proprietary software is better supported than open source software. After several years of supporting both open source software and proprietary software, it becomes clearly evident that just because you pay for proprietary software does not mean that supporting that software is any easier; in fact, there are plenty of reasons why supporting open source software is actually easier.

Let’s identify the set of steps you would take to handle a support issue for proprietary software.
First, you would have a system administrator consult the software documentation to learn more about the issue at hand to find a solution to the problem. If the administrator cannot resolve the issue with the use of documentation, then do one of the following:

• If you have business-level or production-level support from the software vender, open a support ticket with them at this time.

• If one is available, post your issue on the online community for the product (forums, mailing lists, wikis, etc.).

• Seek out another existing employee who might know how to solve the issue.

• Contract a third-party expert to help fix this issue.

• If the issue is actually a bug with the software itself, issue a bug report to the vender.

Believe it or not, the general steps to handling an issue with open source software line up almost identical to the steps above. At times it’s actually easier to deal with a bug fix for open source than it is for proprietary software. In open source, bugs are typically submitted to an online issue tracking system, which is public to any user. For simple everyday support issues there really isn’t much difference between open source support and proprietary software support.


What about when complex errors occur? For example, you may not be able to find anyone else from the online community that has experienced the issue. And nothing is popping up when typing the error messages into Google. In this case, the issue could be related to your data and specific use of the software. This would explain why no other users have experienced the same issue.

So what are you to do when there is no answer online and you're having an issue with the software? And now here lies one of the great benefits of open source: you have access to crack open the black box and see what is inside.

A skilled software developer has access to the actual source code that makes up the open source project – unlike if the issue was occurring within proprietary software. The developer will be able to debug the issue by crawling through the code rather than waiting for assistance from outsourced tech support or vender support. Sometimes the issue can be majorly complex, and crawling through the source code is often the only way to truly diagnose the problem. When/if the issue is identified as a bug in the software, a skilled developer or contracted third-party expert can rebuild the software with a self-made fix for this issue – no vender interaction required.

Proprietary software support issues can hit the “black box” – that is, getting a fix for a problem is quite rare and you’ll usually need to find a workaround for the support issue instead. Typically, the bigger the vender, the harder it is to obtain a fix. The beauty of open source support is whether you’re fixing the issue by hiring a third-party open source software expert (such as OpenLogic) or by utilizing an existing employee, you can always take full control of your support needs.



 

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing

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

Online piracy is a serious issue, and media companies are continually looking for ways to fight it. Currently, United States federal law enforcement has the authority to shut down US-based sites that facilitate pirated copyrighted material. Those site owners can face fines and risk their site being shut down – not to mention that whole pesky jail time thing. However, so far none of these threats have managed to put a stop to piracy, especially on those websites not based in the United States (and therefore not as easily subjected to US law) such as the popular site, The Pirate Bay, a Swedish website that hosts torrent files and allows users to share them with each other.

Cue the controversial Stop Online Piracy Act and the Protect IP Act, fondly known as SOPA and PIPA. Both bills had intentions to combat copyright infringement on foreign sites by preventing US-based sites from linking to, advertising on, or funding sites that provide pirated content. Sounds great in theory, but the problem is in the bills’ broad language. As it stood the bill would allow for the Justice Department to target websites who were unknowingly or unintentionally hosting links to pirated content. Those sites – including big user-oriented sites like Facebook – could essentially have the plug pulled on them unless they censored the user-generated content to be certain they weren’t hosting anything deemed illegal (this is where the uproar about censorship comes from). You can check out a nice breakdown of SOPA here.

SOPA and PIPA were very recently put on hold after much protesting and petitioning from the likes of Wikipedia, Google, the Free Software Foundation, and angry Internet surfers everywhere – but you can bet this isn’t the last we’ve heard of bills such as these. So what would similar bills mean to open source software if they were realized? Here’s what the potential impact could look like:

Impact on the Virtual Community

Open source communities are an essential part of open source software. In many cases, online forums are some of the only ways to get documentation, technical support or notice of software updates (that is, unless you use a convenient third-party resource like OpenLogic). SOPA, again based on its non-specific language, could have required a site owner to strictly monitor or possibly censor user comments in social platforms, including forums, to avoid risking a user posting a link to a site that promotes or facilitates piracy. These sites, worst-case-scenario, would be liable for the content uploaded to it – if those sites didn’t take control over their user-generated content, you may not be able to find them anymore. Alex Howard at O’Reilly Radar does a great job of explaining this – read more here.

If similar legislation came to fruition, it would likely impact many if not most OSS community websites. For example, let’s say a developer visited a forum and decided to add his two cents and provide a link to extra information. Maybe that link went to a site that provides pirated content or access to pirated content (even if the developer wasn’t aware of this). Theoretically, if the owner of the forum didn’t take action to delete that comment then the site owner could end up in deep water.

The foundation of open source is built upon the freedom of the Internet, and free communication (without liability risk) is one of the most important aspects of the open source community – without it open source wouldn’t function as it was originally intended.

Impact on Open Source Software Usage and Development

Open source projects found (or possibly even perceived) to be aiding online piracy could encounter problems if bills like SOPA and PIPA were to pass. For example, earlier last year the Department of Homeland Security demanded Firefox take down its option to add on MAFIAAfire – an open source project designed to redirect users to alternate domains when they try to access domains (some of which were piracy-aiding) that have been seized by the ICE. Instead of just giving in, Mozilla sent a letter requesting justification of the project’s illegality. If legislation like SOPA and PIPA had been enacted at that point, Mozilla may not have had much of a choice in the matter – they could have had to either remove MAFIAAfire from their repository of add-ons or face harsher consequences, at worst, being shut down. The same could go of any other open source project deemed to be aiding or promoting online piracy – the project could be shut down.

The Open Source Initiative (OSI) articulated its disapproval in an open letter issued in opposition of SOPA and PIPA, stating:

“…the Stop Online Piracy Act (SOPA), PIPA requires the use of internet censorship tools, undermines the global nature of the internet, and threatens free speech online. PIPA introduces a deeply concerning degree of legal uncertainty into the internet economy, particularly for users and businesses internationally…”

The OSI went on to list specific issues relating to freedom of speech in the letter, but also expressed its concern that SOPA could create a need for excessive compliance measures, as any web property unknowingly using even a shred of open source that could be interpreted as ‘piracy-friendly,’ it could be shut down. This would ultimately hinder the use of open source, chilling development and possibly risking financial support for the community.

Of course, this post covers what would be “worst-case-scenario” – with SOPA and PIPA stalled, we hopefully won’t have to face harsh legislation like this as a reality. Currently there’s already a bill in line to take its place (check out the OPEN Act, which appears to better protect the freedom of the Internet and is backed by Google, Facebook, Twitter and others). The important thing to remember is that future of open source software is reliant on open Internet and freedom to communicate openly. Not only are these basic human rights, but also these two rights in particular are the ideals the open source community is built upon in the first place. It’s important we continue to give input and preserve the fundamentals that open source stands on so it can continue to grow.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing

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

When preparing to scan your application development projects for open source software, one simple approach is to point your  scanner at the root directory of your development system. However, that is probably not the most efficient approach because the results may include many open source components that are not actually part of your application. Or worse, the scanner may miss components that are not present in the build environment. There are many reasons to be careful and selective about what you scan and why.  Here's a short list of considerations to keep in mind when preparing to scan and determine the open source used in your application.

Binaries vs. Source Code

When do you have to supply binaries in your scanning effort? Open source scanning tools like OSS Deep Discovery can scan and find snippet-level matches within source files. If you are using open source libraries you may think that simply providing source code is sufficient, but here are a few rules to consider when deciding whether to include binaries.

1) If you only have compiled versions of some libraries you may have no option -- you have to include the binaries. But often, compiled versions of open source libraries can be easily obfuscated and may not be recognized by the scanner. In cases like this, if you know of binary-only libraries in your code, it is in your best interests to try to find and download the original source. You will have a much better chance of getting accurate results, and the scanner may even find some additional open source components you didn't know were used in the original open source library.

2) If you have the source code to all binaries you provide in your final application, then there is little reason to include binaries. They may only complicate the results and make reconciling the scan more difficult.

3) There are some circumstances you may want to include binaries when you also have all the source available. On Linux systems, for example, running “ldd” can provide good information on how your code is linked to standard open source libraries in the operating system. This linking can provide additional information about license obligations that are triggered on the combination or linking of programs.

Build vs. Runtime Components

While it is much easier to just provide everything when running a scan, you may want to think about run vs. build-time components. Here are a few examples of where this can be important.

1) Many times build components are licensed under the GNU General Public License (GPL).  Scans that include build-time components (that do not get distributed with your application) may turn up matches that are hard to explain to your legal department or compliance group. For example, if you are careful not to use GPL code for policy reasons on a commercial application, but a scanner shows several matches to GPL-licensed code, you then need to help your less technical folks understand why these components are not distributed, why it's not a compliance issue, or why GPL is in your code when you said it wasn't.

2) There are times that simply including everything is a good thing. It helps confirm what open source components get distributed with your application so you make sure you don't accidentally ship something that triggers some unintended license obligations.

Additional Components

A common mistake I see people make when preparing to scan their projects for open source is to accidentally leave components that include open source out of the scan. Here are a few considerations to keep in mind when preparing to scan your code.

1) Does your build process download and use components that are not in your source code repository? If additional code is downloaded at build time, make sure that those additional components are included when you run the scan. This is particularly important if you use tools like Maven.

2) Does you product rely on additional components that are not part of the build environment you are scanning? This may seem like an obvious question, but sometime we get so close to our work we miss the obvious. When preparing files to scan double check that you have included all components you ship.

Performing an open source scan and audit of your code is an important component of the modern software build process. Keeping these relatively easy set of considerations in mind can help make the process more efficient and easier to manage.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing

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

Open source benefits to businesses are pretty obvious, even if only recently recognized. It costs less, and often works better, than its commercial competitors. Developers have long preferred open source products to their commercial counterparts. In fact, this developer preference is why we are seeing the surge in enterprise open source usage. Why do developers prefer open source so strongly?

I want it yesterday!

Developers want to get stuff done. The thought of engaging in a procurement process is enough to sap the energy from almost any idea. We will just go back to reading hacker news instead of slogging our way through all that red tape.

Open source tools, on the other hand, are always close at hand. It takes almost no time from conception to actually writing code if you are using open source tools. Even better you can wait until you have something interesting to demo before you ask for forgiveness. With commercial offerings you almost always have to ask for permission, and we all know that is a sure fire way to get your pet project shut down.

Choice is important

Open source software suffers from the paradox of choice. There are often so many choices that it is a little paralyzing. On the other hand, the only thing worse than having too many choices is having too few. Faceless procurement processes practically guarantee that you will end up using a suboptimal tool. (This is not just a problem for developers; it happens any time someone other than the intended users chooses the tool.) Nobody wants to be stuck on a death march, and using a suboptional tool set is one way to make sure a project has problems.


The blow of so many open source choices is softened by the freedom to download several and give them a try in realistic situations. Deciding what tool to use based on check lists of features is very unsatisfying. Trying out different tools for a small project is a much better approach. This approach is devastatingly easy with open source. Just download the package and give it a shot. Commercial offerings, on the other hand, usually make this somewhat more difficult. You are likely not able to get a download and license without talking to a sales droid. Even if you are able to make it through the "lead generation" gauntlet, commercial products usually have steeper learning and setup curves because of their closed nature.

It's the information, stupid

This might be most important reason of all. The amount of information that is available for most open source projects is just mind boggling. No matter what problem you are having or question you are wondering about, someone has probably written a blog or mailing list post about it. The solution to even really esoteric problems are usually just a Google search away.

But wait, there's more... In the rare situations that Google is unable to answer your questions there are the mailing lists. The average open source mailing list is good enough to make you want to have its love child. The people subscribed know the product in and out, and they are always ready to talk about their baby. Give them an interesting problem to chew on and they will bend over backwards to find a solution.

Escape hatches are comforting

A final (for my list) benefit of open source to developers is the comfort of having access to the source code -- even if they never use it. Often you don't really want to have to read or modify the code of your tools, but having that option is very comforting. It means that if you run into some horrible bug, you can fix it. If you need to use the tool in some unanticipated way, you can modify it to work the way you need. If you want to use some poorly documented feature, you can always figure out how it works straight from the horses mouth. It is a lot harder to use tools that are opaque, and any tool that you don't have the source code for is a black box just waiting to soak up your valuable time.

What is you favorite benefit to using open source?

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing

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

OpenLogic’s Open Source Trending Report analyzes which open source projects are growing the most quickly in enterprise interest and adoption during the past year. With this information, you can keep an eye on the hottest open source projects that may be coming to your enterprise in the year ahead. OpenLogic analyzed eight growth metrics for sixteen open source projects in three categories -- web and application servers; application frameworks; and databases and big data. The projects were stack ranked on each metric and across all metrics to create an overall growth ranking.

Overall Growth Ranking

1. HBase

1. Node.js

1. nginx

1. Hadoop

1. Rails

1. MongoDB

1. Tomcat

1. MySQL

1. Apache

1. Spring

1. Grails      PostgreSQL(tie)

1. Struts

1. JBoss

1. GlassFish

1. CouchDB

Category Trends

Within each category, OpenLogic also analyzed which projects were trending up (all or most of the metrics were up), trending level (some metrics were up and some were down), or trending down (all or most of the metrics were down). Below are the trends by category.

Application Server/Web Server Category

• Trending Up: Node.js and nginx

• Trending Level: Tomcat and Apache HTTP Server

• Trending Down: JBoss and GlassFish

Analysis

Node.js is helping to drive a resurgence of JavaScript. It acts as an application server for JavaScript apps, thereby increasing scalability and performance. Nginx is a high concurrency, low memory usage web server and reverse proxy that is gaining strong adoption across the internet.

Tomcat and Apache HTTP server continue to be the 800-pound gorillas in their respective categories, but with a broad adoption base, their growth is more limited than some newer technologies.

The surprise in this category is the downward trend of JBoss. Although JBoss continues to be a popular option, we see more enterprises that are shifting off proprietary application servers chossing lightweight options like Tomcat.

Frameworks Category

• Trending Up: Rails

• Trending Level: Spring, Grails, Struts

• Trending down: (none)

Analysis

It's not a big surprise to see that Rails, an application framework for the Ruby language, is generating a lot of interest and growth. Rails is well suited to the highly scalable web applications that are becoming more prevalent in the enterprise. In addition, Rails attracts developers with its emphasis on convention over configuration, which can greatly accelerate development time.

Spring, Struts, and Grails all are trending level, showing that they continue to attract a steady level of interest in this category.

Databases and Big Data Category

• Trending Up: HBase, Hadoop, MongoDB

• Trending Level: MySQL, PostgreSQL

• Trending Down: CouchDB

Analysis

In this category many of the Big Data and No SQL projects came out on top of the overall growth rankings. Some of the growth these projects are enjoying can be attributed to the current hype around the entier Big Data category, but these technologies are also very quickly making their way onto the radar of enterprises.  These technologies are enabling brand new applications that were formerly much more difficult with traditional database and data analysis techniques. As a result, they are often chosen for new projects where they are no established database vendors to displace.

The one exception to the dominance of Big Data is the downward trend of CouchDB. CouchDB arrived on the scene a few years ago as one of the hot new NoSQL vendors. However, one of the main companies backing CouchDB is stepping away from their open source commitment and the project is a fit for a more limited set of use cases than some of the other NoSQL alternatives.  It’s possible that this project may regain its footing in 2012.

MySQL and PostgreSQL both trended level. Despite the Oracle acquisition of MySQL, it still ranked ahead of PostgreSQL in our growth rankings.

Methodology

To develop the Open Source Trending Report, OpenLogic analyzed popular as well as up-and-coming open source projects that are used as core infrastructure in enterprise applications in order to evaluate growth in enterprise interest and adoption. The three categories analyzed were web and application servers; application frameworks; and databases and big data. For each open source project, OpenLogic analyzed eight metrics that include public data, as well as aggregated data from OpenLogic’s tools and customer base of over 250 enterprises worldwide. The OpenLogic report used the following eight metrics:

• Public data: Google search volume.

• OpenLogic Exchange (OLEX) and OSS Deep Discovery Scanner: The report evaluated OLEX search volume, views of packages, downloads, requests within corporations to use the project and matches against the project during scans. OLEX is a Software-as-a-Service solution for the comprehensive governance and provisioning of open source software used by many Fortune 100 companies.

• OpenLogic CloudSwing and Open Source Support Contracts: OpenLogic aggregated data on customers purchasing support contracts from OpenLogic for each project, as well as projects that users deployed through OpenLogic CloudSwing, an open PaaS platform.

Subscribe to The Enterprise Open Source Blog by Email

Follow @openlogic
Follow @KimAtOpenLogic
This work is licensed under a Creative Commons Attribution 3.0 Unported License .

Google estimates that the exact phrase, “open source compliance,” is searched only 73 times globally per month. In contrast, “free software” is searched 90,500 times globally per month, and “source code” is searched 450,000 times globally per month.

The way I interpret this isolated piece of data is that either:

1. The vast majority of the people using open source software are so confidant that their open source compliance is spot on, that they don’t need to search for compliance solutions;


2. People haven’t looked at addressing the issue as fast as the interest and adoption of open source software has grown; or


3. People just don’t know what they don’t know and could very well be sitting on top of a ticking time bomb with issues of compliance waiting to surface.

So if you have stumbled upon this article or you are one of the 73 people in the world this month that searched for “open source compliance,” the following five steps or questions will help get you going in the right direction:

1. Identify the open source software – “What open source software do I have?”

First you need a complete and transparent view as to WHAT open source software is being used in your code base, often referred to as an audit or a package review.  You can't begin to comply with the licenses if you don’t even know what you have.  For smaller amounts of code, you may be able to get away with self-reporting and manually inspecting files, but most likely you'll need to use some kind of scanning technology or purchase audit services from a third party for a thorough assessment.  To learn more about the audit options that are, you can review The In’s and Outs of Open Source Audits.

2. Identify the licenses – “What license is the open source software under?”

Often, this question is answered alongside the first question.  Sometimes the answer is apparent.  For example, if you are using a well-known open source package, the license information for that package may also be well established.  However, open source packages can embed other open source under other licenses within them.  Sometimes the license stated on a project website is not what you find within the actual code.  In any case, determining the package is not enough, some amount of research is often needed to determine or confirm the proper license.

3. Identify your obligations – "What do I need to do to comply with the open source licenses"

Obligations and requirements that licenses pose can vary depending on a few factors.  First, identify what requirements or obligations the license imposes; what conditions does the license place upon your use of the software?  You also want to pay attention to any restrictions or termination clauses.  Then you will need to consider how you are using the software.  Most license obligations are triggered by how you are using the software, for example, are you distributing the code?  Have you modified it.  Read The 4 Steps to Understanding an Open Source Audit to see each step explained in greater detail.  Once you have gone through this process, you can create a compliance checklist - a list of all the steps you need to take to ensure you have complied with the open source software licenses present in your codebase, based on how you are use case.

4. Implement Compliance – “How do I actually comply?”

Now that you have determined what you need to do to comply, it's time to do the work.  Using your compliance checklist as your guide, take the steps needed.  This will most likely include making sure a copy of the various licenses are included, attribution notices are in place, source code is provided for any copyleft licenses, and so forth.  If you can't comply, then you may need to look at alternative licensing or replacing the code.

To learn more about implementing compliance check out A Practical Approach to Open Source License Compliance

5. Implement the changes for long-term success – “How do I stay in Compliance?”

Now that you are in compliance, how do you stay there?  As the development process moves forward, your audit and compliance may become outdated quickly.  Without instituting an open source policy and governance or tracking process, all this work will need to be re-done again.  An open source policy will lay out your overall goals and guidelines as to the use of open source software in your enterprise.   A process will be needed to track, approve, and review new open source software coming into your codebase.  Schedule periodic audits and compliance updates at regular intervals.

 

Staying in compliance is like keeping your attic clean. You know that when you start this process after a long lay off, you are probably going to find things you don’t like and you may have to make some tough decisions.  However, the process wouldn’t be so daunting if you knew exactly what was in there and had a structure in place to allow only the right things in. The same holds true with adding things to your attic as it does with adding to your code base.  Once you've done the spring cleaning, you need to have a clear understanding as to what is allowed in, where to put it, and what isn’t.  And everyone needs to be on board.

Is there a 6th step to open source compliance that you can add?

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @AaronMandelbaum
View Aaron Mandelbaum's profile

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

Is one of your resolutions for the new year to create an enterprise open source governance process for your organization, or review and update your existing governance process? If your organization doesn’t already have an open source governance process, this should definitely be on your list of goals for 2012. Ditto if you have a governance process that’s outdated, incomplete, or inconsistently implemented throughout the organization.

As with any business process change, it can be difficult to find the time, inspiration, and support from others necessary to get started with creating or updating your company’s open source governance process. If you find yourself in this predicament, now is the perfect time to review the many ways an effective governance process can positively impact your organization. Here’s a list of five benefits to help motivate you and your team to get started.

1. Improved Employee Morale

Inconsistent, outdated, or (even worse) non-existent rules and processes are frustrating. If employees don’t know how, when, and where open source is allowed or even encouraged, there’s a good chance that someone will eventually make a mistake that gets him or her – and potentially the organization as a whole – into trouble. Conversely, when employees are aware of the boundaries of acceptable open source usage, know how to procure open source, and have defined processes for requesting approval for new packages, they don’t need to worry about causing problems by using the wrong open source license or package.

An effective open source governance process improves employee morale by enabling smart, appropriate open source usage while enforcing rules fairly and consistently. An effective governance process also enables employees to request approval for new open source packages or new uses of open source, thereby eliminating any inclination to go around the company’s open source policy.

2. Increased Open Source Usage

By defining boundaries and processes, you can actually increase open source usage in the organization. This in turn can bring forth other benefits such as lowering technology costs, accelerating innovation, and attracting and keeping top technical talent. After all, who doesn’t want to be part of an organization that uses the latest open source technologies and out-innovates its competition?

3. Improved Public Relations

Good intentions can go a long way, especially when it comes to public relations. An effective open source governance process can help your organization develop and maintain a positive relationship with the open source community. This might include project contributors and committers, advocacy groups such as the Software Freedom Law Center (SFLC) and Free Software Foundation (FSF), and even individual developers who may be potential customers or employees.

How exactly will your governance process create this goodwill? You’ll first have to communicate the fact that your company has an open source policy, encourages open source usage, and has processes in place to govern open source usage. This can be done with a page on your corporate website, a dedicated open source subdomain or site (for open source fulfillment, for example), and/or by encouraging employees to participate in and present at open source conferences. No matter how you do it, the bottom line is you’re likely to see positive results when the open source community knows you’re trying to do the right thing in terms of responsible open source usage and license compliance.

4. Improved Budget and Resource Planning

An effective open source governance process will help your organization better understand what open source software is in used as well as the nature if its usage. This can be an eye-opening experience for companies that didn’t previously track and govern open source usage. Organizations often learn that they’re using a lot more open source than they thought they were, and that many open source projects are deployed in production systems and critical customer-facing websites or applications.

Whether your governance process simply confirms what you thought you knew or opens your eyes to an entirely different picture, gaining accurate data will help you better plan budgets and allocate resources. You may find that that you need open source support for critical systems, or that you have redundant services contracts with different vendors that can be combined or eliminated. You may also realize that you need to put a greater focus on open source license compliance for packages used in distributed products, or that there are opportunities to replace commercial software with open source already used elsewhere in the organization. Regardless of the conclusions you draw, you’re likely to be better prepared for future planning with the data your open source governance process gives you.

5. Reduced Legal Risks and Less Chance of IP Infringement

The most obvious benefit of an effective open source governance process is perhaps also the most significant. By definition, an open source governance process will help your organization understand and control how, where, and when open source software and licenses are used – essentially operationalizing your open source policy. Assuming your policy is comprehensive and up-to-date (if not, check out my last entry, 3 Steps to Jumpstart Your Open Source Policy), a governance process that enforces it should help your organization prevent open source license violations, reduce potential legal risks, and avoid IP infringement.

What do you think is the greatest impact of an open source governance process? If you select other, please leave a comment and share your thoughts!

[polldaddy poll="5836065"]

 

Pre-paying for open source software technical support and consultative expertise might sound crazy to some of our readers, but it should sound like a very smart and safe business decision.  As an industry indicator of the growing need for commercial support on open source software OpenLogic's support team saw a 39% increase from 2010 to 2011 in the total number of support incidents submitted during the last calendar year.

I have the pleasure of working with many different client organizations to help them determine if, when and what service level of commercial open source support is right for them.  Every time we discuss the options our conversation is a little different from the last, and rightfully so.  Evaluating the organizational need for open source technical support depends significantly on where, how, why and when the open source is going to be used.  These considerations all most likely revolve around some amount of a formalized open source strategy or open source software policy.

Just about anyone these days will echo the comment, “Nothing is ever really, truly free anymore.” If you agree with this statement to some extent, the rest of this article will summarize a few key reasons why OpenLogic’s enterprise customers purchase (and continue to renew) a subscription for pre-paid support and/or consulting.

Confidence in the Support Provider Through Service Level Agreements (SLA’s)

The OpenLogic technical support team expertise has been built up over the last 11+ years to provide industry leading SLA’s that compliment both production and non-production environments.  It goes without saying that enterprises have their own in-house expertise in the form of DBA’s, system admins, architecture teams, etc. If open source software system set-up, configurations, troubleshooting, problem solving and issue resolution are 115% core competencies of the in-house experts, then it would be safe to rely on those team members. However, in a more realistic scenario, these are not 115% core competencies of an in-house team and a third party will eventually be required to help provide support. Ideally that third party would offer SLA’s with guaranteed response and resolution times like OpenLogic.

Choice and Flexibility

OpenLogic aggregates support on hundreds of different community versions of open source software products under a variety of SLA’s.   This depth of support available is (to the best of my knowledge) unmatched anywhere in the world. Enterprises that are just starting to use open source typically begin working with OpenLogic for support on one or two products and continue working with us because they have confidence we can help them develop a success strategy for other critical aspects of using open source. The OpenLogic Expert Community and Expert Partners provide an anonymous relationship for our customers to have a direct channel of commercial communication with top committers and contributors to the most widely used enterprise-grade open source products.

It’s Pre-Paid!

This one might sound like a stretch given the state of our global economy where budgets are extremely tight or in some cases completely frozen, but please bear with me. True story: I’m filling in for one of our technical experts on blogging duties this week because he’s booked on consulting engagements for two weeks straight.  A client of mine came to us recently with multiple mission-critical issues identified in a major open source product that were affecting its customers.  Realistically it takes some time to cross all the T’s and dot all the I’s in any legitimate support and services contract related to mission critical technology systems.  Had this client contacted us weeks, months, or years before the mission-critical failure to begin the contract revision process we could have been completing the diagnosis and resolution of the issue during the holiday weeks instead of pushing through last minute paperwork. Hindsight is obviously 20/20 and no one can accurately predict when a system will come crashing down in production, but if and when it does crash having a 24x7 SLA support contract backing up the open source environment ensures that an expert will be able to bring it back up very quickly! (Yes, even during the holidays).

The critical nature of open source software support doesn’t have time to wait for procurement cycles to complete.  The team here is backed by a global network of expertise – they are literally are some of the best in the world who write the code you are most likely already using. 

Hopefully this article and the growth of our new blog continues to dispel some of the remaining FUD (fear, uncertainty, doubt) in the industry and will show organizations there are very realistic alternatives to the status quo of only using open source based on availability of in-house expertise or a commercially available license for the product.  By forging long-term partnerships with OpenLogic, our customers save time and money (potentially lots of it depending on the size of an environment). In some cases we just might even help reduce the stress-level of the in-house system administrators and DBA’s day-to-day lives.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @JesseH303
View Jesse Hood's profile

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

Everybody wants an "Enterprise Cloud" these days, even if they work for a smaller business, but what exactly does that mean?  What is an enterprise cloud solution?

Here's a list of 5 key features to look for in a cloud solution that will help you decide if it's enterprise ready:

Choice

• Description: In the enterprise, there is never a one-size-fits-all solution.  For any problem.  Ever.  This is why nearly every large enterprise has one of everything.  They have applications running on multiple databases, operating systems, and programming languages.  Their developers run many different IDE's.  There's no reason to think the cloud space will be any different.

• Tip: The enterprise cloud solution you choose must support multiple deployment clouds, both public and private, as well as multiple programming languages, components, and stacks.  The one true deployment stack, programming language, or cloud today will only be one of several in a few years.  Embrace this diversity and use the right tool for each job.

Reusable Library

• Description: Once you have an application or stack tuned and ready to use on your cloud of choice, you need to have the ability to save it and share it with peers.  Once you find a shared stack, it's critical that you're able to modify it further in case your use case is slightly different from the original creator's.

• Tip: Your solution should have some private area for your company, departments, and individuals to save their stacks and applications.  It should be easy to share, modify, and reuse stacks on any cloud.

Cost Control

• Description: Nobody wants to get a huge public cloud bill out of the blue and have to explain it to their boss or Accounting.  Even private clouds are frequently using chargebacks (billed to your department) and showbacks (reports distributed to department heads - think "peer pressure") to keep particular apps and departments from hogging all the shared resources.

• Tip: Make sure your cloud solution helps you visualize spending across all clouds, public and private, and applications running on them.  Automated budget enforcement is even better.

Integrated Monitoring

• Description: If business users can't tell if their applications are up and running happily through a self-service web portal, they'll have to call IT to get the information they need.  At some point, they'll tire of this process and try to get around it by going elsewhere for their cloud solutions.

• Tip: An integrated monitoring and management solution, even if it's basic, brings business users closer to IT.  Make sure your cloud solution will let end users know how well their stacks and applications are doing through a simple web page.

Support

• Description: Over time, your company will undoubtedly deploy applications into multiple clouds.  You may start with a public cloud today and eventually use a private cloud, or vice versa.  You may change programming languages, application servers, or databases.  In any case, enterprises and their business users demand support at every level.

• Tip: Try to find support vendors that continue to help if you change stacks, components, programming languages, or clouds.

If your solution provides each of these key features, you're in good shape.  Your users won't feel locked in to any particular technology, yet they'll get the support they need to move forward quickly in an enterprise-friendly manner with appropriate controls.  Your enterprise cloud solution will make you and your internal customers happier and more productive in no time.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @CloudSwing

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

The location and amount of source code scanning and analysis an organization should expect to do when beginning a new initiative will likely have a direct correlation to establishing or revisiting a meaningful open source policy. Retroactively auditing for open source and analyzing licenses can quickly become a much more time and resource intensive task than expected for companies that are starting these projects in 2012, mainly due to large legacy code bases that have never been vetted for open source before.

This article includes a short description of how the individuals who are or will become members of an open source review board could start thinking strategically about a scanning project to maximize efficiency of limited resources. Ideally an open source policy takes into account the importance of ongoing and accurate provisioning of the code on the front end and uses regularly scheduled source code scanning to ensure the policy is being communicated effectively.

There are two likely approaches that different organizations could take when beginning source code scanning tasks. Not to say we should downplay the importance of provisioning; in fact, we should heighten the level of communication in the organization about the open source policy and continue to highlight the importance of the provisioning stage.  By doing this we have will have an accurate report to work off of as we continue the source code scanning initiatives.


The two main approaches can be described as the linear style for source code scans or the targeted approach for source code scans.

• The linear style has significant value to an organization that absolutely needs to create a full baseline inventory of all OSS used. The scanning and analysis goes project by project from start to finish through the source code of every distributed product line, production environment website, data center’s server infrastructure, individual workstations and other areas of possible usage to produce an organizational "map" of all the open source environment. This approach could take a while and could be expensive, but it will give an SVP of Legal and a CIO/CTO the confidence that they’ve vetted all of their legacy code for the presence of open source. The organization knows that this map of open source has a very high degree of accuracy.

• The targeted approach will produce a higher degree of meaningful information more efficiently based on some amount of pre-determined criteria. The criteria might be very obvious for a small organization; for example, if it only distributes a single product or product line. On the contrary, it could become extensive and very specific based on the size of the organization, its industry, its customers’ industry(s), the intended usage models of open source, etc. There may very well be some areas of open source usage that an in-depth analysis is not appropriate for and could actually be a lost expense for an organization to invest time and money into. The targeting approach does leave some holes in the organization’s "map" of open source that may eventually need to be filled. Obviously these two approaches do not need to be exclusive – we can always go back to fill some of the holes and complete the map later.

These questions might help an organization come up with some basic criteria to prioritize where and how much to scan, as well as determine if a targeted or linear approach (or both eventually) makes sense.

• Is there a timeline or deadline that needs to be met for generating some or all of the open source application audit reports?

• Does the deadline reflect some kind of organizational event? This event could be a product release or maybe a corporate divestiture in 2012

• Are there areas of the entire IT environment that present potentially higher exposure to a license violation?

• Are there specific licenses that present potentially higher concerns to the organization?

• Are there areas of “older” code bases that have never had a second, third, and fourth set of eyes look at them?

• Are there areas of more recently developed code that will be easier/faster to analyze? If the developers who worked on the projects are still around and can quickly answer questions about open source usage post-scan it really will help in achieving compliance

• Have we looked at the differences in size of code between the build environment and the run time environment?

• Does our policy specify if some open source is OK to use in a build environment but not in a run time environment?

• Is identifying older versions of open source products used in production environments going to be important to keep the environment updated, secured and as efficient as possible?

OpenLogic’s team of open source auditors and IP analysts spend all day, every day, (and sometimes all night) looking through source code and binary distributions to analyze the open source and other third-party components that organizations are using. While we are a pretty savvy group of experts, there are some things that we cannot decide for an organization when it comes to a source code scanning initiative -- but hopefully this article has gotten you thinking about where, how, when and why to get started.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @JesseH303
View Jesse Hood's profile

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

There are three main levels of cloud computing as pretty well defined across the industry.

On one end of the spectrum you have Infrastructure-as-a-Service (Iaas), which is the relatively straightforward rental of computing power, storage, and bandwidth. You control all, or nearly all, of the software that runs on your rented virtual machines.  This often includes an operating system in a virtualization environment and that can be in a public or private cloud.  In a public cloud we see examples like Amazon EC2 or Microsoft Azure. In the private cloud you might be using technologies from vendors like Eucalyptus or products like OpenStack.

On the other end is Software-as-a-Service (SaaS) where you pay on a monthly or yearly basis for web-based software. You usually don't know, or rarely care, how it's implemented, upgraded, or scaled; you have little or no control over the environment.  This is typically where we see deployment of web applications or  web services like Gmail or SalesForce.com.

In the middle is Platform-as-a-Service (PaaS).  Here vendors offer turnkey application deployment and scaling platforms. It also includes vendor services wrapped in easily accessible API's for storing data, sending messages and emails, delivering content through a distribution network (CDN), and other facilities. The idea here is that people aren’t provided with just the server and hardware but more of a platform that they can begin development on.  This broad area of the spectrum contains everything from Database-as-a-Service (DaaS) to Testing-as-a-Service (TaaS) to Security-as-a-Service.

One of the main benefits that people enjoy from PaaS solutions is the speed to market it provides.  Here you don’t have to worry about getting a platform in place, standardization, scaling, and keeping all of that up to date.  Instead you can begin building your application on top of that PaaS solution, resulting in faster time to market and increased productivity.


Here are 5 Keys to Look for, and Questions to Ask, When Examining an Open PaaS Solution:

Choice of Infrastructure
This is primarily the virtual hardware, the network, disk, etc.  Something you would typically expect from an IaaS vendor like Amazon EC2.  The idea of choice here means that you can click a button within the Open PaaS environment and be presented with the option to select which cloud you wish to deploy on.

Choice of Platforms
Ultimately this is the option to choose which application server, web server, languages and other technologies that you want to use in order to build your software stack.  You should be asking yourself, what are your limitations and potential restrictions you would encounter down the road?

Portability
This is the ability to not just be able to port your code over across clouds or across vendors, but also to be able to get your data in and out and not feel like you’re being held hostage to the platform provider in any number of ways.

Choice of Support
Here you want to understand whom you can go to when something goes wrong.  When you have a question, or when you want to talk about your use cases or get architectural advice, who do you go to? Do you have to go straight to your PaaS vendor at this point, or are there other options?  Can you get help from the community?   Who should you call and whom should you email?

Open Source Licensing
One of the most important parts of being open in this environment is access to the code, what you’re deploying, and how it works. This provides you with the transparency you’re looking for to see and understand the changes that are taking place.

Download the entire webinar presentation below, and learn more about selecting an Open PaaS Solution that is right for you.
Open PaaS as a Gateway to Cloud: Practical Advice for Choosing a PaaS Solution

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @AaronMandelbaum
View Aaron Mandelbaum's profile

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

Cloud technology is the next step in the evolution of predictable software engineering processes. With the cloud, servers become instant-on commodities. They are built the same way every time, providing consistency from the ground up. Servers instances are cheap and easy allowing each component of an application to be isolated to minimize conflicts. Instances are disposable, so there is no longer a need to worry about server drift. Just get a new one every time.

We can follow several recent advancements in software engineering processes that have been building on each other to see how this all fits together:

• Open source software provides quality, freely available building blocks to build applications around.

• Agile processes turn features into bite size stories that can deliver value rapidly.

• Repeatable builds, functional tests, and continuous integration turn quality control into a predictable, automatable procedure.

• Virtual machines give the ability to better utilize hardware and provide better isolation.

• Devops engages developers in how to build for a production environment and test that environment early and often.

Combining all of these things together can help create a streamlined software delivery process that gives confidence to release quickly.

Successfully utilizing cloud technologies definitely takes a shift in mindset. Engineers tend to be control freaks. I used to be the one cherishing every new piece of hardware. Carefully selecting every component that went into the box. Coddling those servers and tweaking every last setting to get it absolutely perfect. Shuddering at the thought of anyone else putting their hands on them and knowing each touch point meant an opportunity for the server to deviate from the plan. I've also looked at cloud options in the past thinking "That's not the OS I'd use" or "that version is not new enough".

But I've also been the one cursing dependency issues when running multiple apps on a single server at the same time. (What do you mean I can't have glibc 2.4 and 2.5 at the same time. I need both!) Ferreting out slight version differences in libraries between (Why does this work on my box but not yours?). Managing IPs, ports, and reverse proxy configurations to get the most out of each box.

Creating a cloud based development process, either for a public cloud (like Amazon or Rackspace) or for an internal enterprise cloud, has been like a breath of fresh air. I quickly get as many environments as I need, I get a fresh server exactly how I want it, every time.

Like clockwork. Predictable.

This is a central concept to what we are trying to accomplish with CloudSwing, Creating a system that enables users to deploy to the cloud with predictable, repeatable results that can help people realize the potential of the cloud.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
View Eric Weidner's profile

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