Ean Schuessler wrote: > I'm sorry, but I am dense. Please help me understand. If I have a > Microsoft device and they provide an opensource Linux installer which > ships a Windows Mobile based firmware then how would this not meet your > distribution criteria? When considering Silverlight(tm) development > tools this use case is not even far-fetched. > > I made the mistake in my earlier message of saying "main". I should have > said "sourceless". In either case, the firmware in question could be > distributed as part of our standard install images. I guess I must be dense as well, because I really have no idea what you're talking about. Why would we ever want to include something like that in our installer images? How would such a phone be used here? Are we installing Debian onto the phone or what? If I do read you correctly then the installer you are talking about is some user space app that would be used to for example upgrade the firmware in a phone that is _not_ running Debian, but can maybe be connected to a system that does run Debian via USB. I suspect we already have examples of such utilities in Debian, and, as this for its primairy function (firmware update to external device) depends on something that at best belongs in non-free (IF we are allowed to distribute it at all), but is a lot more likely to be downloaded by a user as needed, I'd expect to find that open source installer in contrib. One huge difference here is that this would be a _service_ to the external device (upgrading its firmware while it is already running and usable). In this case loading the firmware onto the device is not a "requirement to make it function as a peripheral device to the Debian system", the use case we're primairily interested in. I don't see any use case requiring either this installer of yours or that firmware to end up in our installer images. Anyway, I'd really prefer to concentrate first on the use cases that this GR is actually meant to solve instead of such, at least as far as I understand you (which may well be not at all), contrived, extreme examples. Let's first concentrate on whether we actually want to support those normal use cases and then worry if we maybe need further restrictions or tightening of definitions to prevent abuse in weird use cases. Or, maybe you can propose an amendment that clearly describes the holes you see and intends to close them? In the end there is still always something like common sense in the application of rules too. Problem now is that we have absolutely zero room to maneuver. I intend this to be my last contribution in this part of the thread. Cheers, FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.