[packagekit] Triggering EULA dialog?

[Richard Hughes]

On Thu, 2009-02-05 at 13:37 -0800, Dan Kegel wrote:
> On Thu, Feb 5, 2009 at 8:59 AM, Duncan Mac-Vicar Prett
> <dmacvicar at suse.de> wrote:
> > Dan Kegel wrote:
> >> Egads.  You mean it's not even inside the package?
> >> If somebody takes the .rpm elsewhere, and installs it,
> >> the EULA won't be displayed?
> >> That's surprising.
> >
> > Sure, it is not an rpm feature, but a package manager feature.
> > Also features like the package manager only displaying updates that
> > require a reboot or restart of the package management engine are usually
> > on top of rpm, and exposed in the metadata.
> 
> Does the same thing go for flagging a package as containing
> a security update?

Yes, as the metadata doesn't belong to the package, it belongs to the
distro. Be aware that that is just the way it's done for rpm -- if you
are using deb or another packaging format you could store the data in
the package itself. If you store the update data in the package, you
have to download the package before you can provide the user the details
about whether he wants to download the package. Catch 22.

> It would be nice if this kind of metadata was standardized
> and incorporated into .rpm, so all the information needed
> to properly install a package was packaged up in the package
> file (which I believe was the original intent of packages,
> hence the name :-)

Sure, you could do that. If you defined a standard that all EULA text
was stored in the package file, it would be trivial for PackageKit to
run a post-inst rule -- but then you've got the main problem for this
approach -- what if the user says "no".

Most EULAs are required to be agreed to _before_ the package is
downloaded on the client computer. Nearly all have to be agreed to
before the install starts -- if we add EULA facilities as a post-inst
script then the files are already on the users computer -- ctrl-c the
package manager and you've got the content without agreeing to the EULA.

Put the EULA in the metadata, and this means you can ask the user before
the package is downloaded, and certainly before it is unpacked.

> That would also make it easier for ISVs trying to maintain a
> repo.

It might make it easier, but your lawyers would be spitting feathers.

> At Google, we maintain one for our client apps,
> and we've been told we're missing a trick or two
> in the metadata.  It's quite a burden to discover how
> to run the various flavors of repositories correctly.

Right, I think it's only the opensuse guys that support EULAs in
PackageKit, a fedora repo has no mechanism to store the EULA at the
moment. I believe there was some work done to integrate it in the yum
metadata a few months ago, but I don't know how fruitful this was.

Basically, I believe the concept of a EULA is broken, if it comes with
the package itself, or if it's required as a click through to access the
package itself in an free-to-access public repo. The only way it makes
sense is physically on a bit of paper that comes with the physical
media, and even then it's legally dubious.

I guess it's pretty impossible for a company to enforce a EULA when:

* You could write a front-end tool to ignore the EULA metadata
* You can just extract the package file without running the scripts

>From a legal point of view, what are you actually trying to achieve?

Richard.