ThirdPartyPackages

Summary

Some software cannot be incorporated into Ubuntu's comprehensive package repositories. We should explore options for providing Ubuntu users with convenient access to such software.

Rationale

As Ubuntu gets bigger more and more commercial vendors are interested in providing their software for Ubuntu. We need a convenient way to install this software. Currently installing software that is not inside our archives is harder than it needs to be.

It is possible to provide various levels of support to the vendors. In the simple case we help the vendor to make it easy for our users to discover their software and install it. This can be done via gnome-app-install and by providing support to install debs that are designed for Ubuntu. At some point in the future it may involve supporting some infrastructure to pay for software and issue license keys.

Use cases

  • Alice wants to install a commercial image manipulation application. She installs it from the "commercial" component in gnome-app-install and gets a activation key directly from the vendor.
  • Bob wants to install skype. It is provided as a .deb downloadable from the vendors site. He downloads it via mozilla and sees a dialog that tells him about missing dependencies and whether he wants to install software off the Internet. He installs it and gets a working skype this way.

Scope

This spec covers Ubuntu, the front end initially covers gnome.

Design

There are two different use-cases that we want to support. The first is to provide commercial software with gnome-app-install that can come from external vendors. The second is to support direct installs of debs.

Extending gnome-app-install

Gnome-app-install already contains desktop files for the available applications in universe and multiverse. Those desktop files contains the keys: 

X-AppInstall-Package=synaptic
X-AppInstall-Section=main

This mechanism will be extended for proprietary applications to include additional keys. The critical factor here is the concept of channels. A channel is a way for the vendor to provide software. Technically it is a sources.list fragment with additional meta-information that will be added to /etc/apt/sources.list.d/ (support in apt for this needs to be written/merged). The meta-information includes a icon for the channel and desktop-files/icons for gnome-app-install. We can use this pseudo desktop files for things like server applications as well.

The channels will be provided with a "proprietary-channels" package. Updated versions of that can be put into "dapper-updates" if new vendors join in. The sources.list.d fragments points to a repository setup by either the vendor or by us (if the vendor pays for that).

The vendors will have to send us updated channel information if e.g. if they put more user-visible packages into their repository or if there are URL changes. The proprietary-channels package is updated then.

The following information for proprietary applications is required:

  • Proprietary: yes/no
  • what channel the application is in (for g-a-i)
  • Charge: free-beer, trial, pay (to display to the user)
  • More-Information-URL: the url that points to the license/prices
  • Redistribution: yes, no, limited

The following information is put into the channel package for each vendor:

  • sources.list.d fragment that points to the archive of the vendor
  • some information about the channel and possibly a icon
  • key for the archive of the vendor
  • desktop files for gnome-app-install and icons for it

After turning on proprietary gnome-app-install will install the proprietary-channels package and read the additional information in it. The user can then search (or browse) the commercial offerings. If he decides to install one of them he will be subscribed to the vendors channel (his sources.list.d/ will be updated) and the package he selected will be installed. From this point on the vendors packages are in the normal "apt" space and available with apt/synaptic/aptitude. For packages that require the user to pay (and that are not usable without) a warning is displayed. This will ensure that the user does not download a big application, only to discover that he won't be able to run it without paying for an expensive key.

In order to support hosting of proprietary software on our servers we will need to create a new component, called (to be confirmed) "proprietary". This is where we will store debs for software that is supported by somebody, but is non-free and possibly non-redistributable. It must go into a separate pool to make sure that it's not mirrored.

It's the vendors responsibility to support security updates in it's channel. We can't do better than the vendors here and we rely on them.

installing debs directly

We also provide a convenient way to install deb files directly in a safe way. The user should be able to see what the debs contains (description, files) and the dependencies need to be analyzed and we have to check if they can be installed.

Future

In the future we may support keymanagment/payment ourself. This should probably integrated into launchpad. We may also support repositories that are "lockable" and that are only unlocked after some transaction.

Implementation

GUI

The option to turn on the proprietary channel/repository should be easily discoverable, so it will be on the front page of the Add Applications tool.

We will add these two checkboxes to the front page of the "Add Applications" tool (gnome app installer): 

    [x] Commercial software
    [ ] Unsupported software

This will turn on the universe / multiverse / commercial components in the following fashion:

Unsupported OFF

Unsupported ON

Commercial ON

commercial

commercial, multiverse, universe

Commercial OFF

(main, restricted only)

universe, multiverse

The commercial application component should remain turned off by default in Ubuntu.

Install debs directly

To install debs in a safe way, there are two options. One is to add support for it to libapt itself. There is a baz branch for this in "apt--local-install--0". The current patch is rather intrusive and the apt maintainer does not particularly like it.

The other alternative is to provide an application (which can be part of the apt package) that will analyze the deb and its dependencies. If they can be satisfied it will be installed, otherwise it won't.

Code

Install debs directly

Some prototype work is being done to install deb files directly in the bzr archive at http://people.ubuntu.com/~mvo/bzr/gdebi--main

There are also test-packages available in Dapper or at: 

deb http://people.ubuntu.com/~mvo/gdebi/ /

Outstanding issues

What is a good list of proprietary applications to have?

we could look at this list for more ideas: http://www.ubuntuforums.org/showthread.php?t=80295

  • OPINION ONLY: This method still suffers from the "you can only install what Ubuntu makes available" problem for new users, ie you add staroffice to a repo but the user wants wordperfect. What would be nice is if a user was able to install applications in a "space" that could not damage/effect the base(Ubuntu approved) system in anyway. Klik(http://klik.atekon.de/) does this nicely, not sure how it could work just putting it out there

Comments

Please, check the following link for package installation options: How to install ANYTHING in Ubuntu!http://monkeyblog.org/ubuntu/installing/

A distinction should be made between commercial and proprietary. These are not the same! http://www.gnu.org/philosophy/words-to-avoid.html#Commercial http://www.gnu.org/philosophy/categories.html -- Jeroen van Splunder

  • In this case, it is both "commercial" and "proprietary". If an app is free, Ubuntu would probably have distributed it on its own. On the other hand, there seems not much interest to package any software which is non-free and non-commercial. We have interest in this sort of apps usually because it is forced by a vendor, which does not believe in free software, while unfortunately their software is in wide use. -- AlanTam

Could it be possible to remove all kde apps from the list if the default desktop are gnome. it should be possible to show the kde apps with a radio button. -- Alex Thomsen Leth

  • In the point of view of a useable desktop, I don't see the need to distinguish between GNOME and KDE apps. It will be confusing to the users as well.

How about instead of a single official repository, a repository white-list is implemented? This list could contain all the official Ubuntu repositories, Commercial repositories that obide by a set of guide-lines and other 'safe non-ubuntu' (known non-spyware) repositories (eg debain).

Such a list would also enable a safe way to 'single click' web apt-get. eg ThirdPartyApt. -- ArwynHainsworth

Info (!) Note to those who are still commenting on this spec: it has been implemented. See the launchpad spec tracking page. (mdke)

CategorySpec

ThirdPartyPackages (last edited 2008-08-06 16:28:30 by localhost)