Posts

The following is adapted from Open Source Compliance in the Enterprise by Ibrahim Haddad, PhD.

Companies or organizations that don’t have a strong open source compliance program often suffer from errors and limitations in processes throughout the software development cycle that can lead to open source compliance failures.

The previous article in this series covered common intellectual property failures. This time, we’ll discuss the four common open source license compliance failures and how to avoid them.

License compliance problems are typically less damaging than intellectual property problems, as they don’t have the side effect of forcing you to release your proprietary source code under an open source license. But license compliance failures may still have serious consequences including:

  • An injunction preventing a company from shipping a product until source code is released.

  • Support or customer service headaches as a result of version mismatches (as a result of people calling or emailing the support hotline and inquiring about source code releases).

  • Embarrassment and/or bad publicity with customers and open source community.

4 Common OS License Compliance Failures

Problem #1: Failure to publish or make available source code packages as part of meeting license obligations

How to avoid it: Follow a detailed compliance checklist to ensure that all compliance action items have been completed when a given product, application, or software stack is released into the market.

Problem #2: Failure to provide correct version of the source code corresponding to the shipped binaries.

How to avoid it: Add a verification step into the compliance process to ensure that you’re publishing the version of source code that exactly corresponds to the distributed binary version.

Problem #3: Failure to release modifications that were introduced to the open source software being incorporated into the shipping product.

How to avoid it:

  • Use a bill of material (BOM) difference tool that allows the identification of software components that change across releases

  • Re-introduce the newer version of the software component in the compliance process

  • Add the “compute diffs” of any modified source code (eligible for open source distribution) to the checklist item before releasing open source used in the product.

Problem #4: Failure to mark open source code that has been changed or to include a description of the changes.

How to avoid it:

  • Add source code marking as checklist item before releasing source code to ensure you flag all the source code introduced to the original copy you downloaded

  • Conduct source code inspections before releasing the source code

  • Add a milestone in the compliance process to verify modified source code has been marked as such

  • Offer training to staff to ensure they update the change logs of source code files as part of the development process.

The most important outcome of non-compliance cases has been that the companies involved ultimately had to comply with the terms of the license(s) in question, and the costs of addressing the problem after the fact has categorically exceeded those of basic compliance.

Therefore, it is really a smart idea to ensure compliance before a product ships or a service launches. In part 6 of this series, we’ll cover some of the top lessons learned in achieving open source compliance that open source professionals need to know.

Download the free e-book, Open Source Compliance in the Enterprise, for a complete guide to creating compliance processes and policies for your organization.

Read the other articles in this series:

An Introduction to Open Source Compliance in the Enterprise

Open Compliance in the Enterprise: Why Have an Open Source Compliance Program?

Open Source Compliance in the Enterprise: Benefits and Risks

3 Common Open Source IP Compliance Failures and How to Avoid Them

4 Common Open Source License Compliance Failures and How to Avoid Them

Top Lessons For Open Source Pros From License Compliance Failures

With 2016 behind us, we can reflect on a landmark year where open source migrated up the stack. As a result a new breed of open service orchestration projects were announced, including ECOMP, OSM, OpenBaton, and The Linux Foundation  project OPEN-O, among them. While the scope varies between orchestrating Virtualized Network Functions (VNFs) in a Cloud Data Center, and more comprehensive end-to-end service delivery platforms, the new open service orchestration initiatives enable carriers and cable operators to automate end-to-end service delivery, ultimately minimizing the software development required for new services.

Open orchestration was propelled into the limelight as major operators have gained considerable experience over the past years with open source platforms, such as OpenStack and OpenDaylight. Many operators have announced ambitious network virtualization strategies, that are moving from proofs of concept (PoCs) into the field, including AT&T (Domain 2.0), Deutsche Telekom (TeraStream), Vodafone (Ocean), Telefonica (Unica), NTT Communications (O3), China Mobile (NovoNet), China Telecom (CTNet2025), among them.

Traditional Standards Development Organizations (SDOs) and open source projects have paved the way for the emergence of open orchestration. For instance, OPNFV (open NFV reference platform) expanded its charter to address NFV Management and Orchestration (MANO). Similarly, MEF is pursuing the Lifecycle Services Orchestration (LSO) initiative to standardize service orchestration, and intends to accelerate deployment with the OpenLSO open reference platform. Other efforts such as the TMForum Zero-touch Orchestration, Operations and Management (ZOOM) project area addressing the operational aspects as well.

