• Because you had to use up all that juicy hardware that it took you so many months to provision.
• Because it was hard to configure and manage physical machines, so you wanted to concentrate them to make it easier for system administrators to manage.
• Because you did your best to standardize entire stacks so your J2EE applications could run in harmony in a single WebLogic instance (ha!).
• Because it was the cool thing to do.

In the cloud, it’s easy to provision new servers. The means you can run each application (or just part of an application) on its own server. Why?

• You don’t have to wait months for IT to give you a machine.
• You’ve bought into the DevOps movement and have lots of automation to help install, configure, integrate, and test your stacks and applications, so it’s not a big deal to spin up a new instance.
• You’re comfortable using the best tool for the job, which means you frequently deploy components written in Java, Ruby, and JavaScript.
• You use a combination of SQL and NoSQL data stores, such as MySQL, PostgreSQL, Redis, memcached, CouchDB, and HBase.
• You want to avoid dependency conflicts.

That’s a nice list of reasons, but I see you’re not convinced. Let’s look at the really compelling reasons to separate your apps.

• It’s easier to scale applications running on their own instances. You don’t have to worry about dragging along Application B with its measly 1,000 hits per month when you need to scale out Application A getting 1,000 hits per second.
• Some applications don’t scale as well as others. What if Application B won’t even scale beyond a single instance? Load balancing it along with Application A might break it badly.
• Independent applications are safer. If all your apps are on the same instances and those instances go down, you lose all your apps at once. That’s not good for SLA’s and uptime measurements. It’s better to spread out your risk across instances and even clouds.
• Isolated apps are easier to manage. When you need to apply an operating system patch required for Application A, do you really want to test Application B to make sure it won’t cause a problem? And what happens if there’s a dependency conflict?
• It’s simpler to test isolated apps. In your QA environment, it’s incredibly convenient to fire up new instances, test them, and blow them away when you’re finished. If your applications are mixed, you need to test Application A in context with a fully configured production version of Application B to make sure there aren’t unintended side effects related to forcing them to co-habitate.

Once you’re on board with this line of reasoning, it’s easy to see why many cloud savvy technologists also deploy key stack components on their own instances, isolated from the rest of the application. For example, you could place your application server on one instance, your caching server on another, and your various SQL and NoSQL data stores on still other instances. With this arrangement, you can easily deploy, upgrade, scale, test, and monitor each tier independently of the others. Yes, it’s more work when you’re just getting started so I don’t recommend you do all this work right away. Instead, wait until you’re done with your basic application development and have stabilized your stack components and versions somewhat. At that point, you can decide whether you believe your application needs to be exploded either for extreme scalability purposes or for the reasons outlined above. If so, break up your application into the appropriate number of pieces.

Whether or not you choose to spread your application stack across server instances, I highly recommend you put no more than one application per cloud server unless you have special circumstances in play. For example, if you value performance far more than scalability, you might want to collocate applications that communicate frequently to avoid network overhead. In most cases, you’ll be better off splitting them up.

With one application per cloud server, it’s easier to develop, test, deploy, upgrade, scale, monitor, and manage your software. This best practice in the cloud will pay for itself 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
.

Most open source auditing engagements are completed in the context of scanning a code base of a product line to confirm that a company has appropriately separated their intellectual property from the third party components.  When third party components are used and distributed all licenses for these components need to be identified and there needs to be confirmation that appropriate license compliance steps have been taken.  OpenLogic’s Application Audit and Certification of Compliance services are one solution to consider when outsourcing to a team of experts as these are a full report of all materials, licenses, and a re-verification of compliance steps being completed.

Dependency Scanning Use Case

Depending on the industry and level of maturity of the open source policy management process, a more granular level of scanning may be needed.   Open source packages often bundle other open source software within the larger or parent project.  Some companies want to know not just which open source projects are included in their code, but also identify and then associate the sub-components or dependencies to a parent project.  Open source communities come in all shapes and sizes with varying degrees of attention to the issue of documenting dependencies.  In fact not all open source communities that build and maintain projects accurately disclose and update the dependent libraries that the project uses.  There may have been significant changes from version to version resulting in an old and previously accurate list of dependencies being partially incorrect in the newest versions. Consequently, what was once a pre-approved version of an open source project to use in a distributed code base, could easily be a policy violation and potential license violation in that next version.

