The before times

For a very long time, the prevailing attack surface was the network layer. Naturally, organizations focused on plugging holes in the network layer, and over time, network security tools became extremely efficient at keeping attackers at bay. So, just as naturally, attackers moved on to greener pastures—and they found plenty of opportunities in the application layer. 

Despite the number of breaches that began piling up, organizations still largely looked at application security as a compliance exercise, externally motivated by regulation, customer requirements, and executive mandate. Do the scan, check the box, move on.

This was (and still is in some places) immensely frustrating to all of us who always want to see real security happen. Because breaches continue to occur and continue to get worse.

More recently, organizations have begun to see the light. (Serious data breaches have a way of doing that.) Now, we see growing concern about real risk, which has created an internally motivated drive to move from a compliance approach to one based on managing application risk. Finally, popular opinion is coming round to what we’ve known the whole time: AppSec matters.

ASPM represents that shift from compliance to risk. We are entering the era of actually managing risk in application security, instead of either doing nothing or running around like chickens with our heads cut off (still doing, effectively, nothing).

But just what is ASPM? 

ASPM is still evolving as a market, and what exactly it is and does is still up for discussion and innovation. At Mend.io, we break it down into two values:

1. Consolidation and standardization

Thus far, SAST, SCA, container, etc., scan findings have largely been seen as their own separate results. But because each finding equates to some amount of risk, all of these scans should be compared and contrasted. This means both consolidation and standardization, and both are still emerging areas. 

For instance, it’s useful to evaluate if Finding #12 in my open source code is more or less risky than Finding #8 in my custom code. Putting all of the vulnerability findings on one scale makes for easier prioritization across the entirety of the application security domain. 

2. Context

No one is going to fix all of the vulnerabilities, because it’s simply not feasible. But fixing the wrong vulnerabilities—the ones that have no actual bearing on real risk—is worse than fixing none at all. It’s both money poured straight down the drain and can be demoralizing to the teams tasked to do the work.

With ASPM, more contextual data on findings is possible, including but not limited to:

• Reachability
• Exploitability
• Is a fix available?
• Is the application in production?
• Is it business critical?
• Is it internet-facing?

In turn, this means better prioritization and effective remediation of the 5% of findings that actually affect 95% of your security posture.

ASPM ≠ single pane of glass

ASPM needs to be more than yet another dashboard bringing information in via API. 

It should not be about simply seeing, but rather about assigning true risk to a vulnerability through accurate evaluation. That brings us back to the importance of consolidating, standardizing, and contextualizing risk management data. 

As we see it, there are currently three approaches to adding that context:

1. Filtering. Filter by exploitability, reachability, severity score, etc. It seems good in theory and it will work for one-off projects, but it falls apart as developers keep adding things over time.
2. Risk scores. This involves assigning points to things like exploitability and reachability, to create a final risk score that organizations can use to remediate those that have the highest score. The problem here is that no one believes the scoring. It’s a one-size-fits-all approach that assumes average and standard organizations to begin with, when there’s really no such thing.
3. SLA-based risk scoring. We think there is a third alternative. Prioritization scores mean nothing if no one believes them. This is an ongoing issue with vulnerability findings and nothing new to ASPM, but we think the better option is to build a score that’s believable because each organization builds it themselves based on their own SLAs and other factors that make sense for their specific goals.

Understanding the future of application security starts with learning the lessons of technology history, and we have certainly seen this pattern of hype to consolidation and standardization before. As threat actors continue to focus their indefatigable efforts on the application layer, the motivation to quickly mature ASPM will only grow, so we expect to see rapid and ongoing innovation in this area. Stay tuned! 

According to Gartner, “Magic Quadrant reports are a culmination of rigorous, fact-based research in specific markets, providing a wide-angle view of the relative positions of the providers in markets where growth is high and provider differentiation is distinct.” 

A Gartner Magic Quadrant is a culmination of research in a specific market, giving you a wide-angle view of the relative positions of the market’s competitors. By applying a graphical treatment and a uniform set of evaluation criteria, a Magic Quadrant helps you quickly ascertain how well technology providers are executing their stated visions and how well they are performing against Gartner’s market view.

You can read the report here and decide for yourself.

The Mend.io difference: Providing true confidence in risk reduction

Our goal is to enable our customers to deliver secure applications and meaningful risk reduction to the enterprise. To do that, we believe that application security must be as unobtrusive as possible. Pushing developers to focus on security has proven to be a losing battle. Instead, we use automation to build trust and reduce risk by automating the prioritization of cloud-native application risk and its mitigation across the entire software supply chain. We believe this is the most impactful way to reduce the attack surface and deliver a secure application. 

Mend.io is focused on building a new AppSec reality by 2027, where applications arrive into production free of meaningful security risk — and stay that way — without requiring manual labor or effort from engineering teams. Here’s our strategy:

• Automation: Mend.io is focused on providing complete automated remediation workflows for both open source and custom code, conveniently shown to the developer in their normal work environment (the source code repository). This includes high-value Merge Confidence data sourced from the real-world experience of millions of Mend Renovate users, allowing developers to avoid adding unexpected functional risk.
• Protection: We deliver 360-degree protection for malicious packages — blocking them before they can be download and identifying them within existing code bases — powered by the world’s fastest and most accurate malicious package detection engine, which achieved a 100 percent detection rate on Rubygems and a 99.8 percent detection rate on npm over the past two years.
• Trust: Building trust with developers and security teams through Renovate, our crowd-sourced data platform with more than one billion downloads to date. Our automated recommendations to upgrade versions and fix security flaws can be deployed without manual interaction, within native development workflows, and will not break code. We have hundreds of enterprise customers today relying on our automated fix suggestions. We will continue to leverage our expertise and telemetry on vulnerable methods within both our SCA and SAST cloud platform to extend into custom code and provide remediation advice via “auto-correct” for common secure coding mistakes. 

