"Having dell provide an out of the box running linux node with all the required drivers and enterprise class packages installed would in many cases slash IT costs"
Do you really know of any "enterprise class" bussiness that do delegate their node installs to the PC builder? That don't have their own approval procedures, that don't have their own approved procedures for installing/imagining their PCs with their corporate tools and programs?
"It's probably easier for dell to install an OS than not since they need to test the box before they ship it."
Do you mean that what comes preinstalled on a Dell is any kind of testing suite?
"All anyone cares about is to have hardware with free drivers, from there any distro can be installed."
That hits the mark, yes. And it is *VERY* easy for Dell to find the way so it's good for everybody: certify for Debian "Stable", that's all.
Debian is a known distribution that only uses free software and it's not bleeding edge. In sort: if it works on Debian Stable, it will work with any other. Still, Dell people is corporate, but Debian helps here too. What are the chances for a Debian-certified hardware not to work on RHEL or Suse? I'll bet they are almost nihil, so once certified on Debian re-certify for Red Hat and Suse is nuts. Even more: is the case that you want some hardware certifiable (think PERC)? No problem: Debian is an open community you will find far easier developing open source drivers and have them included on Debian as far as they are good quality than with anyone else that can have their own corporate portfolio.
So let's sort this again. Mr Dell: by certifying Debian you... 1) Will be certifying one of the most popular distributions 2) Will satisfy users of not so well known distributions (if it works with Debian you can bet it'll work with Arch, Slackware, Gentoo... you name it, and that's all that need and can expect users of such distributions) 3) Will satisfy FOSS zealots: if it works on "vanilla" Debian Stable this means it works over true tested open source software with no "small letter" involved 4) You still have an easy path for "corporate" distributions like Red Hat or Suse: since it works with Debian, you have an easy way to certify for Red Hat or Suse.
I don't think it requieres a genious mind to see this.
"You wouldn't be right anyway, since there are tons of library dependencies in Linux apps where updating a component could cause a chain reaction affecting all libs that use it, the libs that use the libs, and some app that uses the latter libs, you never suspected."
Yes.
Still, I have yet to have *any* problem on a security update on Debian "stable" on about six years. How's that possible?
I'll tell you: Microsoft updates are not *security* updates; they overly change the way Windows behaves so it's no wonder something breaks because of it. If they were as concious as Debian people are about fixing *only* security holes and doing it by introducing the less possible changes and no behaviour change at all, you could bet Windows patches wouldn't be such a nightmare.
Please understand that has nothing to do with being Windows or Linux but about how serious they are about how upgrades have to be done: Debian is rock solid; Red Hat a bit of a concern; Gentoo almost doesn't pay attention to it; Microsoft is about as good as Gentoo.
"Congratulations. This rant has won Tuesday's Non-sequitor Of The Day award."
I see, Chewbacca Defense. So after all is not that you were non-knowledgeable about the GPL; it's not that you are one of those "minor trolls" that FUD about the GPL because they prefer BSD-like licenses (of course for *other's* work, not theirs); it simply you are a blatant troll.
"Maybe Linux App Finder is what you're looking for?"
No, it isn't. It is an interesting place on its own, but doesn't hit the bulleye. I was talking explicitly about Debian. While one part of a comparasion could be the one that App Finder offers, there are other elements like "beware this package because it's orphaned" or "this is two main versions behind upstream while this other is only one" or (these are real cases) "kmail works awfully on Debian on disconnected IMAP" or "while documentation implies so, you can't reliabily use Trac with mod-python": all those are Debian-specific and while some of this info can be obtained from debian sites, there're no face-to-face comparations and the info that there exists is quite dispersed and not always easy (or fast) to be found.
"Yes. The whole point of the GPL is to influence how other developers license their unique, unrelated code if they want to use yours."
Bullshit. The GPL makes quite a few provisions so if your software is really unrelated you can use and even distribute your software, whatever its license is, along with GPL.
"Maybe you should read it and understand RMS's objectives with the GPL, then."
I think I clearly understand RMS' objectives with the GPL, thanks. I even know better: I know to read the GPL itself.
"If a developer wants to "open source" _their_ code, as they release it, they should use the BSDL. "
False: if you want to use *my* code to leverage your efforts so you have to code *less* due to the existance of *my* code, the you will have to use *my* code under *my* terms. You can go as far as distribute your pure code (since its *yours*) under whatever license you want to, but as long as you distribute *my* code intermingled with yours, then you will have to do it under *my* own terms. You can go so far as to publish your code as a patch against my codebase; then you will only be distributing your code and you will be able to do it under whatever license you see fit. You please go read the damn GPL.
"If a developer wants to "open source" their code, any subsequent 3rd-party modifications to that code, *and the independent code written by anyone else who wants to use their code*, they should use the GPL"
That's plain FUD. You can write as much code of your own and release it under any license you see fit -as long as "your" code is not built up as a modification of my own source code; that's it. You can publish your code as a patch against mine; you can use, for instance, a DLL of mine I released under GPL and publish strictly *your* code under whatever license you see fit, as long as it's only *your* code the one published (ie: you can release your source code under whatever license you see fit, since that's only your code, but you won't distribute a binary unless you GPL the binary too, since that binary is a modification of my library since it contains ones and zeroes that are the pure result of my coding efforts).
"And it doesn't, because the conditions around which that access occurs and the attitude to it is vastly different. Moreoever, the potential implications of "rogue code" are substantially different ("simple" lawsuit vs potentially having to GPL a previously closed-source product). "
And that's again FUD. Open source is distributed under some license terms, closed source is distributed under some license terms. Even more: if we talk about the GPL is about a lawsuit versus the choice to GPL the illegally distributed under closed-source terms -or- stop distribution of the offending code -or- reaching to a new agreement with the GPLed code copyright holder. You have more options, nore less, and more sane too (if you illegally distribute closed source code you will be against a lawsuit or... a lawsuit, where the GPL has an explicit provision that if you distribute GPLed code you can be OK by just stopping the distribution once demanded without further allievances -and still retain the "default options" of a lawsuit or reach a new distribution agreement off-courts with the copyright holder).
"It is the last thing that gives the lawyers and directors the biggest worry"
It is then a worryness based on false assumptions provided to create fear. FUD again. And again, what kind of attorneys worth their salt has a company that even fail to read the damn license? It's everything right there!
"The differences are the likelihood of using "rogue code" (significantly higher with open source) and the potential implications of doing so (possibly much worse with GPLed source code)."
FUD, FUD and more FUD. Firstly you are mixing at your leisure talking about "open source" an talking about "GPL" as you see fit to your intentions. Secondly you are making blatantly false asertions about the GPL. Thirdly you are extending such assertions -in case they were true, and they don't, to open source in general. FUD, FUD and more FUD I say.
"The problem here is two-fold: You need somebody to write the comparisons. Somebody either unbiased, or capable of overlooking that. You need somewhere to host the writeup(s)."
Well, I think there's already somebody (or, it's suppoused to be somebody at least) writing the "one package a day" articles. My point was not so much about somebody stepping front (they're going to do it on their spare time, so I wouldn't dare to say they *must* do this or that), but about what I would find a better way to get most benefit from the effort, once somebody has taken the decision about doing it.
My "problem" with debian packages is not to find them (apt-cache makes quite a good job on it) but comparing "competing" packages, and I don't know about any resource on Debian on this.
Just an example: I don't mind about an explanation on how good apt-cacher is (a Debian package to cache access to Debian repositories), but it would be much better a side-to-side comparation among apt-cacher, apt-proxy and squid on repository-caching functions so I can use it to make my opinion for my environment.
"People advocating the GPL tend to be the worst, however, since they are inherently more interested in influencing other people's code than their own (because, if they weren't, they wouldn't be using the GPL)."
So people distributing under the GPL are trying to tell how you distribute *your* code!? That's first news to me. I was under the strong impression (both because I developed code under the GPL and used code under the GPL... and took the time to read the GPL itself) that people distributing under the GPL are just telling under what circumnstances are you allowed to use/distribute such code. If you abide OK, if you don't, you won't use that code but, of course, you can still completly free to dictate how is *your* code to be distributed nevertheless.
"Or haven't you noticed how frequently "you have access to the source" is put forward as an advantage of open source software ? "
The fact is that there *is* an advantage about having access to the source (sometimes the advantage is minimal, such the "shared source" case from Microsoft, sometimes the advantage is hughe, such is the case for Public Domain code, but there *is* an advantage). Not only open source recognices it, but all contracting/licensing under non-redistribution and/or scrow (which on my experience is the vast majority of big software contracts) recognices that too.
"Straw man. The source code for closed-source products is neither easily available nor, more importantly, advertised as being usable."
And I again, have to say that you probably haven't been too long on this bussiness: having access to the source code is quite usual, even on source code being distributed under non-disclosure/closed source agreements. Obviously is not as common as the case with open source (where you *always* gain access to the source) but it is quite common anyway. And, obviously, neither open nor closed source advertise "the code to be usable", but "the code to be usable under such and such terms as expressed in the acompanying license".
"People like you. [is being disingenous]"
Thank you.
"You made one just a few sentences ago, trying to pretend that source code for open-source and closed-source has similar availability"
No. I didn't go into the relative frecuency of gaining access to open source code relative to closed source code, but I said (and so I maintain) that there's quite a lot of times where developers gain access to closed source code and that doesn't seem to pose "significant threats" as seems to be the case with open source. And I say that smels FUD from miles away.
"and, hence, using either has similar legal considerations."
But of course they have! On closed source you are limited to whatever the license agreement stablishes. On open source you are limited to whatever the license agreement stablishes too. Where's the difference?
"Yeah, if your devs are billionaires who can afford to window-shop closed source code licenses from their pocket money"
I bet you haven't work too much in the bussiness.
"Meanwhile, in the real world..."
Menawhile, in the real world, tons of developers work on either internal projects with total source code access (the vast majority) or gain access due to company's agreements (directly or on scrow) to the source code base they are playing with.
The fact is there's quite a lot circumnstances where a developer comes in contact with foreign source code that is managed by telling the developer what he can do with the code and what he can't (hell you are trusting your coders for some of the most important assets you company has: both its IP and its information management procedures but you are not confident they can follow some easy directions like "you ain't touch non-blessed foreign code"? that's absurd) but it seems that only *open* source code poses a significant copyright threat. That's FUD and nothing else.
"Because closed-source code doesn't try to pretend it is available for source-level availability, as open-source frequently does."
Which open source does so?
All I know is that software is protected by copyright laws and distributed under a license agreement. I *know* that even if I'm not a lawyer. How can a lawyer think otherwise?
"There are potentially _significant_ and _far reaching_ effects of using GPLed source code"
There are potentially _significant_and_far_reaching_ effects of using closed licensed source code too. In fact, *everything* covered under copyrigth laws have potentially _significant_and_far_reaching_ effects, *I* know this and *any* lawyer knows this. On the other hand, open source licenses tend to be written down in clear-crystal terms in order to avoid any misconceptions (albeit only on a best-effort intent) while other license agreements, CLUFs et al. seem to be written specifically to mislead people or force the law to say things not imagined by the legislator (the most blatant case: "if you pay for something you acquire some rights for the thing to be done properly" which most CLUFs try to work against). On a company, attorney's work is dealing with contracts and license agreements day-in day-out so what's the *specific* problem regarding license agreements on the open source camp? If anything, a company attorney should be glad that, on average, open source license agreements tend to be easier to deal with.
"Disingenuous comparisons"
Where do those "disingenuous comparisions" come from? What you are doing is trying to make people Fear where there's nothing new to fear about and ofering Uncertainty talking about generic issues when the real case comes down as easy as read the f* license that comes with the code, in order to make people Doubt about the validity of a hugh class of software distribution agreements in negative and vague terms. And you know what Fear, Uncertainty and Doubt makes up to, right?
"To take one example from a client that shall remain nameless. I needed an SQL tool to do my job, and the only approved tool was Query Analyzer. At the same time they were in a process of migrating to a new platform, and everyone issued new PCs had to be on the new platform. Unfortunately, they had not certified Query Analyser (and Enterprise Manager) for use on the new platform. Could I have it installed anyway? No, against policy. Could I downgrade to the old platform? No, against policy. Could they make an exception to policy? Blasphemy. I could tell you how much time and money was wasted on that, but you'd swear I was lying."
I'd believe you since I've been there too.
But then, what's the case about "fearing open source" when the fact is that the ones that stablished the policy were the ones that shited it -and such situations will rise both using open or closed source software?
No. I think the (somehow) real "problem" with open source is twofold: 1) Marketroid FUD speech. A PHB is not a technician and surely knows more or less about "technocrap" than a geek about quarter balancing. So the PHB forms an opinion with the elements that reach their hands (just exactly the same *we* all do). And what he has on his hands are pretty coloured brochures from well known closed source companies that can spend money on those issues against vague references from other products that do not expend money on bright coloured brochures (and for the most part, such "vague references" will come from the side of the ones that do expend money on bright coloured brochures). 2) The old adaggio: timeo danaos et dona ferentes. It's free thus it must hide something malicious.
"With regard to your premise number 1, I don't agree that's a "mistaken impression" at all"
Yes, it is. It wouldn't be a "mistaken impression" if source code added *new* legal problems, but the case is that it doesn't add new problems at all, so they shouldn't be more scared about the GPL than they are about Microsoft's CLUF, for instance. There lies the "mistaken impression".
"What if I downloaded Spring, renamed it and sold it to my client as my own work? I would be in trouble."
Of course you could be in troubles. But "what if I downloaded Microsoft Office 2003, renamed it and sold it to my client as my own work?" I certainly would be in *big* troubles too, so where's the novelty? Answer: nowhere. For you to use code written by others, you need them to agree. Sometimes this involves royaties sometimes not, that's all.
"if you use any open source code in your company's software, your failure to comply with the legal conditions for doing so (such as the GPL) can and will put you in close communication with your lawyers"
If you use any closed source code in your company's software, your failure to comply with the legal conditions for doing so (such as the Microsoft's CLUF) can and will put you in close communication with your lawyers.
So once again: where is the novelty of the case so company's lawyers can cry "fire, fire!" when talking about open source that were not the same with all closed source they don't cry "fire, fire!" about?
" have you tried opening a complex spreadsheet in openoffice ?"
Yes.
"it'll take ages"
False.
"On my 3 year old windows laptop similar spreadsheets open in 20% of the time in Excel."
False again.
You probably meant that open *Excel* spreadsheets on Openoffice.org took ages; that I admit. But open *openoffice* spreadsheets on Openoffice.org works just OK. On the other hand, trying to open Openoffice.org spreadsheets on Excel doesn't take ages: it takes forever.
Maybe he should find a higher VIP just to point the case as it is, not as it seems.
Per the notice we are not talking here about "evaluating Samba as a replacement"; Samba is *already* working and working "great: fast, secure, stable", but a VIP thinks is "amateurish".
What we should say about a manager that on purpouse forgets *facts* in favour of *opinions*? Maybe it's time to restudy if the company is making a good deal paying big cash to such a person.
Not to talk about that other little detail: Next time a (say) comercial executive feels she is in charge of technical choices, maybe a technician should decide the marketing strategy for the company.
"In fact I can't understand how can US workers comply and go away with such a draconian practice like a "non compete" clause. What do they think you are supposed to do for a year? Washing cars?"
No, living out of the surplus wages. It's easy: they add a 12 months non-competing clause, you add a 12 months wages should be payed.
On the other hand, I don't know in the USA, but where I live such clauses wouldn't be enforceable.
"If OpenNMS wants to play with the big boys, they will have to beef things up a bit. Once you can withstand being slashdotted, then we'll talk."
Let's see if I understood properly.
Do you really imply that in order to develop a suitable network management solution you must pay big cash to your bandwith provider or else your product must be shit?
"You are right that article does not use the word absorb, but it implies that the object absorbs light."
So, after all, you made me read the article. What's the good of Slashdot then?
But, after reading it, I must say no: it doesn't imply at any moment the new material absorbs light in any significant manner.
"Otherwise, it would not appear dark in the picture"
I think you mean the picture where it appears with some other objects. If you look at it carefully, the other objects are brilliant because the light they reflect, like a glass seen at an angle; when something doesn't emit/reflect/refract light in your direction what color do you think it's seen, no matter if it's transparent or not?
"it would not be useful in solar cells"
As the article clearly states, its usefulness in solar cells or leds is as a new "optical coating"; and it's a more efficient coating because it doesn't reflect any light but do transmit almost all light (either from a diode inside to the environment, so the diode is brightest, or from the environment to the functional parts of a solar cell in the inside so "The new coating could increase the amount of light reaching the active region of a solar cell"). Do you remember how do we call an object that efficently transmits light? Transparent, that is.
"and it would not be useful as a source of black body radiation."
It does nothing to be with a body being transparent or opaque. Every single mass in Universe will emit radiation at a rate that depends solely on its absolute temperature disregarding *all* other physical properties of the object (from a black hole to a massive supernova). A non-reflecting body makes a perfect experimental black body not because it's black (on its common acception which implies not only being black, but being opaque too) but because its light emissions due to temperature won't be "contaminated" by reflections of other elements' radiation laying around (the measure chamber itself, for instance): they'll truly be their own "black body" radiations and only them -and this applies equally well to an opaque body and to a perfectly transparent one.
"Your ability to miss the blindingly obvious is breathtaking. The point is simply this, if IBM (manufacturer of OS/2) can provide a DST fix *free* to all of their customers, why is M$ & Billy the barf bag charging for theirs.?"
I think it's you the one that don't see the obvious. I'll repeat it again: they charge for new features *because they can*. Full stop.
"Oh, and your contention that the fix is a "feature"? No person of any standing would ever assert that a patch to bring a (still) widely used OS into compliance is a feature."
Because changing the way a system behaves due to new circumnstances not known or not aplicable by the time the system was released is *always* a feature, not a fix.
"As for stupidity, learn to spell, or better yet, actually learn the English language you third-world call centre refugee. "
Probably my English is not as good as you, still I understand the difference between ignorance and stupidity, which seems to be quite beyond your abilities.
Maybe but then, who tells Exchange what current time is? The OS. And the OS that Exchange runs on makes the extrange assumption that in order to move local time by one hour it must move forward or backwards computer time by one hour which make time gaps (and problems) appear.
"I want my meeting to happen at a particular local time"
You are right there *is* a problem, you are wrong you want a meeting happening always at local time. There are two scenarios: one of them will be avoided by using a sensible system that interanlly manages times always as UTC (as everybody does *except* Microsoft); the other just can't have a satisfactory answer. Let see them:
1) A multiconference is apointed among a guy in New York, other in Milano and a third one in Canberra on JUN/21/2007 9:00 London time. It only makes sense having this conference apointed GMT/UTC. If it happens that Milano starts summer savings time you will want the Milano guy connecting one hour later per his local time, not change all others because of his local change.
2) You have an appointment with your doctor on JUN/21/2007 9:00 local time. No matter how crazy local time goes, you still will want your doctor to recieve you at 9 o'clock that day -except, of course, that you both were so used to managing UTC instead of local time that it made more sense to move your appointment just as it would happen on the first scenario.
Now, for every simple programatic solution you can only take into account one scenario or the other, not both of them at the same time. Which one the OS vendor should take? It's clear to me that the obvious choice is the first one. If, for instance, Oklahoma state comes crazy regarding its local time, it should stay as a local Oklahoma problem if any, and shouldn't "leak" anywhere else. You can get this by always internally storing time as UTC. That's not only my conclusion; it's the conclusion reached by all OS vendors -with the exception of Microsoft, of course.
"WIW, every time I've installed a Linux machine it stored local time on the hardware clock also. You're usually given the option of which format to use.."
You are always given the option to use local *instead* of UTC, which is the standard on all unix-like systems. And you know why? Because it's well known that all well behaved OSs store time as UTC (and linux is a well behaved system to this regard). But there's quite a famous PC OS that is not well behaved, and it's well known that Linux usually has to coexist with that other famous PC OS. So the only reason Linux asks you if you want to store time as local is because Windows! It's because there's no other way to have the fiction that on a multiboot environment both windows and linux show the proper local time.
"I don't think you understand the full nature of the problem."
I don't think *you* understand the full nature of the problem, which, once again, it's that Windows is crap and tries to force its crapness down your throat even when you are not using windows.
"what exactly is your excuse for charging folks for this rather elementary fix?"
That's plain simple. They charge because they *can*. Even if Microsoft had a sane guarantee policy (of course, they don't have it) this is not a bug but a feature. Microsoft is a privative software vendor and is just OK for them to charge for new features. Others don't charge for new features? That's fine and good for them, but this doesn't mean Microsoft needs any "excuse" to charge for new features; that's just the way they make bussiness and it's no news at all.
"So, Billy barf-bag,"
There's no "Billy barf-bag" here. If you find surprising Microsoft charging for features, maybe the one surprised is the one being plain unprofessional -or even stupid, here. You first decided to get locked on a company that can and will decide how much they will charge for *any* feature, then you surprise that they decided to use the power you put on their hands? doh!
Slashdot Mirror
"Having dell provide an out of the box running linux node with all the required drivers and enterprise class packages installed would in many cases slash IT costs"
Do you really know of any "enterprise class" bussiness that do delegate their node installs to the PC builder? That don't have their own approval procedures, that don't have their own approved procedures for installing/imagining their PCs with their corporate tools and programs?
"It's probably easier for dell to install an OS than not since they need to test the box before they ship it."
Do you mean that what comes preinstalled on a Dell is any kind of testing suite?
"All anyone cares about is to have hardware with free drivers, from there any distro can be installed."
That hits the mark, yes. And it is *VERY* easy for Dell to find the way so it's good for everybody: certify for Debian "Stable", that's all.
Debian is a known distribution that only uses free software and it's not bleeding edge. In sort: if it works on Debian Stable, it will work with any other. Still, Dell people is corporate, but Debian helps here too. What are the chances for a Debian-certified hardware not to work on RHEL or Suse? I'll bet they are almost nihil, so once certified on Debian re-certify for Red Hat and Suse is nuts. Even more: is the case that you want some hardware certifiable (think PERC)? No problem: Debian is an open community you will find far easier developing open source drivers and have them included on Debian as far as they are good quality than with anyone else that can have their own corporate portfolio.
So let's sort this again. Mr Dell: by certifying Debian you...
1) Will be certifying one of the most popular distributions
2) Will satisfy users of not so well known distributions (if it works with Debian you can bet it'll work with Arch, Slackware, Gentoo... you name it, and that's all that need and can expect users of such distributions)
3) Will satisfy FOSS zealots: if it works on "vanilla" Debian Stable this means it works over true tested open source software with no "small letter" involved
4) You still have an easy path for "corporate" distributions like Red Hat or Suse: since it works with Debian, you have an easy way to certify for Red Hat or Suse.
I don't think it requieres a genious mind to see this.
"You wouldn't be right anyway, since there are tons of library dependencies in Linux apps where updating a component could cause a chain reaction affecting all libs that use it, the libs that use the libs, and some app that uses the latter libs, you never suspected."
Yes.
Still, I have yet to have *any* problem on a security update on Debian "stable" on about six years. How's that possible?
I'll tell you: Microsoft updates are not *security* updates; they overly change the way Windows behaves so it's no wonder something breaks because of it. If they were as concious as Debian people are about fixing *only* security holes and doing it by introducing the less possible changes and no behaviour change at all, you could bet Windows patches wouldn't be such a nightmare.
Please understand that has nothing to do with being Windows or Linux but about how serious they are about how upgrades have to be done: Debian is rock solid; Red Hat a bit of a concern; Gentoo almost doesn't pay attention to it; Microsoft is about as good as Gentoo.
"Congratulations. This rant has won Tuesday's Non-sequitor Of The Day award."
I see, Chewbacca Defense. So after all is not that you were non-knowledgeable about the GPL; it's not that you are one of those "minor trolls" that FUD about the GPL because they prefer BSD-like licenses (of course for *other's* work, not theirs); it simply you are a blatant troll.
Have a nice day.
"Maybe Linux App Finder is what you're looking for?"
No, it isn't. It is an interesting place on its own, but doesn't hit the bulleye. I was talking explicitly about Debian. While one part of a comparasion could be the one that App Finder offers, there are other elements like "beware this package because it's orphaned" or "this is two main versions behind upstream while this other is only one" or (these are real cases) "kmail works awfully on Debian on disconnected IMAP" or "while documentation implies so, you can't reliabily use Trac with mod-python": all those are Debian-specific and while some of this info can be obtained from debian sites, there're no face-to-face comparations and the info that there exists is quite dispersed and not always easy (or fast) to be found.
"Yes. The whole point of the GPL is to influence how other developers license their unique, unrelated code if they want to use yours."
Bullshit. The GPL makes quite a few provisions so if your software is really unrelated you can use and even distribute your software, whatever its license is, along with GPL.
"Maybe you should read it and understand RMS's objectives with the GPL, then."
I think I clearly understand RMS' objectives with the GPL, thanks. I even know better: I know to read the GPL itself.
"If a developer wants to "open source" _their_ code, as they release it, they should use the BSDL. "
False: if you want to use *my* code to leverage your efforts so you have to code *less* due to the existance of *my* code, the you will have to use *my* code under *my* terms. You can go as far as distribute your pure code (since its *yours*) under whatever license you want to, but as long as you distribute *my* code intermingled with yours, then you will have to do it under *my* own terms. You can go so far as to publish your code as a patch against my codebase; then you will only be distributing your code and you will be able to do it under whatever license you see fit. You please go read the damn GPL.
"If a developer wants to "open source" their code, any subsequent 3rd-party modifications to that code, *and the independent code written by anyone else who wants to use their code*, they should use the GPL"
That's plain FUD. You can write as much code of your own and release it under any license you see fit -as long as "your" code is not built up as a modification of my own source code; that's it. You can publish your code as a patch against mine; you can use, for instance, a DLL of mine I released under GPL and publish strictly *your* code under whatever license you see fit, as long as it's only *your* code the one published (ie: you can release your source code under whatever license you see fit, since that's only your code, but you won't distribute a binary unless you GPL the binary too, since that binary is a modification of my library since it contains ones and zeroes that are the pure result of my coding efforts).
"And it doesn't, because the conditions around which that access occurs and the attitude to it is vastly different. Moreoever, the potential implications of "rogue code" are substantially different ("simple" lawsuit vs potentially having to GPL a previously closed-source product). "
And that's again FUD. Open source is distributed under some license terms, closed source is distributed under some license terms. Even more: if we talk about the GPL is about a lawsuit versus the choice to GPL the illegally distributed under closed-source terms -or- stop distribution of the offending code -or- reaching to a new agreement with the GPLed code copyright holder. You have more options, nore less, and more sane too (if you illegally distribute closed source code you will be against a lawsuit or... a lawsuit, where the GPL has an explicit provision that if you distribute GPLed code you can be OK by just stopping the distribution once demanded without further allievances -and still retain the "default options" of a lawsuit or reach a new distribution agreement off-courts with the copyright holder).
"It is the last thing that gives the lawyers and directors the biggest worry"
It is then a worryness based on false assumptions provided to create fear. FUD again. And again, what kind of attorneys worth their salt has a company that even fail to read the damn license? It's everything right there!
"The differences are the likelihood of using "rogue code" (significantly higher with open source) and the potential implications of doing so (possibly much worse with GPLed source code)."
FUD, FUD and more FUD. Firstly you are mixing at your leisure talking about "open source" an talking about "GPL" as you see fit to your intentions. Secondly you are making blatantly false asertions about the GPL. Thirdly you are extending such assertions -in case they were true, and they don't, to open source in general. FUD, FUD and more FUD I say.
"The problem here is two-fold:
You need somebody to write the comparisons. Somebody either unbiased, or capable of overlooking that.
You need somewhere to host the writeup(s)."
Well, I think there's already somebody (or, it's suppoused to be somebody at least) writing the "one package a day" articles. My point was not so much about somebody stepping front (they're going to do it on their spare time, so I wouldn't dare to say they *must* do this or that), but about what I would find a better way to get most benefit from the effort, once somebody has taken the decision about doing it.
My "problem" with debian packages is not to find them (apt-cache makes quite a good job on it) but comparing "competing" packages, and I don't know about any resource on Debian on this.
Just an example: I don't mind about an explanation on how good apt-cacher is (a Debian package to cache access to Debian repositories), but it would be much better a side-to-side comparation among apt-cacher, apt-proxy and squid on repository-caching functions so I can use it to make my opinion for my environment.
"People advocating the GPL tend to be the worst, however, since they are inherently more interested in influencing other people's code than their own (because, if they weren't, they wouldn't be using the GPL)."
So people distributing under the GPL are trying to tell how you distribute *your* code!? That's first news to me. I was under the strong impression (both because I developed code under the GPL and used code under the GPL... and took the time to read the GPL itself) that people distributing under the GPL are just telling under what circumnstances are you allowed to use/distribute such code. If you abide OK, if you don't, you won't use that code but, of course, you can still completly free to dictate how is *your* code to be distributed nevertheless.
"Or haven't you noticed how frequently "you have access to the source" is put forward as an advantage of open source software ? "
The fact is that there *is* an advantage about having access to the source (sometimes the advantage is minimal, such the "shared source" case from Microsoft, sometimes the advantage is hughe, such is the case for Public Domain code, but there *is* an advantage). Not only open source recognices it, but all contracting/licensing under non-redistribution and/or scrow (which on my experience is the vast majority of big software contracts) recognices that too.
"Straw man. The source code for closed-source products is neither easily available nor, more importantly, advertised as being usable."
And I again, have to say that you probably haven't been too long on this bussiness: having access to the source code is quite usual, even on source code being distributed under non-disclosure/closed source agreements. Obviously is not as common as the case with open source (where you *always* gain access to the source) but it is quite common anyway. And, obviously, neither open nor closed source advertise "the code to be usable", but "the code to be usable under such and such terms as expressed in the acompanying license".
"People like you. [is being disingenous]"
Thank you.
"You made one just a few sentences ago, trying to pretend that source code for open-source and closed-source has similar availability"
No. I didn't go into the relative frecuency of gaining access to open source code relative to closed source code, but I said (and so I maintain) that there's quite a lot of times where developers gain access to closed source code and that doesn't seem to pose "significant threats" as seems to be the case with open source. And I say that smels FUD from miles away.
"and, hence, using either has similar legal considerations."
But of course they have! On closed source you are limited to whatever the license agreement stablishes. On open source you are limited to whatever the license agreement stablishes too. Where's the difference?
"Yeah, if your devs are billionaires who can afford to window-shop closed source code licenses from their pocket money"
I bet you haven't work too much in the bussiness.
"Meanwhile, in the real world..."
Menawhile, in the real world, tons of developers work on either internal projects with total source code access (the vast majority) or gain access due to company's agreements (directly or on scrow) to the source code base they are playing with.
The fact is there's quite a lot circumnstances where a developer comes in contact with foreign source code that is managed by telling the developer what he can do with the code and what he can't (hell you are trusting your coders for some of the most important assets you company has: both its IP and its information management procedures but you are not confident they can follow some easy directions like "you ain't touch non-blessed foreign code"? that's absurd) but it seems that only *open* source code poses a significant copyright threat. That's FUD and nothing else.
"Because closed-source code doesn't try to pretend it is available for source-level availability, as open-source frequently does."
Which open source does so?
All I know is that software is protected by copyright laws and distributed under a license agreement. I *know* that even if I'm not a lawyer. How can a lawyer think otherwise?
"There are potentially _significant_ and _far reaching_ effects of using GPLed source code"
There are potentially _significant_and_far_reaching_ effects of using closed licensed source code too. In fact, *everything* covered under copyrigth laws have potentially _significant_and_far_reaching_ effects, *I* know this and *any* lawyer knows this. On the other hand, open source licenses tend to be written down in clear-crystal terms in order to avoid any misconceptions (albeit only on a best-effort intent) while other license agreements, CLUFs et al. seem to be written specifically to mislead people or force the law to say things not imagined by the legislator (the most blatant case: "if you pay for something you acquire some rights for the thing to be done properly" which most CLUFs try to work against). On a company, attorney's work is dealing with contracts and license agreements day-in day-out so what's the *specific* problem regarding license agreements on the open source camp? If anything, a company attorney should be glad that, on average, open source license agreements tend to be easier to deal with.
"Disingenuous comparisons"
Where do those "disingenuous comparisions" come from? What you are doing is trying to make people Fear where there's nothing new to fear about and ofering Uncertainty talking about generic issues when the real case comes down as easy as read the f* license that comes with the code, in order to make people Doubt about the validity of a hugh class of software distribution agreements in negative and vague terms. And you know what Fear, Uncertainty and Doubt makes up to, right?
"To take one example from a client that shall remain nameless. I needed an SQL tool to do my job, and the only approved tool was Query Analyzer. At the same time they were in a process of migrating to a new platform, and everyone issued new PCs had to be on the new platform. Unfortunately, they had not certified Query Analyser (and Enterprise Manager) for use on the new platform. Could I have it installed anyway? No, against policy. Could I downgrade to the old platform? No, against policy. Could they make an exception to policy? Blasphemy. I could tell you how much time and money was wasted on that, but you'd swear I was lying."
I'd believe you since I've been there too.
But then, what's the case about "fearing open source" when the fact is that the ones that stablished the policy were the ones that shited it -and such situations will rise both using open or closed source software?
No. I think the (somehow) real "problem" with open source is twofold:
1) Marketroid FUD speech. A PHB is not a technician and surely knows more or less about "technocrap" than a geek about quarter balancing. So the PHB forms an opinion with the elements that reach their hands (just exactly the same *we* all do). And what he has on his hands are pretty coloured brochures from well known closed source companies that can spend money on those issues against vague references from other products that do not expend money on bright coloured brochures (and for the most part, such "vague references" will come from the side of the ones that do expend money on bright coloured brochures).
2) The old adaggio: timeo danaos et dona ferentes. It's free thus it must hide something malicious.
"With regard to your premise number 1, I don't agree that's a "mistaken impression" at all"
Yes, it is. It wouldn't be a "mistaken impression" if source code added *new* legal problems, but the case is that it doesn't add new problems at all, so they shouldn't be more scared about the GPL than they are about Microsoft's CLUF, for instance. There lies the "mistaken impression".
"What if I downloaded Spring, renamed it and sold it to my client as my own work? I would be in trouble."
Of course you could be in troubles. But "what if I downloaded Microsoft Office 2003, renamed it and sold it to my client as my own work?" I certainly would be in *big* troubles too, so where's the novelty? Answer: nowhere. For you to use code written by others, you need them to agree. Sometimes this involves royaties sometimes not, that's all.
"if you use any open source code in your company's software, your failure to comply with the legal conditions for doing so (such as the GPL) can and will put you in close communication with your lawyers"
If you use any closed source code in your company's software, your failure to comply with the legal conditions for doing so (such as the Microsoft's CLUF) can and will put you in close communication with your lawyers.
So once again: where is the novelty of the case so company's lawyers can cry "fire, fire!" when talking about open source that were not the same with all closed source they don't cry "fire, fire!" about?
" have you tried opening a complex spreadsheet in openoffice ?"
Yes.
"it'll take ages"
False.
"On my 3 year old windows laptop similar spreadsheets open in 20% of the time in Excel."
False again.
You probably meant that open *Excel* spreadsheets on Openoffice.org took ages; that I admit. But open *openoffice* spreadsheets on Openoffice.org works just OK. On the other hand, trying to open Openoffice.org spreadsheets on Excel doesn't take ages: it takes forever.
"I've used Samba at home..."
Quite convincing argument against an accusation of being "amateur".
"Maybe he should point this VIP"
Maybe he should find a higher VIP just to point the case as it is, not as it seems.
Per the notice we are not talking here about "evaluating Samba as a replacement"; Samba is *already* working and working "great: fast, secure, stable", but a VIP thinks is "amateurish".
What we should say about a manager that on purpouse forgets *facts* in favour of *opinions*? Maybe it's time to restudy if the company is making a good deal paying big cash to such a person.
Not to talk about that other little detail: Next time a (say) comercial executive feels she is in charge of technical choices, maybe a technician should decide the marketing strategy for the company.
"In fact I can't understand how can US workers comply and go away with such a draconian practice like a "non compete" clause. What do they think you are supposed to do for a year? Washing cars?"
No, living out of the surplus wages. It's easy: they add a 12 months non-competing clause, you add a 12 months wages should be payed.
On the other hand, I don't know in the USA, but where I live such clauses wouldn't be enforceable.
"If OpenNMS wants to play with the big boys, they will have to beef things up a bit. Once you can withstand being slashdotted, then we'll talk."
Let's see if I understood properly.
Do you really imply that in order to develop a suitable network management solution you must pay big cash to your bandwith provider or else your product must be shit?
Woooha, what a charming troll!
But you are wrong: I'm not still to stupid; I'm adamant.
"You are right that article does not use the word absorb, but it implies that the object absorbs light."
So, after all, you made me read the article. What's the good of Slashdot then?
But, after reading it, I must say no: it doesn't imply at any moment the new material absorbs light in any significant manner.
"Otherwise, it would not appear dark in the picture"
I think you mean the picture where it appears with some other objects. If you look at it carefully, the other objects are brilliant because the light they reflect, like a glass seen at an angle; when something doesn't emit/reflect/refract light in your direction what color do you think it's seen, no matter if it's transparent or not?
"it would not be useful in solar cells"
As the article clearly states, its usefulness in solar cells or leds is as a new "optical coating"; and it's a more efficient coating because it doesn't reflect any light but do transmit almost all light (either from a diode inside to the environment, so the diode is brightest, or from the environment to the functional parts of a solar cell in the inside so "The new coating could increase the amount of light reaching the active region of a solar cell"). Do you remember how do we call an object that efficently transmits light? Transparent, that is.
"and it would not be useful as a source of black body radiation."
It does nothing to be with a body being transparent or opaque. Every single mass in Universe will emit radiation at a rate that depends solely on its absolute temperature disregarding *all* other physical properties of the object (from a black hole to a massive supernova). A non-reflecting body makes a perfect experimental black body not because it's black (on its common acception which implies not only being black, but being opaque too) but because its light emissions due to temperature won't be "contaminated" by reflections of other elements' radiation laying around (the measure chamber itself, for instance): they'll truly be their own "black body" radiations and only them -and this applies equally well to an opaque body and to a perfectly transparent one.
"Your ability to miss the blindingly obvious is breathtaking. The point is simply this, if IBM (manufacturer of OS/2) can provide a DST fix *free* to all of their customers, why is M$ & Billy the barf bag charging for theirs.?"
I think it's you the one that don't see the obvious. I'll repeat it again: they charge for new features *because they can*. Full stop.
"Oh, and your contention that the fix is a "feature"? No person of any standing would ever assert that a patch to bring a (still) widely used OS into compliance is a feature."
Because changing the way a system behaves due to new circumnstances not known or not aplicable by the time the system was released is *always* a feature, not a fix.
"As for stupidity, learn to spell, or better yet, actually learn the English language you third-world call centre refugee. "
Probably my English is not as good as you, still I understand the difference between ignorance and stupidity, which seems to be quite beyond your abilities.
"Exchange does store dates in UTC."
Maybe but then, who tells Exchange what current time is? The OS. And the OS that Exchange runs on makes the extrange assumption that in order to move local time by one hour it must move forward or backwards computer time by one hour which make time gaps (and problems) appear.
"I want my meeting to happen at a particular local time"
You are right there *is* a problem, you are wrong you want a meeting happening always at local time. There are two scenarios: one of them will be avoided by using a sensible system that interanlly manages times always as UTC (as everybody does *except* Microsoft); the other just can't have a satisfactory answer. Let see them:
1) A multiconference is apointed among a guy in New York, other in Milano and a third one in Canberra on JUN/21/2007 9:00 London time. It only makes sense having this conference apointed GMT/UTC. If it happens that Milano starts summer savings time you will want the Milano guy connecting one hour later per his local time, not change all others because of his local change.
2) You have an appointment with your doctor on JUN/21/2007 9:00 local time. No matter how crazy local time goes, you still will want your doctor to recieve you at 9 o'clock that day -except, of course, that you both were so used to managing UTC instead of local time that it made more sense to move your appointment just as it would happen on the first scenario.
Now, for every simple programatic solution you can only take into account one scenario or the other, not both of them at the same time. Which one the OS vendor should take? It's clear to me that the obvious choice is the first one. If, for instance, Oklahoma state comes crazy regarding its local time, it should stay as a local Oklahoma problem if any, and shouldn't "leak" anywhere else. You can get this by always internally storing time as UTC. That's not only my conclusion; it's the conclusion reached by all OS vendors -with the exception of Microsoft, of course.
"WIW, every time I've installed a Linux machine it stored local time on the hardware clock also. You're usually given the option of which format to use.."
You are always given the option to use local *instead* of UTC, which is the standard on all unix-like systems. And you know why? Because it's well known that all well behaved OSs store time as UTC (and linux is a well behaved system to this regard). But there's quite a famous PC OS that is not well behaved, and it's well known that Linux usually has to coexist with that other famous PC OS. So the only reason Linux asks you if you want to store time as local is because Windows! It's because there's no other way to have the fiction that on a multiboot environment both windows and linux show the proper local time.
"I don't think you understand the full nature of the problem."
I don't think *you* understand the full nature of the problem, which, once again, it's that Windows is crap and tries to force its crapness down your throat even when you are not using windows.
"what exactly is your excuse for charging folks for this rather elementary fix?"
That's plain simple. They charge because they *can*. Even if Microsoft had a sane guarantee policy (of course, they don't have it) this is not a bug but a feature. Microsoft is a privative software vendor and is just OK for them to charge for new features. Others don't charge for new features? That's fine and good for them, but this doesn't mean Microsoft needs any "excuse" to charge for new features; that's just the way they make bussiness and it's no news at all.
"So, Billy barf-bag,"
There's no "Billy barf-bag" here. If you find surprising Microsoft charging for features, maybe the one surprised is the one being plain unprofessional -or even stupid, here. You first decided to get locked on a company that can and will decide how much they will charge for *any* feature, then you surprise that they decided to use the power you put on their hands? doh!