The need for a system against which people can certify and can also make derivatives is key to the success of Ubuntu. However, the low takeup of the Linux Standards Base by application vendors suggests that vendors are more interested in certifying systems than collections of libraries and paths. This specification provides a middle road that balances these two needs.


Dapper will be supported for five years, which makes it a great platform for vendors who want to support their software on Ubuntu. Ubuntu and Launchpad make it trivial to brand and customize Ubuntu. The conflicting needs of these two use cases require us to define a core of Ubuntu that can be counted on.

The more variables we introduce into the supported system, the more trouble we will have asking vendors to certify. Further, security updates may cause necessary kernel ABI changes causing problems for third party hardware vendors.

Our package naming policy requires that packages that have an ABI change must have a different SOVERSION. Because of this, it is theoretically possible to run a newer version of Ubuntu by including dapper in the sources.list and expect that applications will Just Work. However, this doesn't tell the whole story - configuration file formats may have changed, file locations may have changed (for example, the /usr/doc to /usr/share/doc transition). When something is certified on Ubuntu, there is no reasonable way of capturing all of the depended-on components of the system.

Use cases



Hardware Vendors


All packages included in main.


We have chosen to be conservative when defining the core of Ubuntu.

Supported Branding Scenarios

A branded derivative MUST NOT remove or alter any packages that are installed by the installer. There are three scenarios that are interesting for derivatives:

1. A standard Ubuntu install.

This install includes ubuntu-minimal, ubuntu-standard, ubuntu-sounds, the Linux kernel, and ubuntu-desktop. This environment provides our standard Gnome desktop.

To customise this, a derivative MAY replace the contents of ubuntu-docs and ubuntu-artwork.

2. A standard Kubuntu install.

This install includes ubuntu-minimal, ubuntu-standard, the Linux kernel, and kubuntu-desktop. This environment provides our standard KDE desktop.

To customise this, a derivative MAY replace the contents of kubuntu-docs and kubuntu-default-settings.

3. A minimal Ubuntu Server install.

This install includes ubuntu-minimal and ubuntu-standard. This environment provides a minimum install with no desktop or graphical environment and is suitable for certifying servers and hardware drivers.

Acceptable Brandings

An Ubuntu derivative MAY install additional software from main by default.

An Ubuntu derivative MAY install third-party software by default, but a third party vendor MAY require that software to be removed before accepting bug reports on their software.

If an implementation is certifying against the kernel module ABI, the module MUST either provide updates with each ABI bump, contract with a third party vendor to do this for them (like Canonical Ltd.), or provide binary blobs with module interface components that can be provided in restricted, per the licensing policy.


If Company X wanted to certify their application against the standard Ubuntu install, they should install that and test their applications. A derivative that added an extra piece of software from main in the default install, and a custom machine management application would still remain certified.

If Company Y wanted to provide a sound card driver for their system, they should install and test against the Ubuntu Server install. Because the Ubuntu and Kubuntu installs only include software from main, software certified against the Ubuntu Server platform remains certified against the desktop environments.

BoF agenda and discussion

Oracle FAQ about linux:


DapperStandardsBase (last edited 2008-08-06 16:17:15 by localhost)