Standards efforts are guiding the open source orchestration projects, which set the stage for 2017 to become The Year of Orchestration.

One notable example is the OPEN-O project, which delivered its initial release less than six months from the project formation. OPEN-O enables operators to deliver end-to-end composite services over NFV Infrastructure along with SDN and legacy networks. In addition to addressing the NFV MANO, OPEN-O integrates a model-driven automation framework, service design front-end, and connectivity services orchestration.

OPEN-O is backed by some of the world’s largest and innovative SDN/NFV market leaders, including China Mobile, China Telecom, Ericsson, Huawei, Intel, and VMware among them. The project is also breaking new ground in evolving how open source can be successfully adopted for large scale, carrier-grade platforms.

To learn more about OPEN-O and rapidly evolving open orchestration landscape, please join us for our upcoming Webinar:

Title: Introduction to Open Orchestration and OPEN-O

Date/Time: Tue January 17, 2017  10:00a – 11:00a PST

Presenter: Marc Cohn, Executive Director, OPEN-O

Register today to save your spot in this engaging and interactive webinar. Can’t make it on the 17th? Registering will also ensure you get a copy of the recording via email after the presentation is over.

For additional details on OPEN-O, visit: www.open-o.org

Start exploring Essentials of OpenStack Administration by downloading the free sample chapter today. DOWNLOAD NOW

DevStack is a GitHub-based deployment of OpenStack, provided by OpenStack.org, that allows for easy testing of new features. This tutorial, the last in our series from The Linux Foundation’s Essentials of OpenStack Administration course, will cover how to install and configure DevStack.

While DevStack is easy to deploy, it should not be considered for production use. There may be several configuration choices for new or untested code used by developers, which would not be appropriate for production.

DevStack is meant for developers, and uses a bash shell installation script instead of a package-based installation. The stack.sh script runs as a non-root user. You can change the default values by creating a local.conf file.

Should you make a mistake or want to test a new feature, you can easily unstack, clean, and stack again quickly. This makes learning and experimenting easier than rebuilding the entire system.

Setting up the Lab

One of the difficulties of learning OpenStack is that it’s tricky to install, configure and troubleshoot. And when you mess up your instance it’s usually painful to fix or reinstall it.

That’s why Linux Foundation Training introduced on-demand labs which offer a pre-configured virtual environment. Anyone enrolled in the course can click to open the exercise and then click to open a fully functional OpenStack server environment to run the exercise. If you mess it up, simply reset it. Each session is then available for up to 24 hours. It’s that easy.

Access to the lab environment is only possible for those enrolled in the course. However, you can still try this tutorial by first setting up your own AWS instance with the following specifications:

Deploy an Ubuntu Server 14.04 LTS (HVM), SSD Volume Type – ami-d732f0b7

with a m4.large (2 vcpus, 8GiB ram) instance type, increase the root disk to 20G, and open up all the network ports.

See Amazon’s EC2 documentation for more direction on how to set up an instance.

Verify the System

Once you are able to log into the environment verify some information:

1. To view and run some commands we may need root privilege. Use sudo to become root:

  ubuntu@devstack-cc:~$ sudo -i

2. Verify the Ubuntu user has full sudo access in order to install the software:


    root@devstack-cc:~# grep ubuntu /etc/sudoers.d/*

    /etc/sudoers.d/90-cloud-init-users:# User rules for ubuntu

    /etc/sudoers.d/90-cloud-init-users:ubuntu ALL=(ALL) NOPASSWD:ALL

3. We are using a network attached to eth2 for our cloud connections. You will need the public IP, eth0, to access the OpenStack administrative web page after installing DevStack. From the output find the inet line and make note of the IP Address. In the following example the IP address to write down would be: 166.78.151.57 Your IP address will be different. If you restart the lab the IP address may change.   


 root@devstack-cc:~# ip addr show eth0

    2: eth0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

        link/ether bc:76:4e:04:b5:9b brd ff:ff:ff:ff:ff:ff

        inet 166.78.151.57/24 brd 166.78.151.255 scope global eth0

           valid_lft forever preferred_lft forever

        inet6 2001:4800:7812:514:be76:4eff:fe04:b59b/64 scope global

           valid_lft forever preferred_lft forever

        inet6 fe80::be76:4eff:fe04:b59b/64 scope link

           valid_lft forever preferred_lft forever


     root@devstack-cc:~# ip addr show eth2

    4: eth2:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

        link/ether bc:76:4e:06:10:32 brd ff:ff:ff:ff:ff:ff

        inet 192.168.97.1/24 brd 192.168.97.255 scope global eth2

           valid_lft forever preferred_lft forever

        inet6 fe80::be76:4eff:fe06:1032/64 scope link

           valid_lft forever preferred_lft forever
