[packagekit] Triggering EULA dialog?

Richard Hughes hughsient at gmail.com
Fri Feb 6 04:20:45 PST 2009


On Fri, 2009-02-06 at 03:23 -0800, Dan Kegel wrote:
> On Fri, Feb 6, 2009 at 2:54 AM, Richard Hughes <hughsient at gmail.com> wrote:
> > 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
> 
> True, to some extent, it's all smoke and mirrors.

Exactly. EULAs are not legally enforceable.  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.

> >From a legal point of view, what are you actually trying to achieve?
> 
> I'm trying to identify best practices for running an ISV repo
> of LSB-ish packages.  The repo in question is the one described at
> http://www.google.com/linuxrepositories/
> 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.

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.

> At the moment, I'm trying to figure out how best to package Chrome,
> and am mulling over how updates (of both the package and a user's
> plugins) will work.

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

I don't think trying to control the distribution channel like this and
enforcing a EULA is a smart thing to do, sorry.

Richard.





More information about the PackageKit mailing list