If you are familiar with OSS development and license types a single file can make a very big difference.  For example, in one of our scans the OpenLogic audit and IP analysis team actually found a license conflict between source code components in an open source project.  We contacted the community to inform them of the conflict as they were not even aware this conflict existed.  The community acknowledged someone had in fact contributed code that created this conflict and the community did the right thing for their end users by removing the conflicting code and replacing it.

If you scan and analyze the open source software project code directly, you can then determine all the dependencies that are used by the specific version.  For example, if an organization’s states that the most recent version of Zlib must be used, then this organization would complete a scan to find out if anything has changed from version to version.  As a result, the organization can then confidently make the statement to customers, investors, acquiring companies, etc. “Yes we ship the Zlib library with our product, we always ship the most recent version of Zlib, and we can tell you exactly what Zlib is using in the newest version.  Would you like to see it?”  Then obviously the company would introduce the most recent Zlib Bill of Materials and Licenses to the audience.

The OSS Deep Discovery scanning tool has a customizable setting for this exact situation thus reducing the number of false positives found in the initial results.  In other words, by adjusting the settings accordingly, the scanner will identify all the components inside of Zlib instead of simply reporting that you have matches to Zlib.

The real world example for this level of diligence goes back to having and managing an actionable open source policy.  Open source review boards that have monthly, bi -monthly, weekly, or even impromptu daily meetings about what can and cannot be used and under what conditions need the ability to quickly identify and document these occurrences, make decisions, implement critical policy rule changes and communicate all of this easily to the organization.  One new or changed file can make a big difference in protecting millions of dollars of development and intellectual property.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing
Follow @JesseH303
View Jesse Hood’s profile

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

One theme involved the idea that open source license compliance is not a legal problem, but an engineering and software problem. Discussions around SPDX touched upon this; specifically, that compliance in the supply chain must begin with creating a bill of materials that can be read and understood upstream and down. In order to create such a bill of materials, the work must be done before the product enters the supply chain, ideally during the development process. Those doing license enforcement discussed how the most common non-compliance scenario entails a failure to provide the correct corresponding source code – be it incomplete, the wrong version, or source code that doesn’t match the distributed binary. Again, this information is best tracked early on, not after the fact. This is not to blame developers, but highlights the reality that processes to prevent or address compliance from the get-go are often lacking.

The other theme I heard in a variety of forms had to do with education. The best development processes are useless if training is lacking, not grounded in a practical rationale, or not backed by management. Of course, before we can talk about the quality of education, this presumes there is a policy to train employees on. Not so much, as it turns out research by Gartner showed that in spite of widespread adoption of open source software, most organizations lack an open source policy or framework. Meanwhile, at universities and other educational institutions, computer science students are steeped in the use of open source software, but are not getting any training on licensing issues.

This led me to think. If good compliance habits begin at the development stage; yet developers are not really getting educated on best practices until working in a company that provides such education; and the percentage of companies that institute open source policies trails behind open source software use, then we are left with a big gap in terms of dealing with compliance before it becomes an issue. What steps can we, as individuals, take in the meantime? If I could have the undivided attention of developers, what lessons have I observed as an attorney that I would I pass along about using or creating open source software? What could developers begin doing right now?

Here are three simple, yet crucial things that can be done regardless of whether your company has yet to implement an open source policy:

1) Do NOT strip out license notices, copyright notices, or any other such information.

I know, this sounds like stating the obvious, but it happens. The thing is, someone wrote that code, someone perhaps a lot like you. They deserve credit, they chose a particular license for a reason, that’s why they included such notices. If they chose an open source license, they have given you some broad rights for using their software, so you have no reason to obfuscate where it came from or, worse yet, pass it off as your own. Stripping out this information also makes it very difficult for anyone else who uses that code to understand who the copyright owner is and what license it is released under.

If you are creating an open source project, then this tip becomes: include a copyright and license notice in your code. Preferably in each file. This does not need to be extensive and you can refer to the license text elsewhere if you want to save space, but be clear. You may not care so much about which license your code is under, but if that code achieves widespread use, the people using it will care and they will want to do the right thing according to your wishes, so make it easy for them to do so.

2) If you are using only part of a file or package or modifying it, keep the notices with the code.