Public IP eth0
Internal IP eth2

4. When the previous command finishes return to being the Ubuntu user:


    root@devstack-cc:~# exit

    logout

    ubuntu@devstack-cc:~$

Install the git command and DevStack software

DevStack is not typically considered safe for production, but can be useful for testing and learning. It is easy to configure and reconfigure. While other distributions may be more stable they tend to be difficult to reconfigure, with a fresh installation being the easiest option. DevStack can be rebuilt in place with just a few commands.

DevStack is under active development. What you download could be different from a download made just minutes later. While most updates are benign, there is a chance that a new version could render a system difficult or impossible to use. Never deploy DevStack on an otherwise production machine.

1. Before we can download the software we will need to update the package information and install a version control system command, git.    


    ubuntu@devstack-cc:~$ sudo apt-get update

    

    ubuntu@devstack-cc:~$ sudo apt-get install git

    

    After this operation, 21.6 MB of additional disk space will be used.

    Do you want to continue? [Y/n] y

    

2. Now to retrieve the DevStack software:


    ubuntu@devstack-cc:~$ pwd

    /home/ubuntu

    ubuntu@devstack-cc:~$ git clone https://git.openstack.org/openstack-dev/devstack -b stable/liberty

    Cloning into ’devstack’...

    

3. The newly installed software can be found in a new sub-directory named devstack. Installation of the script is by a shell script called stack.sh. Take a look at the file:

    ubuntu@devstack-cc:~$ cd devstack

    ubuntu@devstack-cc:~/devstack$ less stack.sh

4. There are several files and scripts to investigate. If you have issues during installation and configuration you can use theunstack.sh and clean.sh script to (usually) return the system to the starting point:

    ubuntu@devstack-cc:~/devstack$ less unstack.sh

    ubuntu@devstack-cc:~/devstack$ less clean.sh

5. We will need to create a configuration file for the installation script. A sample has been provided to review. Use the contents of the file to answer the following question.

    ubuntu@devstack-cc:~/devstack$ less samples/local.conf

6. What is the location of script output logs? _____________

7. There are several test and exercise scripts available, found in sub-directories of the same name. A good, general test is the run_ tests.sh script.

Due to the constantly changing nature of DevStack these tests are not always useful or consistent. You can expect to see errors but be able to use OpenStack without issue. For example missing software should be installed by the upcoming stack.sh script.

Keep the output of the tests and refer back to it as a place to start troubleshooting if you encounter an issue.

    ubuntu@devstack-cc:~/devstack$ ./run_tests.sh

While there are many possible options we will do a simple OpenStack deployment. Create a ~/devstack/local.conf file. Parameters not found in this file will use default values, ask for input at the command line or generate a random value.

Create a local.conf file

1. We will create a basic configuration file. In our labs we use eth2 for inter-node traffic. Use eth2 and it’s IP address when you create the following file.


    ubuntu@devstack-cc:~devstack$ vi local.conf

    

3. Navigate to the System -> Hypervisors page. Use the Hypervisor and Compute Host sub-tabs to answer the following questions. a. How many hypervisors are there?

b. How many VCPUs are used?

c. How many VCPUs total?

d. How many compute hosts are there?

e. What is its state?

4. Navigate to the System -> Instances page.

a. How many instances are there currently?

5. Navigate to the Identity -> Projects page.

a. How many projects exist currently?

6. Navigate through the other tabs and subtabs to become familiar with the BUI.

Solutions

Task 2

6. $DEST/logs/stack.sh.log

Task 5

3. a. 1 b. 0 c. 2 d. 1 e. up

4. a. 0 5. a. 6

The Essentials of OpenStack Administration course teaches you everything you need to know to create and manage private and public clouds with OpenStack. Download a sample chapter today!

Read the other articles in the series:

Essentials of OpenStack Administration Part 1: Cloud Fundamentals

Essentials of OpenStack Administration Part 2: The Problem With Conventional Data Centers

Essentials of OpenStack Administration Part 3: Existing Cloud Solutions

Essentials of OpenStack Administration Part 4: Cloud Design, Software-Defined Networking and Storage

Essentials of OpenStack Administration Part 5: OpenStack Releases and Use Cases

Start exploring Essentials of OpenStack Administration by downloading the free sample chapter today. DOWNLOAD NOW

Infrastructure providers aim to deliver excellent customer service and provide a flexible and cost-efficient infrastructure, as we learned in part one of this series.

Cloud Computing, then, is driven by a very simple motivation from the infrastructure providers’ perspective: “Do as much work as possible only once and automate it afterwards.”

In cloud environments, the provider will simply provide infrastructure that allows customers to do most of the work on their own through a simple interface. After the initial setup, the provider’s main task is to ensure that the whole setup has enough resources. If the provider runs out of resources, they will simply add more capacity. Thus another advantage of automation is that it can facilitate flexibility.

In this article, we’ll contrast what we learned in part two about conventional, un-automated infrastructure offerings with what happens in the cloud.

The Fundamental Components of Clouds

From afar, clouds are automated virtualization and storage environments. But if you look closer, you’ll start seeing a lot more details. So let’s break the cloud down into its fundamental components.

First and foremost, a cloud must be easy to use. Starting and stopping virtual machines (VMs) and commissioning online storage is easy for professionals, but not for the Average Joe! Users must be able to start VMs by pointing and clicking. So any cloud software must provide a way for users to do just that, but without the learning curve.

Installing a fresh operating system on a newly created virtual machine is a tedious process, once again, hard to achieve for non-professionals. Thus, clouds need pre-made images, so that users do not have to install operating systems on their own.

Conventional data centers are heterogeneous environments which grow to meet the organic needs of an organization. While components may have some automation tools available, there is not a consistent framework to deploy resources. Various teams such as storage, networking, backup, and security, each bring their own infrastructure, which must be integrated by hand. A cloud deployment must integrate and automate all of these components.

Customer organizations typically have their own organizational hierarchy. A cloud environment must provide an authorization scheme that is flexible enough to match that hierarchy. For instance, there may be managers who are allowed to start and stop VMs or to add administrator accounts, while interns might only be allowed to browse them.

When a user starts a new VM, presumably from the aforementioned easy-to-use interface, it must be set up automatically. When the user terminates it, the VM itself must be deleted, also automatically.

A bonus of the work to implement this particular kind of automation is that with a little more effort, usually involving the implementation of a component that knows which VMs are running on which servers, the cloud can provide automatic load-balancing.

Online storage is an important part of the cloud. As such, it must be fully automated and easy to use (like Dropbox or Gdrive).

There are a number of cloud solutions, such as Eucalyptus, OpenQRM, OpenNebula, and of course, OpenStack. Open source implementations typically share some design concepts, which we will discuss in part 4.

Various cloud solutions have been in existence since the mid-1960s. Mainframes provide virtualized resources but tend to be proprietary, expensive, and difficult to manage. Since then there have been midrange and PC architecture solutions. They also tend to be expensive and proprietary. These interim solutions also may not provide all of the resources now available through OpenStack.

The Essentials of OpenStack Administration course teaches you everything you need to know to create and manage private and public clouds with OpenStack. Download a sample chapter today!

Read the other articles in the series:

Essentials of OpenStack Administration Part 1: Cloud Fundamentals

Essentials of OpenStack Administration Part 2: The Problem With Conventional Data Centers

Essentials of OpenStack Administration Part 4: Cloud Design, Software-Defined Networking and Storage

Essentials of OpenStack Administration Part 5: OpenStack Releases and Use Cases

The following is adapted from Open Source Compliance in the Enterprise by Ibrahim Haddad, PhD.

Traditionally, platforms and software stacks were implemented using proprietary software, and consisted of various software building blocks that originated as a result of internal development or via third-party software providers with negotiated licensing terms.

The business environment was predictable and companies mitigated potential risks through license and contract negotiations with the software vendors. It was very easy to know who was the provider for every software component.

open-compliance-fig1.png

building blocks

Figure 1 illustrates the major building blocks of a traditional hardware and software platform.

