Subscribe by Email

Your email:

Connect With Us!

Current Articles | RSS Feed RSS Feed

FOSS Knowledge, Part 3: Reaching the goal

  
  
  

In my last two posts, I discussed the evolution of open source knowledge: where we came from, where are we now, and how did we get here. I provided some examples of common misunderstandings and knowledge gaps and suggested that such gaps may be due to the need to take action without taking as much time to prepare and plan as is optimal.  The sum total is that misconceptions and misunderstandings about open source persist both within and outside the software industry.

Open Source Software Bill of Materials, What are They Good For?

  
  
  

What is an open source software (OSS) bill of materials (BOM)? In the simplest terms, it is a list of the OSS components used in an application. But, it can actually be much more. Most OSS BOMs will, at a minimum, also contain the licensing information associated with each OSS component.

Do You Hear What I Hear?

  
  
  

I am asked two very reasonable questions, on a very regular basis, by some very interesting people.

Tips and Tricks to Choosing Open Source Software for Business Use

  
  
  

As a developer I'm always keeping my eye out for new technologies that can help me do my job better or faster. There's a saying in this industry: "work smarter, not harder." If I can use a piece of existing code instead of writing it from scratch, I will, unless there's a good reason not to. And diving into a new language, library, framework, or database can be like wearing a brand new pair of jeans. The novelty is exciting.

Open Source Code Scanning with “Noise Reduction” & Multiple Matching Techniques

  
  
  

Commercial source code scanning tools have become quite the hot topic for CIO’s, software development managers, in-house counsel, and enterprise architecture teams over the last eight to ten years.   The emergence of these new technologies obviously has direct correlation to the maturity of open source software, which is now just as common as commercially-licensed software in medium to large enterprise data centers.  Additionally, the distribution of open source into the consumer market is undeniable making source code scanning a critical risk mitigation measure for all companies that are buying or selling modern technology.  Today’s article will briefly explain “noise reduction” and the process of using multiple matching techniques in a source code scanning tool.

What Would I Tell Developers About Using Open Source Software?

  
  
  

In the first two weeks of April, I attended four distinct open source related events in three different cities and two countries. It will take months to ponder, absorb, and follow-up on all of the thought-provoking presentations, conversations, and feedback I participated in or received. In spite of the range of topics and agendas being covered along the way, there were a couple themes that reverberated.

Why You Should be Using SPDX for Open Source License Compliance

  
  
  

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




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

Open Source Software Management: A Recap of the Top Articles

  
  
  

 

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 DataLinkedIn 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






Subscribe to The Enterprise Open Source Blog by Email

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

Building the Business Case for Open Source Code Scanning

  
  
  

I often talk to people who are having a hard time developing the business case for purchasing and implementing a source code scanning tool or purchasing an application audit service.  I respond by describing  that a legitimate and successful business case in 2012 needs to include the following:

    • At minimum, a general understanding of the basics of open source software

    • Both the want and need to find and implement a solution

    • The organizational drivers and resources to develop a solution to a problem or to enhance and compliment an existing system that lacks efficiency or accuracy

    • Cross-functional approvals and resources from multiple departments

    • Accurate and balanced vendor evaluation and selection criteria


Hopefully some of the ideas in this article will resonate to help all of you continue building the business case as you consider how or when to start a scanning and license compliance initiative.

I’m going to start with the “want to” - a company that understands that complying with all licenses for third party code it uses, including open source software, is the right thing to do.  Yet, that company may not have the resources or urgency to make the purchase and implement a plan.  As a result, the “want to” is always harder to sell on than “need to.”

Complying with open source licenses, as requested by the original authors of open source projects, is the responsible approach to using other people’s software.  To quote a colleague of mine on our engineering team, “it’s generally frowned upon to use someone else’s software code without proper attributions.”  Scanning software code is now a pretty important part of ongoing compliance strategies for organizations.  Those that understand this and appreciate the hard work of others want to comply, and are complying, to the best of their ability.

The founding ideology of this industry still exists today for good reason and the organizations in North America and Europe that are interested in ensuring license compliance are doing so to keep open source alive and healthy.  In fact one could present numerous arguments and examples to support the fact that our day-to-day lives now rely on open source software.  Consumer products like smart phones, newer cars, flat screen TV’s, most computers, all ISP’s, probably any cloud computing environment, maybe even a brand new waffle maker, all have open source software embedded in them.  Those open source software components are most likely, if not definitely, being re-used by the company distributing it in their products.  The reality is that if any company intends to keep using open source and selling technology, that has been created because of the history of the open source industry, then respecting the terms of open source licenses is just as important as respecting any commercial software license.

The “need to” category represents potential business risks that turn the "want" into an immediate need.  Below are several examples as to why an organization needs to implement an open source scanning solution:

    • The organization understands and values all of the reasons included in the “want to” category and realizes that every day that passes without implementing some kind of process to proactively vet code bases for open source is increasing the exposure and risk of a “want to” turning into a “need to immediately.”  The final outcome of some of these projects might identify a very low level of risk and exposure.  Nevertheless, not actively addressing this potential (in order to determine risk) is a very dangerous approach to the use of open source software.


    • There is a product road map or technology release schedule for the organization that has made an intentional  (or unintentional) decision, to distribute open source software in a commercial product or to use open source in a customer facing web site.

    • The organization has been contacted by one of the governing bodies that are interested in enforcing license compliance -or- the individual author of an open source product has contacted the organization directly to inquire about the usage of their copyrighted software.  If this kind of inquiry goes unanswered the worst-case scenario is a suit eventually getting brought against the organization(s) in question for violating the license or copyright.

    • There is a merger and acquisition (or divestiture) planned sometime in the calendar year and the assets to be acquired (or sold) have a known or high probability of including open source components.

    • There has been significant turnover in the personnel that have been involved in the use of open source and collecting any voluntary information about the usage and associated licenses would be impossible.

    • The organization outsources software development to a third party and:

        • The third party either disclaims any OSS usage but wont rep and warrant it in a contract (HUGE RED FLAG)

        • The third party discloses some amount of OSS usage but can not easily and quickly produce a list of components

        • The third party discloses OSS usage and delivers a bill of materials and associated licenses but the nature of the transaction(s) and distribution require additional due diligence.

        • The third party unknowingly includes open source in the product they develop.




The thing is, your company may not "need to" right now, but is it worth waiting until there is an urgent reason and scrambling to find a solution?  The best business case is the case that includes a proactive approach, instead of reactive.

A few other considerations are included in my older blog articles and if there are other valuable reasons that our audience “wants to” or “needs to” start scanning source code to identify the open source please engage in a discussion on the forum below!



Subscribe to The Enterprise Open Source Blog via email




View Jesse Hood's profile

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

Open Source License Compliance in the Cloud

  
  
  

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.





Subscribe to The Enterprise Open Source Blog by Email

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

Enterprise OSS Blog Policy

If you read a post on The Enterprise OSS Blog, please leave a comment. Let us know what you think, even if it's just a few words. Comments do not require approval, but they are moderated.OpenLogic reserves the right to remove any comments it deems inappropriate.

 

Contact Us

Browse by Tag