[packagekit] EULA Prompts

Richard Hughes hughsient at gmail.com
Mon Dec 3 10:23:04 PST 2007


First things first: I'm not a big fan of proprietary software. I know it
sometimes has to exists, and lots of people already use it.

Proprietary software usually requires agreeing to a EULA (or other
special licence or terms of use). The EULA can be per-repo (e.g. livna),
per-package (flash) or per-group (vmware-*)for packages. It can also be
per-system or per-user. We need to be able to support each of these in
PackageKit.

We already have RepoSignatureRequired (so we can add a GPG key for a
repo), but I think the issue of repo signing and agreeing to a package
eula is orthogonal, and hence isn't part of this discussion.

Now, I see a few ways that installing proprietary software can be
handled currently in PackageKit:
 * We just don't support installing packages that are non-free from the
GUI or pkcon tools and hide available packages from the search results
 * We silently agree to the licence when downloading and installing the
product, and show a Message() post transaction that we need to review
the licence and uninstall the software if we do not agree to it (legally
questionable)
 * We install the package, and error out (with ErrorCode) if we have to
agree to a EULA of any sort, with the logic that this software will have
to be installed from the console using native tools
 * We install the package, and special ErrorCode which we have to agree
to for a requeue. If we agree, then the transaction is requeued with
additional flags to indicate that the licence has been agreed to. Of
course, nothing stops a client program just doing the install with the
extra flag and not showing the licence at all.
 * We add the licences to a licence database and the user agrees or
disagrees on each one prior to even searching. If the user agrees then
the available licence filter is taken away. This is nicest from a UI
point of view as the user can decide "I want only free stuff apart from
things from livna or vmware" and the search results reflect this. Of
course, this requires the most interaction with the packaging native
backend and would be impossible for most if not all of what we have
already.

What I want to make very clear is that we can't (and won't) support
scripts that just expect input on STDIN - they are just to broken to
workaround. If a script needs input then we should just error out and
Message() the user that the package needs fixing and they should report
it to the vendor. [We need to add this functionality to PkSpawn - anyone
got any ideas how to detect a script waiting on stdin?]

For some more comments, read http://wiki.debian.org/PackageKit

Please reply on list so we can keep the wiki page fairly sane.

Thanks.

Richard.





More information about the PackageKit mailing list