Quote Originally Posted by probono
That would be fine with me, but I am not sure whether debian would allow klik to host recipes for stuff like RealPlayer and Flash even though the binaries wouln't be hosted there. Stuff like RealPlayer and Flash is exactly the reason why I saw a need for klik in the first place.

Where I see more possible synergies is a cooperation with sites like www.kde-apps.org - wouldn't it be awesome to have a klik button next to each app listed there?
Debian has certainly had packages previously which installed external binary non-free software. A debian server won't be able to carry binary non-free data though (afaik) without a struggle (for example binary firmware in the kernel was looked at very seriously). They do already carry the flashplugin-nonfree package in contrib for testing and unstable.

I am however far more concerned about your desires to keep a part of klik itself non-free, the client. I don't think you have thought through some of the ramifications of that decision, and perhaps I can draw some to your attention.

If you have one non-free client, it must support all distributions and releases, not simply Knoppix or else the potential for kde-apps.org to link to you is greatly minimised.

By having a closed section you invite a re-implementation. This could either be that someone simply writes a free compatible client, or else that someone recreates the entire system. I can quickly conjure up half a dozen examples of where people would want their own klik. All this would delay the time before end users see a benefit from this (fractured work).

Some people will not contribute to the project as they fundamentally disagree with placing the control of their work under a non-free licence.

Security through obscurity is no security at all! If you want to protect end users from malicious software, then you should secure the client, not hide it's source! You could use cryptographic signing of the recipies (distro should include a key), include md5sums for all external data, layer the client so that it must remain unaltered as it fetches parts of itself which can in turn fetch further parts (of itself or the recipies).

Why are you suggesting that klik is so useful to hackers? What is special about klik as compared to ssh, wget, bash, perl, etherdump or kppp or ... ?

You have your own focus on klik (kde and knoppix) but others will have different ideas. By keeping the client closed you do not encourage everyone to join in and work on the system to improve it for all, but restrict your system to those who don't mind giving you their code because their exact target is the same as yours.