Critical parts of your business's infrastructure depend on open source software. If you don't believe me, go find a worker bee in your IT department and ask them. Go ahead, I'll wait. You need a plan for how to handle problems with that software. Open source software is unfairly reliable but even the best systems will have problems occasionally. In this article we'll go over some things that will help you get the most of out the open source communities that develop and support the software you use.

Join the community before you need help

You'll get better results if you are a active member of the community. It is human nature to expend more effort helping members of the group. If someone at your organization has helped others in the community solve their problems the community will repay you for that when you need help. Active involvement shows that you are interested in helping the community succeed. Once you have shown an interest in the success of the community, the community will respond with particular zeal to your calls for help.

This involvement does not need to difficult or time consuming. Just answering the occasion newbie question on the mailing list is usually more than sufficient. You just want to raise awareness that you are interested in, and capable of, helping the community succeed. Your involvement does need to be on going, though. The good will you generate by participating has a limited shelf life.

Do your homework

Before crying wolf, research, and try to fix, the problem on your own. Google the error message or a description of the problem you are seeing. Read the project FAQ. Search the mailing list archives and forums for others who have experienced the same, or similar, problem and actually read the threads you find.

Once you have exhausted Google, FAQs and mailing list archives, spend a little time characterizing the problem you are experiencing. Does the problem always occur or only in some situations? If the tool has logs, do they contain interesting output? Can you turn on some additional logging/tracing? What does your deployment look like? Has anything about your usage of the software changed recently?

The quality of the responses you get from the community will be directly related to the quality of the information you give them. Remember that the community will only know what you tell them. The more information you provide, the more they will be able to help you, and they really want to help you.

Be respectful

You are thinking, "what kind of jerk would publicly disrespect a bunch of people he is asking for help?" The answer is usually just a normal, reasonable person in a tough spot. It is harder than you'd expect to remain respectful when critical stuff is broken and your boss is breathing down your neck to get it fixed. It is easy to let your stress affect your interactions with the community you are asking for help. So easy, in fact, that it will happen by default if you don't actively choose to be respectful.

If you are polite and respectful you will get what you need. However, remember that most of the people who inhabit mailing lists and forums are doing it for free. They usually have day jobs, families, etc. so they may take a little time to respond to your pleas. They want their community to succeed -- which means they want you to succeed -- so they will do their absolute best to help but sometimes life will intrude.

Being respectful mostly means doing your homework so as to not waste the communities valuable time; actually trying any potential solutions that are proposed; and, probably most importantly, avoiding any implication that the community owes you something. Nobody like a brat with a sense of entitlement, and you want people to like you when you are asking for help.

Don't forget to say thanks

Once you get the solution to your problem -- and you will get a solution -- be sure to let the team that helped you know it worked and tell them thanks. Of course, actions speak louder than words. Becoming an active member of any community that helps you is the best thanks. That is how open source software grows and gets better.

Another great way to say thanks it to evangelize projects that have great communities. That helps both users and outstanding communities.

Conclusion

If you follow the steps above you will get mind-blowingly great support from open source communities. Much better than you'd ever get from a proprietary software vendor. The superiority of support provided by open source communities is one important reason our support offerings are so valuable.

We use our relationships with enterprises and open source communities to serve both better. To the benefit of the open source communities, we handle a lot of simple questions without distracting the community from their valuable work. Our ongoing close relationships with enterprises allows us to understand their individual IT infrastructures and cultures more deeply than an open source community could. That knowledge allows us to rapidly access the community to solve even the hardest problems with few false starts or dead ends. This also means less distraction for the community, which in turn means we all get more and better open source software.



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 use of open source software enables application developers to build better applications more efficiently and cost effectively. Yet, open source license compliance in the app store setting can be a bit puzzling.

