Everything you need to know about Open Source & Third-party Software Policy Guidelines

10.26.21 By

According to the 2019 Open Source Security (OSS) and Risk Analysis (OSSRA) Report, 96% of codebases contain open source components. With the average codebase containing 298 open source components, they account for 60-80% of all software code.

Engineers leverage these open source licenses and their components to help create, accelerate, and innovate their software development processes. For development teams that utilize open source and third-party code, understanding usage guidelines as well as following them is critical to maintaining quality and reducing risk.

For example, in the above report, it was also reported that 85% of codebases contained components that were more than four years out-of-date or had no development activity in the last two years. Such incidences pose a legal, financial, and security risk to organizations who utilize software with these components. While many organizations have dedicated Legal/Audit/Engineering/Management teams in place, it is the responsibility of the developer to understand and mitigate risks that come with OSS licenses as well as the guidelines for proper usage.

Back to Basics: Types of Open Source Software Licenses

Types of OSS Licenses

Public domainMost used Permissive model
  • It means that anyne can modify and use the software without any restrictions.
  • However, even if a component is free and comes without any legal strings attached, you should always make sure it’s secure before adding it to your own codebase.
PermissiveContains minimal requirements about how the software can be modified or redistributed
  • Also known as “Apache style” or “BSD style”, this type of license is perhaps the most common and popular with free open source software.
  • Besides the Apache License and the BSD License, another common varient is the MIT License.
CopyleftAllow code modifications and distribution, as long as you meet the requirements for redistribution under the same license
  • Different licenses have different scopes. Some copyleft licenses allow you to release the modified code only; others require you to release the entire application under the same license.
  • One of the most common restrictive licenses is the GNU GPL (General Public License).
  • Its cousin, AGPL (Affero General Public License), is also becoming more popular, as it closes the SaaS loophole found in the GPL.
No License / unlicensed codeblic domainDoes not mean “public domain”
  • Even if code was released to the public and doesn’t come with a specific license (such as a code example from Stack Overflow), you might still have to meet certain obligations to use that code.
  • By default, the copyright for unlicensed code belongs to its creator, who must grant explicit permission for you to use it.
  • The safest way to approach unlicensed code is to treat it as proprietary (i.e., not open source).

Open Source Software Licenses Compared

Today, engineers have a wide array of OSS licenses to choose from, which has given rise to the domination of permissive open source in comparison to copyleft licenses. The Apache 2.0 license and the MIT License are far more popular than the GPL family, together comprising over 50% of open source licenses currently in use.

Open Source Software Licenses Compared

Source: WhiteSource

License Preferences

Certain licenses are leveraged far more than others as they satisfy numerous requirements of both engineers and businesses too. Of course, specific license permissions and limitations determine license preference for many and hence, the MIT license is predominately preferred as per WhiteSource.

License Preferences

Source: WhiteSource

Understanding the Types, Permissions, Conditions, and Limitations of Licenses

Now that we know the names, types, and categories of open source licenses, let’s deep dive into how to actually use them. With every type of OSS license, there are different permissions, conditions, limitations you need to follow. We have included the most commonly used and preferred OSS licenses below.

Permissive Licenses

Copyleft Licenses

OSS-components-guidance

The above table highlights the multiple aspects you should consider before utilizing, sharing or distributing your work using OSS components. Be sure to also lean on the expertise of your legal, engineering, and management teams to guide you.

Role of the Opensource / Third-party software Review Board (OSRB)

Opensource/ Third-party software Review Board (OSRB) is a team comprised of members responsible for establishing and reviewing licensing terms as well as reviewing against known security vulnerabilities before adopting new OS libraries/components. The OSRB also provides strategy, communication and guideline manuals (set of rules and regulations to be followed) for IT professionals in organizations. It also consists of the following aspects to regulate the use of OSS licenses-

  • Recommended Guidelines

    Any open source component licensed under the following commonly-used licenses can be freely used without additional disclosure or approval by the OSRB.

    • Apache License, 1.0, 1.1 and 2.0 variants
    • Eclipse Public License (EPL)
    • MIT License
    • Berkeley Software Distribution (BSD), 3-clause, 2-clause, and 0-clause variants
    • Mozilla Public License, 1.0, 1.1 and 2.0 variants
    • Common Development and Distribution License (CDDL)

    Any other software other than those mentioned above will require review and explicit permission from OSRB.

  • Approval Process

    Every organization has a predefined process to identify, review, leverage, manage, and distribute components associated with diverse open source licenses. With this process in place, organizations can identify risks and regulations associated with OSS licenses and also gain other benefits including accelerated delivery schedules and preemptive actions to mitigate risks or surplus costs.

    OSS Approval Process