If your application security program could benefit from greater automation and real risk reduction, we’d love to talk to you about it.

Gartner, 2023 Gartner Magic Quadrant for Application Security Testing. Authors Mark Horvath, Dale Gardner, Manjunath Bhat, Angela Zhao, Ravisha Chugh. Published May 17, 2023.

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, Magic Quadrant is a registered trademarks of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved.

Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s Research & Advisory organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

With CodeCatalyst, developers can spend more time developing application features and less time setting up project tools, creating and managing CI/CD pipelines, provisioning and configuring various development and deployment environments or coordinating with team members. 

Why this is important

According to Forrester Research’s “State of Application Security, 2022” report, attackers looking for an easy way into systems are now focusing their attacks on applications. This makes it no surprise that the report found applications to be the top cause of external breaches, with the number of newly discovered open-source vulnerabilities having more than doubled from 2018 to 2021.

Companies must revise their application security strategies and frameworks to properly secure the large amount of open-source software that today’s cloud-based applications often contain. The latest advisories around open source security coming from the U.S. government highlights the need for increased focus and investment from companies to reduce their software attack surface and prevent malicious code from entering their code base.  

It’s simple, you can’t fix what you don’t know you have. Mend SCA provides identification of the most critical open source security vulnerabilities, removing the manual work to find gaps in security.

Using Mend SCA with CodeCatalyst workflows means that developers using the new service can quickly and efficiently scan their code leveraging our market-leading open-source detection engine.

Using Mend SCA with Amazon CodeCatalyst

Through our collaboration with AWS, existing users of Mend SCA will be able to easily configure vulnerability detection within CodeCatalyst workflows. This simplifies vulnerability detection by letting developers initiate a code scan via Mend SCA within the Amazon CodeCatalyst interface. Additionally, the Mend SCA CodeCatalyst action offers:

• Intuitive interface: Discovered vulnerabilities are displayed directly inside CodeCatalyst so developers can remain in their development environment. Vulnerabilities are also reported in Mend.
• Comprehensive coverage: Coverage is provided for 200 languages and coding frameworks 
• Full visibility: Vulnerabilities are identified in both direct and transitive dependencies 
• The most comprehensive database: Access the Mend open source vulnerability database, which is widely regarded as the most accurate and comprehensive in the world 

Find more information about Amazon CodeCatalyst here.

Today, we’re announcing a new brand identity to better reflect the transformation of our company and our focus on the detection, automated remediation, and prevention of application security issues: WhiteSource is now Mend.

Alongside our brand evolution, we’ve announced that we extended our unique automated remediation capabilities beyond open source code to to provide the industry’s first automated remediation for custom code security issues in the Mend Application Security Platform. These changes reflect our pursuit of making application security centered on fixing: enabling enterprises to secure their proprietary and open source code in an automated, remediation-centric way so developers can spend their time creating innovative applications.

Mend makes AppSec all about fixing

The application security industry is stuck. 

Far too many companies limit their security practices to detecting vulnerabilities to check off regulatory compliance criteria, often overwhelming developers with the sheer volume of these issues. The industry needs to focus on risk reduction and protecting important data, not bare-minimum compliance. With attacks becoming more sophisticated and frequent, the stakes are too high to limit application security practices to a compliance-centric mindset. Mend takes a lead in this paradigm shift with our automated remediation-first approach for both open source and custom code.

Why did we rename ourselves Mend?

It’s simple: this name best represents what we do.

With Mend, organizations have what they need to go beyond detection and automatically find and close application security holes faster. Developers can see in real time, in their native environment, exactly how to fix – mend – their code, word-for-word, and help their companies reduce application security risk without impacting demanding development deadlines. Just as importantly, Mend helps foster relationships between development and security teams to help these often at-odds job functions to better collaborate. Our new name and appearance are about more than just a “look”, it’s about how we enable organizations to mend the relationships of these teams as they mend their application security.
Developers code. Mend cures.

As a company, we value action and empowerment and aim to carry these priorities through in the products that we bring into the world. We believe that when we remove barriers that hinder innovation – for example, the notion that security and speed are antithetical – teams can do great work.

The future for Mend and Mend customers: Taking AppSec to new heights

We have a proven track record of successfully meeting complex and large-scale application security needs by providing teams with what they need to seamlessly fix vulnerabilities and secure applications. As we grow and evolve our brand, our goal remains the same: remove the burden of application security so developers can effortlessly secure what they create.

Our work towards this vision is continuing to crystalize with automated remediation of security vulnerabilities for SAST and the integration of Mend Supply Chain Defender with its existing JFrog Artifactory plugin, all within the Mend Application Security Platform.

Mend is enabling enterprises to find and fix security issues in not only open source code, but now also custom code using automated remediation. The Mend platform easily integrates into the developer’s workflow to deliver automatic remediation for both SCA and SAST, presented directly in the developer’s repository. Current tools for SAST might provide some education about resolving security holes, but it’s not enough. We are the first to bring automated remediation to custom code security issues. Now, developers and security teams can move from detection and manual processes to automated remediation of application vulnerabilities across their entire codebase.

Integration of Mend Supply Chain Defender, with the Mend platform plugin for JFrog Artifactory further supports enterprises by enabling those using the plug-in as a private repository manager to prevent malicious open source software from entering their code base. Those using Artifactory need to install Supply Chain Defender just once and they can confirm all their projects involving Javascript or Ruby are protected from harmful code with a centralized policy enforcement and auditing point. 

We’re excited to expand our automated remediation to SAST, and to be the first in the market to do so. Mend is dedicated to helping security teams and software developers meet their primary goals — security with speed. I’m grateful for the Mend team for its hard work, especially over the last year as we’ve experienced massive growth and demand for our products. And I’m grateful for our more than 1,000 customers and our partners who support taking Mend to new heights.

Starting now, you’ll see our new look incorporated throughout our company and products. If you don’t already, find us on LinkedIn and Twitter to follow our journey as Mend.

You can read additional details about all our updates in the formal announcement.

Learn more about automated remediation for SAST and the Mend Supply Chain Defender.

Escalating risks demand a new approach to application security 

Cybercriminals are always seeking new ways to attack and infiltrate organizations’ systems. In the last few years, attackers have turned their attention to the application layer, which has experienced an escalation in attacks, as Threatpost reported in June 2021. Such attacks are having a far larger and more serious impact than previously.

This is partly due to the success of existing cybersecurity and network security solutions that have forced attackers to seek new and different vulnerabilities. It has become increasingly difficult for them to attack the network layer, so naturally, they search elsewhere in the chain, at the application layer. Correspondingly, there has been a huge rise in application-based attacks versus network-based attacks, which for the last 20 years or so was the primary target.

As attackers shift to different targets, the security community must consistently rise to this challenge with innovations to thwart them. 

Why SAST?

It’s common for large enterprises to own and operate multiple security products. In some cases, the number is more than 50. Sometimes a separate security tool may be justified, for example, when the functionality is highly specialized. But in the case of application security, neither security managers nor application developers should have to use different security products from different vendors, as is presently common practice. 

Sometimes the fragmentation is downright silly. Take the example of an SQL injection vulnerability. This could be caused by a vulnerability in an open-source library or by a weakness in custom source code. Or both. Until recently, to discover these different root causes required the use of different tools that don’t communicate with each other. If vulnerabilities were caused by both custom source code and open-source code, there has been no sensible and straightforward way to know which poses the greater risk and therefore which remediation should be prioritized over the other. That’s frustrating when the resources needed to fix them are the same set of resources.

Our vision is to take what we’ve done successfully with software composition analysis (SCA) and apply our expertise to SAST so that users can discover and address all their risks in one solution, with no need for additional tools. It’s a new, more integrated approach to solving the application security problem, and it provides an easier, more efficient, and more effective user experience.

Mend unique value: Auto-remediation 

For these reasons, enlarging the scope of our product to include custom code vulnerability detection and remediation made sense to us, as well as to the customers on our advisory panel. Our next question was: What other value can we bring?

Traditionally, SAST products have been designed for compliance purposes: running a static analysis test to find vulnerabilities allowed an organization to tick a box. But the market has evolved. Enterprises today are much more interested in reducing their software risk than they were in the past. This new requirement demands a fresh approach — one that includes taking corrective action, rather than just reporting on vulnerabilities.

At Mend, we believe that vulnerability detection by itself creates little value. It’s really just half the job. That is why over the past five years we have worked to build the best auto-remediation in the world for open source software. And it is why we now intend to build the best auto-remediation in the world for custom source code security weaknesses.

I believe our market opportunity is huge. Automated remediation is what Mend is best known for. This capability allows developers to save huge amounts of time, and therefore allows organizations to develop applications faster and more securely. Our intention now is to be the first security vendor to develop a next-generation application security platform that doesn’t just find custom code vulnerabilities but remediates them.  

Mend value: shift-left 

Another long-standing philosophy at Mend has been to shift security testing “left” in the software development lifecycle (SDLC). Many studies have shown the advantages of early testing and early remediation, and so this is how we have designed our software composition analysis product. Going forward, we intend to implement this philosophy with our new SAST product. Currently, Mend SAST shifts left by integrating with build systems, repositories, and CI/CD pipelines. Automated triggers are fast and easy to setup. And since our scan engine is so fast (10 times faster than traditional SAST products), your engineers will get results in minutes or less.  

Building the next generation of SAST

At Mend, the development of our SAST platform has been a journey to build a complete solution that includes everything you need to secure your application. This involved a “buy and build” approach.

While Mend has some of the best application security engineers in the world, we recognized the value of also looking outside the company for exceptional technologies. As mentioned in our press release today, we have acquired two companies’ technologies for inclusion in Mend SAST. Xanitizer provides our customers with an amazingly accurate scanning engine for Java and JavaScript, and DefenseCode provides our customers with an extremely fast scanning engine along with wide-ranging support for multiple development languages. Together with our proprietary technology, our customers will have an application security solution that combines fast scanning with extreme accuracy, all in one platform that offers the full “detect, prioritize and fix” value chain.

The future of SAST and its impact on the security ecosystem

Our new SAST technology is a big step forward for the industry and for users alike. It signifies an important change in the way application security is implemented and the value it delivers. 

We’re leading the development of the next generation of application security. I anticipate that, three or four years from now, your application security system will run automatically and completely unobtrusively. You’ll know it’s there, but you won’t be bothered by it. You won’t really care what it’s doing. It will catch and fix the vulnerabilities on its own, making sure that your software is safe and secure. And that’s our aspiration: to provide automated remediation so effective that we’ll make your application security invisible.

But what do containers really do, and is adopting Docker the right move for your company? Read on to find out.

A crash course on containers

The first thing to realize is that containers are actually not a new technology, but have been built into Unix-like operating systems for decades. Simply put, they are a way of bundling applications and their dependencies into a unit that can be easily shipped, deployed, and run in isolation of other processes. Each container encapsulates a running application and its user space, and runs on top of the underlying operating system’s kernel.

As a result, a container can be distributed and deployed independently of the host machine, as long as the OS kernel is the same. In other words, containers do away with complicated dependency management and the need to set up complex environments by hand, and provide a sandboxed environment for applications to run in. The result is a faster and more reliable development and deployment process.

If you’re thinking that this kind of application and dependency bundling sounds a lot like virtual machines, you’re right. The difference is that virtual machines bundle up the entire operating system, while containers do not.

This might not seem like a big deal, but the consequences are huge. The bottom line is that containers are drastically smaller and faster than virtual machines. A hardware setup that can support only a few dozen virtual machines can often run hundreds of containers, and a typical container will load in milliseconds, compared to seconds or even minutes for a virtual machine.

This is one of the reasons why containers are so hot right now, and explains why a company like Google now runs all its internal and external services within containers. But Google has an army of top engineers to make sure that its container setup works well. What should you do if you want to try containers but don’t have Google’s resources?

Docker, the elephant.. well actually, the whale in the room

Even though containers have been around for decades, chances are that you’ve only heard of them in the last few years. In fact, the growing popularity of containers is directly tied to the growing popularity of Docker, a platform for managing containers on Linux systems.

Docker is not a container system itself — it relies on the container capabilities of the underlying operating system. Instead, Docker simplifies the creation and distribution of container images. Just as importantly, Docker also enables runtime constraints on the way that containers use hardware resources, providing the kind of resource sharing that’s typical of virtual machines.

Docker came along at the right time to popularize the decades-old container technology, and now, it is supported inside Amazon Web Services, the Google Compute Engine, and Red Hat Enterprise Linux.  Even Microsoft is working to integrate Docker containers into the newest version of Windows Server. While several alternatives exist, Docker is undeniably the king of the container mountain right now.

Is Docker right for you?

So far, we’ve talked about the big benefits of containers relative to virtual machines, and relative to traditional, bare-metal environments. But before you jump on the Docker train, there are a couple of issues you should be aware of.

The first of these is the pace of development. Docker is being developed at a rapid clip, and there might be subsequent issues with backwards compatibility. Also, a new release of Docker typically comes out once or twice a month, and updating the Docker binary currently requires shutting down all containers running on the machine. These issues might be blockers for many deployment scenarios.

Second, security within containers is still an open topic. While containers provide additional isolation compared to non-virtualized environments, they provide less isolation (and therefore protection) than virtual machines.

One solution to this problem is to run containers inside of a virtual machine. Another option is to use Mend’s real-time alerts on security vulnerabilities within Docker containers. Right now, Mend is able to detect open-source components in the container itself (CentOS and Debian) and detect the software inside (covering 16 different programming languages).

Even with these issues, containers hold the promise of easier development and deployment processes. As the increasing support and adoption of Docker throughout the industry indicate, it’s definitely worth investing some resources to figure out whether your organization could also benefit from this spreading technology.

BSD Licenses or the original BSD License and its two variants — the Modified License (3-clause), and the Simplified License/FreeBSD License (2-clause) are a family of permissive free software licenses. Due to their permissive nature, they have very relaxed conditions about redistributing software licensed under them.

1. What are the terms and conditions of the license?

The BSD License family lets you freely modify and distribute your software’s code in the source or binary format as long as you retain a copy of the copyright notice, list of conditions, and the disclaimer.

The original License or the 4-clause License also contains an advertising clause and a non-endorsement clause (detailed explanation about these clauses are offered in the following questions). The modified License or the 3-clause License was formed by removing the advertising clause from the original License. Further, the FreeBSD version or the 2-clause License was formed by removing the non-endorsement clause from the modified License or the 3-clause License.

2. What is the difference between the original 4-clause BSD License and the modified 3-clause?

The advertising clause from the original BSD License requires users to acknowledge the original authors of any used BSD-licensed components in all advertising materials mentioning features or use of their software. This clause was criticized for several reasons. It also made the original License incompatible with the GNU GPL.

Basically the BSD License authors expected developers to include the following acknowledgment in their copyright notices.

However, due to misunderstanding the license (and even with malice intention, in some cases), developers started replacing the above acknowledgment text by adding their own or their organizations’ names.

This led to situations where developers were required to list too many attributions, each corresponding to a used BSD-licensed component in their software.

Following the feedback, in 1999, the advertising clause that appears in the original License was removed to create the Modified 3-clause License.

3. What is the difference between the modified 3-clause BSD license and simplified 2-clause?

The Simplified 2-clause License further toned down the 3-clause License by removing the non-endorsement clause. This clause ensured that users could not make it sound like their software was endorsed by any of the acknowledged developers or organizations.