About a year and a half ago, there was a stir when GNU Go was removed by Apple from its App Store. The game, licensed under the GNU General Public License version 2 (GPL v2), was available for download on the App Store. The Free Software Foundation (FSF) contacted Apple and the developer who submitted the game to the App Store regarding non-compliance with the GPL v2, noting that the developer failed to provide the source code and Apple was in violation of the license as well. The FSF also provided a public explanation of its stance on its blog. Apple unceremoniously pulled the game from the App Store, thus eliminating the question of non-compliance. The focus of the discussion centered around restrictive terms in the App Store terms of service that conflicted with the GPL v2, section 6 which prohibits any further restrictions on the rights granted by the GPL v2 to recipient of the software.

What fascinated me about this controversy was the lack of focus on the other key requirements of the license. Afterall, every non-compliance action I'd heard of to date had involved the failure to provide the source code. If Apple had yielded to the FSF and revised its App Store terms of service to include an open source software license carveout thus remedying the restrictive clauses conflict, would that have fully satisfied the FSF?

While we don't know the answer to that question, we can think about what would happen if the App Store, or any app store for that matter, is considered to be distributing the applications that are provided on its market. (It is possible that the app store's relationship - either legally or contractually or both - with the developer as that of an agent only, but we'll save that analysis for another post.) And why is this question important? Distribution triggers the compliance requirements of most open source licenses. In other words, the app store would be responsible for compliance for any open source software licenses included in the applications available in its market. A copyright holder might sue the app store for direct infringement, as well as contributory infringement for the developer's non-compliance.

Either way, the next question in the legal analysis is whether the app store qualifies as an online service provider under the Digital Millennium Copyright Act (DMCA). Actually, a court may answer this question first as a matter or practicality.[1] The DMCA limits liability of online service providers for infringing material provided to the service by its users (i.e. app developers here) so long as the provider meets certain conditions. Whether an app store can be considered under the DMCA definition of an online service provider has yet to be tested, but it seems likely given the trend of caselaw that has held such vendors as Amazon and YouTube to qualify.

Assuming the app store falls under the domain of the DMCA protection, the app store would then have to show that: 1) it does not have knowledge of the infringing material or if it does have knowledge, it act expeditiously to remove the infringing material; 2) it does not receive any financial benefit directly attributable to the infringing activity; and 3) it responded expeditiously to remove the infringing material after receiving statute-conforming notice from the copyright holder.[2] "Knowledge" in the first prong can be actual knowledge or an awareness of facts or circumstances from which infringement is apparent.[3] It is this latter scenario that is one of the crux issues in the Viacom v. YouTube case. There, the district court explained that general knowledge was not enough to rise to this threshold, stating that, "[t]o let knowledge of a generalized practice of infringement in the industry, or of a proclivity of users to post infringing materials, imposes responsibility on service providers to discover which of their users' postings infringe a copyright would contravene the structure and operation of the DMCA."[4] As applied here, general knowledge that open source software is often used in mobile applications and non-compliance can be an issue is not enough. However, given the DMCA conditions, it makes sense that Apple would "takedown" the infringing application once notified.

In practical reality, if adoption of the code and license compliance is the goal of an open source software copyright holder (which is usually the case), then the DMCA doesn't really help. If the app store doesn't know non-compliant open source software is present in the applications developers provide, then it escapes liability. If the app store becomes aware of non-compliance open source software present in the applications it distributes, then the DMCA encourages removal of the offending application.

Meanwhile, app stores, application developers, and end-users all benefit from open source software being present in applications.  App stores benefit by having higher quality and cheaper applications to provide, sell, and advertise on their market.

Yet, the nature of the app store combined with the current legal construct results in little incentive to correct non-compliance. Practically speaking, it's tacit non-compliance by the app store or removal of the application. And what about the developer's responsibility to comply when "distributing" the application to the app store? Does the lack of (publicly visible) compliance enforcement in this space mean the open source community has acquiesced to this reality? Why should app stores, application developers, and end-users benefit so greatly from the use of open source software in applications in the absence of open source license compliance?



Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing
Follow @jilaynelovejoy
View Jilayne Lovejoy's profile

[1] See Corbis Corp. v. Amazon.com, Inc., 351 F.Supp. 2d 1090, 1098 (2004).
[2] 17 U.S.C. § 512(c)(1).
[3] 17 U.S.C. § 512 (c)(1)(A).
[4] Viacom Intern. Inc. v. YouTube, Inc., 718 F.Supp.2d 514 (S.D.N.Y. 2010).

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