This is a really a variation on the first point, but takes it a step further. For example, say you want to use one portion of a file that is licensed under BSD. You may take that portion and insert it into the file you are writing, but you still must comply with the BSD license, namely by retaining the license text and the copyright notice. The best way to do this would be to include a notice stating that this file contains some code by the original author and the BSD license in the same place that you put your own copyright notice and licensing information. Conversely, say you have modified the original BSD file. Add a notice along with the author’s copyright and license notice stating so. Yes, I know, BSD does not require notice of modifications and maybe you don’t care about having attribution for your contribution, but wouldn’t it be useful to track that information for your internal reference? And if you were a person using that file down the road, wouldn’t it be helpful from a development standpoint to know how it differs from the original file?

3) Determine what the license is, really.

You are in a hurry. You go to Google Code and download a project that is exactly what you are looking for. Google Code says it’s under MIT which you know is a permissive license. ‘Great,’ you think. Not so fast. Sometimes Google Code, SourceForge, GitHub, etc. are wrong. In fact, sometimes the project’s own website contradicts what is found in the code. It only takes a few minutes longer to look inside the files and check the actual license contained with the code. If it doesn’t match the license stated on the website (especially if it is the project-maintained website), then you will want to make a note of this or even contact the project authors if the contradiction is stark. If you end up having to do a little research, record your findings in a way so that you or someone else can retrace those steps. Trust me, you won’t remember and that website, that version, or even that project may not be available still later when someone else wants to know.

At this point, a developer reading this might challenge back as to why she should take the time and initiative to do these things if it’s not required? The thing is, good compliance efforts align with good engineering habits. If you don’t believe me, listen to what OpenLogic director of engineering and co-founder, Eric Weidner, had to say on this topic. In the big scheme of things, a small amount of time in the development process can go a long way on a number of fronts.

What other tips would you add here?

Subscribe to The Enterprise Open Source Blog via email

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

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

Cloud technology is evolving faster than we can read about it. Marketplaces are now part of our common vernacular.  The ever changing world that we live in and these advancements in technology are providing the open source software community with infinite opportunities to showcase creativity to the world.

I have highlighted three of the more recognizable, and recently launched marketplaces, that speak to this opportunistic time for open source software contributors and users.

Amazon Web Services (AWS) Marketplace

On April 19th, Amazon announced the launch of their Amazon Web Services (AWS) Marketplace.  The announcement was heralded by many in the cloud technology and open source software arenas, as a giant step for “cloud-kind.”  ZDNet, an extremely popular tech-blog, referenced the recent AWS Marketplace launch in an article titled, “Amazon Launches AWS Marketplace as One-Stop Cloud Shop.”  Hitting the nail on the head with that reference, the marketplace provides a unique opportunity where customers can “check-out” right from the AWS Marketplace platform with pre-configured stacks and software as well as a variety of services, right in their own personal shopping cart.  The marketplace also integrates with the AWS cloud, which allows for purchase and deployment of your technology without ever leaving the platform.

Salesforce.com AppExchange

Another pioneer in the growth of marketplaces, SalesForce.com, announced the launch of their marketplace, AppExchange, last November, and then almost immediately announced that their AppExchange had gone mobile.  The mobile announcement provided Salesforce.com users with a single location to enhance their experience by incorporating the availability of mobile apps to eliminate most plausible obstacles to accessing their data.

The AppExchange provides partners with the opportunity to develop apps with the “social, mobile, open and trusted capabilities” of Force.com, Salesforce.com’s social enterprise platform.  Salesforce.com’s AppExchange provides users with easy mobile access to critical data and contributors with the opportunity to distribute apps to over one million users on AppExchange. This in turn fosters creativity and forward thinking by providing developers with an opportunity to decrease the time spent on building customized apps for their company’s needs.

The AppExchange marketplace offers several free open source applications such as the HTML5 Contact Viewer and Salesforce Viewer for iPad.

With so much discussion around marketplaces and the value they’re providing to the open source community, I thought it would make sense to hear first hand from one that just celebrated its first birthday!

HubSpot App Marketplace

HubSpot, a Cambridge, Massachusetts based marketing software company, launched their own HubSpot App Marketplace in April of 2011.  The marketplace currently has 54 apps available and serves over 6500 customers.  After being founded in 2006 by two former MIT students, (Brian Halligan and Dharmesh Shah) and receiving over $65 million in funding from sources like Google Ventures and Salesforce.com over the last 5+ years, HubSpot has become arguably the leading SaaS marketing solution available at this time.

Arjun Moorthy, Vice President Business Development and Partner Products at HubSpot, and closely involved in the success of the HubSpot App Marketplace, was kind enough to spend some time sharing his thoughts on marketplaces, success, open source software, and beyond.

