Philippe Ombredanne

As the presentations discuss, identifying dependencies can be a tedious task. It depends on the software project itself, as well as the used technology stack how certain dependencies can be identified. In the panel discussion about the special stories when trying to identify all dependencies.

Package URLs are a compact way to identify software packages across multiple ecosystems. Together with the new "vers" Version Range Specifier, these two mini specs will offer a new way to create new, mostly universal dependency resolvers and installers, working across ecosystems.

Because no tech stack is an island running on a single programming language and in a single package ecosystem, we need a way to talk about packages across ecosystems: talk about their type, name, location, version and dependent version ranges. purl and vers are an attempt to solve this problem.

How to talk about packages, dependencies and vulnerabilities using a common language?

I will present Package URL, a way to references package across ecosystems which is emerging as a de-facto standard. And I will introduce a new work-in-progress, mostly universal notation to express version ranges to be used in resolving package dependencies such as "I require package foo, version 2.0 or later versions" and referencing affected vulnerable packages versions as in "vulnerability CVE-123 affects package bar, version 3.1 and version 4.2 but not version 5".

These two will show a way to create new, mostly universal dependency resolvers and installers, working across ecosystems and we will promote the rise of universal package managements where one tool and one unified spec can rule them all.

The devroom intro by devroom organization team!

If we come to this presentation: A big thank you for all persons who have submitted their presentation and many thanks for all attending.

This is a presentation of the latest features and updates in ScanCode toolkit and its companion projects.

ScanCode toolkit is an open source scanner that thrives to provide best-in-class license, copyright and package manifest detection and data collection.

This session presents the current, latest and upcoming features and developments, as well as new projects, data and tools to enable FOSS SCA.

Welcome to the Software Composition Analysis Devroom

This presentation introduces the devroom on software composition - an emerging topic on understanding what softare is being made of.

All small businesses are short on money and time, often putting free and open source software compliance (FOSS) at the bottom of their priorities. But FOSS compliance is not merely a matter of legal risk, it can deeply affect a company’s reputation and with it, the ability to hire engineers, form partnerships, and present a good external image. Moreover, a basic level of FOSS compliance is generally a must for companies going through funding rounds and M&A events. And a compliance journey also implies understanding the provenance of third-party software in use with other applications such as security or quality.

Traditionally, FOSS conferences have featured presentations by large companies that begin with “my Open Source Program Office handles…”. They describe tooling and processes for companies with thousands of employees, none of which small companies can even attempt to replicate. What small companies need is a way to prioritize their tasks and risks and to break down the process of getting into compliance into discrete and tangible steps supported by free and open source compliance tools. Some steps make sense at a one person company, others at 50 and yet others at 500.

This presentation aims to help small businesses understand:
-the basics of what is necessary to be compliant with most FOSS licenses,
-which products pose the highest FOSS compliance-related risks,
-which entities are most likely to cause legal trouble for them,
the first steps they should take on their journey to becoming compliant,
-the common challenges in early compliance efforts,
-an overview of what comprehensive compliance should look like at -the end of the compliance journey,
-and what are the free and open source tools they can use to fulfill their compliance tool needs for efficient and cost effective compliance automation.

Several prominent FOSS projects have changed their FOSS licenses to alternate licenses that make software available, but with additional restrictions intended to help financially sustain FOSS development and combat "strip mining" by software-as-a-service providers. Additionally, recently several related organizations have jumped into the the role of helping sustain open source by providing (for a fee) funding conduits, fundraising services, or other mechanisms to route money to maintainers.

Affirmative position: FOSS benefits from sustainability efforts

1. First Affirmative Constructive (1AC) = 7 minutes a. Cross-examination of First Affirmative by Second Negative = 3 minutes
2. First Negative Constructive (1NC) = 7 minutes a. Cross-examination of First Negative by First Affirmative = 3 minutes
3. Second Affirmative Constructive (2AC) = 7 minutes a. Cross-examination of Second Affirmative by First Negative = 3 minutes
4. Second Negative Constructive (2NC) = 7 minutes a. Cross-examination of Second Negative by Second Affirmative = 3 minutes
5. First Negative Rebuttal (1NR) = 3 minutes
6. First Affirmative Rebuttal (1AR) = 3 minutes
7. Second Negative Rebuttal (2NR) = 3 minutes
8. Second Affirmative Rebuttal (2AR) = 3 minutes