In Jilayne Lovejoy's recent blog entitled Open Source License Interpretation Made Easy she examines a method for interpreting open source licenses based on viewing licensing terms as a series of "if-then" statements. In this blog I'd like to take a look at providing you with a handy method to categorize terms of use into groups to further help simplify the compliance process.

A few years ago I wrote an article in Wazi on Comparing Open Source Licenses. In that article I provided a short introduction, then gave links to a few tables showing a comparison of common open source licenses. Here is closer look at the contents of those tables and how you can use that information to help you in your open source license compliance efforts.

Obviously, not all open source licenses terms of use will fall into just a few simple categories, but we have found that there is definitely a pattern to most open source licenses. By using the following list you can quickly identify and comply with common requirements, then focus your efforts on the more arcane requirements, like purchasing a book if you use the product for commercial purposes or buying the author a beer if you see him at a conference.

Here are the basic categories we found common to most open source licenses:

1. Notice and Attribution Obligations

a. General Compliance Obligations
These are things like: you can use the software as long as you meet the following requirements...

b. Location of Notice Requirements
I love it when the author tells me specifically where I have to include attributions, like in my documentation, or in a Notice file accompanying the software. If the license says you must provide attribution but doesn't say how, then I suggest you create a convention for your organization than enforce it. For example, always include a 3rd-party attribution file somewhere users can easily access and read.

c. Copyright Notices
These are generally terms about not modifying or removing copyright notices. Sometimes they may ask you to add specific copyrights to your documentations.

d. Warranty Disclaimer Notice
Most open source licenses disclaim warranty and offer their software to you "as-is." Make sure you review these so you are not caught off guard by unusual disclaimers in case of a dispute.

e. Attributions
Like the "location of requirements" obligation, this section tells you who (author, organization, etc.) you need to mention or give attribution to in order to comply.

f. Modifications
These requirements tell you what you have to do if you make modification to the original code.

g. Specific Obligations
While these might be covered under the more general categories they may contain special conditions, like if you advertise the use of this product you have to place specific attribution text in your advertising materials.Look for specific obligations that fall out of the normal categories.

2. Restrictions

a. Endorsement
Many licenses restrict you from using the name of author or organization as an endorsement just because you include their software in your product.

b. Product Naming
Like endorsement requirements, many licenses restrict you from using the author, organization or project name in your product name.

c. Other
As you review licenses look for terms of use that expressly prohibit you from using the product in a specific way. Make sure you are aware of these restrictions to avoid potential violations.

3. Termination

Under what conditions is termination allowed or invoked? Familiarize yourself with these to make sure you don’t find yourself in a situation in the future that could trigger termination. Such a violation could cause you to lose your right to continue to distribute your product.

4. "Copyleft"-ness

The term "copyleft" is generally defined by terms of use that require you to distribute source code and/or retain any derivative work under the original license. Various licenses have different degrees of" copyleft"-ness. For example, some may only require you to distribute source code if the original code is modified while others may always require it. Familiarize yourself with terms that require derivative works to be licensed under the original license only or that have any requirement to supply source code as these are some of the most enforced infringements to date.

5. Application Instructions

Some licenses contain sections to help you with compliance by providing sample attribution text or instructions on how to comply. Look for these types of terms usually listed near the end of the actual license text or in a separate README, COPYING or LICENSE file distributed with the open source software.

6. Define Terms

Many open source license are not written by lawyers and consequently do not always define key terms used in the license. If the open source licenses you encounter happen to have a terms definition section take time to understand how the various terms are used in the context of the license.

By categorizing license terms of use into these categories hopefully you can simplify the compliance process. We use these basic categories to help us to build compliance checklists for internal compliance efforts and when providing open source auditing services for our customers.

Have you seen other categories that you use to help you with compliance? I would love your comments and thoughts. Please post your comments below.



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
.

