Of course. The problem isnt the amount of money, they problem is the amount of red tape you have to go through to get any money at all. A million or a cent, it doesnt matter.
You dont call Troll Tech to get the license, you call the purchasing department, who need a decision that it is an official product that your company uses, which can only be obtained through an evaluation project approved by a steering comittee, etc etc.
If you really believe they'll give you the company credit card and that you as a developer can order what you want to do a project, that's not the way it happens. With (L)GPL software you can usually wing it; you dont have to bother going through the red tape, because you only have to do that if you buy something.
Well, a bit on the silly side, I just went through a horrible horrible bug in Linux 2.0.30. After somewhere around 500 days uptime... IT WRAPPED! According to last, it went up at:
Suddenly I was back at 0 uptime, and my logfiles went through a spasm with kernel error messages ending with this:
Apr 28 01:56:07 dream kernel: Call Trace: [do_gettimeofday+34/68] [sys_gettimeof day+44/112] [system_call+85/124] Apr 28 01:56:07 dream kernel: Code: f7 f1 ba 10 27 00 00 89 c1 31 c0 f7 f1 a3 dc fa 1a 00 89 c3
Oh, well, still it didnt panic, altho a load of apps including X went haywire.
It sorta puts life into a perspective too. Last time I rebooted this machine I was 25. Now I'm 27. Agh.
Re:Sure, Qt for Free Software, gtk for Shareware
on
The Desktop Wars
·
· Score: 1
a) RMS dislikes the use of LGPL for free software unique items. He's pragmatic enough to realize that LGPL is more likely to get something used if there is already a proprietary version of it.
b) Uhm. The QPL doesnt do anything for compatibility with other OSS licenses. It gives a vague (and legally undefined) suggestion that other OSS licenses can be used with QPL, but some OSS licenses like the GPL cannot be used with QPL software.
And by the way, have you ever tried to go through the red procurement tape in a corporation?
"You want to buy what? That's not in the strategic buisness plan! From what company? They're not in our alliance vendor list! A new development environment? We dont want anymore, we've already got 30! Do you have a charge code? Who's budget is this coming from?"
In most corporations, if something costs something, you've got the choice to either pay for it out of your own pocket or go through a years worth of budgeting, politics, studies, projects, etc. That is the *real* bar for getting something costing money accepted.
KDE is mostly C++, GNOME is mostly C. KDE uses Qt, GNOME uses GTK.
This makes it far less fun to borrow code. And on top of that you have the license issue. KDE cannot legally reuse GPL code with Qt without the permission of the author because Qt (even with QPL) doesnt have a GPL compatible license. To solve this, KDE is slowly moving over to the Artistic License (perl (which, IIRC, is distributed under both GPL and AL)). This is not GPL compatible either, altho it is compatible with the QPL (meaning, GNOME cannot use the code without a separate license, altho they can use the GPL version of the code).
So, the idea of code reuse between KDE and GNOME has some problems. This does not prevent common standards and interoperability, of course.
Usually within the same legal entity. This isnt exactly a new or different issue than common site licenses that corporations engage in all the time, or other closed group issues.
To claim someone is an employee of your organization you'd need employment contracts, etc. Hmmm... and isnt unpaid 'employees'... frowned upon in the US? Wouldnt it be fun when your 'customers' decide to file a class action lawsuit for several months of pay, even tho minimum wage...
To deter violations of the GPL you do not need any huge amounts of cash. If you do not comply with the GPL, you do not have the rights to do anything with the code, since the legal status reverts to copyright.
Copyright violation is a federal crime punishable by up to 10 years in prison and/or fines of $250000, so just call your nearest friendly government agency and they'll do the work for you. This isn't a game of 'we're safe, he cant afford to sue'. This is a case of the violator going to jail.
After that you can file a civil lawsuit if you want more punitive damages awarded.
If they do not abide by the GPL terms they are violating copyright. The GPL does not grant you any rights to the software unless you abide by those terms. The copyright remains intact and is the 'fallback' that's valid if they fail to abide by the terms of the GPL.
Copyright violation is a federal crime punishable by up to several years in prison and severe fines for each case of infringement. The copyright holder can contact the appropriate legal entity to file charges.
Beyond that, the copyright holder may file a civil lawsuit for damages. How that would be evaluated is, of course, up to the court, altho you could likely make a good legal argument for the poor idealistic programmer against a nasty rich copyright infringer, and a jury might award a good deal of punitive damages (punitive damages are often meant to hurt, to teach the violator not to do it again).
But I'm not sure I'd go so far as to call SCO a legitimate vendor. In fact, SCO is one of the best reasons for Linux there is. I feel no sympathy for SCO; had they been a bit less greedy and a bit more into improving their system they could be reaping the benefits today. But a vendor with ideas like TCP/IP being an 'addon', and producing the worst unix I've ever had the displeasure to work with, they're just getting what's coming to them.
Just choose upgrade when booting off the installation disks.
I've actually tried this, and imagine my surprise; It Worked:). (At least 5.0-5.2)
If you have a slow connection I'd suggest you get a CD from cheapbytes or something. While I do like to pay every now and then for a dist, I do tend to space it to once a year, not every few weeks:).
Where do you think those illegal weapons come from? Built in the outlaws gun factory? Beamed here by aliens?
Illegal weapons are simply legal weapons illegaly sold, stolen, etc. And as long as guns are legal, you wont stop feeding the illegal market with new weapons.
But of course, it'll probably take 50 years until you've cleaned out most of the illegal market. Maybe shorter time if you seriously attempt to reduce the number of weapons in circulation. But they wont vanish overnight.
Sounds cool doesnt it? Pretty much like "If nukes are outlawed only outlaws will have nukes!". I want one too.
The point being this: With a lot of guns in circulation most criminals will have one. With less guns in circulation less criminals will have one.
The criminal wont have to take the weapon away from the person, he'll already have his own (stolen, bought, whatever). And do you really think he'll play fair? Are you going to go for your gun when you're staring down the barrel of his gun? The cards in this game are stacked solidly against the honest upstanding citizens who'll usually have the disadvantage of being surprised, having ethical considerations, lack of routine in shooting people, might actually care what happens, getting a case of nerves, etc.
Me, I'd rather face a mugger with a knife. I can usually outrun a stoned mugger with a knife, but it's a lot harder to outrun a bullet.
/* As a special exception, if you link this library with files compiled with GCC to produce an executable, this does not cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. */
So, yes, crtbegin.o originates with GCC/EGCS. However, while GCC/EGCS is under GPL, the parts that get included in binaries have special exceptions.
I hope you understand my reasoning a bit better now.
No, you cannot run any applications without the compiler in this sense. That is because what is referred to as the compiler in the sense of essential system component are the parts included in the compiler that get linked into the binaries/are created by the compiler.
When you compile an application, the resulting binary will contain parts derived from the compiler. In the case of egcs you'll get objects like crtbegin.o, containing functions that come from the compiler. You cannot remove those functions and still have a working binary.
That is why the compiler is considered an essential system component exception; since proprietary compilers contain proprietary parts that get linked into the resulting binaries, compiling a GPL application with a proprietary compiler would otherwise result in an undistributable binary.
Yes, you can use the system without the compiler in itself, but you will still have parts in every binary originating from the compiler. While you may not see them because you dont have to explicitly link them (the compiler will always do that by default), they are there nonetheless, and just as much subject to licenses as anything else.
RMS does seem pretty positive about it, and the QPL qualifies as a 'free' license. However, that does not have any real bearing on the GPL compatibility problem, it just makes it easier for copyright holders to grant an exception to the GPL for those who want to link code to Qt.
And, of course, the in-house clause also causes the problem that it will not be legal to even combine GPL and QPL code in an internal/private application, since the QPL requires you to distribute your code to Troll Tech and the GPL forbids distribution of your code if you cannot fulfill the GPL. So any GPL code linking to a QPL Qt will automatically violate one or the other license.
An installer may be necessary to install the operating system, but that doesnt qualify under the core component clause. Essetial core components mean those parts without which you cannot reasonably expect any application to run on the operating system.
That means libc, which most programs link against. It means the compiler since compiling an application usually results in possibly proprietary pieces of code generated by/included from the compiler being included in the resulting binary. It means the kernel since that also is pretty essential to running applications. Those are components that qualify as essential system components. Without those exceptions it wouldnt be possible to run GPL binaries on any proprietary OS or compile them with any proprietary compiler. Wether or not the OS in itself requires a non GPL installer is irrelevant.
As far as the operating system issue goes, there is some useful argument that the proprietary OS vendors can decide what is part of the OS. When it comes to Linux distributors it's not clear at all. Considering even Microsoft has problems to get anyone to accept that Internet Explorer is even a part of the operating system, much less an essential one, in my opinion no Linux distributor can claim 'system component' about anything that is not entirely clear.
Tightening the license may just mean clarifying the core component clause to prevent misunderstandings.
While an installer is hardly an essential system component either, Caldera is not 'The Linux Operating System'. Since I have seen few Qt based GPL applications saying 'this application is written to be run only on Caldera OpenLinux', it would be an obvious attempt at evading the GPL license of other peoples code.
In either case it's a useless point to argue, because you cannot gain anything from arguing it. You'll just get badwill from GPL developers because they will not trust your willingness to abide by the GPL license. It's doubtful any claim of system component would hold up should it ever get to court, because the court is likely to uphold the copyright holders interpretation over some pretty obvious evasion attempt. And you'll end up with a tightened license on any such code to avoid any misconceptions.
So, just ask the copyright holders for a separate license or refrain from using third party GPL code.
No it doesnt. Shipping Qt with the system doesnt make it an essential system component. You can still run Linux without Qt. The system component clause refers to kernels, libc, compiler, etc, without which it would be difficult to run anything on a system.
I would personally persue any license violation in case any of my GPL code was linked with Qt without permission (I'd probably grant permission for Qt tho) because otherwise the GPL is worthless if anyone can throw a distribution together, ship it with a proprietary library and claim system component.
Enlightenment->SoundBug?
on
Red Hat 6.0
·
· Score: 1
There's an option to esd (enlightenmend sound daemon) that will make it release the device after a couple of seconds after last use. So you can do that.
Since esd actually works on other platforms than Linux I quite like it too. Imagine my surprise when starting gnome and my usually very quiet HP-UX workstation suddenly did sound.
And, of course, you can use esddsp to use apps that write to/dev/dsp with esd.
Further, esd is not dependent on Enlightenment or GNOME. When people whine about GNOME being distributed as a gazillion different files, they usually miss the point that those applications are not dependent on GNOME and things like esd can be used wether you run GNOME or KDE, or just a window manager. In my opinion that is an advantage.
Yep. And as a system administrator supporting HP-UX, Solaris, AIX, IRIX, BSDI, SCO and some things I forget, and a sometimes cross-platform unix programmer in my free time, I'm finding at times that I'd be happy to sacrifice some of the 'better' for more of the 'same'. It usually just results in having to use 'the worst common denominator' and/or writing dirty kludges anyway.
Oh, and I forgot to mention, good luck with your free FreeBSD installation. It's a great choice of operating system. I'd definitely try it out at home myself if I hadn't had the chance already at work:).
If proprietarization has a price, how much is it? When has a BSD licensed author ever lost money by using a BSD license?
When has the code ever stopped being free? XFree86 was ready to proceed without The Open Group when they changed the license. The code you and I were using was still free and open.
The GPL will not save you from code forking. EGCS and GCC make a good example. The GPL does not have a clause saying forks are not allowed.
Well, the original UNIX forking is one example, as is X (display postscript, for example). The cost of the damage caused is difficult to calculate, but the forking has caused little but incompatiblity for programmers and problems for system administrators. As you may be tired of the GPL religion, I'm dearly tired of discovering subtle differences in every UNIX, even tho their heritage has so much in common. If the GPL will do through force what enlightened self interest didnt do for compatibility, then I'll take that.
The GPL does, indeed, not forbid forking of the code, but it does take away a lot of the incentives to fork (IE, making a proprietary version, including a new feature and competing on 'Buy our stuff. We have FOO. They dont.'). Since that leaves only serious technical disagreements as a reasons to fork, it happens more rarely (and never in a proprietary fashion, allowing backports and discouraging incompatibility).
Embrace-and-extend becomes a lot easier when you can just take the code supporting the protocol and add your own stuff, rather than having to reimplement it from scratch.
As regards the conceding of the desktop, there is was a recent interview with Jordan Hubbard at http://www. internetworld.com/print/current/webdev/19990412-fr eebsd.html. I also remember reading similar sentiments on usenet several times. Mr Hubbard and some other fairly outspoken BSD advocates may not represent the BSD community, but in such a case the other developers should speak out too, because this idea appears to be fairly prevalent. I most certainly hope the BSD crowd would join in in the quest for the desktop, because together we'd be stronger.
And, as far as the tightness of control, since it appears people have differing opinions on this, I'd guess it's just a matter of how involved you are and what you mean with 'control':). 'Linux' probably has a lot more than 150 people 'in control' because the separate packages tend to be maintained by separate and unorganized people. The different packages in themselves have a lot fewer of course (some control the kernel, some glibc, some gcc, etc). And in the end, the distribution creators have control over what happens in the integrated end result. The same is, of course, true of BSD in some fashion, because the BSD distributions include external software too. I guess it's just a matter of opinion in the end:).
Well, there are no serious technical reasons. Both will experience minor temporary advantages in one direction in some parts of the system at different times. But due to the high exchange between systems I dont think any such difference will last, and most claims in either direction are usually just advocacy.
I've had both keel over at high loads. But I expect any system running at 60 loadavg to keel over eventually, and in any case you have a serious sizing problem (not to mention response time problem) if you have a sustained loadavg around 60.
So in the end it comes down to a few practical, political and personal preference issues.
SysV. I do not maintain just BSD based systems. Since I have to maintain AIX, Solaris and HP-UX which are all more or less SysV style, any time I get to a BSD based system it's an annoyance. This is an annoyance with Linux too, at times, but at least it's a little more SysVish (we can argue the merits about that...).
GPL. Some BSD supporters argue about the extra freedom of the BSD license, but in my opinion, if BSD should make major inroads and raise corporate interest then we'd just get another... SunOS, HP-UX 9, etc. The BSD license is more free than the GPL, but the price of that freedom is proprietarization, code forking and yet another round of incompatible embrace-and-extend corporate wrangling around. No Thank You. We Have Done That Already. BSDI has a tendency to play nice, but the others dont.
A realistic view on the market. BSD appears to be willing to concede the desktop to Windows, and be content with being a very good server platform. While that may be a possibly realistic view, it isnt in my opinion an acceptable one. Because Microsoft will not tolerate either BSD or Linux as a server platform, and they'll do everything they can to make sure that the Windows clients wont work with anything but NT, or that there are major proprietary advantages of using NT. Giving up the client market means, IMO, giving up any chance at existence at all. It wont matter how good you are if Microsoft has total control of the clients. And most of the major advances in Linux have come as far as they have because the people behind them were not realistic.
And finally, for various reasons,I actually prefer the more componentized and anarchistic development of parts of the Linux systems. I'm happy to leave the integration to the distribution makers, but I like the lack of central control.
Slashdot Mirror
Of course. The problem isnt the amount of money, they problem is the amount of red tape you have to go through to get any money at all. A million or a cent, it doesnt matter.
You dont call Troll Tech to get the license, you call the purchasing department, who need a decision that it is an official product that your company uses, which can only be obtained through an evaluation project approved by a steering comittee, etc etc.
If you really believe they'll give you the company credit card and that you as a developer can order what you want to do a project, that's not the way it happens. With (L)GPL software you can usually wing it; you dont have to bother going through the red tape, because you only have to do that if you buy something.
Well, a bit on the silly side, I just went through a horrible horrible bug in Linux 2.0.30. After somewhere around 500 days uptime... IT WRAPPED!
According to last, it went up at:
reboot system boot Tue Dec 16 22:51
(That would be 1997).
Now:
11:40pm up 22:21, 1 user, load average: 0.01, 0.04, 0.00
Suddenly I was back at 0 uptime, and my logfiles went through a spasm with kernel error messages ending with this:
Apr 28 01:56:07 dream kernel: Call Trace: [do_gettimeofday+34/68] [sys_gettimeof
day+44/112] [system_call+85/124]
Apr 28 01:56:07 dream kernel: Code: f7 f1 ba 10 27 00 00 89 c1 31 c0 f7 f1 a3 dc
fa 1a 00 89 c3
Oh, well, still it didnt panic, altho a load of apps including X went haywire.
It sorta puts life into a perspective too. Last time I rebooted this machine I was 25. Now I'm 27. Agh.
a) RMS dislikes the use of LGPL for free software unique items. He's pragmatic enough to realize that LGPL is more likely to get something used if there is already a proprietary version of it.
b) Uhm. The QPL doesnt do anything for compatibility with other OSS licenses. It gives a vague (and legally undefined) suggestion that other OSS licenses can be used with QPL, but some OSS licenses like the GPL cannot be used with QPL software.
And by the way, have you ever tried to go through the red procurement tape in a corporation?
"You want to buy what? That's not in the strategic buisness plan! From what company? They're not in our alliance vendor list! A new development environment? We dont want anymore, we've already got 30! Do you have a charge code? Who's budget is this coming from?"
In most corporations, if something costs something, you've got the choice to either pay for it out of your own pocket or go through a years worth of budgeting, politics, studies, projects, etc. That is the *real* bar for getting something costing money accepted.
There are several issues making that difficult.
KDE is mostly C++, GNOME is mostly C.
KDE uses Qt, GNOME uses GTK.
This makes it far less fun to borrow code. And on top of that you have the license issue. KDE cannot legally reuse GPL code with Qt without the permission of the author because Qt (even with QPL) doesnt have a GPL compatible license. To solve this, KDE is slowly moving over to the Artistic License (perl (which, IIRC, is distributed under both GPL and AL)). This is not GPL compatible either, altho it is compatible with the QPL (meaning, GNOME cannot use the code without a separate license, altho they can use the GPL version of the code).
So, the idea of code reuse between KDE and GNOME has some problems. This does not prevent common standards and interoperability, of course.
Yep, and not by Redhat either. The article has several facts sorta wrong.
Usually within the same legal entity. This isnt exactly a new or different issue than common site licenses that corporations engage in all the time, or other closed group issues.
To claim someone is an employee of your organization you'd need employment contracts, etc. Hmmm... and isnt unpaid 'employees'... frowned upon in the US? Wouldnt it be fun when your 'customers' decide to file a class action lawsuit for several months of pay, even tho minimum wage...
To deter violations of the GPL you do not need any huge amounts of cash. If you do not comply with the GPL, you do not have the rights to do anything with the code, since the legal status reverts to copyright.
Copyright violation is a federal crime punishable by up to 10 years in prison and/or fines of $250000, so just call your nearest friendly government agency and they'll do the work for you. This isn't a game of 'we're safe, he cant afford to sue'. This is a case of the violator going to jail.
After that you can file a civil lawsuit if you want more punitive damages awarded.
If they do not abide by the GPL terms they are violating copyright. The GPL does not grant you any rights to the software unless you abide by those terms. The copyright remains intact and is the 'fallback' that's valid if they fail to abide by the terms of the GPL.
Copyright violation is a federal crime punishable by up to several years in prison and severe fines for each case of infringement. The copyright holder can contact the appropriate legal entity to file charges.
Beyond that, the copyright holder may file a civil lawsuit for damages. How that would be evaluated is, of course, up to the court, altho you could likely make a good legal argument for the poor idealistic programmer against a nasty rich copyright infringer, and a jury might award a good deal of punitive damages (punitive damages are often meant to hurt, to teach the violator not to do it again).
But I'm not sure I'd go so far as to call SCO a legitimate vendor. In fact, SCO is one of the best reasons for Linux there is. I feel no sympathy for SCO; had they been a bit less greedy and a bit more into improving their system they could be reaping the benefits today. But a vendor with ideas like TCP/IP being an 'addon', and producing the worst unix I've ever had the displeasure to work with, they're just getting what's coming to them.
Just choose upgrade when booting off the installation disks.
:). (At least 5.0-5.2)
:).
I've actually tried this, and imagine my surprise; It Worked
If you have a slow connection I'd suggest you get a CD from cheapbytes or something. While I do like to pay every now and then for a dist, I do tend to space it to once a year, not every few weeks
Where do you think those illegal weapons come from? Built in the outlaws gun factory? Beamed here by aliens?
Illegal weapons are simply legal weapons illegaly sold, stolen, etc. And as long as guns are legal, you wont stop feeding the illegal market with new weapons.
But of course, it'll probably take 50 years until you've cleaned out most of the illegal market. Maybe shorter time if you seriously attempt to reduce the number of weapons in circulation. But they wont vanish overnight.
Sounds cool doesnt it? Pretty much like "If nukes are outlawed only outlaws will have nukes!". I want one too.
The point being this: With a lot of guns in circulation most criminals will have one. With less guns in circulation less criminals will have one.
The criminal wont have to take the weapon away from the person, he'll already have his own (stolen, bought, whatever). And do you really think he'll play fair? Are you going to go for your gun when you're staring down the barrel of his gun? The cards in this game are stacked solidly against the honest upstanding citizens who'll usually have the disadvantage of being surprised, having ethical considerations, lack of routine in shooting people, might actually care what happens, getting a case of nerves, etc.
Me, I'd rather face a mugger with a knife. I can usually outrun a stoned mugger with a knife, but it's a lot harder to outrun a bullet.
From egcs-1.1.2/gcc/crtstuff.c:
'This file is part of GNU CC.'
Follwed a bit later by:
/* As a special exception, if you link this library with files compiled with GCC to produce an executable, this does not cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. */
So, yes, crtbegin.o originates with GCC/EGCS. However, while GCC/EGCS is under GPL, the parts that get included in binaries have special exceptions.
I hope you understand my reasoning a bit better now.
No, you cannot run any applications without the compiler in this sense. That is because what is referred to as the compiler in the sense of essential system component are the parts included in the compiler that get linked into the binaries/are created by the compiler.
When you compile an application, the resulting binary will contain parts derived from the compiler. In the case of egcs you'll get objects like crtbegin.o, containing functions that come from the compiler. You cannot remove those functions and still have a working binary.
That is why the compiler is considered an essential system component exception; since proprietary compilers contain proprietary parts that get linked into the resulting binaries, compiling a GPL application with a proprietary compiler would otherwise result in an undistributable binary.
Yes, you can use the system without the compiler in itself, but you will still have parts in every binary originating from the compiler. While you may not see them because you dont have to explicitly link them (the compiler will always do that by default), they are there nonetheless, and just as much subject to licenses as anything else.
RMS does seem pretty positive about it, and the QPL qualifies as a 'free' license. However, that does not have any real bearing on the GPL compatibility problem, it just makes it easier for copyright holders to grant an exception to the GPL for those who want to link code to Qt.
And, of course, the in-house clause also causes the problem that it will not be legal to even combine GPL and QPL code in an internal/private application, since the QPL requires you to distribute your code to Troll Tech and the GPL forbids distribution of your code if you cannot fulfill the GPL. So any GPL code linking to a QPL Qt will automatically violate one or the other license.
An installer may be necessary to install the operating system, but that doesnt qualify under the core component clause. Essetial core components mean those parts without which you cannot reasonably expect any application to run on the operating system.
That means libc, which most programs link against. It means the compiler since compiling an application usually results in possibly proprietary pieces of code generated by/included from the compiler being included in the resulting binary. It means the kernel since that also is pretty essential to running applications. Those are components that qualify as essential system components. Without those exceptions it wouldnt be possible to run GPL binaries on any proprietary OS or compile them with any proprietary compiler. Wether or not the OS in itself requires a non GPL installer is irrelevant.
As far as the operating system issue goes, there is some useful argument that the proprietary OS vendors can decide what is part of the OS. When it comes to Linux distributors it's not clear at all. Considering even Microsoft has problems to get anyone to accept that Internet Explorer is even a part of the operating system, much less an essential one, in my opinion no Linux distributor can claim 'system component' about anything that is not entirely clear.
Tightening the license may just mean clarifying the core component clause to prevent misunderstandings.
While an installer is hardly an essential system component either, Caldera is not 'The Linux Operating System'. Since I have seen few Qt based GPL applications saying 'this application is written to be run only on Caldera OpenLinux', it would be an obvious attempt at evading the GPL license of other peoples code.
In either case it's a useless point to argue, because you cannot gain anything from arguing it. You'll just get badwill from GPL developers because they will not trust your willingness to abide by the GPL license. It's doubtful any claim of system component would hold up should it ever get to court, because the court is likely to uphold the copyright holders interpretation over some pretty obvious evasion attempt. And you'll end up with a tightened license on any such code to avoid any misconceptions.
So, just ask the copyright holders for a separate license or refrain from using third party GPL code.
No it's not. It's not an essential system component just because some random distributor says so.
No it doesnt. Shipping Qt with the system doesnt make it an essential system component. You can still run Linux without Qt. The system component clause refers to kernels, libc, compiler, etc, without which it would be difficult to run anything on a system.
I would personally persue any license violation in case any of my GPL code was linked with Qt without permission (I'd probably grant permission for Qt tho) because otherwise the GPL is worthless if anyone can throw a distribution together, ship it with a proprietary library and claim system component.
There's an option to esd (enlightenmend sound daemon) that will make it release the device after a couple of seconds after last use. So you can do that.
/dev/dsp with esd.
Since esd actually works on other platforms than Linux I quite like it too. Imagine my surprise when starting gnome and my usually very quiet HP-UX workstation suddenly did sound.
And, of course, you can use esddsp to use apps that write to
Further, esd is not dependent on Enlightenment or GNOME. When people whine about GNOME being distributed as a gazillion different files, they usually miss the point that those applications are not dependent on GNOME and things like esd can be used wether you run GNOME or KDE, or just a window manager. In my opinion that is an advantage.
Well, on the desk next to me...
9:08am up 485 days, 10:17, 12 users, load average: 0.13, 0.05, 0.01
That's linux 2.0.30...
Yep. And as a system administrator supporting HP-UX, Solaris, AIX, IRIX, BSDI, SCO and some things I forget, and a sometimes cross-platform unix programmer in my free time, I'm finding at times that I'd be happy to sacrifice some of the 'better' for more of the 'same'. It usually just results in having to use 'the worst common denominator' and/or writing dirty kludges anyway.
Oh, and I forgot to mention, good luck with your free FreeBSD installation. It's a great choice of operating system. I'd definitely try it out at home myself if I hadn't had the chance already at work :).
When has the code ever stopped being free? XFree86 was ready to proceed without The Open Group when they changed the license. The code you and I were using was still free and open.
The GPL will not save you from code forking. EGCS and GCC make a good example. The GPL does not have a clause saying forks are not allowed.
Well, the original UNIX forking is one example, as is X (display postscript, for example). The cost of the damage caused is difficult to calculate, but the forking has caused little but incompatiblity for programmers and problems for system administrators. As you may be tired of the GPL religion, I'm dearly tired of discovering subtle differences in every UNIX, even tho their heritage has so much in common. If the GPL will do through force what enlightened self interest didnt do for compatibility, then I'll take that.
The GPL does, indeed, not forbid forking of the code, but it does take away a lot of the incentives to fork (IE, making a proprietary version, including a new feature and competing on 'Buy our stuff. We have FOO. They dont.'). Since that leaves only serious technical disagreements as a reasons to fork, it happens more rarely (and never in a proprietary fashion, allowing backports and discouraging incompatibility).
Embrace-and-extend becomes a lot easier when you can just take the code supporting the protocol and add your own stuff, rather than having to reimplement it from scratch.
As regards the conceding of the desktop, there is was a recent interview with Jordan Hubbard at http://www. internetworld.com/print/current/webdev/19990412-fr eebsd.html. I also remember reading similar sentiments on usenet several times. Mr Hubbard and some other fairly outspoken BSD advocates may not represent the BSD community, but in such a case the other developers should speak out too, because this idea appears to be fairly prevalent. I most certainly hope the BSD crowd would join in in the quest for the desktop, because together we'd be stronger.
And, as far as the tightness of control, since it appears people have differing opinions on this, I'd guess it's just a matter of how involved you are and what you mean with 'control' :). 'Linux' probably has a lot more than 150 people 'in control' because the separate packages tend to be maintained by separate and unorganized people. The different packages in themselves have a lot fewer of course (some control the kernel, some glibc, some gcc, etc). And in the end, the distribution creators have control over what happens in the integrated end result. The same is, of course, true of BSD in some fashion, because the BSD distributions include external software too. I guess it's just a matter of opinion in the end :).
Well, there are no serious technical reasons. Both will experience minor temporary advantages in one direction in some parts of the system at different times. But due to the high exchange between systems I dont think any such difference will last, and most claims in either direction are usually just advocacy.
I've had both keel over at high loads. But I expect any system running at 60 loadavg to keel over eventually, and in any case you have a serious sizing problem (not to mention response time problem) if you have a sustained loadavg around 60.
So in the end it comes down to a few practical, political and personal preference issues.
SysV. I do not maintain just BSD based systems. Since I have to maintain AIX, Solaris and HP-UX which are all more or less SysV style, any time I get to a BSD based system it's an annoyance. This is an annoyance with Linux too, at times, but at least it's a little more SysVish (we can argue the merits about that...).
GPL. Some BSD supporters argue about the extra freedom of the BSD license, but in my opinion, if BSD should make major inroads and raise corporate interest then we'd just get another... SunOS, HP-UX 9, etc. The BSD license is more free than the GPL, but the price of that freedom is proprietarization, code forking and yet another round of incompatible embrace-and-extend corporate wrangling around. No Thank You. We Have Done That Already. BSDI has a tendency to play nice, but the others dont.
A realistic view on the market. BSD appears to be willing to concede the desktop to Windows, and be content with being a very good server platform. While that may be a possibly realistic view, it isnt in my opinion an acceptable one. Because Microsoft will not tolerate either BSD or Linux as a server platform, and they'll do everything they can to make sure that the Windows clients wont work with anything but NT, or that there are major proprietary advantages of using NT. Giving up the client market means, IMO, giving up any chance at existence at all. It wont matter how good you are if Microsoft has total control of the clients. And most of the major advances in Linux have come as far as they have because the people behind them were not realistic.
And finally, for various reasons,I actually prefer the more componentized and anarchistic development of parts of the Linux systems. I'm happy to leave the integration to the distribution makers, but I like the lack of central control.