It also introduced a disclaimer about views and opinions expressed in the software to be those of the authors and not of the FreeBSD project.

4. Is it considered copyleft?

Copyright is a law that restricts the right to use, modify, and share creative works without the permission of the copyright holder. When an author releases a program under a copyleft license, he makes a claim on the copyright of the work and issues a statement that other people have the right to use, modify, and share the work as long as the reciprocity obligation is maintained.

The BSD License family doesn’t impose the reciprocity clause, you’re free to redistribute your code as you like. The BSD Licenses are highly permissive and don’t have any strict terms governing their software redistribution.

5. Is it compatible with GPL?

As mentioned earlier, it was the advertisement clause in the original license that made it incompatible with the GNU GPL. The newer versions of the original licenses, i.e., the 3-clause and the 2-clause variants are compatible with GPL.

6. What are the differences between the modified BSD license and other licenses?

GPL license

The GPL is copyleft. It requires you to disclose your source code and make the modified version open source as well. It also forbids you from sub-licensing, meaning that you can’t change any of the original license terms or introduce any of your own. You’re also required to state all the changes you make to the original code.

The BSD license family (including the Modified License), on the other hand, doesn’t compel you to do any of the above. They have fairly relaxed redistribution terms.

Apache 2.0 license

Both the newer BSD Licenses as well as the Apache 2.0 License are permissive in nature, allowing easy redistribution. In fact, the earlier versions of the Apache License were identical to the original (and later the modified) BSD licenses, but Apache License 2.0 sets them apart.

The Apache License 2.0 explicitly lays down the grant of patent rights while using, modifying or distributing Apache licensed software; it also lists the circumstances when such grant gets withdrawn.

It also has stringent terms when it comes to modifications. It requires you to explicitly list out all the modifications that you’ve done in the original software, i.e., you’re required to preserve modification notices. The Apache License also states clearly that you can’t name your product in any way that hints at the product being endorsed by Apache. So you can call your product “SuperWonderServer powered by Apache” but not “Apache SuperWonderServer”.

The Modified License doesn’t impose any such terms or grant explicit patent rights.

MIT license

MIT is one of the most permissive free software licenses. Basically, you can do whatever you want with a software licensed under the MIT license – only if you add a copy of the original MIT license and copyright notice to it. Its simplicity is the reason behind its high adoption rate among developers.

If you use the MIT license, you can use it as-is. But if you use any of the BSD licenses, you’re still required to modify the license copy to suit the project at hand.

Besides, the Modified License, thanks to its non-endorsement clause, protects you from having your name involved in a project unless you want to.

7. Does it grant patent rights?

The BSD licenses don’t grant any patent rights. You can contrast this with the Apache 2.0 License, where the license explicitly lists its patent terms. It clearly lays down the grant of patent rights while using, modifying or distributing Apache licensed software; it also lists the circumstances when such grant gets withdrawn.

The BSD Licenses, on the other hand, just grant a copyright license. While licensing your component, you will have to take care of the patents yourself.

8. Can I combine BSD-licensed components with proprietary code or code licensed under other open source licenses?

Yes. The permissive nature of the BSD licenses allows you to combine BSD-licensed components with proprietary or open source software. But be sure to check the compliance terms of the licenses of the code that you’re looking to merge with.

Like if you have licensed your component under the original BSD license, it won’t be compatible with code licensed under the GNU GPL. Consider the compatibility issues carefully while combining them.

So that’s about it for eight of your top Berkeley Software Distribution Licenses (BSD) questions answered. Do you have any more? I would be happy to find the answers for you.

*The author of this blog is not a lawyer, and you should not interpret this BSD-license information as legal advice of any kind. Information is provided on an as-is basis. For a legal consultation, please contact your legal advisor.

Today, we have compiled a list of your top 10 questions about the Common Development and Distribution License.

Common Development and Distribution License (CDDL) is an open source license published by Sun Microsystems to replace the Sun Public License (SPL). The CDDL license is considered by Sun (now Oracle) to be SPL version 2. It is inspired by the Mozilla Public License (MPL). Sun used to release its free software / open source projects under its Sun Public License (SPL) before it turned to rely upon the CDDL in 2004. CDDL is often dubbed as a cleaned up version of the MPL and is made to facilitate reusability.

1. What are the Common Development and Distribution License (CDDL) terms and conditions?

You’re free to reproduce and distribute any original or derivative works of any software licensed under the CDDL. However, you must not remove or make any changes to any copyright, patent or trademark notices contained in the software.

You must also retain any notices of licensing or any descriptive text giving attribution to any contributor or the initial developer.

When you distribute your software in an executable form (any form other than source code), you are required to make the source code available as well under the CDDL. The executable form may be released under the CDDL or any CDDL compatible licenses.

The source code that you have to make available includes your contributions as long as they are addition to, deletion from or modification of the contents of a file containing the original software – or new files that contain parts of the original program. That means that if your additions are made in separate and independent files that do not contain the original code, you do not have to release it under the CDDL. You may do that if you choose to, but you’re not obliged.

In addition, you must include a copy of the CDDL with any source code that you distribute. For each modification that you make, you must identify yourself as the modifier by including a notice in your modified files.

2. Is the CDDL considered copyleft?

The CDDL is considered a weak copyleft license.

