Hello, On Apr 30 11:35 Olaf Meeuwissen wrote (shortened): > Johannes Meixner <jsmeix at suse.de> writes: > > On Apr 24 16:35 Olaf Meeuwissen wrote (shortened): > >> Johannes Meixner <jsmeix at suse.de> writes: > > > > Because of legal issues we cannot do anything automatically > > with proprietary stuff. ... > When a proprietary model requires a proprietary package that does not > mean that SUSE (or any other distributor) has to provide it. What > distributors can provide the user with is a means to conveniently > download the required package from its "canonical" location and > install it. This of course after warning the user that they are about > to download and install third-party software that is absolutely not > supported by their distribution, that is non-free ...
Yes. But this is not the "automatically" which I mean. When I say "automatically", I mean something without user interaction. A user dialog is what I call "manually" - i.e. the user must actively do something - even if this "something" is perfectly guided by YaST. > This can be as simple as the following proof of concept: > > wget $url_to_proprietary_package > rpm -U $package No. Before the wget I would have to show the right proprietary license dialog so that the correct proof of concept is: wget $url_to_license_text show the proprietary license dialog if the user accepts the license then wget $url_to_proprietary_package && rpm -U $package else show a "it cannot work" message. This leads again to the same old question: What are the reliable fixed URLs for the right versions of your proprietary packages? And to a new question: What are the reliable fixed URLs for the right license text for the right version of your proprietary packages? Note that on the usres's computer an older version of the epkowa backend may run. I would have to make sure that YaST downloads the right version of the proprietary package. For example our business products Suse Linux Enterprise Server (SLES) and Suse Linux Enterprise Desktop (SLED) have a lifetime of several years (about 5 years, sometimes even longer). Usually there are no package version upgrades during lifetime (except for severe bugs, e.g. security issues, but e.g. not just because there are some more supported models or some new features) so that it can happen that a SLES/SLED user runs a 5 years old epkowa backend. Compare https://answers.launchpad.net/hplip/+question/30595 I cannot have the license texts preinstalled. Guess what happens if a user finds them and wonders why the hell he has proprietary software installed (otherwise there would be no proprietary license text) and where the hell this proprietary software is installed? Don't have only usual home users in mind! Think about enterprise admins who do care about the exact licenses of their installed systems (e.g. the workstations where SLED runs). I will never ever risk any tiny license issue with any of our customers because of whatever quick and dirty "proof of concept" hack with proprietary software. I cannot even have the license texts on our CDs/DVDs and install them only just before YaST shows them because the license texts on our CDs/DVDs might be outdated for the actually downloaded proprietary package (have the possibly 5 years old SLED system in mind). If I would implement something like the "proof of concept", I need the currently right matching license text downloaded at the same time as the proprietary package is downloaded. I need the currently right license text separated before any proprietary stuff is stored on the system. I will not download and unpack any proprietary stuff and then show the license dialog. Alternativery provide a free "iscan-setup" tool which does all what is necessary regarding proprietary stuff. I can call such a tool from YaST if a model is set up which requires proprietary stuff. > What are the _legal_ issues with this? Do you really want an authoritative answer? As soon as the Avasys lawyers and our lawyers start a discussion about the legal issues, you can probably wait very long until I might start to implement something. Perhaps in the end everything is very simple but likely the lawyers need much time until the issue is finished. Just trust me and provide what I request to get good support with reasonable effort in a reasonable time or you might get no support at all (depending on what the lawyers do). > Above I was thinking along more generic lines. Stuff that > would work for all proprietary crap, > not just what comes with iscan. Usually each proprietary stuff has its own special issues (which are introduced by each special proprietary license) so that usually each proprietary stuff requires its own special handling. The proprietary crap form HP is ideal because there is nothing a distributor has to care about - just provide HP's free stuff. > Small correction: it is not Avasys' proprietary stuff. The > proprietary stuff is EPSON's, Avasys is just(?) doing the > development, testing and distribution. A good example why I must get the right proprietary license text from an URL from you so that the right spelling is shown to the user. Think about the very unlikely case that company names change which might make a pre-installed license text outdated (have the possibly 5 years old SLED system in mind) e.g. when a company which does no longer exists with this name grants an old license for a package which is downloaded and installed right now - I am no lawyer but this looks at least plain wrong. Alternativery provide a free "iscan-setup" tool which does all what is necessary regarding proprietary stuff and I would no longer have to care about proprietary issues because then it is totally up to you. > > Again I request to split any non-free stuff from IScan > > (i.e. the whole content of the non-free/ source directory) > > and provide the iscan frontend as separated package. > > I'd love to ditch that directory but there is no viable free > alternative for libesmod at the moment and without it there's > not much point in using iscan, really. Perhaps my request was not clear enough: I request to split any non-free stuff from IScan (i.e. the whole content of the non-free/ source directory) to have free sources for the epkowa backend and whatever else free stuff in IScan (e.g. a iscan-setup tool) and provide the free sources as one source code package and on the other hand provide the iscan frontend with its proprietary library as separated source code package. > > We will support this for printers in the future, see > > http://en.opensuse.org/Image:Printer_mschmidkunz_rc2_driverwizard_greyed.png > > (note the preselected "[X] Show Only Free Software"). > > For the full story see > > http://en.opensuse.org/YaST/Development/Printer_Enhancement > > Looks interesting. Any plans to integrate scanners and all-in-ones? As soon as scanner stuff appears at the LSB/OpenPrinting server, we will of course think about how to integrate them too. Currently I don't know if and how LSB compatible packages could be provided on another server. There are discussions regarding trust. E.g. how to make sure that what is downloaded from whatever URL is actually what was tested and certified by the LSB. See the mail thread with subject "There is no good package management for LSB packages" on the lsb-discuss at lists.linux-foundation.org list: https://lists.linux-foundation.org/pipermail/lsb-discuss/2008-February/004642.html in particular see https://lists.linux-foundation.org/pipermail/lsb-discuss/2008-February/004647.html I answered too but unfortunately only on lf_driver_backport, see https://lists.linux-foundation.org/pipermail/lf_driver_backport/2008-February/000201.html > > To make a maximum number of users and distributors happy, > > provide well separated packages: > > - One free software package for all architectures > > which contains the epkowa backend and the free > > iscan-setup tool. > > - One proprietary package for those architectures > > which you like which contains the iscan frontend. > > - For each proprietary model a proprietary package > > for those architectures which you like which contains > > the proprietary plugin. > > - For each proprietary model which needs firmware upload > > a proprietary package for all architectures which contains > > the firmware file. > > If it were up to me, I'd do the same. The above is the only thing > that makes sense from a software design perspective. The above is also the only thing that makes sense from a legal/lawyers perspective. I must split always the proprietary stuff manually from the IScan sources to make our iscan-free package because I cannot provide proprietary stuff in our iscan-free source package. (I explained this a long time ago in exhaustive detail.) > > Note the difference: > > Proprietary plugins are architecture dependant. > > Firmware files are not architecture dependant. > > I'm well aware of the difference but as long as Avasys still uses this > manual download method for packages ... you wouldn't want to download > four packages by hand just to get your device working. Even now, with > only two, people forget to download the plugin. I noticed the issues. But what hinders Avasys to make big all-in-one packages for the different kind of models? I talk about how to split the sources and how to provide the sources so that distributors and lawers are happy. Avasys is of course totally free to take all sources and make one big-and-fat all-in-one binary package with all plugins for all models or several all-in-one binary packages with only one plugin for each kind of model or whatever Avasys likes. Do not mix up source packages and binary packages! Clean up your sources! Provide clean source packages! Make it easy for the distributors to make very most of your users happy out of the box. Optionally provide whatever binary packages you like for those cases where the distributors cannot make your users happy out of the box. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