Please feel free to add your own answers in the comments section below!

Q:  What do you think has been the biggest software related factor contributing to the growth and success of your marketplace?

A:  Growth has come largely from a very low barrier to develop apps on the platform and also provides customers an easy way to install and use those apps.

Q:  With the announcement of Amazon AWS Marketplace and marketplaces popping up with great frequency, what do you think has been the biggest reason for this expansion?

A:  The iPhone has made the metaphor for app purchases become mainstream.  It no longer seems technical but actually consumer-friendly.  So now other software vendors have followed suit and are doing their own app marketplaces.

Q:  In your mind, what makes for a successful marketplace?

A:
1.Easy to create apps
2.Easy to adopt and use apps (one-click install, integrated billing)
3.Clear support
4.High quality apps to seed the market
5.Quality controls to maintain sanity of marketplace

Q:  Can you speculate as to where you see marketplaces evolving to?

A:  In the business world, marketplaces may coalesce around verticals and/or functional lines.  So, marketers will have a marketplace for their needs, finance professionals may have theirs, people who work in healthcare may have theirs etc.

Q:  In your opinion, what has the evolution of marketplaces done for open source software?

A:  Many marketplaces (iOS App Store, Google Play, Facebook Application Directory) thrive because of the perception that a single developer or small team can quickly develop an app that has immediate access to a high-interest user base.  That quick development relies almost completely on open source development frameworks, tools and technologies to come together.

Q: How do you think open source software has contributed to the growth and evolution of marketplaces?

A:  The impact of the large availability of high quality tools for development can’t be overstated.  The total cost of development to put together an “app” is in most cases a trivial amount beyond the time of those involved.

Arjun provided some great insight and details that appear to highlight the similar common denominators existing in each of these three successful marketplaces.  There seems to be one common implied value that these successful marketplaces offer to us: they make our lives easier.  Somehow, someway, to whichever audience they have chosen to serve, the ease of use, the low barrier to entry, or the tasks they simplify, it all makes our lives easier and to me, seems to be the fundamental formula of a successful marketplace.

How would you answer these same questions?

OpenLogic is very proud to announce that we were included in the launch of the Amazon AWS Marketplace.  You can view all of our open source software products and solutions here, and be sure to check out our fully flexible PaaS solution, CloudSwing, to deploy your apps to the cloud in minutes and also choose a support option that fits your open source software needs.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing
Follow @AaronMandelbaum

View Aaron Mandelbaum’s profile

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

.

Now, your head is spinning too.  Take a deep breath and let me explain the answers to those questions.

What if it breaks?  Who is on the hook at 2am?
Purchasing SLA technical support from a third party vendor means that if you have problems or something breaks you can call them.  Most production support provides a 1 hour response time and a 72 hour work around time, even at 2am.

Is it secure?
Open Source Software isn’t any less secure than commercial software.  In fact because it is open and has more eyes on it at any given time, security vulnerabilities can be caught much sooner.  Our support team also routinely looks at each package we support and cross references it with the National Security Vulnerabilities Database.  We know the same day that a vulnerability is found and notify our customers.

Is it as good as commercial software?
If you mean is the technology as advanced?  The answer is often that it is more advanced.  Open Source Software communities don’t rest on their laurels.  They are constantly writing code to enhance their project.  They track and fix bugs.  With the increased number of eyes on a package, development happens quickly.  And since OSS communities are a meritocracy you can rest assured that individuals who are contributing and committing code are top notch developers!

What about indemnification?
This will vary by vendor.  Some vendors don’t offer indemnification and many others do.

Now what are you waiting for?  Tell your manager you want to use OSS in production and tuck a copy of this blog in your back pocket to answer all of the questions before they’re even asked.

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
.

Licensing Often Sets Expectations

Few companies purchase commercial software solutions without also purchasing ongoing support, but the dynamic is often markedly different for open source. Open source software is of course different from commercial software in some very significant ways — free to download and try, often introduced to the organization bottom-up rather than top-down, typically easier to customize, and so on – and these differences clearly play into perceptions about open source support.

When a commercial software solution is purchased, there’s typically a willingness to pay an annual maintenance fee in order to protect the initial investment in the software. Take away the up-front investment in licensing, and the perceived importance of investing in support services often goes away as well. In other words, the licensing can set expectations about other costs associated with the software, such as support.