License Compliance has become big business. Many proprietary tools exist, but fortunately in recent years FLOSS tools to aid understanding the licenses of codebases have been created. This panel includes developers of many of these freely available tools. We'll discuss what these tools do, if they can actually address compliance problems in the wild yet, and the general challenges of developing freely available tools in a heavily proprietarized industry.

Panel discussion with some of the speakers from the Package Management Devroom throughout the day, discussion the future of package management.

Let's debabelize the way we identify and locate software packages across tools, databases and APIs with the new purl aka. package URL!

We build and release software by massively consuming and producing software packages such as NPMs, RPMs, Rubygems, etc. Each package manager, platform, type or ecosystem has its own conventions and protocols to identify, locate and provision software packages.

When you need to track and store information for various packages, it is difficult to reference these across tools and package "ecosystems" in a clear and uniform way.

The purl aka. "mostly universal" package URL is born from a grass-root initiative to provide a simple spec and libraries and solve this problem: standardize existing approaches to reliably identify and locate software packages.

A purl is based on the expressive syntax of familiar URL strings: these are easy to grok for humans and machines alike and can work consistently across programming languages, package managers, packaging conventions, tools, APIs and databases.

A purl could be useful:

• To reliably reference the same software package across inventory and scanning tools, .
• In cross-system metadata indexing, aggregation or alerting systems that collect, catalog and monitor packages information such as versions, dependencies, licensing, etc. across multiple package managers,
• When tracking known vulnerabilities of a package or its dependencies, and eventually relate the multiple incarnations of a code package across packaging systems,
• And many other kinds of analysis, such as building dependency graphs of packages, etc.

Can you tell exactly which source files are built into your binaries? Any sufficiently large build feels a bit like magic! Join me to explore how you can debug your build by stracing it and rebuilding a build graph of files and tools transformations.

Some applications for this knowledge:

• better control of which subset of the code you use and depend on.
• general build hygiene and debugging such as pruning obsolete or dead code.
• build optimization

And answer some questions such as:

• if a file is really used or not and where it is used and what for.
• how it was compiled and combined
• what are your build dependencies.

I will present a TraceCode, a FOSS tool that uses build-time syscalls tracing to reconstruct your build graph. Using build tracing with strace (disclaimer: I am a small-time contributor to strace ), you capture a complete trace of all the systems calls happening during your build.

The trace is then parsed and processed to reconstruct the build graph of your binaries as a directed graph of files transformations over tools such as code generators, scripts, compilers, assemblers, linkers, etc. This requires NO modification of your build at all.

The graph can then be analyzed for fun and profit, including creating fancy dot graphic visualizations and can help understand exactly which files were built, by what and how they were transformed in multiple steps from sources to your final binaries.

As a bonus, I will also present new FOSS extension that perform similar build reversing but using static analysis only.

A distro package environment such as Debian and a language-focused package environment such as npm may seem very similar at first. But underneath, they are very different in their goals, features and approach to create packages and manage dependencies.

Some package management environments are bazaars and some are cathedrals. What does this mean? Join me for a tour of horizon to compare and contrast the goals and ways of key package package management environments: What's their purpose? How we use then and how they are meant to be used? How do they deal with dependencies differently and why? Who creates and uses the packages?

A clear answer to these questions can help to better leverage these package environments, management tools and repositories or registries.

Software is (often) distributed as binary. But where is the corresponding source code? Given a binary, how can you find out which source code was used to compile?

Using advanced techniques and open source tools, we can find out which source code was built in a binary. The applications are important for FOSS license compliance and/or enforcement as well as general code hygiene and build sanity.

Can you tell exactly which files are baked into the binaries of the software you build and distribute?

There are many applications for this knowledge:

• facts finding for FOSS license compliance and enforcement.
• better control of what third-party code you use and depend on and their related FOSS license requirements.
• general software and build hygiene such as pruning obsolete or dead code.

With clarity on what's in your binary, you can better understand:

• if a file is really used or not and what it is used for.
• if and how files are linked together such as static vs. dynamic linking.
• if some extra files are pulled from network repositories at build time.
• what are your build and runtime dependencies.

We will review why this does matter, present available FOSS tools and techniques to get back to the corresponding sources from built binaries using dynamic build tracing and static analysis; and the applications, usage and caveats of these techniques for various programming languages and platforms.

So join me and let's find out what's in your binary!?