Cloud computing has forever changed enterprise IT. As enterprises turn to the cloud, they find open source software plays a central role in cloud-based services and in the infrastructure of the cloud itself. The use of open source in the cloud brings with it questions and challenges in the area of open source license compliance – many not raised by traditional uses of open source.

We're hosting a free webinar today in which Jason Haislmaier, Partner at Bryan Cave HRO and adjunct professor at the University of Colorado School of Law, will discuss the impact of cloud computing on open source license compliance. Topics to be covered include:

• Where is open source used in the cloud (and where is it likely to appear)?


• What is the current landscape of open source licensing in the cloud?


• How does the cloud change the notion of software "distribution" (and what does this mean for open source licenses)?


• What are the major differences between open source compliance in the cloud vs. traditional computing models?


• What questions should you be asking when deploying open source to the cloud?

Reserve your seat for this informative discussion or download the webinar recording and slides from our corporate website approximately 24 hours after the webinar.



Follow @openlogic
Follow @gbellcolorado
Subscribe to The Enterprise Open Source Blog by Email

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

One thing I look at for when looking at cloud computing services and Platform as a Service (PaaS) offerings is how I could apply their features to applications I've developed in the past.  This gives me a good guide for the types of architectures I'm likely to work with in the future.  Most of the applications I've been involved with have been complex in nature with moving parts that often don't fit into many PaaS offerings.  Very few have been applications that fit neatly into a PaaS box.

Cloud technology is often associated with flexibility as instant-on servers can enable developers an unlimited supply of servers to deploy code.  PaaS is really about convenience and potential productivity.  The potential productivity comes from getting your developers to work in the boundaries defined by the platform, and reducing the number of decisions that may need to be made.  It provides these benefits at the expense of choice.  This is certainly not a new decision for software engineers to make.  Every software project is continuous stream of decisions to "buy" or "build".  It's one of the things that makes the open source community so compelling.  Of course building can give all the flexibility to make code that does exactly what is needed exactly the way the engineers intend, but there are often many choices of libraries and applications that can do the job.  It's only a matter of deciding which application's boundaries can be lived with.

In the current platform as a service landscape, there are a only a few players in many different technology spaces.  With only a few choices, it's important to evaluate each service to know what types of applications are possible and what concessions will need to be made to develop for the platform.

With CloudSwing, we've built upon our past experience building enterprise applications for many different industries and listened to our enterprise customers tell us what features they needed in a flexible cloud platform.  We've built in features to allow users to customize their own platforms and save them for continued use later.  This provides the ability to make the choices that best fit the needs of the application.  This is the foundation of an Open PaaS.

How well do your applications fit the current PaaS offerings?

 



Subscribe to The Enterprise Open Source Blog by Email

Follow @openlogic
Follow @cloudswing
Follow @esweid01



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

The vast majority of enterprises use open source software as a significant and growing part of their IT portfolio.  And most enterprises work with one or more open source vendors to get commercial grade open source support for the open source software they use. In order to select the right open source support vendor, it’s important to understand their business model and how that model impacts you.

The 4 most common types of open source software support models and the implications for enterprises:

1. Pure Open Source: Sell Support and Services

           Examples: Drupal, OpenLogic

           Lock-in: None

Vendors with this type of business model provide support and services for software that is offered under an open source license.  The vendors may focus on a single open source project (e.g. Drupal) or provide support services for many open source projects (e.g. OpenLogic).  Because the open source software is freely available under an open source license, you are not locked in to the vendor.  There is nothing that prevents you from deciding later that you want to self-support or choose another vendor, you don’t need to worry about switching out the open source software.  This approach gives you the most flexibility.

2. Certified Distribution Model: Sell Subscriptions, Tools and Support

            Examples: Red Hat, CloudEra

            Lock-in: Some

Vendors with this type of business model take an open source project and do additional testing, certification or bundling.  Red Hat Enterprise Linux is the most well-known version of this model.  In the process of “certifiying” a release, the vendor may select or create patches and fixes.  This “certified version” is then branded (e.g. RHEL, Cloudera Distribution of Hadoop) and you are charged for some combination of subscription to this branded, certified release, support and add-on tools or services (e.g. Red Hat Network, CloudEra Manager). In this case, there is some degree of lock-in.  First, if you don’t renew your subscription, you may be required to remove branding, switch off the certified version or stop using the add on tools or services.  While this may be possible, it may require some effort on your part or require you to give up some functionality.  As a result, there is some degree of lock-in associated with these models.