A quick look at Google’s global monthly search statistics confirms that the number of people looking for open source downloads by far outnumbers those looking for support, consulting, or training services for that software.

The True Cost of Free

Let’s be clear about one thing: open source isn’t exactly free. Sure, you can download it and try it out without paying a licensing fee, but a variety of other expenses can come into play throughout the life of the software. You’ve probably heard this before, but it bears repeating: open source is free as in puppies, not free as in beer.

Just like commercial and even proprietary software solutions, open source software requires personnel to configure and maintain it. Those employees may require training on new versions, or you may hire new personnel who need to be trained. Consulting services might be needed to assist with migrations and special projects. And last but not least, commercial open source support might be required to help resolve problems and keep critical systems up and running. In this regard, open source is no different from any other type of software.

Now, none of this will come as a surprise to most CTOs, but I’ll wager that many still perceive open source as somehow different from commercial software. “Sure, I realize that there will be costs associated with open source over time,” one might say, “but we’ll cross that bridge when we come to it.” In other words, we’ll wait until the want becomes a need.

Evaluating Needs vs. Wants

As I mentioned at the top, not all organizations view open source support as a want. Indeed, some of the world’s leading companies have firm policies that all software used in the enterprise — including open source — must be backed by technical support. What drives companies to take this approach? I believe there are several best practices common to these organizations:

• Software is software: Companies that view open source support as a need do so because they treat all software the same regardless of the source. Whether open source, commercial, or proprietary, these companies have a policy that all software must be approved for use and supported. These companies also strive to ensure compliance with open source licenses.
• Low risk profile: Should a serious issue arise, these companies want to ensure that help is just a phone call away. Support can certainly be purchased on short notice, but what happens if a critical system breaks after hours or on a holiday? Even if a problem happens on a Monday morning, can management and procurement approve the purchase quickly enough to avoid serious repercussions? Companies with a low risk profile address these questions by securing open source support ahead of time.
• Access to the community: Most open source support providers employ or contract with members of the open source community, so a commercial support contract can connect a company to the community that actually develops the software. This can be critical when it comes to fixing bugs, suggesting new features, or committing your own changes and enhancements back to the open source project.

Summary

Whether you view open source support as a want or need likely depends on many different factors. The amount of open source software used in your organization as well as how that software is used undoubtedly factors into the equation, and there may be other considerations beyond the best practices I highlighted above. How do you view open source support and other costs associated with open source? Have your views changed as your organization has increased open source usage in recent years, and do you expect any changes in your viewpoint in the near future?

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
.

SPDX defines a standard way to represent the contents and licensing of software packages. This standard representation provides a shared vocabulary for tools involved in managing license compliance. The SPDX standard is being developed under the auspices of The Linux Foundation as a way to ease complying with the licenses of open source software. The model provided by SPDX is fully compatible with proprietary software licensing also. This means that SPDX provides a uniform way to represent the licensing of any software package. Being able to treat both open source and commercial software the same way allows license compliance processes and tools to be simplified and streamlined.

Reuse

A key value to SPDX is the reuse it can facilitate. Once a package has been analyzed, an SPDX file can be saved containing that information. The next time that package is encountered, rather than redoing the analysis, the previously saved SPDX file can be used. The shared vocabulary provided by SPDX means that other tools, organizations and people will be able to understand the information. This sharing could be purely internal if your organization maintains a library of SPDX files for packages it has seen in the past. Or the sharing could even be across multiple organizations if, for example, the supplier of a package could provide SPDX files to purchasers so that they know how to comply with the licensing of that component. You could even get SPDX data for open source packages from an independent third party. We recently published SPDX files for six popular open source packages. That data is free for anyone to use. Feel free to download and use them to streamline your license compliance process.

Another level of reuse supported by SPDX is the license list. This list is a curated set of common open source licenses. The list exists primarily so that an SPDX consumer can be sure they know what it means when an SPDX file states that a package is licensed under, for example, the GPL version 2. Licenses on the list are given a unique, permanent short name and a permanent URI. These identifiers provide a way to communicate about which licenses are used by a package in an unambiguous way. The license list also indicates when it exists in other license lists. This can be helpful working with legacy data, or communities that maintain their own license lists. Using the license list as your primary repository of license info is often a simple, highly effective, way to utilize the value of the SPDX standard.

Automation

