[packagekit] Triggering EULA dialog?

Dan Kegel dank at kegel.com
Fri Feb 6 04:42:36 PST 2009


On Fri, Feb 6, 2009 at 4:20 AM, Richard Hughes <hughsient at gmail.com> wrote:
> Have you been told you have to do a EULA from your legal department
> or are you doing it "to be on the safe side". I would be interested to know,
> as shipping firefox with a EULA on first run really upset a lot of people.

I think our lawyers want a EULA for the branded version, Chrome, that
people download from our site.  I don't think they are asking for an EULA
for anyone building from our source and distributing it under a different
brand.

>> It would be nice if there were a Repo Metadata For Dummies manual
>> that covered how to properly run repos for all popular distros
>> (or maybe at least all the ones that use Packagekit as their front end).
>
> Right, that's up the distributions.

Yeah, but packagekit.org would be a nice jumping off place for
ISVs thinking of running a repo that supports all those distros.
Might be worth an FAQ entry sometime, pointing to the various
distro doc pages.  e.g.
Q. So Packagekit is a great unifying front end for package management.
Is there also a unifying backend?  i.e. how can I as a software vendor
run a repository that supports all the distros that use PackageKit?
A. Sorry, there's no unified backend.  You can build your software once
using the interfaces in the LSB, but you have to package it in several
formats (at least .rpm and .deb, and maybe .psi if you want to reach Turkey),
and set up four to six different kinds of metadata describing the packages,
one for each distro.  See [links to each distro's repo metadata guide,
link to USB, link to OpenSuse Build Service].

> Being honest, I would argue you're putting the cart before the horse.
> What's wrong with releasing a source tarball and letting the distros
> package it up with the correct build options, library deps and
> buildsystem metadata? It's what distros do best.

We're doing that; see chromium.googlecode.com.  But we're
also packaging it ourself and branding it as Chrome, and running
our own repo, with quick security updates (probably quicker than
the distros can do, as they need to do a second level of QA).

> Again, different distros will have different ideas how to handle this --
> for instance fedora might want each plugin packaged separately and
> installed system wide, but Ubuntu might be happy with installing them in
> ~/.chrome-plugins

Yar, much thinking to be done there.

> I don't think trying to control the distribution channel like this

We're not, as far as I can tell.  Everyone's free to get, build, and distribute
the code, as long as you observe the terms of the source code licenses
(mostly BSD, see http://code.google.com/chromium/terms.html )
and the google terms for any google logos or names you use.
(If you pull an Iceweasel, you don't need to use any of our logos or names,
but I think the terms for the Chromium name and logo are minimal
and shouldn't be a burden even for Debian.  The Chrome (as opposed to
Chromium) name and logo are reserved for our builds.)

> and [I don't think] enforcing a EULA is a smart thing to do, sorry.

Then why does PackageKit offer the EULA feature?
- Dan



More information about the PackageKit mailing list