A copyleft license, like the GNU GPL, the MPL or the Eclipse License, requires that you give down-the-stream users of the program the same rights that you yourself received. For that purpose, you are required to distribute the program – including any modified and extended versions of it – under the same license. This means that using such a copyleft licensed component in your code, will require you to release your entire program as an open source. Essentially, it means to distribute the original or modified software under the same license that it originally carried.

The CDDL requires you to release the source code of only the CDDL licensed components that you use or modify in your code under the CDDL. If you distribute your software in its executable form, you are bound to include the source code form but the executable can be distributed either under the CDDL or under a compatible license.

3. Does the CDDL grant patent rights?

Yes, it does. Any contributor grants you the right to use the patents that his contribution embodies. CDDL takes a very clear stand on patents — you can use, modify, and redistribute CDDL licensed components without any concerns about any patents that the code contributors might hold on the contributed technology.

The CDDL discourages patent litigations against developers by terminating the usage rights to of anyone who initiates a patent claim against a developer about the code that h/she has contributed.

4. What is the difference between CDDL version 1.0 and CDDL version 1.1?

CDDL version 1.1 was submitted a year after the first draft in early January 2005. It includes some corrections that prevent the CDDL from being in conflict with European Copyright law and to allow single developers to use the CDDL for their work.

5. What is the difference between the CDDL and the GNU GPL and is it compatible with them?

The GNU GPL requires that you subject to it any program that is a derivative work of the original software. That means that you have to make its source code available. This is considered strong reciprocity. The CDDL takes a software approach. As we have seen, if your additions are made in independent files that do not contain any part of the original program – then these files are not subject to the CDDL. It means, amongst other things, that you do not have to release these files’ source code.

Furthermore, the GPL takes a tough stand on changing the license’s terms and conditions. While certain additions are permitted under GPL 3, the general rule is that no other changes can be introduced. As opposed to that the CDDL only subject the source code version of the software to its provisions. The executable version can be distributed under the terms of any other license that you choose, provided that it is in compliance with the terms of the CDDL and that the license for the executable does not attempt to limit or alter the recipients’ rights in the source code form of the program.

Due to these differences, the CDDL is not considered compatible with the GNU GPL.

6. What is the difference between the CDDL and the Mozilla Public License (MPL)?

The CDDL is based on the Mozilla Public License (MPL) version 1.1, but it has made few changes to make it more accessible to developers, and the MPL version 2.0 was also significantly modified.

The two main differences between the two licenses are GPL compatibility and simplicity:

• Although both licenses are considered as weak copyleft, the MPL version 2.0 is compatible with the GNU GPL while the CDDL is not.
• CDDL is better structured and it deliberately uses a simpler, more consistent language to make the license more understandable and increase developer’s adoption rate.

7. What is the difference between the CDDL and the Apache and BSD licenses?

The Apache and BSD licenses are permissive open source licenses. You are not required to make your modifications and additions available under these licenses when you choose to distribute a program that they cover. CDDL, as noted above, subjects some of your contributions to its terms and conditions. In addition to that, both Apache 2.0 and BSD are considered compatible with the GNU GPL, unlike CDDL. However, the CDDL is compatible with both the Apache and the BSD licenses.

8. Can I use CDDL licensed components in a commercial product?

Yes. You can use CDDL licensed components in a commercial product. You can even sell and resell software with CDDL licensed components. However, when you do any of these, make sure to release any original or modified CDDL licensed components contained in your software under the CDDL only and meet the other terms and conditions of the license mentioned above.

9. Can I license my software under the CDDL?

Yes. The CDDL is designed to be reusable. So you can license your software under the CDDL. In fact, when the MPL was modified to draft the CDDL, it was deliberately kept simple so developers will adopt it and reuse it easily.

10. Can I combine CDDL licensed components with proprietary code or code licensed under other open source licenses?

CDDL licensed components can be mixed with components licensed under other licenses, whether open source or proprietary. If compiled with other open source licensed components, then these licenses must be compatible with the CDDL. It is always recommended to take special care and – if necessary – consult an attorney when you combine free software with proprietary code or even with other open source licenses.

So these are ten of your top Common Development and Distribution License (CDDL) questions answered. Do you have any more? I would be happy to find the answers for you.

*The author of this blog is not a lawyer, and you should not interpret this as legal advice of any kind. Information is provided on an as-is basis. For a legal consultation, please contact your legal advisor.

The Microsoft Public License is a free and open source software license released by Microsoft, which wrote it for its projects that were released as open source. You’ll see Ms-PL a lot if you’re into .NET coding. Microsoft’s free open source project hosting site, CodePlex, also has a lot of Ms-PL’ed projects.

1. What are the Microsoft Public License (Ms-PL) terms and conditions?

You are free to reproduce and distribute original or derivative works of any software licensed under the Ms-PL license. However, you may not use any contributors’ name, logo, or trademarks when you do so. The Ms-PL protects the authors by explicitly not offering any express warranties or guarantees for using your code. So the author is not liable if the code doesn’t work well in some usage.

When you distribute software (or its portion) under the Ms-PL, you’re not required to distribute its source code. You may do so if you want to, but you’re not obliged. However, you’re required to:

• Retain all copyright, patent, trademark, and attribution notices that are originally present in the software.
• Additionally, if you distribute any portion of the software in its source code form, you may do so only under the Ms-PL by including a complete copy of this license with your distribution. If you distribute any portion of the software in its compiled or object code form, you may only do so under any other license that complies with the Ms-PL.

