The future of klik: GPL

[probono]

Update: klik is going GPL (dual license like qt), see next page

I have opened this thread to discuss the future of klik. Thanks to all of you who share your ideas on how klik can be made a killer app.

Before we start discussion, let me share some of my personal views about klik:

* Knoppix (or any other system) is the "base", klik is for supplying (relatively small) add-ons.
This means that klik is not designed as a "package manager" that could or should replace apt. Instead, klik is designed to be the easiest way for the user to add, let's say, RealPlayer (which will not be a part of debian anytime soon). Klik is designed for the dialup user who just wants to download the minimum of what he really needs instead of MBs of apt package descriptions. This also means that each klik recipe will be built for a specific version of Knoppix (or any other system) and is unlikely to run on (very) others. klik shifts the task of "package management" away from the user towards the developer of the klik recipe.

* Each klik recipe installs one "self-contained" application (or set of apps).
This means there will never be "dependencies" between klik packages. klik doesn't *want* to have dependencies. The user should always be free to delete an AppFolder without having to fear that this could break anything else. klik is designed for people to try out many new apps just for fun and then decide whether to keep them or not. In cases where several apps share many common parts (e. g. libraries), these packages should be built into one klik recipe (e. g. mplayer, mencoder, kplayer, kmplayer, kmediagrab could well be in *one* klik recipe).

* klik recipes use server-side PHP includes.
This makes it easy to upgrade code that is common to many klik recipes. Ideally, we would have just one "generic" klik code for a certain type of app (e. g. KDE, Gnome, Wine, Konsole apps). Then making each recipe would be quite easy, as it is today already for KDE apps.

* klik should use, but not require deb meta information.
deb packages contain a lot of useful information (e. g. menu entries, postinstall scripts) that could be used by the klik recipes. However, klik should never be dependent on the deb format, but instead also allow for other packages (e. g. RPMs) to be used. Sometimes, there are no deb packages for a certain app which nonetheless runs fine in Knoppix.

* klik should allow the easy integration of non-free apps.
It is a matter of fact that many users want an easy way to add non-free apps to their desktops. klik should allow for that to happen in a legitimate way. Since klik scripts can download packages from the commercial vendors' servers directly, licensing should not be a problem. klik recipes don't "redistribute" software, they simply tell the client where to obtain and how to unpack packages. (*If* this is in contrast to debian philosophy, klik cannot be integrated into debian. Sorry.)

* klik should have *one* central store that is open to all.
What is the greatest pro of sites such as kde-apps.org? Well, it is that they show all the KDE apps in *one* place. I go there, and I know what exists. All sorted in convenient ways. Wouldn't it be even greater if there was a place like kde-apps where I knew each app I see could be installed on *my* system hassle-free with just one klik? Of course this would be much nicer than having to seek for apps in many different places as it is today. Because of that, we should try our best not to have multiple klik stores but *one* store that would have to be open for all. "Open" means that everyone can use and upload klik recipes BUT there must be some sort of quality control built in. Since klik recipes run on the user's machine, they are potentially dangerous. So I envision a klik store that works similar to shalshdot: Everyone can post klik recipes (and improvements) like in a web forum, but they become klikable only after a moderator has "modded them up".

* The klik store should have a system for users to report their success on different (standardized) systems in an easy way. After each klik installation, there could be a screen in the klik client that asks "worked" or "did not work". THe klik client could submit this information, together with the information about the system it is running on, to the klik store's database. That way, people could easily see "runs with Knoppix 3.3 19-11-2003".

* klik recipes could be autogenerated on the server.
Using apt-get server-side, it should even be possible to auto-generate klik recipes server-side for at least some classes of apps, ot at least minimizing the klik recipe developer's effort through "wizards". It should always be possible, however, to hand-write recipes.

* the klik client source should not be open to everyone.
Otherwise, generations of hackers and dialer programmers could use slightly modified versions of the klik client to do their evil thing. I do not want to help them by providing them with the code of the klik client. No question, every hacker could write a klik client like program on their own, but giving it to them openly would allow every "script kid" to do evil things with it. Therefore, I suggest making everything GPL except for the klik client, which would be released as closed-source freeware. People with a long tradition in open source development would get the source code for inspection, but not the general public. Again, this is just to prevent KDE from becoming a platform for dialers and stuff.

* klik allows for easy "software URLs".
What can you remember better - klik:/RealPlayer8 or http://www.mygreatserver.com/downloa...ation/8/rp.gz?

These are my personal thoughts. They are not the only way to to klik, but they are how I envisioned klik when I created it. Some people think klik has the potential to make a huge impact for Linux on the desktop. Sure enough, I am unable to actually build all of this on my own. The future of klik is really what you - the GNU/Linux, debian, KDE, Knoppix, ... community - make of it. I will sure do what I can, but I cannot do it all alone.[/b]

[Vick]

Your are starting in a bad move... you know (win win) or (lose lose) or (win lose) deals. Well your are doing a lose lose project, by starting with a closed or semi closed project that shud not be open to all, that is very bad news for all us knoppix dev and users, the place for a project the way you want it to be, is not the good place for it here.

I told you already make a win win move, make it GPL, and start focusing global with knoppix.

If you are to make it non gpl, then go away with your crap far from us, its insulting the community.

On what i'm starting to see you're are not a winner, from now you are profiting from innocent contributers.

I dont know why people dont open there eyes and stop contributing to scrips or programs that are mining or future and closing it bite by bite. Please stop!, stop! and open your eyes.

It is still time to change your plans dont be blinded by false illusionist (Mirage).

The future is open, the future is freedom, the future is us the open source community and dont forget that.

PS: dont forget that all the code you are using come from the open source, you can use it because it's gpl.

What you done is not an innovation, it already exist and used by stupid closed projects.

An innovation is sumting new, creating something out of nothing.

innovation :
1. The act of innovating; introduction of something new, in
customs, rites, etc.

2. A change effected by innovating; a change in customs;
something new, and contrary to ESTABLISHED customs,
manners, or rites.

You want innovation, then do it the gpl way and not like all others STUPID closed, restrictive rules.

[probono]

closed or semi closed project that shud not be open to all

klik *is* open to all! You can contribute recipes, see the recipes others have contributed, download the source code of the klik client, everything. If you are serious about contributing, you can even code the next generation klik store, just drop me a line.

I told you already make a win win move, make it GPL, and start focusing global with knoppix.

I know, and I am still considering it. But there is Open Source besides GPL, and you know that.

The future is open, the future is freedom, the future is us the open source community and dont forget that.

I belivee the same, that's why I did klik

What you done is not an innovation, it already exist and used by stupid closed projects.

So why do people want klik so badly then? Because it's *not* commercial, and because it's *open*. (To make it even more open, we need server-side infrastructure that is yet to be built, see my first post in this thread.)

Vick, I think we share the same ideal, but I am not sure which way works best in order to achieve it. What I want to create with klik is "the" open and free point-and-klik software store. This is not neccessarily about "technical innovation" but about "end user experience". I want to bring community effort into an area that is otherwise dominated by, well, companies.

[probono]

http://non-us.cdimage.debian.org/ (...) I would set this up for you on my server (which has > 160GB spare, and 100Mbit/s bandwidth)

Would you allow for GPLd Packages that are not in debain to be hosted on that server? That is essential. The problem is not for files that are already in debian, but for files that are not in debian yet but do exist as, let's say, rpm.

I don't really follow the comment about there being 1001 servers being a bad thing.

You can see this at debian itself: It is inconvenient for the (non-geek) end-user to search sites like www.apt-get.org in order to find essential software (such as decent multimedia players) that is not in "official" debian. One package here, another there, and tomorrow they are all gone or the upgrade breaks compatibility with the rest of my system. Here we can learn from Lindows with their less restrictive policy with regard to what debian purists call "non-free" software.

Why would it be bad for Debian to start adding Klik recipes to official packages

Wouldn't be "bad", but difficult to do and I suppose debian purists wouldn't allow it.

have both the klik repository, and the required snapshots be maintained at, for example http://klik.debian.org/

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?

[bfree]

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.

[probono]

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!

