The Software Package Data Exchange (SPDX) standard is getting some love lately and this is good news for open source license compliance. Which is, in turn, good for open source in general. If you are involved in software license compliance activities you need to include SPDX in your plans for the future. It will allow you to manage the risks of software licensing in a more efficient and predictable way than ever before.

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
.

Cacti Makes Device Monitoring Simple

Every organization must monitor its infrastructure’s uptime and performance. While the popular Nagios application is a good general-purpose monitoring program that you can extend with plugins to handle just about any task, you may do even better by employing Cacti as a graphical front end to RRDTool‘s data logging and graphing functionality. Cacti was developed specifically to monitor and collect performance information, while Nagios is more oriented toward state changes, such as noting whether a daemon is up or down.

View the full article here

 

Build Cross-Platform GUI Applications With wxWidgets

If you develop GUI applications, you probably know what you want from a toolkit or framework. Chances are that the ability to build apps that run on multiple platforms is high on the list, along with ease of use and deployment. Those are among the strong points of wxWidgets, an open source library designed to make it easy to create cross-platform GUI applications.

View the full article here

 

ViewVC Helps CVS and SVN Go GUI

Almost everyone who works with version control systems (VCS) feels the need, sooner or later, for a graphical interface, because sometimes a GUI makes your life easier. ViewVC is a full-featured browser interface that’s portable as can be, given the design choice (web-based) and the programming language (Python). It was originally created for CVS users and later extended to support Subversion as well.

View the full article here

Using Nagios to Monitor Your Clusters' Health

The Nagios network monitoring and alerting framework lets you easily keep track of a wide variety of hosts and services, and generate reports and alerts targeted to specific teams or individuals. By using plugins, you can further enhance Nagios’s functionality, giving it capabilities not available in the core product. One such plugin lets you monitor the health of your cluster instead of that of individual hosts.

View the full article here

Must Know WordPress SEO Tricks

Many new WordPress users are under the impression that WordPress already takes care of search engine optimization (SEO) upon installation. However, the out-of-the-box WordPress installation that most people rely on doesn’t offer the best SEO results possible. If you want your WordPress sites to rank as highly as possible on search engine results pages, adopt the following techniques to enhance your sites’ placement in results from Google and other search engines.

View the full article here



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
.

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.

Release schedules, like everything else in software engineering, are always a trade off. The downside of rapid release cycles is that users have to deal with those releases. Dealing with any particular release is usually pretty easy, but dealing with all the releases of all your dependencies can be quite difficult. Our applications, for example, usually depend on a hundred or more individual open source components. I suspect that most projects have similar levels of open source dependency. Just keeping track of all the releases across a dependency set that large is difficult.

Just ignoring releases of the open source you depend on is a bad idea. (Though it is a pretty common approach to this issue.) Open source projects don't release just for the fun of it. When they release a new version there are usually very good reasons. Those reasons almost always include security, performance and productivity.

Security improvements

New releases of any software component are likely to include some security improvements. Open source components are no exception. Open source software is probably more secure, on the whole, than proprietary software, but that does not mean it's perfect. Most open source projects are quick to fix any security issues as soon as they are discovered. Dissemination of such fixes happen by releasing a new version of the component. If you are not using the latest release of a component, the version you are using probably has at least one known vulnerability.

Performance improvements

Open source software tends to get faster over time. Odds are that the most recent release of any open source component is faster than the one that came before it. If you are not using the newest version of a component you are missing out on that performance improvement. As we all know, speed is a feature. A very valuable feature.

Productivity improvements

Functionality improvements are easily the most common changes made to any software. Much more common than security fixes or performance improvements. This should not be surprising, developers write open source software because they want better tools. Your development teams could be writing better software and getting it done more quickly by using all the improvements being continually added to the open source you use. But only if you are staying up-to-date.

How to stay up-to-date

Now we get down to the nitty-gritty. I really wish I could tell you how to easily deal with new OSS releases, but I can't. Even here at OpenLogic staying up-to-date is a continual struggle. I do have a little bit of advice, though.

A stitch in time saves nine

Upgrade to each new release as soon as possible. It is always easier to upgrade one step at a time. If you don't stay on top of upgrading and miss a bunch of releases the upgrade process is bound to be painful. If you ever do fall behind, and you probably will, do the upgrades as soon as you notice, the problem will only get worse if you wait.

Notifcations

Find a way to get notified when new releases are shipped. Subscribe to the mailing list and create an email filter to flag release notices. Sign up for a release notification service like OpenUpdate. If the project has a blog, subscribe to it. Anything to increase the likelihood that you, or your team, will notice when a release is published.

Commit to staying up-to-date

If you are a manager make it clear to your development team(s) that you understand the importance of being up-to-date and make time in the schedule for those chores. If you are a developer educate your manager about the importance of keeping the open source you depend on up-to-date. Building a culture that values security, performance and productivity is the only way to ensure that your organization continually benefits from up-to-date open source dependencies.