The automation potential of SPDX is the aspect I find most compelling. I am a software developer so that is not particularly surprising. The superb machine processability of SPDX data opens the door to huge improvements in license compliance processes. Imagine being able to amalgamate various existing SPDX files for libraries you use, spot check them for correctness, then run a scanner on your code and merge that information into the SPDX data and then feed that into a tool that gave you a simple checklist of things to do before shipping your software. Now imagine being able to do that with minimal manual effort. That is the promise of SPDX. All of the tools you use speaking the same language so that you can easily integrate the best tools available, whether they are open source, commercial or custom built. With SPDX 1.0 we have the technology we need to facilitate that dream. Already most vendors in the license compliance space support SPDX. The SPDX working group also provides a great set of open source tools for working with SPDX data. This means that we can start automating and streamlining the compliance process today.

Future proofing

Vendor neutrality is another important feature of SPDX. This is important regardless of whether you use bespoke tools, the tools of a single vendor, mix and match tools created by various vendors or don’t use any tools at all. The shared vocabulary provided by SPDX means that you are never locked in to a particular tool. If you find a new tool to improve your compliance efforts you can take all the data you already have and import it, or take it’s output and use that data with your existing tools. Even if you currently have a completely manual process SPDX still has potential benefits. Using the open source tools provided by the SPDX working group today means that you can easily move to a more automated process in the future with minimal effort. The freedom provided by SPDX is hugely valuable.

As you can see SPDX is a giant leap forward for license compliance. It provides capabilities for improving the quality and reducing the difficultly of license compliance efforts. These benefits come from the ability to reuse previously completed work, automating the process more aggressively and avoiding vendor lock-in. At OpenLogic we are strong supporters of the SPDX effort, both by contributing significantly to its development and by supporting SPDX data directly in our scanning and compliance tools and services. Improving open source license compliance is better for everyone and SPDX provides a real way to achieve that goal today.

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
.

Enterprise developers interested in learning how they can quickly and easily deploy to the cloud can see OpenLogic’s video “OpenLogic CloudSwing Demo: Your App. Any Stack. Any Cloud: https://bitly.com/CloudSwingPaaS.”

AWS Marketplace is a new online store where customers searching for business and development software can find, compare, and immediately start using software in the Amazon Web Services cloud.

“We are excited to be among the first participants of the AWS Marketplace,” said Rod Cope, CTO and Founder of OpenLogic. “OpenLogic is uniquely positioned to offer easily deployable open source stacks and full enterprise grade support for both fixed and custom built stacks in the cloud.”

OpenLogic’s products available in the new AWS Marketplace provide:

• Stack flexibility: OpenLogic will provide pre-configured stacks including LAMP, Nginx, Tomcat, Node.js and Rails and custom stacks using OpenLogic CloudSwing. CloudSwing enables users to quickly and easily deploy either pre-built or customized technology stacks in the Amazon cloud and track associated costs of the deployment.
• Enterprise grade security: All stacks pre-configured with security best practices.
• Enterprise support: Commercial grade support including business hour or 24×7 with response time commitments as low as one hour.
• Flexible pricing: For a flat monthly fee, OpenLogic customers get unlimited support incidents on all of the components in the open source stack. There are also free options for customers who do not need support.

To view OpenLogic products and services available in the AWS Marketplace, please visit:

http://www.bit.ly/openlogicAWSMarketplace.

About OpenLogic

OpenLogic is a leading provider of enterprise open source solutions for the cloud and the data center.  OpenLogic helps hundreds of leading enterprises across a wide range of industries to safely acquire, support, and control open source software.  OpenLogic offers certification, commercial-grade technical support and indemnification for over 650 open source packages backed by the OpenLogic Expert Community.  OpenLogic also offers CloudSwing, a complete open PaaS solution for enterprises seeking to deploy applications and customized open source stacks in the cloud, and OLEX Enterprise Edition, a SaaS solution for open source scanning and governance.

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 Management: Dealing with New OSS Releases

The first quarter of this year has be a busy time in open source management. JBoss has had two releases in the 7.1 series, the Apache web server has had two releases in the 2.4 series and Ruby on Rails has had two releases in the 3.2 series just to name a few. This may sound like a flurry of new releases, but is really par for the course. In the open source world releases happen all the time. Most open source projects take the release early, release often motto to heart. And for good reason too, it results in better software.

Read the full article

Apache HTTP Server: New Features for Version 2.4