Well, in principle you are right. But in this case... the "bad guy" could just take my code, strip out all the security stuff and instead insert "bad stuff", and let people install his modified version. What could you do against that - nothing!

Believe me - I would like to make it GPL rather yesterday than tomorrow. Just - will history then bash me for bringing the "bad" to Linux?

I will watch what people are saying about this and if everyone is for GPL- well, then perhaps indeed we will go GPL real quick!

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.

It's the recipes which are written for a specific underlying OS - anyone is free to write recipies for whatever distro he wants. klik works best with live CDs, though, since these have a known set of apps and libs preinstalled. Other systems can use "package managers". Because Knoppix is probably the world's favorite live CD, I personally focus on this, but klik itself isn't restricted on Knoppix.

[bfree]

It's the recipes which are written for a specific underlying OS - anyone is free to write recipies for whatever distro he wants. klik works best with live CDs, though, since these have a known set of apps and libs preinstalled. Other systems can use "package managers". Because Knoppix is probably the world's favorite live CD, I personally focus on this, but klik itself isn't restricted on Knoppix.

Does that mean the client has no dependencies and will work on any distro (e.g. mandrakemove)? If not klik is unlikely to ever be used beyond knoppix (if even there) as the client is not accessible.

Also, I still don't understand what is so special about klik that it needs to be "secured" like this? How is it different to provide the source to the kilk client then to provide the source to konqueror (or anything else really)? What is going to get people to install a modified "bad stuff" version in the first place? How is someone going to be tricked into installing a dodgy klik?

[mrclark1971]

...hey probono...

First, I want to say that I am new to the Linux community. I am not a true, blue linux newbie anymore but I haven't exactly graduated to the next level yet either...

Second, I applaud your work with what you and the others have done with klik. I have been wanting to see something like this for a while.

Third, I will put in my two cents worth on why you should place all of klik under the GPL.

(A) [You didn't get here by yourself] Linus and all the Linux programmers, Klaus and the Knoppix community (which you are an important part of...), and the rest of the Linux community have placed millions of lines of code and thousands of programs under the GPL. They thought it was important to do so because they are part of the community. That is the philosophy and spirit of the community. I hope you will make that same decision. Remember the community wants to help you with klik...they are excited about klikk! Please don't smear your own important contributions by trying to hold your code back now.

(B) [You won't achieve your contributions full potential by yourself] If you do choose to keep it closed, then you will fracture some others away from you. By doing that, klik will never achieve it's full potential. Linux is like a raging wildfire just because of it's "openness." I hope that you see that (even though you will be the maintainer of klik) it's about "all of us."

(C) [Don't be like Darl... ] Darl, from SCO, is using the same argument in front of Congress right now that you show in your list of concerns. Darl says that Linux, because of the open source model, is a danger to national security. He spews other things as well that you can read on www.groklaw.net at your own pleasure. Despite what Darl says, Linux remains secure. I hope you will not use this as your argument against going under the GPL. [btw, please do not take the above comparison as an insult. I was comparing on your logic not yourself to him... ]

I hope you will take the above [along with what others have posted] as reasons to GPL your code. BUT...it is your choice!

P.S. To Vick: Grow Up! Probono is just trying to do what he thinks is right. I don't agree with him but I understand he has some concerns about his code. The linux community should support each other even if one of them is wavering. We shouldn't curse each other! Your posts actually make me sick. If you want Probono to contribute his code to the community, why don't you take the first step and make a positive contribution to this discussion. Your "...The linux community will curse you forever" type post is crap! Take a pointer from bfree. I think he has some very good points! btw, I don't know what type of person you are (I guess I'll find out when you reply) but I hope you take this as constructive criticism so we can get back to the task at hand (ie. help Probono make a good and reflective decision). Anyway...my two cents!

[probono]

Does that mean the client has no dependencies and will work on any distro (e.g. mandrakemove)?

Yes.

[probono]

hi mrclark1971,

your points are all valid. Except for that I don't like to be compared with Darl...

Probably I'll ask some of the KDE core developers what they would recommend me to do. If someone with real C and security experience would help me in "securing" the client, that would make me feel better about GPL'ing it.