Could we list some of the things currently in Fedora that are affected by this? For instance, anything using the autodownloader that hansg worked on would seem to be affected and would need to be removed (which, I believe is a reversal from the results of discussion when hansg wrote it.)

Yeah, would be good to know exactly what the impetus behind this is, and what packages are thought to be on the chopping block. In my eyes, this is a mighty slippery slope...

The autodownloader games would not be affected, as they are downloading content, not code. I worded it carefully to handle that case.

The impetus here is that a certain large software vendor wants to add software to Fedora which does not serve any useful purpose unless it downloads a large binary chunk of precompiled static software (which is non-free). The software they want to add to Fedora is under a free license, and they are attempting to make the argument that such behavior is not explicitly forbidden by our guidelines.

Also, FWIW, I am unaware of any existing Fedora packages which would be removed as a result of this additional guideline text.

All the crap which only works with the nvidia driver: libvdpau, libXNVCtrl and similar junk. The now-retired libflashsupport would probably also have failed that test, as it's of absolutely no use without the proprietary Flash. And FWIW, IMHO that's a good thing, we shouldn't ship that stuff, to me it's just common sense (and I don't understand why we voted to allow libvdpau).

There's one issue I can see with the wording: it only talks about the legal prerequisites. E.g. "If the dependencies are legally acceptable for Fedora, then they should be packaged and included in Fedora", but what if they're kernel modules? (Or is the intent here to legalize appropriately-licensed third-party kernel modules if they're required for applications to work? ;-) FWIW, I'd also vote in favor of that, but I think I'd be alone. :-( )

I think a reasonable case could be made for standalone FOSS libraries as being useful, even if there is not currently any FOSS applications using them. Having functional library APIs encourage free software developers to code applications using them. Nevertheless, FESCo would be the arbiter of "useful".

The intent is not to permit kmod packages, this does not introduce that sort of a loophole. In fact, it would probably prohibit any applications from being included in Fedora which depended on third-party kernel modules to be "functional or useful". To clarify this, I'd suggest rewording that sentence to drop the word "legally":

If the dependencies are acceptable for Fedora, then they should be packaged and included in Fedora as a pre-requisite for inclusion of the dependent software.

So what I was trying to get at, was "is this supposed to be a way to revert the decision to let libvdpau in", which Kevin apparently thinks it could be, but spot says is not the case.

The distinction that I think needs to be made then, given spot's explanation, is that it can't be software that requires non-free, legally unacceptable, or binary-only bits on the same system to be useful. If the free software is useful to talk to another system or device on the network regardless of it being non-free, legally unacceptable (to Fedora) or binary-only, I don't see how you could reject it from being in Fedora.

For example, most networked printers are non-free with binary-only software running on them, but I doubt if we're going to yank printer drivers out of the distribution. I'm not aware of any Amazon EC2 server I can install on a Fedora host, so all the EC2-related packages in Fedora aren't useful without a system (or systems) running non-free software to talk to. And so on.

That's a good clarification. Here's a rewording that takes that into account:

== Packages which are not useful without external bits ==

Some software is not functional or useful without the presence of external code dependencies in the runtime operating system environment. When those external code dependencies are non-free, legally unacceptable, or binary-only (with the exception of permissible firmware), then the dependent software is not acceptable for inclusion in Fedora. If the code dependencies are acceptable for Fedora, then they should be packaged and included in Fedora as a pre-requisite for inclusion of the dependent software. Software which downloads code bundles from the internet in order to be functional or useful is not acceptable for inclusion in Fedora (regardless of whether the downloaded code would be acceptable to be packaged in Fedora as a proper dependency).

This also means that packages which are not functional or useful without code or packages from third-party sources are not acceptable for inclusion in Fedora.

This proposal was accepted.