Black Duck Blog

Rob Bearden

I’m excited to be joining Black Duck’s Board of Directors and wanted to take an opportunity to introduce myself to the Black Duck community. If you’re interested in my bio you can get more information here.

I’ve been fortunate to work with some exceptional teams and companies in the open source community over the last decade or so. JBOSS paved new ground for open source in middleware with a market-leading java app server. SpringSource helped propel development efficiency with its widely adopted programming model and application infrastructure. Stepping back and looking at my career, much of my work has focused on implementing infrastructure strategies and development frameworks that help make the process better, faster and cheaper. Black Duck has already had a big impact in a similar way by enabling large scale use of open source and managing it across the development life cycle. I’m excited to be joining Black Duck in helping to broaden the use of open source even further.

Why do developer teams need help to make effective use of open source? There are at least two reasons.

First, there’s lots of open source out there, which is a benefit for sure, but it also presents a challenge. To quote my friend Matt Asay from Alfresco, the challenge with open source is “to make ‘abundance’ manageable.” With over 220,000 open source projects, this ‘abundance’ presents challenges in finding good code, assessing its fit for use, managing and tracking it over the application lifecycle, as well as ensuring standardization of components across large distributed organizations. With so much to choose from, different team members/groups/divisions are apt to pick similar but not the same component which adds to complexity.

Black Duck invests significant resources aggregating the free content available on over 220,000 open source projects, then packages that information in an enterprise scale platform to enable development teams to use the abundance of code in a more manageable, efficient, compliant and secure way.

The second reason development teams need help with open source is the complexity of code used today. In today’s development environment, the pressure to turn out innovative software applications is greater than it’s ever been. The global recession has made competition fiercer, and development teams have to do it all with the same or fewer resources. They’ve turned to open source software not just for their tooling or the O/S or their web and app server, but for “componentry” they can re-use to speed application development. Open source is just one of the many smart ‘code-sourcing’ strategies I see development teams using to compete more effectively. It’s no longer a question of whether to use open source or not; development managers are optimizing around where to focus in-house development, use of open source components, commercial code, and outsourced development. It’s a multi-source world and development teams need tools like the Black Duck Suite to make the best choices from the hundreds of thousands of open source components available while managing integration and deployment with all the other code in development.

It’s a big challenge and a big opportunity for Black Duck, developers and the industry as a whole and I’m thrilled to be right in the thick of it.

We’d love to hear your thoughts on the role of open source in the new multi-source world we’re living in today, so please share your comments here on the Black Duck Blog.

Eran Strod
Director of Product Marketing
estrod@blackducksoftware.com

Open source developers may not realize it but in certain circumstances their work is subject to export regulation. When open source developers create an account on SourceForge.net they are required to agree to SF’s terms and conditions. Checking that innocuous little box to “opt-in,” they are acknowledging that they are aware and pledge to comply with Section 740.13(e) of the Export Administration Regulations (”EAR”) 15 C.F.R. Parts 730-772.

There are only three facts that you need to know about the above:

1. The fact that you have no idea what this is does not get you off the hook
2. See number 1
3. See number 2

The fact is the US government regulates the transfer of encryption technology to other countries. One of the big challenges for multi-source developers, who create products which mix open source with other types of software, is understanding whether there is encryption in their code. As software developers increasingly leverage open source and other components, it becomes more challenging for them to have intimate knowledge of what is in their code.

If it turns out you are using strong encryption, then you most likely are required to submit a notification or license application with the US Commerce Department. Strong encryption uses key lengths greater than 80 bits for symmetric algorithms, 1024 bits for asymmetric algorithms and 160 bits for elliptic curve. The requirements differ depending on the function of the product, the end user, the destination country, the encryption strength, and the intended use. If you are using weak encryption (defined in my October 13th blog, then you are OK. If you are between the limits of weak and strong, well then…make friends with a knowledgeable compliance professional.

Today Black Duck Software published an analysis that we performed looking at the encryption content in open source projects. We found that about 7% of open source projects contain encryption algorithms, however not all encryption is strictly controlled. We did find nearly 8,000 projects which could require a notification or license application to be filed before exporting. This includes some of the most popular open source projects.

Our message for multi-source developers is simply this: “Know Your Code.” If you want to learn more about complying with encryption export regulations, we have put together a guide to encryption export compliance for open source developers (and for developers using open source).

PS: Ps: Two more facts – two popular sites, SourceForge and Google Code, have language about export in their user T’s & C’s. See below:
SourceForge Terms of Use

You are aware that all postings of open source encryption code controlled under U.S. Export Control Classification Number (ECCN) 5D002 must be simultaneously reported by email to the U.S. government. You are responsible for submitting this email report to the U.S. government in accordance with procedures described in this document and Section 740.13(e) of the Export Administration Regulations (”EAR”) 15 C.F.R. Parts 730-772.

Google Code Additional Terms: By using Google Code (the “Service”), you agree to be bound by our Google Terms of Services located here.

5.2 You agree to use the Services only for purposes that are permitted by (a) the Terms and (b) any applicable law, regulation or generally accepted practices or guidelines in the relevant jurisdictions (including any laws regarding the export of data or software to and from the United States or other relevant countries).

Click here to listen to a podcast on my discussion of the threat of encryption algorithms to commercial enterprises.

Eran Strod
Director of Product Marketing
estrod@blackducksoftware.com

Last week I attended the BIS Update conference in Washington, D.C. For those of you that are not familiar, the Update conference, put on by the Bureau of Industry and Security (BIS), is an annual conference of nearly 1,000 export compliance professionals, government officials, attorneys and business leaders who assemble in DC to network and learn about changes in US export policy. The world economy as we know it would not exist without this tight knit community who essentially shepherd the export of US-origin products through a maze of Commerce Department regulations to eager customers around the world.

What does export compliance have to do with open source software?

As renowned analyst Bob Igou from Gartner Research recently wrote “40% of open source software is used as building blocks in larger software development projects.” (1) One of the challenges that companies face when leveraging hundreds of thousands or even millions of lines of open source code is that it is very time consuming and expensive to understand what’s in that code, including knowing if it contains regulated code. From a legal perspective, ignorance is not an alibi. If code is in a product that a company is shipping, then that company is on the hook to make certain it is compliant. That is especially true for software that contains strong encryption which is regulated by the Bureau of Industry and Security of the US Department of Commerce. And we aren’t talking theoretical risk here. Penalties for violating the regulations include prison (up to 20 years), fines of $250K (or 2X the value of the transaction) and worse.

Just to give you an example of one of the boundaries. “Weak” encryption can be self-classified without notification or government review. Weak currently means:

•56-bit or less Symmetrical
•64-bit or less Symmetrical & “Mass Market” (2)
•512-bit or less Asymmetrical
•112-bit or less Elliptic Curve

We spoke with about 60 compliance professionals at BIS Update and I repeatedly heard this feedback: they cannot do their jobs (keeping their companies compliant) if software development organizations do not give them good information about the encryption content inside products. One compliance professional described fighting with a product manager who insisted there was no encryption in a popular software platform that was being bundled into their system, when in fact she (the compliance specialist) knew that to be false from previous experience.

Conflicts like these can be easily resolved when the facts are established. Our message at the show was we can automate this process and make it easy to analyze and find encryption, even create a cryptographic bill of materials for projects. When you “Know Your Code” you can stop arguing about facts and get back to the business of creating value for your company.

(1) “User Survey Analysis: OSS Spending Intentions Hold Steady While IT Services for OSS Continue to Evolve, North America, 2009,” Bob Igou, August 27, 2009 (Gartner Document ID: G00170359)
(2) “Mass Market” is formally defined in the Export Administration Regulations

For more information regarding product management and export compliance, I recommend reading “What Makes Complying with Export Controls Involving Encryption So Hard?” by noted attorney Ben Flowe Jr.

Jim Berets
Vice President of Product Management
jberets@blackducksoftware.com

Deciding which open source components to use in a development project requires consideration of a variety of factors including suitability for the problem at hand, licensing terms, quality, security, and supportability.

Coverity recently released a report showing that OSS continues to improve in quality. The report, which analyzed more than 280 open source projects found “the overall integrity, quality, and security of open source software is improving.”

The most highly vetted projects – Samba, tor, OpenPAM and Ruby – graduated to what Coverity calls “Rung 3″; an additional 32 projects graduated to “Rung 2″ because they “eliminated multiple classes of potential security vulnerabilities and quality defects from their code.” (Higher rungs indicate the resolution of issues identified at lower rungs, and a higher degree of analysis by Coverity’s tools.)

Reviewing the 36 “Rung 2″ projects using data contained in the Black Duck KnowledgeBase yields some additional insights:

- The quality of the Rung 2/3 projects stems at least in part from longevity and breadth of use. They are, on average, more than 8 years old.

- Vitality matters in selecting OSS. The communities behind these projects have collectively delivered more than 1,300 releases, at an average of about 5 releases per year, per project.

Mounting evidence supports the view of open source as a cornerstone of application development and IT infrastructure. The Black Duck KnowledgeBase of over 200,000 open source projects provides our customers with important project vitality information, as well as license and other metadata, to support making good choices when selecting components.

Eran Strod
Director of Product Marketing
estrod@blackducksoftware.com

Edu4 is a company based in Nantes, France that markets distance learning tools and multimedia equipment for education. Until a recent lawsuit, they were known primarily only in France.

From their website: they were founded in 1987 and in the past 20 years have grown to have 70 employees. They are ISO 9001 certified which, if you are familiar, requires an incredible amount of hard work and discipline. Unfortunately, that certification is being overshadowed by their failure to comply with the obligations of the GPL license and then fighting it all the way to the Paris Court of Appeals.

The Court’s ruling is available on the web (in French) at http://fsffrance.org/news/arret-ca-paris-16.09.2009.pdf

Two weeks ago if you googled Edu4, you probably would have seen all kinds of links to articles about their various activities and accomplishments. Now, you see prominent articles about their GPL violation and their lost court appeal. Edu4’s brand has been severely tarnished.

One of the unique aspects of this case is that an end-user of open source (not just the holder of the copyright) sued violators of the GPL and won. This clears the way for other French users of open source to take legal action when they see a license violation. The preamble to the GPL license (versions 2 and 3) explicitly states that if you distribute (or sell) copies of a GPL program, you are required to give recipients source code and the rights to copy, distribute and modify the code.

During the litigation process it was discovered that Edu4 had removed copyright and license notices in the software. It’s amazing how many times I’ve talked to developers who naively believe that removing these notices either eliminates the obligations, or that it will not be discovered. This rather public example should help debunk those myths.