Ask for advice

I said earlier that I did not have any silver bullets, but maybe you do? How does your organization deal with staying up-to-date and managing their open source? Have you tried something that works really well? Or things that failed miserably? If so I'd love to hear about it.

For the latest package versions, check out OLEX (OpenLogic Exchange), where we provide on-demand access to more than 330,000 open source packages, and over 500 of these open source packages have been certified by OpenLogic for use in the enterprise. The OpenLogic Certified Library is comprised of these certified open source packages. Every open source package included in the Certified Library is supported, indemnified, and maintained by OpenLogic.



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
.

Scanning software code bases to identify the presence, or verify the absence, of open source materials, the associated license information, and other third party components, is now a best practice for many corporate organizations.  More specifically, enterprises that are interested in achieving the goal of diligent license compliance practices, streamlined policy management, and a safe adoption strategy for open source software, have dedicated their resources to these projects.

Today’s article is a comparison of some of the pro’s and con’s involved in owning these initiatives 100% in-house or outsourcing some of the work to a company that has expertise in using source code scanning tools and analyzing open source license obligations.

The question of bringing and owning any new IT project initiative in-house vs. outsourcing the work to expert consultants is not a new one.  There are many different opinions and perspectives from IT industry blogs that provide some excellent considerations on the general decision of in-house vs. outsourced.  So I wont beat this one into the ground any more.  This article will bring an enterprise open source management perspective to the discussion and eventual decision that needs to be made about in-house code scanning or outsourced application audit report preparations.

The biggest consideration is most likely going to be tied to the organization’s industry and the frequency expected to complete these ongoing tasks.  For example a mobile device manufacturing company, ISV, or other technology company that has built their primary revenue generating activities around the commercial distribution of open source (or commercial products that contain open source) may choose to have the in-house solution that will eventually identify new open source components and policy violations on a daily basis.  After completing the base line scan of a product line, the scanning can be automated so that as new code is being introduced into their development life cycle the open source audit reports are updated accordingly.

Alternatively, an enterprise that uses open source for a variety of purposes but is not building the core of their business model around the distribution of open source might choose to outsource only 1 scan a year or more realistically 3 or 4 scans of a code base each year.  The target of the selected code base to be audited is covered in more detail in an article I wrote (Linear vs. Targeted: The Location and Amount of Source Code Scanning is Important) and the basic criteria might include only scanning the distributed product line(s), the acquisition (or divestiture) of any new software code, or simply a semi-annual inventory report to evaluate how the open source environment has changed over the last 3-6 months.

Another significant consideration that gets overlooked is the allocation of the human resource.  Someone will need to help prepare the applications that need to be scanned and either run the scanner and associated analysis themselves or prepare to ship the applications to a company like OpenLogic for analysis.  Depending on the size of the projects, size of the organization, and location of the code base, just preparing to do the scan, might be a significant undertaking.  There are some general open source provisioning strategies that can really help in preparing for a source code scan to make the project much easier and accurate.

Speaking of accuracy this leads me to my next consideration.

Our OSS Deep Discovery scanner has customizable settings that will produce different levels of granularity in the scan results.  Depending on what your ultimate goal is in completing a source code scan and open source application audit you may not need to open every single file to verify the presence or absence of open source or it might be critical to have the highest possible level of accuracy.  Out sourcing the work is going to achieve an extremely accurate result of an application audit report, so accurate that we offer limited indemnification to our clients to back up our professional services work.  Not to say that our clients who are running these projects entirely in-house can not achieve a similar level of accuracy and with our support and training on these tools you definitely can.

The final consideration I will mention is the amount of time expected and needed to complete the analysis after the scan is finished to prepare an open source application audit report.  This is one area that outsourcing the work can potentially help.  Unless an internal resource is already an expert in analyzing source code to accurately identify open source components they will probably need a solid 40 hour week or more of using a source code scanner to feel comfortable and confident in the work they are doing.

Every organization and usage of open source is unique so there is obviously no one right answer and the approach that seems to be the most popular for our clients is a combination of the two.  Many customers are deciding to outsource the “heavy lifting” to us first to complete their baseline scan of a product line(s) and then in years 2 and 3 are taking in-house ownership of the initiative to complete their delta scans on new product versions.

Regardless of how you approach the project, there are opportunities for you to leverage the tools, expertise, and resources needed to help you get the job done right!!



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
.

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.

Before you put an application in a public cloud, ask yourself the following 4 cloud app preparation questions:

Which cloud is best for my use case?

• IaaS providers give you nearly unlimited flexibility to run any software you like, but you're responsible for system administration

• PaaS providers typically restrict your access to software packages and versions, but remove most system administration duties

• Consider that hybrid approaches and "Open PaaS" solutions can give you flexibility while reducing administration hassles

How do I handle security?

