Corporate pressure

Mike A. Harris mharris at redhat.com
Tue Feb 3 08:01:53 UTC 2004


On Mon, 2 Feb 2004, david paeme wrote:

>wouldn't it be a good idea to include some kind of license acceptance
>mechanism into apt/yum/rpm? 

It is an explicit goal and requirement of RPM that all RPM 
packages must be installable without user input of any kind, in 
order to facilitate automatic unattended installation, or 
installation/upgrade from cronjob/script, etc.

I don't know apt or yum's policies or goals in this regard so 
I'll let their respective authors, etc. answer for them though.


>for example, to get adobe acrobat to install, the user would get a
>prompt to accept the adobe license, which he can (and the software
>installs), or not (so, it doesn't install...).

Again, unacceptable to rpm.  That belongs in some frontend, 
either yum/apt/up2date or some Installshield type of rpm package 
wrapper install tool.


>software vendors will probably like this, because they can the user to
>accept their license, and not having people install the software without
>doing that. 

They can do that already if they want, by supplying a wrapper 
application with the rpm payload inside of it.


>and this could work for just about anything (java, flash, binary drivers
>like those from nvidia, etc...)
>
>also,the corporate weight of redhat -- or even some high-profile people
>like ESR or AC -- could help persuade the companies.

For the case of yum or apt, Red Hat has no say whatsoever in what
those project's respective developers put in their applications
as features.  While I personally am indifferent, many other
people would be likely to oppose such changes as they would help
to promote the usage of proprietary software and make it easier
to use.

Outside of yum/apt, it would be entirely in the domain of some
wrapper application that pops up a text and/or GUI dialog to
handle the installation, get the user to accept a EULA, and then
either calls rpm directly after the user has accepted, or uses 
rpmlib to do the dirty work.  In both cases, it's up to the 
application vendor to write their own custom installation app to 
do this, or to look for a pre-existing framework out there that 
does it already. I believe Loki games OSS'd something like this, 
but I don't remember for sure.

There's little benefit for free software community for us to 
develop some proprietary software installer frontend, so it's 
unlikely IMHO that anyone here would write something like that 
and try to peddle it to 3rd party proprietary vendors (for free 
or for $$$).

If proprietary vendors aren't interested in doing such though, 
but certain people in the OSS community are, they should approach 
those vendors to either politely try to convince them to do so, 
or to volunteer to do the work themselves if the vendor allows 
it, as was the case for Nvidia.

I'm not sure where someone like ESR or AC fit into the picture.  
They would both be good candidates for trying to convince a given 
vendor of the merits of OSS and trying to get them to OSS their 
software of course.  But I'm not sure a vendor is likely to care 
about how their stuff is packaged and wether or not it meets some 
"easy to install and use in Linux" thing that they have to 
implement themselves.  At least not until they see some "critical 
mass" form that makes their radars blip.

Just my personal opinion on this anyway.

-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat





More information about the devel mailing list