It is important to note that the Ms-PL terms and conditions document is very short, concise and written in a very coherent language. Microsoft wanted to be very clear and direct with the open source community, which also helps adoption rate (as we know from the BSD license).

2. Is Microsoft Public License (Ms-PL) considered copyleft?

A Copyleft license offers the right to distribute modified and derivative versions of a program, provided that the same rights and freedoms are preserved for downstream recipients of those modifications and derivatives. When you distribute Ms-PL’d software or its portion in its source code form, you may only do so under the Ms-PL license. When you distribute the Ms-PL’d software in compiled or object code form, the Ms-PL license lets you do so only under “a license that complies with the Ms-PL”.

Hence, the Copyleft effect of Ms-PL is clear when choosing to distribute source-code version of the modified or derivative Ms-PL software. It seems that when distributing compiled or object code versions of modified or derivative Ms-PL software, the same rights and freedoms need not be passed through to downstream recipients, even though the Ms-PL text is not entirely clear on this point. This interpretation is supported by Microsoft, the steward of Ms-PL, who maintains that one may distribute compiled or object code versions of Ms-PL’d software under terms of his or her choosing, which must not grant downstream recipients more rights (but can grant them less rights) to the Ms-PL’d software than are granted to that person.

3. What is the difference between Microsoft Public License (Ms-PL) and Microsoft Reciprocal License (Ms-RL)?

The Ms-RL license is a copyleft license that is more restrictive than the Ms-PL. It allows you to modify and distribute any Ms-RL’ed component as long as the modified source files are included and licensed under the Ms-RL.

However, you can license the other files of the software, which are entirely your own work, under any other compatible license you may choose.

4. Are Microsoft Public Licenses allowed in commercial products?

Yes. You can use both Ms-PL and Ms-RL licensed components in commercial products as long as you meet the terms and conditions of these licenses.

5. How can you use a component licensed under the Microsoft Public Licenses in your commercial project?

If you are using Ms-PL’ed components and decided to release the source code of your product, then you will be able to distribute your software only under the Ms-PL. If you choose to release the compiled or object code, you can release it under any other Ms-PL’ed compatible license.

If you are using Ms-RL’ed components, you will need to distribute the modified source files, which can be problematic for many commercial products. However, you may license other files that are entirely your own work under any terms you choose.

6. Is Microsoft Public License compatible with GNU GPL?

No. The Microsoft Public License is not compatible with the GNU GPL. The incompatibility between GPL and Ms-PL stems from the fact that GPL is much more restrictive than the Ms-PL, for example, GPL’s requirement to distribute the source code does not correspond with the Ms-PL clause that enables to compile the program without distributing the source code.

Even the Ms-RL, which is a copyleft license, is not compatible with GPL. It is believed that Microsoft deliberately crafted it open source licenses to be incompatible with the GPL, since as many other commercial companies, it dislikes the fact that if you submit a code under this license, your code can then be taken into a proprietary black hole by someone else.

7. What is the difference between Microsoft Public License and GPL (and LGPL)?

Microsoft Public Licenses were created from a more commercial perspective as you can expect from a commercial company, like Microsoft.

The main difference between the Ms-PL and the GPL, is that the Ms-PL requires you to release your source code only if you’re distributing a Ms-PL licensed software (or its derivative) in its source code form while the GPL requires you to always release your entire source code if you’re using any GPL-licensed component in your software.  The GPL license also does not make any distinctions between the original or modified GPL licensed files and your proprietary code, once you have combined it with a GPL component.

The LGPL is a weaker copyleft version of the GPL that allows proprietary software to use or link to LGPL’ed components without having to subject their proprietary files to the LGPL (i.e., only modifications to the LGPL original files needs to be open sourced). The Ms-RL is somewhat closer to the LGPL. When you license your software under the Ms-RL, you have to release all the Ms-RL’ed components in your software under the Ms-RL license. Also, you can choose to use different licenses for the components used in your software that were not originally licensed under the Ms-RL.

8. What is the difference between the Microsoft Public License and the MIT/BSD licenses?

MIT is one of the most permissive free software licenses. Basically, you can do whatever you want with a software licensed under the MIT license – just make sure that you add a copy of the original MIT license and copyright notice to it.

The BSD license is another highly permissible license that allows you to modify and redistribute software licensed under the BSD license as you like just as long as you attach a copy of the original BSD License to it.

The MIT and BSD licenses, both, don’t require you to release the source code of your software, nor do they have any conditions about mixing the code licensed under them with codes released under other licenses.

However, in the case of the Microsoft Public License, if you do choose to release the source code of your product, you can do so only under the Microsoft Public License.

9. What is the difference between Microsoft Public License and Apache 2.0?

The Apache License 2.0 is a permissive open source software license — so you can release your modified version of the Apache licensed product under any license of your choice (with the unmodified Apache licensed components always retaining the Apache License).

With Ms-PL, however, if you choose to distribute the source code of your product, you can only do so under the Ms-PL license. In case you choose to distribute the object code of your product, you can do so under any license compatible with the Ms-PL.

10. Can you sell Microsoft Public Licensed open source software/code?

Yes. You can sell any Microsoft Public Licensed open source software. However, while you do, make sure that you don’t infringe anyone’s trademarks.

So these are ten of your top Microsoft Public License questions answered. Do you have any more? I would be happy to find the answers for you.