• Top tier public cloud providers are experts at physical security in their data centers - don't worry about this type of security

• Data security:  encrypt data going to and from your application (e.g., HTTPS) and encrypt data at rest in your data stores

• Application security:  test your application against the common OWASP web application vulnerabilities manually and with tools

Who will monitor my application?

• If you choose an IaaS solution, consider monitoring tools like Nagios or Hyperic so you'll be notified if something goes wrong

• With a PaaS solution, your vendor will likely provide various levels of monitoring and alerting

• Whichever type of cloud you choose, be sure to monitor the application (e.g., response times, slow queries) as well as the system (e.g., CPU, memory, network, and disk)
  

• Finally, monitoring cloud costs is important because it can be very easy to run up your bill to unexpected levels if you're auto scaling or running lots of tests, especially integration and load tests

Where do I get support for my stack?

• If you deploy commercial software, you'll need to carefully count license usage to be assured of getting vendor support.  Some licensing agreements will limit you to a number of concurrent instances, which can change rapidly in a public cloud if you're automatically scaling up and down to meet demand.  Other components may have licenses tied to IP addresses.  Still others may charge by the hour.  This can get complicated quickly if you have a mix of software using different measurement criteria.

• If you're using open source tools, the license counting issues go away.  However, you'll need to find one or more vendors to help with development and 24x7 production support on all the critical components you're deploying to the cloud.

After you've answered all these questions to your satisfaction, you're ready to experiment with deploying your first cloud app.  As with any new technology, I highly recommend you start small and grow from there.  Choose a test application that is not mission critical.  This is especially important while you're getting up to speed with public clouds because your application may not yet be "designed for failure".  But that's a topic for another post.



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 literally is a gold mine for enterprises in 2012+ and as the amount of choices increase exponentially so does the need for a provisioning strategy.

Webster’s basic definition for provisioning is to supply someone or something with provisions.  Thanks Webster, I can always count on you to cut to the chase.  Since we are not really writing about supplying food, water or clothing rations I had to find a more appropriate and up to date definition.

This one from webopedia describes provisioning as: The process of providing users with access to data and technology resources. The term typically is used in reference to enterprise-level resource management.

That's pretty good, but let's dig a bit further into the nature of open source to consider the implications of effectively and safely provisioning it for an enterprise.  Three of the largest open source repositories in the world publish the following data about the amount of code available:

• Sourceforge.net  - 324,000 unique OSS projects with over 4 million downloads each day

• Github.com – Hosts over 2 million different repositories with over a million end users contributing to the active development of OSS

• Googlecode – Hosts over 250,000 different OSS projects

That’s a whole lot of open source, and these are just three major repositories.  What about the seemingly infinite amount of other community sites, individual authors hosting their own projects, or corporate sponsored websites that exist to download open source from?  It's a daunting task to even consider how to efficiently and safely provision from that much code let alone do it in compliment to a corporate policy.

By establishing some general provisioning criteria and minimum requirements, that the development communities and their open source products have to meet, enterprises can start to narrow down the choices to some very meaningful selections.

An even more progressive open source provisioning strategy might state the following:

• Open source community projects must be vetted, determined to be safe, and valuable by the enterprise open source review board before the download can be considered.

• End users and developers must first explore and consider existing internal code repositories before considering external acquisition of new open source products or versions.

• The origin of download for any new open source product must be directly from the project homepage hosted by the original authors/community.

• End users and developers must record the point of origin and date associated with the download if there is not an open source management system in place that automatically tracks the information for them.

Understanding the point of origin when downloading open source is critical to mitigate for potential unknown modifications in the code, unknown changes in license type, the potential for virus, trojans or malware, or intentionally placed malicious code.  These potential concerns are rare but the fact is they do exist and the implications of one mistake could be costly.  Some enterprises have taken this strategy a step further and regularly empower developers with the knowledge of why using specific open source libraries and repositories may be a very good idea while simultaneously cautioning teams as to why others may not be acceptable.

The OLEX repository has completed much of this initial legwork by providing a centralized repository that already includes a high level evaluation of open source communities and license types.  Much like the regularly scheduled safety inspection on your car OLEX includes a 42-point certification criteria process that is completed before any code can be provisioned from the repository.

Mature open source policies include an assigned internal risk rating of open source products, pre-approved package and license types, prohibited licenses or packages, enterprise architecture team preferences, open source review board recommendations, and pre-configured stacks that developers might want to consider first before building their own from scratch.  All of these ideas build off of understanding and realizing the value and importance of accurate, efficient, and safe provisioning practices.   In some of my previous articles I’ve described how provisioning strategies and regular use of scanning tools are a really great compliment to a successful long-term open source software strategy.

Now its reader poll time: If you were part of (or if you are part of) an open source software review board for your company what rating on a scale of 1-10 (10 being top priority) would you give to the provisioning phase for the ongoing adoption of open source software?



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
.