The Apache Foundation released Apache HTTP Server 2.2.0 at the end of 2005. Now 7 years later there is a new major release of Apache HTTP Server. Apache HTTP Server currently has  65% market share according to Netcraft. There has always been two competitors in the web space – Apache and IIS – but in late 2007 Nginx was born and has been grabbing more and more market share everyday. Looking at the release notes for Apache 2.4 you can see that this release has a few features that match Nginx’s feature set. Apache HTTP 2.4 has included something for everyone: performance increases; lower memory usage; new modules; program enhancements and new features for old modules.

Read the full article

Cloud Technology, Big Data & Hadoop

Big Data seems to be the word of the year.  Everywhere you look there is Big Data staring you in the face: Blogs dedicated to discussing Big Data; LinkedIn groups with over 10,000 members focusing on Big Data topics.  Just under 15,000 times each month, the exact phrase Big Data, is entered into the search engines of people across the world.

Read the full article

Preparing for Your First Cloud App

There’s a lot of confusion out there around the so-called “cloud app”.  What is it, just another term for “SaaS”?  Or does it refer to running your own application in a public cloud?  As with many phrases that include the ubiquitous word “cloud”, it can mean just about anything.  In the context of this post, “cloud app” refers to an application you’re running in a public cloud, such as Amazon AWS or Rackspace Cloud.

Read the full article

5 Ways an Open Source Governance Process Can Improve Your Organization

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. Likewise if you have a governance process that’s outdated, incomplete, or inconsistently implemented throughout the organization.

Read the full article

Follow @openlogic
Follow @cloudswing

Subscribe to The Enterprise Open Source Blog by Email

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

In OpenLogic Exchange Enterprise Edition (OLEX), we have analyzed several hundred open source licenses and created a list of high-level obligations for each license. For example, in OLEX the Apache License 2.0 list of obligations looks like this:

• Distribute copy of license
• Give notice of or fulfill other requirements related to modified files
• Obligation to include notice text or files
• Obligation to include copyright or trademark notice
• Obligation to indemnify contributors
• Obligation to apply license to original or derivative works
• Restrictions regarding use of trademark
• Termination of patent license upon filing of patent litigation

If you don’t have the luxury of an OLEX Enterprise Edition subscription, you will want to take a similar approach and summarize the list of obligations in easily digestible “chunks.” This will make it easier for the team to take steps to comply with the various licenses used.

Next you want to examine under what conditions you need to meet certain obligations. For example, the requirement to supply documentation about modifications to open source are only triggered when you modify the code. By creating a set of triggers tied to your list of obligations you can quickly determine if you need to take steps or not.

You can then use these sets of triggers to ask your development team how they are using the open source in your product. Once you have their answers in hand, you can begin to eliminate the obligations you don’t need to meet which in turn helps keep the list manageable.

Some common triggers include: distribution, modification of source and creation of derivative works via linking. So for example, you can confirm that open source found in your source files is indeed distributed with your product or not. It is surprising how many files that contain open source in your source tree actually don’t get distributed with the final product. Or, if your code links to an open source library, how so? Dynamically or statically? The answer to these questions allows you to pick the relevant obligations.

Once you understand your list of high-level obligations by license and when those obligations are triggered you can begin to build your checklist. When we build compliance checklists for our customers we build the list by obligation type and license, then also list the responsible packages. For example if we identify a modification requirement in a license, we list the products that have been modified (down to the file level), so that we can later verify modification requirements have been met.

Finally, once you have your checklist in place you can work with your various functional teams to verify that all physical steps have been take to comply. Has your documentation group updated the product documentation to include the appropriate trademark, copyright and attribution requirements? CHECK. Has your development team met all modification documentation requirements and made sure they didn’t remove any copyright statements? CHECK. Has your legal team reviewed your product EULA agreement to make sure it doesn’t conflict with any of the open source licenses and are they fully aware of any restriction on use and have agreed that your organization can meet these restrictions? CHECK. If you need to provide source code via physical medium or hosted download site, is your organization prepared to fulfill requests? CHECK.

The process of license compliance is not trivial but by taking advantage of license categorization, high-level lists of obligations and triggers, you can make the process manageable.

I invite you to comment and provide insights on how your organization complies with open source licenses. If you are interested in learning more about OLEX or services provided by OpenLogic can assist you in your compliance, please feel free to contact us at sales@openlogic.com.

Follow @openlogic
Follow @cloudswing

Subscribe to The Enterprise Open Source Blog by Email

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