3. Open Core Model: Sell Subscriptions for a Proprietary Version

           Examples: EnterpriseDB, Alfresco

           Lock-in: Same as proprietary software

Vendors with this type of business model take an open source project and create a separate version with additional functionality that is provided under a proprietary license.  Often these vendors will only offer support if you use the proprietary version.  When you purchase this version, you have the same degree of lock-in that you would have with a proprietary vendor.  If you no longer purchase the subscription, you can’t get support.  If you want to revert to the open source version of the code, you will need to rip out the proprietary version and make sure you don’t need any of the proprietary features.

4. Dual License Model: Sell Open Source Software Under a Proprietary License

           Examples: MySQL

           Lock-in: Can cause lock-in depending on license requirements

Vendors with this type of business model take an open source project and offer it under two licenses – an open source license (often GPL) and a commercial license.  If you don’t want to use the project under the open source license (for example when you want to redistribute), then you purchase a subscription for the commercial license.   You can still go back to the open source version later, but you will then be required to use the open source license.  If that license is not compatible with your use case, it may be difficult to change to the open source version.  One of the other challenges of this model is that a vendor must own all of the copyrights in the project in order to be able to offer it under a non-open license.  This means that either employees of the vendor must write all of the code, or any outside contributors must sign a contributor agreement that enables the company to put the code under a commercial license.  This has the practical effect of limiting the number of outside contributions to the code, and as a result, you lose the benefit of community development that is often associated with open source projects.

In order to make the best selection, it is important to make sure you understand the business model of any vendor you are considering.  You can then use the business model information as well as the requirements of your particular use case to narrow down your options and make the appropriate choice.



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
.

Your company is actively using open source software, and you’ve realized that an open source governance program is essential to managing the adoption and use of open source. You’ve developed an open source policy and implemented key components of best-in-class governance programs such as an open source request-and-approvals process, source code scanning before distribution, and perhaps even an Open Source Review Board (OSRB). Your engineers are happily (and safely) using open source, corporate counsel nods approvingly every time you pass in the hall, and you’re just about to put your feet up for a well-deserved break when it hits you – you don’t yet have an enterprise-wide governance training program in place.

Well, fret not. In this post I’ll walk you through the process of developing and implementing a training program that will get everyone in the enterprise – current employees, future employees, and outside suppliers – on the same page when it comes to open source governance. I’ll also give you a sample training course curriculum to get you started with developing governance training courses within your organization.

Segmenting Training Topics

The first step in developing your open source governance training program is outlining the topics to cover for different audiences within your organization. The introductory course should be appropriate (and required) for all employees in the business unit, while more advanced courses should be geared just towards engineering, legal, and business personnel who work directly with open source software within the company. Depending on your company’s goals and open source usage model, there may be different tracks (legal vs. technical) and gradations (intermediate vs. advanced) above the introductory course, or a general advanced course may work perfectly well for employees in different roles. However, if your company incorporates technology components from third-party suppliers, a separate course will likely be necessary for procurement personnel and outside suppliers.

It’s important to be as comprehensive as possible and avoid assumptions about what current or future employees know. You may have to endure some eye rolling when you ask engineers to attend the introductory open source governance course, but it’s an opportunity to level-set employees’ expectations and understanding of open source usage within the company (which very well may differ from division to division). In addition, it gives your company’s open source experts an opportunity to showcase their knowledge, answer questions from other employees, raise issues that need to be addressed, and provide valuable input on the training course itself.

Developing Course Outlines

Now that you’ve sketched out the topics that need to be covered for particular audiences, it’s time to create a first draft of your training course outlines. Try to involve key stakeholders in this process –- ideally, representatives from engineering, legal, procurement, the OSRB, and any other essential business units.  You may need these folks to present different sections of the training course, so you may as well get them involved up-front.