The author of this blog is not a lawyer, and you should not interpret this as legal advice of any kind. Information is provided on an as-is basis. For a legal consultation, please contact your legal advisor.

The Eclipse Public License is an open source license developed by the Eclipse Foundation. It’s derived from the Common Public License (CPL). The Eclipse codebase now available under the EPL was formerly licensed under the CPL.

1. What are the terms and conditions of the Eclipse Public License?

The EPL license is a copyleft license. If you modify an EPL’ed component and distribute it in the source code form as part of your program, you’re required to disclose the modified code under the EPL. If you distribute such a program in its object code form, you’re required to state that the source code can be made available to the recipient upon request. You’re also required to share the method for requesting the source code.

The Eclipse Foundation makes clear that, in their opinion, ‘merely interfacing or interoperating’ with an Eclipse plugin does not make your code a derivative work of the plugin

If you redistribute a program with an EPL component, you are obligated to include the full license text and the copyrights.

The EPL protects the author from possible lawsuits or damages caused if a company used his/her component in a commercial product. It also offers patent grant.

2. Is it considered a copyleft license?

Yes, the EPL is considered a weak copyleft license.

Weak copyleft licenses requires you to disclose your source on source code, but not on binaries and therefore you can compile covered sources with others and distribute the resulting (merged) binaries under the license of your choice. With ‘strong’ copyleft license, the GPL family, you are obligated to reuse the same license in case of re-distribution of copies or derivatives on both source and binaries.

3. What is the difference between the Eclipse Public License and IBM’s Common Public License (CPL)?

The EPL revises the CPL by deleting the first sentence in the 7th section of the original CPL that was believed to be overly broad and non-conducive to the growth of the Eclipse ecosystem. The removed content explained how the CPL handled patent retaliation.

4. What is the difference between the Eclipse Public License and the GNU GPL?

The GNU GPL family of licenses has a strong copyleft clause requiring users to release their software’s full source code irrespective of the percentage of the GPL’ed code included. The EPL on the other hand doesn’t require you to open source your entire code. You’re only required to open source any included modified EPL-ed components when distributing in the source code form, and make the source code available upon request when distributing in the object form.

5. Is Eclipse Public License compatible with the GNU GPL?

The EPL is not compatible with the GNU GPL. The GPL requires the user to release the entire software and that the distributor not “impose any further restrictions on the recipients’ exercise of the rights granted”. The EPL, however, requires that anyone distributing the work grant every recipient a license to any patents that they might hold that cover the modifications they have made.

Because this is a “further restriction” on the recipients, distribution of such a combined work does not satisfy the GPL.

6. What is the difference between the Eclipse Public License and the LGPL?

The LGPL is a weak copyleft version of the GNU GPL protecting users creating non-derivative works from having to open source their code when using or linking to an LGPL-ed component.

The EPL too is a weak copyleft license that only requires users to open source any included modified EPL-ed code, but with no obligation on its linking. You will need to release the modified EPL-ed components in case it was modified and released in its source form.

7. What is the difference between the Eclipse Public License and the Apache License?

The Apache License 2.0 doesn’t force you to release your modified version of the Apache Licensed code. Besides, if you’d like, you can choose to release your modified version under a different license (however, you’re required to retain the Apache License for the unmodified parts of the code).

This is very different from the requirements of the EPL, where a developer is required to open source the modified EPL-ed code when distributing in the source code form, and make it available upon request when distributing in the object code form.

Besides, the EPL-ed code in a program can only be released under the EPL, even if the full program is released under a different license.

8. What is the difference between the Eclipse Public License and the MIT License?

MIT is one of the most permissive free software licenses. Basically, you can do whatever you want with a software licensed under the MIT license – only if you add a copy of the original MIT license and copyright notice to it. Its simplicity is the reason behind its high adoption rate among developers.

If you contrast the MIT License with the EPL, you’ll see that EPL has certain requirements when it comes to distributing code — a developer is required to distribute the source code of any included EPL-ed code if any modifications are made to it. Besides, if an EPL-ed modified program is distributed in the object code form (even if it’s part of a proprietary software), the developer is required to make the modified EPL-ed code available if a recipient requests for it. Additionally, an EPL-ed component can only be released under the EPL.

9. What is the difference between the Eclipse Public License and the BSD License?

A developer can choose to distribute a BSD-licensed program as per his/her choice. The BSD license doesn’t impose the reciprocity clause either.

The way the EPL differs from the BSD Licenses is very similar to the way that the EPL differs from the MIT License. Again, the key point of distinction is the requirements regarding distribution. The EPL requires developers to share the modified source code of an EPL-ed component. If the distribution happens in the object code, the developers are still required to open the source code of the modified EPL-ed code upon request.

10. Can you mix code licensed under the Eclipse Public License with other licenses?

Yes, as the original creator of a program, or after obtaining the permission from the original creator of a program, it’s possible to mix code licensed under the EPL with other compatible licenses. However, you must note that the source code of an EPL-ed software can only be released under the EPL.

So these are ten of your top Eclipse Public License questions answered. Do you have any more questions about the EPL that you’re looking to get answered? Do share them in the comments. I’d be happy to extend the post to cover them.

*The author of this blog is not a lawyer, and you should not interpret this as legal advice of any kind. Information is provided on an as-is basis. For a legal consultation, please contact your legal advisor.