Over time, companies started to incorporate open source software into their platforms and software stacks due to the advantages it offers. The reasons varied from product to product, but the common theme across industries was that open source components provided compelling features out of the box, there were meaningful economies to be gained through distributed development that resulted in a faster time-to-market, and they offered a newfound ability to customize the source code. As a result, a new multi- source development model began to emerge.             

Under the new model, a product could now have any combination of:

  • Proprietary code, developed by the company building the product/service                    

  • Proprietary code, originally developed by the company under an open source license in the process of integrating and deploying open source components, but was not contributed back to the upstream open source project                    

  • Third-party commercial code, developed by third-party software providers and received by the company building the product/service under a commercial license

  • Open source code, developed by the open source community and received by the company building the product/service under an open source license.                     

open-compliance-fig2.png

development model

Figure 2 illustrates the multi-source development model and the various combinations of sources for incoming source code.

Under this development model, software components can consist of source code originating from any number of different sources and be licensed under different licenses; for instance, software component A can include proprietary source code in addition to third-party proprietary source code, while software component B can include proprietary source code in addition to source code from an open source project.

As the number of open source software components grew in what were once straightforward proprietary software stacks, the business environment diverged from familiar territory and corporate comfort zones.

open-compliance-fig3.png

software adoption

Figure 3 illustrates the adoption of open source software throughout the various levels of a given platform or software stack.

One of the major differences between the proprietary and the multi-source development models has been that the licenses of open source software are not negotiated. There are no contracts to sign with the software providers (i.e., open source developers or projects). Rather, the individuals who initiate the project chose a given open source license, and once a project reaches a certain scale, the licenses are virtually impossible to change.

When using the multi-source development model, companies must understand the implications of tens of different licenses (and combinations of licenses) coming from hundreds or even thousands of licensors or contributors (copyright holders). As a result, the risks that companies previously managed through company-to-company license and agreement negotiations are now managed through robust compliance programs and careful engineering practices.

Part 1 of this series gave an introduction to open source compliance and the business environment behind it. Next week we’ll cover the benefits of open source compliance and the risks that companies face when they fail to comply.

Read the other articles in this series:

 

An Introduction to Open Source Compliance in the Enterprise

Open Compliance in the Enterprise: Why Have an Open Source Compliance Program?

Open Source Compliance in the Enterprise: Benefits and Risks

3 Common Open Source IP Compliance Failures and How to Avoid Them

4 Common Open Source License Compliance Failures and How to Avoid Them

Top Lessons For Open Source Pros From License Compliance Failures

The 7 Elements of an Open Source Management Program: Strategy and Process

 

Download the free e-book, Open Source Compliance in the Enterprise, for a complete guide to creating compliance processes and policies for your organization.

 

The Linux Foundation today released its third annual “Guide to the Open Cloud” report on current trends and open source projects in cloud computing.

The report aggregates and analyzes industry research to provide insights on how trends in containers, microservices, and more shape cloud computing today. It also defines the open source cloud and cloud native computing and discusses why the open cloud is important to just about every industry.

“From banking and finance to automotive and healthcare, companies are facing the reality that they’re now in the technology business. In this new reality, cloud strategies can make or break an organization’s market success. And successful cloud strategies are built on Linux and open source software,” according to the report.

A list of 75 projects at the end of the report serves as a directory for IT managers and practitioners looking to build, manage, and monitor their cloud resources. These are the projects to know about, try out, and contribute to in order to ensure your business stays competitive in the cloud.

The projects are organized into key categories of cloud infrastructure including IaaS, PaaS, virtualization, containers, cloud operating systems, DevOps, configuration management, logging and monitoring, software-defined networking (SDN), software-defined storage, and networking for containers.

New this year is the addition of a section on container management and automation tools, which is a hot area for development as companies race to fill the growing need to manage highly distributed, cloud-native applications. Traditional DevOps CI/CD tools have also been collected in a separate category, though functionality can overlap.

These additions reflect a movement toward the use of public cloud services and microservices architectures which is changing the nature of open source cloud computing.

“A whole new class of open source cloud computing projects has now begun to leverage the elasticity of the public cloud and enable applications designed and built to run on it,” according to the report.

To learn more about current trends in cloud computing and to see a full list of the most useful, influential, and promising open source cloud projects, download the report now.