Some of the topics your introductory training outline should cover include:

• Open source basics: what it is and how it’s different from commercial software

• How and why our company uses open source

• Our company’s policies about open source usage

• Introduction to our OSRB

Some of the topics your advanced training outline should cover include:

• Common open source licenses and how to read a license

• Which open source licenses are acceptable for use within our company

• Common open source license obligations and how we fulfill them

• How to bring open source software into our company

• How to prepare source code deliverables

• How to work with the open source community

Some of the topics your training outline for suppliers and procurement should cover include:

• Acceptable open source licenses for inbound software

• How to deliver software to our company

• Contractual rep and warranty requirements

• Source code scanning requirements

• Introduction to our OSRB

For more detailed outlines of the topics you should consider including in your governance training courses, check out the Sample Open Source Training Courses document on our website.

Training Frequency

Naturally, the frequency of your governance training courses should be driven by factors such as head count, employee turnover, segmentation of course material (introductory vs. advanced courses), and the locations of personnel who need to attend. The frequency of updates to your open source policy and governance processes, as well as significant changes in company’s product offerings or open source usage model, may also impact the course schedule or necessitate retraining.

I recommend leveraging web conferencing tools and recording your training sessions in order to reduce the workload and accommodate employees with different schedules and locations. Try making recordings of your training sessions available on the company intranet, and work with the HR department to incorporate a requirement for “virtual attendance” of training classes into the new employee onboarding process.

Summary

As I discussed in my last post, an enterprise open source governance process can help your organization responsibly increase open source usage, improve employee morale and public relations, reduce legal risks, and improve budget and resource planning. But as with any business process, your open source governance process is only as effective as its implementation. An ongoing training program can help ensure that your open source governance process is consistently followed and maintained so that these important benefits don’t diminish over time.



Follow @openlogic
Follow @gbellcolorado
Subscribe to The Enterprise Open Source Blog by Email

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

Cloud solutions and the term flexible seem to be joined at the hip with each new article, offering, and solution we see.  Despite the repetition of the term, the inference of flexibility is not always clear nor is it well defined.

When evaluating the flexibility of a PaaS solution, and how that fits with your current environment, be sure to look past "now" and examine what the horizon might hold for you and your organization.  Being locked into the wrong cloud solution can limit the options you will have to choose from in the future, if the flexibility of the solution you pick doesn't match those eventual needs.

Examine the 5 C's of flexibility before choosing a flexible cloud solution:

Customizable PaaS:

PaaS offerings can enable you to quickly and easily deploy applications into the cloud by leveraging a standard, pre-built technology stack. However, most PaaS solutions don’t give you the ability to pick and choose your own technology components and versions to fit your specific requirements.

Look for a PaaS platform that is completely customizable to your needs. Flexibility here will allow you to start with a pre-built platform, and then tailor the technology stack to your needs by adding or removing components and changing versions. Be sure that you have the flexibility to add your own code, blend proprietary software with open source, or create your own stack from scratch.

Compatibility:

Ensure that the cloud-based platforms you are evaluating fulfill the technical requirements of your applications and conform to your corporate architecture standards. You need to be able to pick and choose the components, versions, and patches that have been vetted by your technical experts, ensuring that your applications are supportable and secure.  Once you’ve customized your technology components look for a fully flexible cloud solution that allows your team to share them with others on your team or in your company, giving your developers instant access to approved technology stacks that meet your enterprise needs.

If you are migrating existing applications from your data center into the cloud, you'll need to be able to match the specific components that are already being used and avoid porting efforts that can be associated with a fixed PaaS option.

Cost Management:

Cloud based solutions promise lower cost infrastructure options, but you can’t manage your costs unless you can measure your costs.  A fully flexible PaaS cloud solution will provide the cost management capabilities that let you see your spend across multiple clouds and multiple accounts.  With developers and business units often using credit cards to procure cloud resources, it’s difficult to track costs and meet budgets. Ideally you should look for a solution where you can register all of your accounts across all of your cloud providers, and then have real-time visibility into your spend.