[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposed wording for the SC modification

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 
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.


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: