"But when we go to get a new phone and contract..."
I am from Spain. I've been with the same operator for more than two years. I lost my phone, so I needed a replacement. They told me the replacement came with a 18 months retention policy or 150 "fine" if I go with a new operator within that time. I told them where they could safeguard their policy and bought a quite simple free phone for about 100 instead of one of their "flashy" phones free or at the same price at most.
On one hand it's not surprise operators are such bastards. A customer votes with his money, and seems clear people is ready to stand by almost any abouse as long as the front cost is low.
On the other hand, there *is* market for "simple" phones in developed countries (albeit not so simple than the one we are talking about here). I can afford 300 or even 600 on a mobile if I had the inclination, it's only I really want a small, long-standing battery and fancyless one. I finally ended with a benq-siemens AF51, not exactly on the bulleye, but quite close the mark.
"Oh come now, Gentoo isn't that bad in a production environment."
Oh, yes, it is!
"You treat it the same as you would any other distribution"
And then you are doomed. I'll tell you how do I treat distribution maintenance: I have my boxes look at the distribution spools so when there're security updates they download them and send an e-mail for me to know. Then I have a look at what security menaces they provide protection to, then I install them and forget about the issue. You just try to do the same on a Gentoo. Next you will know after an upgrade is you box is non-functional now in a very obvious and disgusting way if you are lucky or on a subtle way you won't detect till two or three days from now if you are not so lucky.
"Change management doesn't change just because you're using a different flavor of Linux."
Yes it does, since the moment different "flavors of Linux" treat change management in quite different ways. An installed system doesn't have to change its behaviour *EVER*, unless the sysadmin in charge so do want. You cannot reach that target in any reasonable way with a distribution that doesn't backports security bugfixes to already delivered software versions: change from Asoftware 1.1.0 to Asoftware 1.2.0 and the system will change its behaviour; don't do the upgrade and the system will have security concerns. A loose-loose situation, if you ask me.
"For what it's worth, Xen makes the process a lot easier to deal with. Clone a DomU, test out the new configuration, then decide whether to use the new DomU or stick with the old DomU"
I didn't say it is not possible to manage change on such environments; I said it's a maintenance nightmare. I do admin Linux systems on Red Hat, Debian, SuSE and Gentoo: I *do* know which are better to maintain, and I *do* know Gentoo is the worst one by considerable margin.
Yes, I know, that's why I said "usually" instead of always, and that's why I said "go read the release notes first"; if the upgrade process changes from `apt-get update && apt-get dist-upgrade` to anything else, is the release notes where you will learn it (anyway, I still use apt-get instead of aptitude).
"but on one of the woody-sarge upgrades i did neither apt-get nor aptitude proposed a sane dist-upgrade"
But reading Sarge's release notes first, would allow you to do it the proper way (from top of my mind, Woody->Sarge transition had a problem with apt and some circular dependencies, so you first should upgrade apt and related, and only then try dist-upgrade. On top of that, Sarge's dependencies are in general better thougth out -I specifically remember some regarding mail service, so you should have a look for the packages the upgrade process installed, since it's quite probably you could trim out some of them).
Again, the morale is "go read the release notes *first*".
"In a Debian-based system, all you need to do to upgrade is change the name of the distro in sources.list, then run apt-get update && apt-get dist-upgrade; this is the official method of doing so."
No, it is not. You forgot one step, the most important one.
The step you forgot is you go to Debian's web site and you read the release notes *first*. Then, you go by its instructions which usually are centered around an apt-get update && apt-get dist-upgrade instance.
I bet the "you first go and read the release notes" is valid for every operative system, it is the most forgotten step and it is the most usual source of problems.
"I tried to address that myth -- the "Fedora is just a trial ground for RHEL" statement"
It's only it is *not* a myth.
I really like Joe 'Zonker' Brockmeier's assertion at http://os.newsforge.com/print.pl?sid=06/04/10/2156 233 : "Fedora founder Warren Togami's "Welcome to Fedora" talk dealt with the history of Fedora, and how Fedora operates. Togami spent a fair amount of time emphasizing how important Fedora is to Red Hat's business, and trying to dispel the notion that Fedora is only a "perpetual beta" for Red Hat's enterprise products. This was tricky, since Fedora _is_ a perpetual beta for Red Hat's enterprise products."
Indeed, the fact that you are trying to hide Red Hat's track on this it's fastly changing my mind about the project: I am one of those that time after time goes with the "Fedora is just a trial ground for RHEL" statement, well, not exactly, since I say "Fedora is THE trial ground for RHEL" (the difference albeit subtile is VERY important), trying to avoid bad temper derivated from the fact that Fedora badly fails at people that approach it under wrong assumptions (you just have to see the comments on this article) and expecting to help those looking at Fedora to take out most benefit from it, but now, I'm seeing you are trying to take advantage after the fact that so much people is using Fedora for the wrong reasons to enwiden your user-base, so expect me counter-acting by saying that Fedora is (partly, at least) a fraud. It still *IS* the trial ground for RHEL but now I have to add: beware, it is a lockin strategy from Red Hat Inc. so newcomers get used on a redhatish platform that will NEVER acomplish production-grade quality so, once you are tied to it you must move into RHEL products for whatever serious enterprises you attempt in the future.
Just a pill: "In addition to the nine board members, there is also a chairman appointed by Red Hat, who has veto power over any decision." (from http://fedoraproject.org/wiki/Board)
That's a *fact*, anything else (...but we will try not to use our veto-power, we are good guys, etc.) are just words.
Do you expect Fedora going in ANY MANNER against Red Hat Inc.'s best interests (like... making it lose the sell of any single RHEL license)?
"The vast majority of experiences that I and every other person I have met with Fedora have been profoundly negative on some level."/TROLL MODE ON That only means that you and almost every other person you know is dumb enough not to read documentation about the tools they try to use./TROLL MODE OFF
"When is the Fedora project going to start fixing its bugs instead of just pushing out bleeding edge packages?"
Plain simple: never.
It is not as if it were a deeply hidden fact; it's even on the fundational papers from RedHat/Fedora. It is known from day O that Fedora's main goal is being Red Hat's testing field for bleeding edge technologies both from the technical and the "social" points of view. From the technical point of view that means its software will be *always* less than polished; from the social one, it only makes sense to open the "build process" as it currently is to gain knowledge about what is well recieved and what, even if hyped, it is not, in order to move RHEL accordingly (once the software is properly polished out of Fedora's suffering).
In sort: Fedora is, and it always has been kindof a "beta" aimed at technoenthusiasts, aficionados and redhat-involved hackers.
"Hey, I'm just saying that it blows my mind how bad Fedora has been for everyone"
It is *NOT* so bad for everything: it is really good for Red Hat Inc. and Red Hat hackers (meaning people that hack/develop on the Red Hat platform not only people that work within Red Hat). But yes, it is quite bad for unknowledgeable people that uses Fedora under false assumptions.
Just exactly the same happens whenever somebody tries to use a hammer as a teaspoon, and you can imagine what the usual name for someone that uses hammers as teaspons is.
"...Or rather they can't accept that someone who went to a worse school could be more intelligent than them."...or, first interview stages come from HR people, not the technical ones. As the old motto says 'you'll never be fired from choosing IBM'. Well, you'll never be fired from choosing Stanford, either. From HR point of view, it is not about hiring the best candidate, but the best one that won't expose their ass: I chose a Stanford's one that ended being an asshole, "well, shit happens, you did it the best you could"; I chose somebody from Whatever Place that ended up being subpar: my HR job is now at stake.
"At very least you'll have to convert everything you're working on into the new application's native format and deal with importing deficiencies"
Which part of "Would you buy a car that would only drive on the vendor's roads, use only the vendor gas and would only work with vendor supplies?" didn't you understand?
"native format/vendor lock-in" doesn't rise a bell in your brain?
"With software the interchangeability is lost, you can't trivially replace Windows with another OS"
Would you buy a car that would only drive on the vendor's roads, use only the vendor gas and would only work with vendor supplies?
But that's what you accept on the software world. Of course, as soon as you forget about your "responsibility" as a customer (what you should ask your provider for), your provider will abuse you (by means of lock-in, in this case). It's up to you to break the ties.
"How does the effect a company who develops a product for another company? Does this constitute distribution?"
Definetly yes.
"Suppose company X wins a contract to develop product P for company Z, if P is developed using and uses GPL software (possibly even modified version of GPL software) perhaps linked together etc. When company X delivers the final product (which will be used only internally by company Z), does this constitute distribution?"
Of course yes.
"Is the only criteria here, that company Z must also gets the source code?"
Yes (well, not exactly. The criteria is that P must be delivered to Z under GPL terms, that mainly means that Z gets the source code and the ability to further redistribute it, again, under GPL terms).
"Is it only that every entity that can get a copy of the binary must also be able to get a copy of the source?"
Is it not the same? I distribute just to Z and Z is the only one that gets the code.
So let's see this case:
Z (the client) will get P under the GPL so they are free to redistribute (under the GPL terms) since point 6 of the GPL states that the distributor "may not impose any further restrictions on the recipients' exercise of the rights granted herein."
On the other hand, X (the developer) can be bound by a contract held between X and Z ie. not to further distribute P to any other client, since the GPL doesn't say anything about that, and that's clearly within common practices.
Note that this approach will only be valid between *companies*. If you (X) are a consultant or an employee of Z, then that wouldn't be consider distribution but internal development, and you would have no rights (except maybe, that of claimed authorship, in the case you are an external consultant, not an employee) over the developed code thus, the GPL wouldn't be "triggered" at all (since it only deals with code distribution).
"The term amounts to making people retroactively waive [i]any[/i] rights they have under the civil law, which is, of course, utter nonsense. But still, with all the crap some companies put into their EULAs, this wouldn't be too surprising to find."
I think that it is the other way around, in fact. I don't know how it comes in the USA, but under (most, if not all) EU countries' law, you cannot resign to already given rigths under civil law, specially not in the case of licenses (a kind of "contract" where one of the sides has no choice to disccuss the terms of the legal abiding agreement). Clauses under those lines would be considered void and nul. Current sofware EULAs tend to be so utterly astounding that specially if the claims from the software vendor goes against a big company with its fair share of lawyers, it won't happen that some clauses are nul but the EULA as a whole, since it would tend to be consider not a fair attempt to reach an agreement -with a few faulty points, but an unfair means for one side to gain complete legal shielding without giving anything in counterpart (you know the tipical EULA: this software won't fit any given function, damage claims will be limited to 100US$ or something equally idiotical, you will resign to your legal rights like the allowance to reverse-ingeneering for cross-compatibility...). Under those circumnstances any claim from the software vendor would be dismissed.
I really would like to see Microsoft going against say, REPSOL for EULA infringement (of course any big company won't be bound by any EULA but by their private contract with Microsoft, but that's another story).
"Opening the HW specs would mean that the original company would have to support some random hacker "optimizing" the algorithms in firmware"
Bullshit#1: de Raadt is only asking for a redistribution license that will allow the firmware, The Very Same Firmware Intel Already Distributes, within OpenBSD CD. Bullshit#2: I work dayin-dayout with vendors with support contracts. First thing they do is telling you that they only will support their shit on blessed operative system X version Y upgrade Z, with firmware versions a, b and c. What would avoid you to tell them you will only support your hardware along with your firmware?
"Also the HW versions change quite often and HW bugs are worked around in firmware"
Bullshit#3: So a reason for them not to release specifications for their bullshit is that it's bullshit after all, isn't it?
"The amount of work to document all the bugs for open source firmware writers would be humongous"
Bullshit#4: Are you really telling us that you will hide from public because even you don't have a database with such bugs? No wonder you won't release your docs nor you will tell what's your company. Who in his sane mind would want to use your products?
"Gaining complete understanding of how our own firmware works takes years for for any novice entering the team"
Bullshit#5: So understanding your firmware is quite difficult and you are trying to avoid headpains to foreign people by not release the docs, is it that?
"Nobody from our team wants to get into scenario where we must try to understand tens of different versions of the firmware and what are the implications of running each of them"
Not to say yours weren't a nice attempt, but I'm afraid the (not to be published) answer from Intel would be on the lines of "So you already bougth our hardware and your money is in our pocket? You can shout the hell out now, we won't give a damn".
To be really effective your letter (and a thousand more on the same lines) should read: "I'm in the process to choose my new laptop (better if you were in the position to say "to choose the next 2000 laptops for my company" but, heck, nobody is perfect) but sadly, due to the lack of support of the wireless chip out of the box on my Open Source Operative System Of Choice, I'm in the hard situation to choose a model from a competitor. Yours faithfully, a Customer That Won't Be Anymore".
"I think Intel can scratch me as a future customer. I am not going to email, I am going to quietly just buy the AMD system in the next few days as I figure market share will have the biggest impact."
I'd bet you'd have the best impact by doing them both: buying a different vendor *and* telling the ones not chosen why you didn't buy for them. They will know that they're loosing market share and they will have hard facts about why they are loosing it so they can properly react.
It is not as if you were making Intel a favour. It is you the one who benefit the strongest the competency is.
"The ability to go in and change a const or DEFINE MAXPOWER from 0xFE to 0xFF may be considered easily modifiable by the FCC."
Unless, of course, the max emit power from the card were 0xFE, weren't it? So they want to be el-cheapo by going software and *then* they have the guts to say that if they don't release their specs is because FCC evil regulations, don't they?
*I* am the consumer, and it's my power to choose going with vendor A or with vendor B. What's so bad with remembering that to them?
Anyway, as it have been already stated, this is not the problem currently since BSD is not even asking for opening the firmware, only for it to be redistributable 'as-is'.
"OpenBSD is mainly used on servers. Servers don't often use WiFi cards"
Yeah, of course not. Since OpenBSD is never used on firewalls nor routers is not as if the ability to "speak wireless" were of any interest...
" if are using OpenBSD on a notebook you have the option of using an Orinoco card."
Are you implying that other vendors are not subjected to the same FCC regulations than Intel, so they manage to acomplish what Intel is unable to do?
"Yes it would be great to have totally free wifi drivers. But in this case Intel has some really good legal reasons for releasing only binary blobs."
It would be great if you knew what we are talking about too.
"How many times will this one be dragged through the mud before people understand.. It isn't Intel's code they are asking for. They are asking the wrong company. Intel is a licensee of code present in the firmware."
How many times will this one be dragged through the mud before people understand.. It isn't de Raadt's problem where Intel is getting the damned code from: Intel can work along with their current firmware supplier in order for it to be redistributable under sane conditions; they can produce their own firmware (it is not as if Intel weren't capable of that); they can buy that company, they can look for a different provider... they can do a lot of things, and it is *Intel's* problem to do anything.
Currently (as in the article that founds this post) the Raadt isn't even asking Intel for the firmware. He's asking *you* to ask Intel to change the redistribution terms for their firmware (by whatever means Intel can manage for this to be done) of their wireless chips or else letting them know you will buy from another vendor. It's up to *you* to do what de Raadt suggests or not.
There is a reason for me too to choose give my money to company A or company B. There's nothing wrong with letting them now.
"They have no choice on the matter and writing billions of letters to them will be pointless."
While I happily accept your reasons, I warmly prefer seeing those billions of letters sent first, and see if there were really nothing to be done after that.
"In Gentoo's case, most of these are issues in portage, either that that particular version should be hard masked, or that gcc 4.1.1 should still be in ~arch (or hard masked)."
While you have spotted the immediate cause, I'd say there's a deeper one too. Most problems on Gentoo come from the very basis of the distribution itself, that is a "source based rolling distribution".
How come that a package on "stable" depend on a library still masked? Because the packager (not a professional on a professional environment, for the most part) built it on his own system (a nasty mismatch of versions -due to Gentoo's "rolling" nature, and irreproducibility -due to Gentoo's "compile it on your own box") and gave the mythical microsoft answer: if it compiles (in my box), deliver!
But... That's Gentoo!
Of course we could ask for "blessed" build procedures, stabilized package versions, security backports... it wouldn't be impossible to get them on Gentoo, but it's highly improbable for this to happen: the people that aproaches Gentoo and makes it come to live just don't tend to think/work that way.
All in all, Gentoo is an awesome effort with a well desserved fame. It's just that (currently at least) its "phylosophy" doesn't fit well on dependable environments.
"I've used Gentoo for years, and it meets my needs far better than any other distribution"
Yes! And that's exactly the point for a community-based effort: it scratches your itch, serves well your needs and it's fun to tweak, so you use it. As other people have said, it's not as if Gentoo's project leader came pointing a gun to your head forcing you to use it.
Slashdot Mirror
"But when we go to get a new phone and contract..."
I am from Spain. I've been with the same operator for more than two years. I lost my phone, so I needed a replacement. They told me the replacement came with a 18 months retention policy or 150 "fine" if I go with a new operator within that time. I told them where they could safeguard their policy and bought a quite simple free phone for about 100 instead of one of their "flashy" phones free or at the same price at most.
On one hand it's not surprise operators are such bastards. A customer votes with his money, and seems clear people is ready to stand by almost any abouse as long as the front cost is low.
On the other hand, there *is* market for "simple" phones in developed countries (albeit not so simple than the one we are talking about here). I can afford 300 or even 600 on a mobile if I had the inclination, it's only I really want a small, long-standing battery and fancyless one. I finally ended with a benq-siemens AF51, not exactly on the bulleye, but quite close the mark.
"Oh come now, Gentoo isn't that bad in a production environment."
Oh, yes, it is!
"You treat it the same as you would any other distribution"
And then you are doomed. I'll tell you how do I treat distribution maintenance: I have my boxes look at the distribution spools so when there're security updates they download them and send an e-mail for me to know. Then I have a look at what security menaces they provide protection to, then I install them and forget about the issue. You just try to do the same on a Gentoo. Next you will know after an upgrade is you box is non-functional now in a very obvious and disgusting way if you are lucky or on a subtle way you won't detect till two or three days from now if you are not so lucky.
"Change management doesn't change just because you're using a different flavor of Linux."
Yes it does, since the moment different "flavors of Linux" treat change management in quite different ways. An installed system doesn't have to change its behaviour *EVER*, unless the sysadmin in charge so do want. You cannot reach that target in any reasonable way with a distribution that doesn't backports security bugfixes to already delivered software versions: change from Asoftware 1.1.0 to Asoftware 1.2.0 and the system will change its behaviour; don't do the upgrade and the system will have security concerns. A loose-loose situation, if you ask me.
"For what it's worth, Xen makes the process a lot easier to deal with. Clone a DomU, test out the new configuration, then decide whether to use the new DomU or stick with the old DomU"
I didn't say it is not possible to manage change on such environments; I said it's a maintenance nightmare. I do admin Linux systems on Red Hat, Debian, SuSE and Gentoo: I *do* know which are better to maintain, and I *do* know Gentoo is the worst one by considerable margin.
"actually debian reccomends aptitude nowadays..."
Yes, I know, that's why I said "usually" instead of always, and that's why I said "go read the release notes first"; if the upgrade process changes from `apt-get update && apt-get dist-upgrade` to anything else, is the release notes where you will learn it (anyway, I still use apt-get instead of aptitude).
"but on one of the woody-sarge upgrades i did neither apt-get nor aptitude proposed a sane dist-upgrade"
But reading Sarge's release notes first, would allow you to do it the proper way (from top of my mind, Woody->Sarge transition had a problem with apt and some circular dependencies, so you first should upgrade apt and related, and only then try dist-upgrade. On top of that, Sarge's dependencies are in general better thougth out -I specifically remember some regarding mail service, so you should have a look for the packages the upgrade process installed, since it's quite probably you could trim out some of them).
Again, the morale is "go read the release notes *first*".
"My school, for example, uses Gentoo for its servers (Although it is maintained by some wannabe-geeks that mostly have no real clue about this stuff)"
It must be true: who but a wannabe-geek with no real clue would choose Gentoo in such an environment? It has to be a maintenance nightmare!
"In a Debian-based system, all you need to do to upgrade is change the name of the distro in sources.list, then run apt-get update && apt-get dist-upgrade; this is the official method of doing so."
No, it is not. You forgot one step, the most important one.
The step you forgot is you go to Debian's web site and you read the release notes *first*. Then, you go by its instructions which usually are centered around an apt-get update && apt-get dist-upgrade instance.
I bet the "you first go and read the release notes" is valid for every operative system, it is the most forgotten step and it is the most usual source of problems.
"we're talking about basically the only stable country in the world where drugs are, in effect, legalized"
What do you mean? Drug consumption is not illegal in Spain and, AFAIK, the same is valid in the rest of the EU.
"I tried to address that myth -- the "Fedora is just a trial ground for RHEL" statement"
6 233 : "Fedora founder Warren Togami's "Welcome to Fedora" talk dealt with the history of Fedora, and how Fedora operates. Togami spent a fair amount of time emphasizing how important Fedora is to Red Hat's business, and trying to dispel the notion that Fedora is only a "perpetual beta" for Red Hat's enterprise products. This was tricky, since Fedora _is_ a perpetual beta for Red Hat's enterprise products."
9 9047 or here http://barrapunto.com/comments.pl?sid=41775&cid=30 8108 . Both links are from the Spanish Slashdot "brother". Anyone can judge how wrong I were/am.
It's only it is *not* a myth.
I really like Joe 'Zonker' Brockmeier's assertion at http://os.newsforge.com/print.pl?sid=06/04/10/215
Indeed, the fact that you are trying to hide Red Hat's track on this it's fastly changing my mind about the project: I am one of those that time after time goes with the "Fedora is just a trial ground for RHEL" statement, well, not exactly, since I say "Fedora is THE trial ground for RHEL" (the difference albeit subtile is VERY important), trying to avoid bad temper derivated from the fact that Fedora badly fails at people that approach it under wrong assumptions (you just have to see the comments on this article) and expecting to help those looking at Fedora to take out most benefit from it, but now, I'm seeing you are trying to take advantage after the fact that so much people is using Fedora for the wrong reasons to enwiden your user-base, so expect me counter-acting by saying that Fedora is (partly, at least) a fraud. It still *IS* the trial ground for RHEL but now I have to add: beware, it is a lockin strategy from Red Hat Inc. so newcomers get used on a redhatish platform that will NEVER acomplish production-grade quality so, once you are tied to it you must move into RHEL products for whatever serious enterprises you attempt in the future.
Just a pill:
"In addition to the nine board members, there is also a chairman appointed by Red Hat, who has veto power over any decision." (from http://fedoraproject.org/wiki/Board)
That's a *fact*, anything else (...but we will try not to use our veto-power, we are good guys, etc.) are just words.
Do you expect Fedora going in ANY MANNER against Red Hat Inc.'s best interests (like... making it lose the sell of any single RHEL license)?
Anyway, that's really an old thread. I can certainly be wrong, but we can go back to jun 2003 to say what my opinions were back then here http://barrapunto.com/comments.pl?sid=35398&cid=1
"The vast majority of experiences that I and every other person I have met with Fedora have been profoundly negative on some level." /TROLL MODE ON /TROLL MODE OFF
That only means that you and almost every other person you know is dumb enough not to read documentation about the tools they try to use.
"When is the Fedora project going to start fixing its bugs instead of just pushing out bleeding edge packages?"
Plain simple: never.
It is not as if it were a deeply hidden fact; it's even on the fundational papers from RedHat/Fedora. It is known from day O that Fedora's main goal is being Red Hat's testing field for bleeding edge technologies both from the technical and the "social" points of view. From the technical point of view that means its software will be *always* less than polished; from the social one, it only makes sense to open the "build process" as it currently is to gain knowledge about what is well recieved and what, even if hyped, it is not, in order to move RHEL accordingly (once the software is properly polished out of Fedora's suffering).
In sort: Fedora is, and it always has been kindof a "beta" aimed at technoenthusiasts, aficionados and redhat-involved hackers.
"Hey, I'm just saying that it blows my mind how bad Fedora has been for everyone"
It is *NOT* so bad for everything: it is really good for Red Hat Inc. and Red Hat hackers (meaning people that hack/develop on the Red Hat platform not only people that work within Red Hat). But yes, it is quite bad for unknowledgeable people that uses Fedora under false assumptions.
Just exactly the same happens whenever somebody tries to use a hammer as a teaspoon, and you can imagine what the usual name for someone that uses hammers as teaspons is.
"...Or rather they can't accept that someone who went to a worse school could be more intelligent than them." ...or, first interview stages come from HR people, not the technical ones. As the old motto says 'you'll never be fired from choosing IBM'. Well, you'll never be fired from choosing Stanford, either. From HR point of view, it is not about hiring the best candidate, but the best one that won't expose their ass: I chose a Stanford's one that ended being an asshole, "well, shit happens, you did it the best you could"; I chose somebody from Whatever Place that ended up being subpar: my HR job is now at stake.
You can easily exchange any two MTA (sendmail/postfix/qmail/exim), for instance.
"Yes but we're looking at a market that only offers cars that run on their own set of roads each."
That's wrong for the most part. It only makes *easier* to find lockin-enabled apps than "proper" ones, and it's no surprise: see my first post.
"At very least you'll have to convert everything you're working on into the new application's native format and deal with importing deficiencies"
Which part of "Would you buy a car that would only drive on the vendor's roads, use only the vendor gas and would only work with vendor supplies?" didn't you understand?
"native format/vendor lock-in" doesn't rise a bell in your brain?
"With software the interchangeability is lost, you can't trivially replace Windows with another OS"
Would you buy a car that would only drive on the vendor's roads, use only the vendor gas and would only work with vendor supplies?
But that's what you accept on the software world. Of course, as soon as you forget about your "responsibility" as a customer (what you should ask your provider for), your provider will abuse you (by means of lock-in, in this case). It's up to you to break the ties.
"How does the effect a company who develops a product for another company? Does this constitute distribution?"
Definetly yes.
"Suppose company X wins a contract to develop product P for company Z, if P is developed using and uses GPL software (possibly even modified version of GPL software) perhaps linked together etc. When company X delivers the final product (which will be used only internally by company Z), does this constitute distribution?"
Of course yes.
"Is the only criteria here, that company Z must also gets the source code?"
Yes (well, not exactly. The criteria is that P must be delivered to Z under GPL terms, that mainly means that Z gets the source code and the ability to further redistribute it, again, under GPL terms).
"Is it only that every entity that can get a copy of the binary must also be able to get a copy of the source?"
Is it not the same? I distribute just to Z and Z is the only one that gets the code.
So let's see this case:
Z (the client) will get P under the GPL so they are free to redistribute (under the GPL terms) since point 6 of the GPL states that the distributor "may not impose any further restrictions on the recipients' exercise of the rights granted herein."
On the other hand, X (the developer) can be bound by a contract held between X and Z ie. not to further distribute P to any other client, since the GPL doesn't say anything about that, and that's clearly within common practices.
Note that this approach will only be valid between *companies*. If you (X) are a consultant or an employee of Z, then that wouldn't be consider distribution but internal development, and you would have no rights (except maybe, that of claimed authorship, in the case you are an external consultant, not an employee) over the developed code thus, the GPL wouldn't be "triggered" at all (since it only deals with code distribution).
"The term amounts to making people retroactively waive [i]any[/i] rights they have under the civil law, which is, of course, utter nonsense. But still, with all the crap some companies put into their EULAs, this wouldn't be too surprising to find."
I think that it is the other way around, in fact. I don't know how it comes in the USA, but under (most, if not all) EU countries' law, you cannot resign to already given rigths under civil law, specially not in the case of licenses (a kind of "contract" where one of the sides has no choice to disccuss the terms of the legal abiding agreement). Clauses under those lines would be considered void and nul. Current sofware EULAs tend to be so utterly astounding that specially if the claims from the software vendor goes against a big company with its fair share of lawyers, it won't happen that some clauses are nul but the EULA as a whole, since it would tend to be consider not a fair attempt to reach an agreement -with a few faulty points, but an unfair means for one side to gain complete legal shielding without giving anything in counterpart (you know the tipical EULA: this software won't fit any given function, damage claims will be limited to 100US$ or something equally idiotical, you will resign to your legal rights like the allowance to reverse-ingeneering for cross-compatibility...). Under those circumnstances any claim from the software vendor would be dismissed.
I really would like to see Microsoft going against say, REPSOL for EULA infringement (of course any big company won't be bound by any EULA but by their private contract with Microsoft, but that's another story).
"Opening the HW specs would mean that the original company would have to support some random hacker "optimizing" the algorithms in firmware"
Bullshit#1: de Raadt is only asking for a redistribution license that will allow the firmware, The Very Same Firmware Intel Already Distributes, within OpenBSD CD.
Bullshit#2: I work dayin-dayout with vendors with support contracts. First thing they do is telling you that they only will support their shit on blessed operative system X version Y upgrade Z, with firmware versions a, b and c. What would avoid you to tell them you will only support your hardware along with your firmware?
"Also the HW versions change quite often and HW bugs are worked around in firmware"
Bullshit#3: So a reason for them not to release specifications for their bullshit is that it's bullshit after all, isn't it?
"The amount of work to document all the bugs for open source firmware writers would be humongous"
Bullshit#4: Are you really telling us that you will hide from public because even you don't have a database with such bugs? No wonder you won't release your docs nor you will tell what's your company. Who in his sane mind would want to use your products?
"Gaining complete understanding of how our own firmware works takes years for for any novice entering the team"
Bullshit#5: So understanding your firmware is quite difficult and you are trying to avoid headpains to foreign people by not release the docs, is it that?
"Nobody from our team wants to get into scenario where we must try to understand tens of different versions of the firmware and what are the implications of running each of them"
See Bullshit#1.
Hi, Cal:
Not to say yours weren't a nice attempt, but I'm afraid the (not to be published) answer from Intel would be on the lines of "So you already bougth our hardware and your money is in our pocket? You can shout the hell out now, we won't give a damn".
To be really effective your letter (and a thousand more on the same lines) should read: "I'm in the process to choose my new laptop (better if you were in the position to say "to choose the next 2000 laptops for my company" but, heck, nobody is perfect) but sadly, due to the lack of support of the wireless chip out of the box on my Open Source Operative System Of Choice, I'm in the hard situation to choose a model from a competitor. Yours faithfully, a Customer That Won't Be Anymore".
"I think Intel can scratch me as a future customer. I am not going to email, I am going to quietly just buy the AMD system in the next few days as I figure market share will have the biggest impact."
I'd bet you'd have the best impact by doing them both: buying a different vendor *and* telling the ones not chosen why you didn't buy for them. They will know that they're loosing market share and they will have hard facts about why they are loosing it so they can properly react.
It is not as if you were making Intel a favour. It is you the one who benefit the strongest the competency is.
"Those wireless adaptors use soft radios"
So what? That's Intel's problem, not mine.
"The ability to go in and change a const or DEFINE MAXPOWER from 0xFE to 0xFF may be considered easily modifiable by the FCC."
Unless, of course, the max emit power from the card were 0xFE, weren't it? So they want to be el-cheapo by going software and *then* they have the guts to say that if they don't release their specs is because FCC evil regulations, don't they?
*I* am the consumer, and it's my power to choose going with vendor A or with vendor B. What's so bad with remembering that to them?
Anyway, as it have been already stated, this is not the problem currently since BSD is not even asking for opening the firmware, only for it to be redistributable 'as-is'.
"OpenBSD is mainly used on servers. Servers don't often use WiFi cards"
Yeah, of course not. Since OpenBSD is never used on firewalls nor routers is not as if the ability to "speak wireless" were of any interest...
" if are using OpenBSD on a notebook you have the option of using an Orinoco card."
Are you implying that other vendors are not subjected to the same FCC regulations than Intel, so they manage to acomplish what Intel is unable to do?
"Yes it would be great to have totally free wifi drivers. But in this case Intel has some really good legal reasons for releasing only binary blobs."
It would be great if you knew what we are talking about too.
"How many times will this one be dragged through the mud before people understand.. It isn't Intel's code they are asking for. They are asking the wrong company. Intel is a licensee of code present in the firmware."
How many times will this one be dragged through the mud before people understand.. It isn't de Raadt's problem where Intel is getting the damned code from: Intel can work along with their current firmware supplier in order for it to be redistributable under sane conditions; they can produce their own firmware (it is not as if Intel weren't capable of that); they can buy that company, they can look for a different provider... they can do a lot of things, and it is *Intel's* problem to do anything.
Currently (as in the article that founds this post) the Raadt isn't even asking Intel for the firmware. He's asking *you* to ask Intel to change the redistribution terms for their firmware (by whatever means Intel can manage for this to be done) of their wireless chips or else letting them know you will buy from another vendor. It's up to *you* to do what de Raadt suggests or not.
"There is a reason for that."
So what?
There is a reason for me too to choose give my money to company A or company B. There's nothing wrong with letting them now.
"They have no choice on the matter and writing billions of letters to them will be pointless."
While I happily accept your reasons, I warmly prefer seeing those billions of letters sent first, and see if there were really nothing to be done after that.
"In Gentoo's case, most of these are issues in portage, either that that particular version should be hard masked, or that gcc 4.1.1 should still be in ~arch (or hard masked)."
While you have spotted the immediate cause, I'd say there's a deeper one too. Most problems on Gentoo come from the very basis of the distribution itself, that is a "source based rolling distribution".
How come that a package on "stable" depend on a library still masked? Because the packager (not a professional on a professional environment, for the most part) built it on his own system (a nasty mismatch of versions -due to Gentoo's "rolling" nature, and irreproducibility -due to Gentoo's "compile it on your own box") and gave the mythical microsoft answer: if it compiles (in my box), deliver!
But... That's Gentoo!
Of course we could ask for "blessed" build procedures, stabilized package versions, security backports... it wouldn't be impossible to get them on Gentoo, but it's highly improbable for this to happen: the people that aproaches Gentoo and makes it come to live just don't tend to think/work that way.
All in all, Gentoo is an awesome effort with a well desserved fame. It's just that (currently at least) its "phylosophy" doesn't fit well on dependable environments.
"I've used Gentoo for years, and it meets my needs far better than any other distribution"
Yes! And that's exactly the point for a community-based effort: it scratches your itch, serves well your needs and it's fun to tweak, so you use it. As other people have said, it's not as if Gentoo's project leader came pointing a gun to your head forcing you to use it.
"Who's going to pay for software anyone can use for free?"
The one that can't get it for free?
I.E. The one that wants a feature/bugfix that is not already there?
Yeah! I heard there's a vacant in Bern.
"I use Debian for ? 11 years (...) the mentality is that the system must be shiped naked with no configuration choices made"
You maybe used Debian for 11 years, but it's obvious you learnt almost nothing in that time.