Licensing Compliance

Whether permissive or copyleft, all open source licenses have notice requirements. Typically, this means you need to include a copy of the applicable license when distributing open source software.

  • OSS licenses for Mobile Applications

    Mobile applications are no exception to the above guidelines. According to a report by OpenLogic, 71% of apps using open source licenses were deemed non-compliant. Since mobile applications are installed on user devices, they fall under the “distributed” category and you are obligated to provide a copy of the license itself along with any notices or attributions required by the license. Below are examples of OSS licenses used by popular applications such as MS Outlook, Zillow, Facebook and Instagram respectively.

    OSS licenses for Mobile Applications 1

    OSS licenses for Mobile Applications 2

    Follow the instructions below to include the licenses of the software used in your applications. If you are using components which don’t fall under the guidelines provided, contact the OSRB for further advise. Here are some helpful links to guidelines on how to use opensource licenses from Google, LinkedIn, Github etc.

  • OSS licenses for Web Applications

    Web Applications render or deliver HTML, JavaScript, CSS & plugins to consumers which are executed in their browsers. You are obligated to keep and provide the attribution information for these libraries.

    • Keep and provide the license & copyright information in the JavaScript files and other assets that are delivered to client machines.
    • Make sure this information is not excluded or removed after minification & bundling process.
    • If this is not possible, include a credits page that lists all OS libraries used in the application.
  • OSS licenses for Windows Applications

    Web Services/ REST APIs

    Other Internal Components

    Applications or services that run on internal servers and are not distributed to end customers are mandated to provide attribution. However, there are some license types which require attribution. As a precaution, you should leave the license and copyright information of the libraries in the code.

  • OSS licenses for Stack Overflow

    Stack overflow is one of the largest communities of developers who share their knowledge. However, the solutions or code snippets contributed by users on Stack Overflow are released under the Creative Commons Attribution-Share Alike 3.0 Unported (CC BY-SA 3.0) license which requires attribution to the source. Though we don’t encourage or support borrowing code from such sites, if it can’t be avoided you need to provide the right attribution to the source.

    As per the CC BY-SA 3.0 license terms, you need to fulfill the following requirements.

    • Section 4(a): include the URL to the license.
    • Section 4(c)(i): give credit to the original author, by name or pseudonym.
    • Section 4(c)(iii): give a URL to the SO source code. (If the source code is in an answer, use the ‘share’ button on the answer to get a perma-link.)
    • Section 3(b): If you make any changes to the source code, add a comment saying “The original code has been modified.”

It is recommended to add the following attribution when you are using code from Stack overflow.

// The class below was written by StackOverflow user user name and is licensed

// under CC BY-SA 3.0 ( http://creativecommons.org/licenses/by-sa/3.0/ ).

// http://stackoverflow.com/a/9999/99999

// https://stackoverflow.com/users/99999/username

OSS Licenses are significant and can pose significant risk to organizational operations and reputation.

If you need a partner to help analyze your requirements and identify the right opensource solutions and also ensure adherence to opensource and 3rd party licensing, we are here to help you. Our teams can help you analyze the right stack, identify licenses, get reports, understand and mitigate risks.

Contact our experts, today!

References

opensource.org/licenses

github.com/todogroup/policies/blob/master/linuxfoundation/lf_compliance_approval.pdf

www.slideshare.net/blackducksoftware/you-cant-live-without-open-source-results-from-the-open-source-360-survey

www.ibrahimatlinux.com/uploads/6/3/9/7/6397792/opensourcestrategyforum-haddad-1.0.pdf


By

Associate Vice President, EDS 

Sreeni is an accomplished technology leader with over 25 years of experience in building highly scalable enterprise applications using the latest digital technologies. He handles pre-sales, technical and solution architecture, project management, and delivery. At Bridgenext, Sreeni has been instrumental in establishing the RPA Center of Excellence (CoE) and the growth of the Intelligent Automation practice in the organization. From design and development to delivering and enhancing automation solutions for clients, Sreeni has a passion for helping firms across industries realize the benefits of RPA.

Email: sreenivas.v@bridgenext.com



Topics: Digital Transformation, Product Design

Solution-oriented technology is our specialty.