Destructionator XIII wrote:I want to weigh in my own personal opinion on the licenses talk.
Ideally, I'd like to see the source and possibly modify it for myself. Well, ideally, I'd like worthwhile documentation and the software to not suck in the first place, but having the source is the next best thing.
Having it means I can look to see how it works, and if I don't like it, I can change it. Now, a lot of Free Software Idiots (henceforth, FSIs) use that as one of their points, which I think is a valid point, but I also laugh at the FSIs since I know the majority of them never actually look at that code (hell, there are only 6 programs I have looked at and modified myself (Linux (the kernel), Qt (cross platform programming toolkit), Blackbox (X11 window manager), fspanel (tiny taskbar), gaim (IM client), and generator (Sega Genesis emulator, which I no longer use anyway)), out of several dozen open source programs I have used). I also intend to eventually modify xterm (X11 terminal emulator) for my own use, but I haven't gotten around to that yet.
Also of the programs I have hacked, I've never submitted my patches upstream, and only intend to redistribute one of them (my version of fspanel, which I am practically rewriting; I have already reworked more than 20% of the code).
Let me explain in more detail why I used the source of each of these programs.
Linux was for education mostly. I toyed with it to understand how it works.
Qt's source was useful in nailing down a question I had about the internals (I wanted to know how it managed memory internally so I could be sure I was correct in interfacing with it). I made minor modifications to it for educational purposes - this code helped me learn better C++ practices. I don't use my modifications, and certainly don't share them. Qt is also an interesting case I will be returning to on licensing.
Blackbox had a minor bug that I fixed in its window placement code. Changed two lines of its code. I also looked at it when writing my changes for fspanel, since it is the API implementation I was talking to, and seeing it in action helps me get my code right.
fspanel is a tiny program that offered a base for something I wanted to write myself - a very small, both in screen size and in memory and disk, taskbar for my own use. The source was out of date and no longer maintained, but it was the closest program to what I had in mind, so I used it as my starting point, but it was still far from what I really wanted, so I grabbed the source and started hacking. Due to the amount of work I have put into it and will be putting into it in the coming days or weeks, I am going to post it on my website for others to look at and use.
gaim had a bug that would make it crash on me every few weeks, so I hacked the offending lines out of the code. If the program didn't suck in the first place, that would have not been necessary. The documentation for its plugin API also sucks, so I used the source to fill in the gaps when I was working on a plugin. Lastly, I intend to use its source as a starting point to write my own IM client, hopefully one that doesn't suck, but I'm not going to be doing that for a while.
generator had hard-coded controls that were just annoying, so I changed them in the source. If they were configurable, this would not have been needed. I eventually ditched the program entirely, though my altered control scheme was actually pretty nice when all done.
Looking at my own experience, being licensed to redistribute the code myself is not a big priority - I use the source, for the most part, as reference / education to fill in the gaps the documentation leaves. I find this very nice with something that must interact programically with my other code; the actual implementation is an accurate reference of how to talk to it. The other use is as a starting point to make something that doesn't suck.
Now, the other argument FSIs make is since it is open source, then the quality is better. Well, this simply isn't true; if OSS guaranteed quality, then why the fuck did I have to hack around with the programs I altered? Shouldn't someone else have already done that? Well, maybe someone did, but if so, he probably did the same thing I did - a quick hack to change it to how he likes it, and he never bothered with sending his changes upstream (either out of laziness or he felt his preferences and hacks would be of no use to others).
Moreover, I've seen some OSS code that is just idiotic. Foolish errors that should be obvious to anyone who knows what he is doing. Since I've seen it, surely others have too, but none of us seem to fix it, or our fixes never get committed. I don't bother trying out of laziness; I usually don't even bother fixing it for myself, so long as it doesn't annoy me. Even if it does annoy me, I'm more likely to search for alternatives than dive into the code. Even trivial modifications can be harder than they seem, anyway. (there I go rationalizing my laziness, but really, would it be worth the effort? I'm probably never going to see any personal benefit by fixing it.)
And to get back on topic, in a license, there are three main things to think about:
1) Redistribution.
2) Availability of the code.
3) Using it on multiple machines.
Let's look at them one by one.
I discussed the usefulness of the code above. In summary, IMO its main use is acting as a very indepth API reference. Being able to fork or fix it is nice, but not used very often, and there are easy enough alternatives there (harassing the Quality Assurance team of the developer for fixes or doing it yourself for a fork, which takes time, but may end up more interesting).
Using something on multiple machines is nice for a user to have, but not necessary, and can hurt the company, meaning the programmers don't get paid, meaning the program stagnates, meaning everyone loses. (Another thing FSIs seem to ignore - coders aren't free, and donations usually just aren't enough). Consider the case of per seat pricing. If a license lets an organization use it as much as they want, they may use it several hundred times for the price of one. The software company would like more revenue, so charging a little bit for each seat seems reasonable to them. And, it seems reasonable to me too. A bulk discount would be nice, and probably acceptable (since the marginal costs are small on the software company's side anyway), but someone needs to pay for the development of the code, and that someone should be the users of the code - that is how business works.
Would you rather all organizations pay (for example) $5000 for a global license, regardless of size, to pay for the cost of developmenting the code, or organizations pay $100 per seat, meaning small businesses can get away with much paying less than big businesses. That just seems fair, and everyone wins.
Finally, you have redistribution. There are two cases where this may be useful:
1) It is something that ties into your product (a common example is the Direct X installer on older games, that the game needs to run, but the user might not have, so it is included for the convienence of the user).
or 2) You modified something and would like to share your changes. This only makes sense if you also have the source, since otherwise, you probably aren't modifying it anyway. If you have this, you can fork off a current program, or take over a dead program easily. If not, you can always try to send your patches back upstream to the original developer (Which is the preferred case either way).
That is in open source practice, not used very often in my experience. When it is used, it is generally in boring, uncreative, ways - there are several forks with very few differences.
You complain about there being different versions of Windows Vista. Have you see how many fucking Linux distros there are? Most them are the same except for some little gimmick! Fuck that. That has done almost nothing good - the FSIs can't agree on anything, leading to a bad user experience. I like choice, but I also like things that work.
Moving on, the biggest problem with redistibtion business-wise is it puts the price for all practical purposes at zero, while the development costs remain greater than zero - the result? A net loss. The only way to get around this is to write free software on commission, making your money up front rather than from selling copies. (Codeweavers does this with Wine). The problem with that is it isn't as scalable. One customer might come to you with a contract, that will pay for his needs, but that is all you will get from it. This might be acceptable, but getting constant sales of something existing that works is much easier than getting constant contracts to add new features. Also, a sale might be, say $50 per user, whereas a contract, since he is the only one paying, is more likely to be around, say $500 from him.
That's right- Free Software itself is a monetary loss. Now, it is possible to make money somewhere else, such as support contracts (Red Hat) or custom contracts (Codeweavers with Wine), but the Free Software itself is a loss.
If money isn't the reason for going free, than what is? Well, there are a few. One might be ideology - you feel this software should be free, or you are just doing it for fun anyway. A more practical one might be to get a rapport with your customers, so they will come to you later for other things (hopefully paying!). The latter might work, and is rather valid, though of course, you must be offering something else too. A variation of that is giving stuff away free for resume material or just simple bragging rights. Though bragging rights don't cause massive systems to be developed.
The simple fact of life is money pays for software, and free software doesn't bring in money, though it might be a part of something that does. If something is done for fun, that is a slightly different situation.
I said above that Qt is an interesting case. It is a software development platform that is dual licensed: the GPL and a proprietary license, and it is quite profitable. What it is basically doing is using the GPL to get their name out and build reputation, and then if you want to make closed source software (get around the restriction of the GPL), you buy a license from them to do so. This is pretty much ideal to me on how software would be, though the GPL works best on a library like Qt - linking to it puts some restrictions on it.
On the different free software licenses: if you ask me, there is one and only one worth using: the GPL. Given above, you aren't going to be making money directly from this program with any free license. If you are writing a linked library, the GPL gives you quite a lot of power - it permits dual licensing. If you are writing something else, it still gives you some power: it ensures your program remains free.
Some FSIs think the GPL is "less free" than licenses such as BSD due to the copyleft clause. Well, consider this analogy: in a civilized country, I can't enslave you unless I want to go to jail. In anarchy, I can. Some idiots would say the anarchy situation is "more free", but I would say the opposite, since being a slave isn't very free at all - you are free to do things so long as you don't take away someone else's freedom. I see free software licenses as the same thing - the GPL says you are free to do stuff with it, so long as you don't take away anyone else's freedom.
From the ideolgy standpoint, it pretty clearly wins. From a practical standpoint, it gives you at least some business advantage (also: if a competetor wants to take it, he must do so on your terms; if he doesn't like the clauses of the GPL, he'll have to rewrite it himself), and lets the user play with the source if he wants to.
I have more to say about open source and what it means to development, but this is getting lengthy and meandering off topic anyway, so I'll save that for later. Summary of my position: proprietary software is a good thing, since it funds its own development, and if you are going to go with a FOSS license, the GPL is the one.
I've altered my kernel to properly report overclocked frequency, but stopped after it became annoying to have to sync it w/ kernel updates- it would have never been merged upstream being a crude hack, and Linux devs not wanting to support overclocked hardware.
Right now I'm rewriting a closed-source freeware app from scratch, since it's extremely buggy and dated- the author wants 500$ for source/ability to modify (From what I can gather from google translate- might be only applicable to commercial entities), which I don't want to pay for something that in the end wouldn't really be mine to redistribute and do as I wish anyway.
What I'm saying above is I think it should be mandatory that proprietary software should be "open sourced" (in terms of code, not cost, like the way old unix programs cost money, but you got the source w/ them), but w/ copyright restrictions. Sure, someone may look into the internals of your code, but if it's mandatory you can look into theirs, and sue them for infringement. I suppose there are areas that this wouldn't work, such as DRM/anticheating mechanisms, hence exceptions.
Proprietary software would still be subject to copying restrictions and whatnot. Users who have paid for the software should be able to distribute the changes amongst themselves though (and the vendor can indirectly benefit by integrating these into mainline as a supported stable solution, in addition to their own improvements in future versions).
Free open source can work for games- make users pay for the content (which is the bigger chunk of the dev costs anyway)/multiplayer service. Of course, being open source, there could be rampant cheating, users can set up their own service (BnetD), and content can be created (see Desert Combat), so on second thought this may not work too well- depends on situation.
If you're an engine developer, there's the QT scheme above, but if your potential licensees use the scheme of charging for content/multiplayer only, that would fall flat, unless you place restrictions on those.
As for the multitude of Linux distros, most of them are inconsequential forks that remain compatible w/ their parent to some degree. (Debian->Ubuntu->Mepis). They are useful as a testbed for stuff.
The corporate environment seems to have standardized on Redhat and to a lesser extent SuSE (which originally was a RedHat derivative). I feel everything other than Redhat, Ubuntu, and Suse are basically marginal and of no significant consequence- Gentoo (yay ricers! funroll-loops.org) and Slackware aren't really mainstream. SuSE for the corporate desktop, RHEL for the server, and Ubuntu for the home user. They each have strengths and weaknesses.
My major peeve about Linux is duplication of effort repackaging the same thing over and over- that's still a problem, and LSB hasn't really helped that much. It's somewhat the fault of app developers- it isn't hard to simply make only a DEB and an RPM, and statically compile the app (at least for the more obscure libraries, ie other than GTK, QT, libssl, etc), instead of dynamically linking and requiring the user to install every obscure convenience library that you've used. Windows developers do this, bringing their dependencies w/ them, it's not like the OS is inherently unsuited to it (well, as long as you're using C- G++ ABI changes are a problem, so you'd have to statically link everything that is based on C++, and QT is fat). VMWare is an example of an app that's reasonably cross-distro that Just Works.
