The posts just keep getting longer... and yet, the conversation never seems to progress. I wonder why?
> This does not show that he assumes the > recommendation feature is implemented by > a discrete project or even a discrete > program. Neither does the subsequent > quote you provided, which merely emphasizes > the importance of differentiating software > relateive to the rest.
In isolation, no, the two quotes do not mean much of anything. Neither of them says outright that all differentiating software is separate from all non-differentiating software.
However, the first quote defines an example of differentiating software, and the second proposes a way of dealing more efficiently with differentiating software. When you add the GPL to this equation, his proposed method DOES NOT WORK with his example UNLESS the differentiating software is in a different project.
Take the GPL out, replacing it with the BSD or MIT or PHP license, and this problem goes away. Mr. Perens is not completely wrong, but the GPL cannot be reasonably applied to existing software in the way Mr. Perens suggests.
> Stability, maintainability and performance > might also be improved by reusing copyrighted > code from a proprietary product sold by some > other company, but that isn't an option either.
That proprietary product does not claim to be free: esse quam videre. It purports to be proprietary software usable by licensed customers, and that is precisely what it is. BSD-licensed software purports to be free-as-in-speech software usable by anyone, and that's what it is. GPL software purports to be free-as-in-speech software usable by anyone, and then defines "anyone" as "people like us".
So I guess it depends on what the definition of "is" is.
The BSD software does impose a few conditions on use, but none of them impacts the actual use of the software. You can still do whatever you like with it in every useful *software* circumstance.
> Are you saying it's wrong to withhold > permission to link a piece of software > with proprietary applications?
No. I'm saying it's wrong to call that software "free", because if ANY useful permission is withheld, the software is no longer free.
> He is referring to software that a company > runs internally which is also available to > competitors, not the proportion of code > within a proprietary product that differentiates > it from its own competitors.
The meaning of "non-differentiating" is well-known and has been discussed in licensing circles for something like a decade.
While Mr. Perens notes specifically that a COTS application is by definition non-differentiating because it is equally available to one's competitors. However, the term "non-differentiating" also applies to well-known algorithms, standardised protocols, and even industry-standard practices.
> You are comparing apples to oranges.
No, I'm comparing software to software. Mr. Perens proposes a mechanism that works with the GPL when proportions A and B can be readily separated into discrete projects, but that DOES NOT work when they cannot. I am suggesting that his mechanism does not represent the majority case, but an edge condition that rarely occurs in the Real World.
> Still unless you have a reputable source > you should not claim ninety percent or any > other statistic for this proprortion.
It doesn't matter what the statistic is. If the proportion of differentiating code in a given project is nonzero, adding GPL code in that project is detrimental to your business because it forces the release of differentiating code to your competition.
I suggest that you know this, but have chosen to ignore it because it does not support your argument.
> How very warm and fuzzy. When companies [blah blah blah] > they usually don't have much patience > for talk of social responsibility.
> As far as I can tell Mr Perens makes no > assumptions about the relative proportion of > differentiating and non-differentiating > code in any particular project. Perhaps you > would be so kind as to actually quote the > relevant text that demonstrates such an error.
Sure.
"...Amazon will also tell you about other books that were purchased by people who bought the book you're interested in. [...] If you go to the Barnes and Noble site, they don't have that feature [...] So, for Amazon, the "recommendation" software is a business differentiator."
The "recommendation" software in question is not a discrete project. It is a feature of a larger project. Shortly thereafter, he continues:
"Thus, to make your business more desirable to customers, you should spend more on differentiating software that makes your business more desirable, and less on software that doesn't differentiate your business."
Apply the GPL to this. You have a differentiating feature for your software. If your software is GPL, your differentiating feature must also be GPL... unless you jump through a number of unnecessary hoops to make it a different product. This inevitably impacts stability, maintainability, and performance.
Furthermore, the next version of the GPL is supposedly going to specifically target this situation, making it much more difficult to jump through these hoops.
> Again, kindly cite a reputable source. > Otherwise I am tempted to suppose you imagined > this statistic.
How about Mr. Perens himself?
"Perhaps 90% of the software in any business is non-differentiating."
Software, not projects. If we accept the truth of this 90% statistic, we must also accept the statistical reality that the 90% is spread across all the projects, and thus that the average across those projects is 90%.
If you propose that he is wrong about the 90% (his own footnote #2 implies a figure of 84%, when the 75.4% figure in the referenced report is adjusted with his estimates for internal programming), then whatever percentage you prefer can be used to replace it. The differentiating software in a business is not localised to purely-differentiating projects; it represents a tiny minority share of projects that are largely non-differentiating.
Compare the alternatives here:
With commercial products, source modification is generally not possible, so the entire project must be written from scratch.
With a GPL source base, the differentiating code would need to be GPL as well, which is unacceptable so the entire project must be written from scratch.
With a BSD-licensed source base, the *differentiating* code may be licensed however the company likes, so only the differentiating code needs to be written.
> The GPL operates on the assumption that > providing a free ride to proprietary software > companies is not advantageous to the free > software movement.
When a proprietary company pays people to modify an open-source codebase, it is also paying them to learn that codebase, which makes them valuable support resources to the community. Furthermore, it encourages the company to expose its developers to the rest of the open source community, where we can demonstrate how great open source development is. This helps give us the advocates and evangelists we need in these proprietary companies, and also arms them with the potent weapon of guilt: "We have taken from this community, and yet we do not contribute - this is a part of our social responsibility."
This is definitely advantageous to the community. It is not advantageous to the RMS agenda, however, which is fundamentally about punishing those nasty proprietary software companies.
> The real point is to eliminate the need for a > project to compete with proprietary > alternatives derived from the same codebase.
Replacing it, instead, with the need for a development team to compete against a support
> Read The Emerging Economics of Open Source by > Bruce Perens
Incidentally, the primary flaw in this particular paper is Mr. Perens' assumption that differentiating and non-differentiating technologies are in different projects. In reality, over 90% of the average project is non-differentiating, while 10% of it *is* differentiating. Under the GPL, you have to write that 90% yourself unless you want to give away the 10% that differentiates your specific project.
That is an incredibly stupid scenario. With a BSD license, the project can be delivered in a tenth of the time and with a much more stable and reliable codebase. But the GPL forces the development team to spend 90% of their time writing something they don't have to write, so they can protect what they *do* have to write. Chances are good that the developers are not experts in the 90%, but in the 10%, so there is a higher likelihood of bugs and security flaws throughout the project.
The GPL operates largely under the assumption that given this scenario, the developer would naturally make the Right Decision to contribute the 10% he has to write in return for the 90% he doesn't. But in a commercial environment, the developer does not normally get to *make* this decision, so the GPL merely forces him to write that 90% all over again for no good reason. Even though the developer knows it's a bad course of action, he simply does not have a choice.
And there is the *specific* economic impact of the GPL, distinct from the economic impact of other licenses: the fact that it has compelled a great many businesses to do business *less* efficiently, and to write code that they would not have to write at all without the license that restrains them.
> I look forward with amusement to your next > attempt to wiggle out from under your own > words.
If I restate something you misunderstood in a way that I believe you will understand it better, I am not trying to "wiggle out" of anything. Yes, I said exactly what you quoted. You have taken it out of context because you don't understand it. I stand by my original position: the GPL makes it harder to make money from writing code (as opposed to supporting code), and expects that this difficulty will encourage people to contribute their code for free. It will not do this. It will simply encourage people to stop writing code that uses GPL software.
> Your argument seems to be that the GPL license > is indirectly preventing contributions because > it cannot be adopted by some organizations > that might otherwise have had an incentive to > offer improvements to the community.
Partially, but I think that's really a minor loss, and rather myopic. I think the larger damage is that the developers employed by those organisations are forced to reinvent the wheel over and over again, which wastes our most precious commodity: developer brain-time. Every time a developer has to write a login facility from scratch rather than use open source options, we forever lose that time. It *could* have been used to advance the state of the art, open source or otherwise (the open source world tends to implement good ideas rapidly), or at the very least to do something that would make the developer happier. Happy developers write better code.
I don't think anyone can dispute that rewriting some basic feature from scratch because of a company policy is one of the most mind-numbingly dull tasks ever, and the world would be better off with less of it.
> Companies who contribute to free software > projects generally do so because the project > represents non-differentiating technology for > them.
Exactly! They contribute what they *perceive* to have ZERO COMMERCIAL VALUE. But forcing their work to *actually* have zero commercial value doesn't change their perception.
Case in point, generic Viagra; we all get tons of spam about it, because the people sending that spam think we haven't ordered it because we simply don't know it's available. NO EXPLANATION OF REALITY WILL CONVINCE THEM OTHERWISE.
Same with projects. No matter how many times you explain that nobody will pay $60 for an email client because there are so many excellent free ones, if your client or employer believes he can make $60 a pop from an email client... he'll pay you to build one. (And when nobody will pay $60 for it, he'll blame you.) The converse applies as well; if your customer cannot see the value in a proposed project, he will not pay anyone to build it.
> I guess you never said this
No, I said that. Then I said "And that means smart people will continue to write and use it."
I'm *ultimately* interested in people writing and using the code, not people making money off it. The money is just the carrot on a stick that gets people to write code. Code is good. Things that get people to write code are good. So when people are making money from writing code, that's good. And when people *aren't* writing code because they *can't* make money off it, that's bad.
I believe that people will write code no matter what, but that by sharing our code as widely as possible, we can encourage more people to write NEW code instead of reinventing the wheel all the time.
> Can you name a specific instance in which I > have even attempted to make business decisions > on behalf of your clients?
No, but every GPL project out there says I can't get paid for anything using it through proprietary license revenues. So I'd call those a bunch of specific instances where that particular business model has been ruled out, which is a business decision made for anyone using the code. If my client could use the code, but wants proprietary l
> I notice you have retreated from your original > position, which was that the development teams > of GPL projects will simply dry up and blow > away from a lack of proprietary license fees.
That is not and has never been my position. There is no horrible fate awaiting GPL projects. I am simply saying that the GPL is crap and should be killed at our earliest convenience, because it is actively preventing people from contributing to the community.
This is not about money. It's about code. Assume I'm going to write code to implement project X for a client. My client will then sell project X as a proprietary product, because I do not get to tell my client how to run his business.
When project X needs feature Y, I can't use GPL code. If I did, project X would fall under the GPL, and my client would have greater difficulty selling it as a proprietary product. Making life difficult for my client is bad business. So since I can't use GPL code, I have to write feature Y myself.
Effect of the GPL: a programmer who was perfectly willing to use open source code has been forced to reinvent the wheel for no good purpose. My time is wasted, my client gets a mediocre feature, and the community gets jack squat.
Contrast the BSD license. I can incorporate BSD code into my client's project without donating anything to the community. So I can pop it in there to save time and effort. I get my job done faster and better, my client gets a high-quality feature, and... well, the community once again gets squat.
But for all the same Very Good Reasons you outline, my client and I *both* now have a natural interest in contributing code to the community.
And I don't *care* who gets paid or how they're paid or where the money goes. It simply isn't relevant. Proprietary license revenues may not be the best way to get paid, but that's not my decision to make for my clients, and it's not *your* decision to make for them either.
The GPL puts us in the business of telling people their business models are wrong. That's a monumentally stupid business. We should get out of it.
> we would NEVER be in the prediciment > we are in now
What predicament? I don't have a predicament. I'm perfectly comfortable using Windows *or* Linux. I don't care who "wins", and it wouldn't matter if I did... because neither of them is going anywhere anytime soon.
> morons like you decide to 'look the other > way' and not realize the ovbiousness of > MS' crimes that affect everyone
I've gone back and forth a few times about Microsoft. There were times I hated them and never wanted to use another Microsoft product, and there were times I thought they were great and wanted to use nothing *but* Microsoft products.
Then I realised the computer doesn't CARE who wrote the software.
Opinions vary, of course, but I have NEVER known anyone who watched both and preferred the five-lions version. The fifteen-vehicles Voltron series was simply better written and more interesting.
In the line of toys sold here in America in the late eighties, the fifteen-vehicles Voltron was called "Voltron I" and the five-lions Voltron was called "Voltron III". Another toy dubbed "Voltron II" was apparently three humanoid robots that stacked up into a mechanised version of the Hindu goddess Kali; I never saw that one in a show anywhere, and it looked even dumber than the five-lions Voltron.
> Can you imagine how much it would cost the > industry AND all government operations if we > didn't have a de facto standard in the form of > Microsoft?
There will *always* be a "de facto" standard. That's essentially what "de facto" means. If Microsoft disappeared tomorrow, sure, we would have a period of confusion while the new standard emerged; in the end, however, we would all be just fine.
> most MCSEs won't be able to hack arcane *nix > systems
In my experience, most MCSEs can't hack squat, and the proportion of high-quality engineers with MCSEs is no higher than it is in the general industry population.
Don't get me wrong, I *like* Microsoft. My company is a Microsoft partner. I think the GPL is stupid, and wish it would just die already so the more-free BSD license could take over. But from a pure engineering standpoint, the industry as a whole doesn't need Microsoft any more than it needs Joe's Bait Shop, and this claim is just another variant of the same tired old "open source doomsday" scenario.
This is a frequent sticking point for one of my clients. There's someone in his office who simply doesn't understand how I can be posting on Slashdot from the office, yet still be working. As a result, he frequently interrupts me when he thinks I'm not working and have been "playing around" for more than fifteen minutes or so.
Now, I visit sites like/. when I'm working on a hard problem and need to concentrate on it. These interruptions break my flow of concentration. Breaking the flow of concentration costs me twenty to thirty minutes of refocusing time. This impacts productivity.
It is next to impossible to convince anyone that the lost productivity is because I was interrupted, and not because I was on Slashdot. You can't measure that I spent half an hour refocusing my mind on the task at hand after an interruption, but you *can* measure that I spent half an hour on/., so when you're trying to figure out why productivity is lower than you expect... it's easier to point the finger at something you can measure.
Amusingly, the three to five interruptions I get each day add up to just short of two hours in wasted time. I wonder if that correlates for anyone else in this study?
> I sell clients on my ability to develop > software
What exactly do you mean by "develop"?
If you are simply installing and configuring elements of the free enterprise stack, then you are one of those people who "stop writing software so they can do something that makes money".
If you are writing new software, I would assume that you are being paid for it, since you "sell clients" on it -- so you can hardly argue that you "can't make money from software".
In both cases, my original point stands, and your failure to understand it is proof that... well, that you don't understand it. Which is a pretty widespread problem in the open source world.
Actually, I have a somewhat different complaint about those people.
I am not one of them, and no matter how long and hard I work, I will probably never *be* one of them. The same goes for just about anyone else, too.
While there are some few thousand programmers who get paid to write GPL code, they are WEIRD, and their employers are WEIRD, and the reasons they are in that position are WEIRD. There is nothing wrong with that, and I say more power to them.
But it does *not* represent a business model on which I think the world's programmers can hang their futures. We cannot all be Linus Torvalds and Rasmus Lerdorf, any more than we can all be Bill Gates and Paul Allen. Even a *bad* commercial developer can keep a roof over his head and food in his pantry, but you have to be in the upper one-tenth of one percent to make ANY money as an open source developer -- and even then, it takes a damned sizeable piece of pure luck.
The logistics don't scale. You may as well tell your careers advisor that you plan to be a rock star, or join the NBA, or become the President of Burundi: it's simply not a viable plan for your future.
Building a new operating system takes a long time and a lot of money.
Because Windows comes on pretty much every new PC, and Linux is readily available for download, you will probably never get that money back.
OS/2 was a superior operating system to Windows 95, but people didn't buy it. They bought computers with Windows, or they installed Linux from cheap CDs (downloading it wasn't feasible at the time for most people). Now the superior O/S is being folded up and thrown away.
So what about the hardware question? NeXT was a superior operating system on superior hardware. First they stopped making the superior hardware, then they stopped making the superior O/S. Why? No money in it.
Has the world changed? Be was a superior operating system on superior hardware. First they stopped making the superior hardware, then they stopped making the superior O/S. Why? No money in it.
The open source community has some pipe dream that when you can't make money from software, you will contribute your software for free. What actually happens is people stop writing software so they can do something that makes money. And for all the rhetoric about freedom, your scads of users aren't really going to matter when the project has only two developers left working on it... and both of them are investing most of their effort in something profitable.
That's why I believe in the BSD license. Code under the BSD license can still be commercially exploited. That means you can still make money off it. And that means smart people will continue to write and use it.
> I don't think there is anything inherently > difficult to implement about Shadowrun.
Oh, I'm not saying "you can't build a decking simulation". People have done that. I'm not saying "you can't build a cybernetics system". People have done that, too.
What I *am* saying is that it's effectively impossible to get all of this stuff under one roof and effectively balanced. Pen and paper RPGs rely on a sense of fair play, which computers cannot enforce the way social groups can.
I think Shadowrun is just too much stuff to fit into one box.
Think about it: what makes Shadowrun cool? The computer aspect, the cybernetic aspect, the "awakened" races, the futuristic setting, the megacorp environment, the sprawl and its attendant squalor, the magic... the list just doesn't stop. You simply couldn't make a Shadowrun game that really lived up to the title. Most of the cool stuff won't fit, so you have to pick one or two things to focus your game, and then you just handwave the rest.
Unfortunately, this guarantees that most of the people who see "Shadowrun" on the box and buy the game will feel like their favorite parts got handwaved -- they'll appreciate what they get for a week, and then they'll clue into the fact that there's an awful lot they *didn't* get.
Shadowrun is also eminently twinkable, so I don't really see a MMOG in its future. It just doesn't translate well. At the gaming table, you have real bonds with real people that make a difference in how you behave, but online -- it's all just pixels, and there's no GM to bring the wrath of the heavens down on you when you're being a dick.
When an expert signs a non-competition agreement with his company, two things happen.
1. The expert must stay and work where he is no matter what he has been offered elsewhere.
2. The company does not need to keep pace with the industry's standard compensation.
Consider Bob, an expert in some technical field. He signs a contract with Company X for $85K, because that's a good salary at the time. Several years later, the average salary for what Bob does is $130K because his specialty is very much in demand.
Why would Company X increase Bob's salary? He probably has no other skill with similar earning power, so under his non-competition agreement he can't even earn a comparable salary to what he makes now.
This is, of course, a short-sighted decision. If your employee is not happy because you don't pay him what he's worth, his work will suffer. Employers generally keep their employees up to par by threatening to fire them.
This, again, is a short-sighted decision: if Company X fires Bob, they will have to pay $130K for his replacement. But Bob would be unemployed, and under his non-competition agreement he can't get another job in the same field. Since this is unacceptable to Bob, he stays.
So Company X gets a $130K employee for $85K, albeit grudgingly and with minimal job performance.
Company Y needs someone to do Bob's job. They like Bob. They tell Bob, "we'll pay you 200K to work for us doing this great new thing". Bob wants to leave Company X, but he can't. So Company Y needs to hire someone else.
Who loses? Everyone. Bob gets unfairly lowered pay. Company X gets bad performance due to low morale. Company Y can't hire the right person for the job. And out here in consumer-land, the consumer loses because Company X produces a shoddy product due to bad morale, and Company Y produces a shoddy product due to lack of expertise.
There is no situation where a non-competition agreement provides any benefits to anyone except the expert's employer, and in the long run any limitation of competition has negative impacts on an industry. (I will leave this as an exercise for the reader.)
So clearly, non-competition agreements are pretty much bad for everybody. Non-DISCLOSURE agreements are good, though. I'm hoping this case is the one that establishes once and for all that a non-competition clause in your contract is unconscionable, and therefore unenforceable.
I have four cats and a toddler. My consoles are frequently subjected to unexpected stresses, as the cats knock things off the entertainment center into the path of our little rampaging maniac who will do God only knows what with them.
With the PS2, I'm resigned to buying new controllers every few months. The XBox, on the other hand, has suffered some truly shocking moments -- and I haven't had to replace anything yet. So yes, construction value counts. Ridicule it as much as you like, I have a certain distaste for spending $40 on a new controller three to five times a year. I also have a problem with replacing consoles because the CD drive decided to quit for no good reason; the first two PS2s I lost were prior to the arrival of our little bundle of terror, and they sat calmly and quietly next to the TV until they decided to stop reading various discs. One of them was then misplaced by Sony's warranty fulfillment center. (Judging by what I've heard from other PS2 owners, this is an extremely rare occurrence, so I don't think it was in any way intentional.)
As far as backward compatibility goes, here's my decision matrix.
PS2: Compatible with predecessor, +1 XBox: No predecessor, 0 GC: Incompatible with predecessor, -1
Is that not a reasonable viewpoint?
Other factors were involved in choosing the XBox over the GameCube, of course, but it *was* the backward compatibility question that kept it from being seriously considered for so long.
I'm primarily an RPG fan, as you quite rightly deduce later in your post, and I'm not a big fan of network multiplayer. Don't get me wrong, the Dreamcast was a fantastic piece of hardware, it just wasn't what I personally wanted in a system. I still have a sort of wistful nostalgia about the DC, for some reason, and have been considering picking one up on the used market for no real purpose other than to say I have one.
I see four major factors going into this question.
1. Is it compelling? Does it offer anything significant over what I've already got? The Dreamcast gave me a big "No" on that score.
2. Is it readily available? I *wanted* the PS2 at launch, but Sony didn't ship enough and I got knocked off the waiting list... so I waited well over a year to get one.
3. Is it worth the price? I didn't buy an XBox at launch, but I bought one when the price dropped below $200. I am impressed enough by the XBox to have the 360 reserved, however, and I fully intend to grab it on the day of release; the XBox is *easily* worth twice the price of a PS2 on construction value alone. (I've completely trashed three PS2 consoles. It says something that I bothered to replace them, though.)
4. What can I do with it? If the answer is "nothing" -- no games -- I'm not really interested. So backward compatibility is critical. The GameCube was the last console to enter my arsenal, because I didn't have an existing library it could use. The key factor there was a strong used game selection and a few killer games (e.g. Legend of Zelda: The Wind Waker).
The LAN Manager hash algorithm splits a password of up to 14 characters into two blocks of 7 characters, the second block null-padded to size. The LM hash values for single- and dual-character second blocks are well known, so an eight- or nine-character password on Windows using the LM hash is effectively a seven-character password.
This assumes you have some systems which can ONLY use the LM hash. Systems with later capabilities can be forced NEVER to use LM hashing by simply using a 15-character password or longer, which won't fit in an LM hash even if it is enabled (which it shouldn't be these days, *unless* you have legacy systems that require it).
In *real* geek circles, we know that "flash" is the crap overflow in the molding process that leaves little blobby tags of plastic and metal hanging off the sides of models, which must be carefully and completely trimmed away before trying to do anything meaningful.
It's all about free-as-in-speech. If you let people do whatever they want, you tend to get more useful things than if you try and *compel* people to do what you THINK would be useful.
No it wouldn't. There are plenty of options, commercial and otherwise.
Like, for example, the BSD license we were just talking about.
> the GPL must be good for something or it > wouldn't exist
I suggest that it is good for making people behave the way Richard Stallman wants them to behave, which is not exactly my idea of freedom.
> Its good for the end consumer (the person you > never mentioned) because they don't have to > pay to get the work done on GPL software.
I don't really care about free-as-in-beer at the moment, because I can afford all the beer I need. Largely because my software normally *isn't* free-as-in-beer.
> They DO have to pay for BSD code that is used > in closed software
No, they don't. The code *used* in the closed software is still under the BSD license, and they don't have to pay for it. It's the closed software itself which may be under another license.
The GPL and BSD license come from opposing economic spectra. Under the GPL, code is scarce; you probably don't have much, and need a lot of it to get anything accomplished. Under BSD, code is plentiful; you probably have plenty of it, but need a little extra help to make a deadline. This is exactly why college students, researchers, and hobbyists *love* the GPL: it matches their needs. They have big ideas and big plans, but they simply don't have the expertise or the patience to develop all that big code to go with it. The GPL gives them a way to make a social contract that gives them lots of code in return for what they believe has little comparative value.
I have different needs. I've been in this business a dozen years. The GPL looks entirely different to me. It's not "give me your little snippets of code and I'll give you this massive codebase"... it's "if you want these little snippets of code, you have to give me your massive codebase". And that doesn't seem helpful, and it doesn't seem very friendly, and it sure as hell doesn't look much like freedom. I agree that the BSD license only works if people are fundamentally good, but the GPL license doesn't work at all -- at least, not for any socially mature and desirable goals.
Slashdot Mirror
The posts just keep getting longer... and yet, the conversation never seems to progress. I wonder why?
> This does not show that he assumes the
> recommendation feature is implemented by
> a discrete project or even a discrete
> program. Neither does the subsequent
> quote you provided, which merely emphasizes
> the importance of differentiating software
> relateive to the rest.
In isolation, no, the two quotes do not mean much of anything. Neither of them says outright that all differentiating software is separate from all non-differentiating software.
However, the first quote defines an example of differentiating software, and the second proposes a way of dealing more efficiently with differentiating software. When you add the GPL to this equation, his proposed method DOES NOT WORK with his example UNLESS the differentiating software is in a different project.
Take the GPL out, replacing it with the BSD or MIT or PHP license, and this problem goes away. Mr. Perens is not completely wrong, but the GPL cannot be reasonably applied to existing software in the way Mr. Perens suggests.
> Stability, maintainability and performance
> might also be improved by reusing copyrighted
> code from a proprietary product sold by some
> other company, but that isn't an option either.
That proprietary product does not claim to be free: esse quam videre. It purports to be proprietary software usable by licensed customers, and that is precisely what it is. BSD-licensed software purports to be free-as-in-speech software usable by anyone, and that's what it is. GPL software purports to be free-as-in-speech software usable by anyone, and then defines "anyone" as "people like us".
So I guess it depends on what the definition of "is" is.
The BSD software does impose a few conditions on use, but none of them impacts the actual use of the software. You can still do whatever you like with it in every useful *software* circumstance.
> Are you saying it's wrong to withhold
> permission to link a piece of software
> with proprietary applications?
No. I'm saying it's wrong to call that software "free", because if ANY useful permission is withheld, the software is no longer free.
> He is referring to software that a company
> runs internally which is also available to
> competitors, not the proportion of code
> within a proprietary product that differentiates
> it from its own competitors.
The meaning of "non-differentiating" is well-known and has been discussed in licensing circles for something like a decade.
While Mr. Perens notes specifically that a COTS application is by definition non-differentiating because it is equally available to one's competitors. However, the term "non-differentiating" also applies to well-known algorithms, standardised protocols, and even industry-standard practices.
> You are comparing apples to oranges.
No, I'm comparing software to software. Mr. Perens proposes a mechanism that works with the GPL when proportions A and B can be readily separated into discrete projects, but that DOES NOT work when they cannot. I am suggesting that his mechanism does not represent the majority case, but an edge condition that rarely occurs in the Real World.
> Still unless you have a reputable source
> you should not claim ninety percent or any
> other statistic for this proprortion.
It doesn't matter what the statistic is. If the proportion of differentiating code in a given project is nonzero, adding GPL code in that project is detrimental to your business because it forces the release of differentiating code to your competition.
I suggest that you know this, but have chosen to ignore it because it does not support your argument.
> How very warm and fuzzy. When companies
[blah blah blah]
> they usually don't have much patience
> for talk of social responsibility.
> As far as I can tell Mr Perens makes no
> assumptions about the relative proportion of
> differentiating and non-differentiating
> code in any particular project. Perhaps you
> would be so kind as to actually quote the
> relevant text that demonstrates such an error.
Sure.
"...Amazon will also tell you about other books that were purchased by people who bought the book you're interested in. [...] If you go to the Barnes and Noble site, they don't have that feature [...] So, for Amazon, the "recommendation" software is a business differentiator."
The "recommendation" software in question is not a discrete project. It is a feature of a larger project. Shortly thereafter, he continues:
"Thus, to make your business more desirable to customers, you should spend more on differentiating software that makes your business more desirable, and less on software that doesn't differentiate your business."
Apply the GPL to this. You have a differentiating feature for your software. If your software is GPL, your differentiating feature must also be GPL... unless you jump through a number of unnecessary hoops to make it a different product. This inevitably impacts stability, maintainability, and performance.
Furthermore, the next version of the GPL is supposedly going to specifically target this situation, making it much more difficult to jump through these hoops.
> Again, kindly cite a reputable source.
> Otherwise I am tempted to suppose you imagined
> this statistic.
How about Mr. Perens himself?
"Perhaps 90% of the software in any business is non-differentiating."
Software, not projects. If we accept the truth of this 90% statistic, we must also accept the statistical reality that the 90% is spread across all the projects, and thus that the average across those projects is 90%.
If you propose that he is wrong about the 90% (his own footnote #2 implies a figure of 84%, when the 75.4% figure in the referenced report is adjusted with his estimates for internal programming), then whatever percentage you prefer can be used to replace it. The differentiating software in a business is not localised to purely-differentiating projects; it represents a tiny minority share of projects that are largely non-differentiating.
Compare the alternatives here:
With commercial products, source modification is generally not possible, so the entire project must be written from scratch.
With a GPL source base, the differentiating code would need to be GPL as well, which is unacceptable so the entire project must be written from scratch.
With a BSD-licensed source base, the *differentiating* code may be licensed however the company likes, so only the differentiating code needs to be written.
> The GPL operates on the assumption that
> providing a free ride to proprietary software
> companies is not advantageous to the free
> software movement.
When a proprietary company pays people to modify an open-source codebase, it is also paying them to learn that codebase, which makes them valuable support resources to the community. Furthermore, it encourages the company to expose its developers to the rest of the open source community, where we can demonstrate how great open source development is. This helps give us the advocates and evangelists we need in these proprietary companies, and also arms them with the potent weapon of guilt: "We have taken from this community, and yet we do not contribute - this is a part of our social responsibility."
This is definitely advantageous to the community. It is not advantageous to the RMS agenda, however, which is fundamentally about punishing those nasty proprietary software companies.
> The real point is to eliminate the need for a
> project to compete with proprietary
> alternatives derived from the same codebase.
Replacing it, instead, with the need for a development team to compete against a support
> Read The Emerging Economics of Open Source by
> Bruce Perens
Incidentally, the primary flaw in this particular paper is Mr. Perens' assumption that differentiating and non-differentiating technologies are in different projects. In reality, over 90% of the average project is non-differentiating, while 10% of it *is* differentiating. Under the GPL, you have to write that 90% yourself unless you want to give away the 10% that differentiates your specific project.
That is an incredibly stupid scenario. With a BSD license, the project can be delivered in a tenth of the time and with a much more stable and reliable codebase. But the GPL forces the development team to spend 90% of their time writing something they don't have to write, so they can protect what they *do* have to write. Chances are good that the developers are not experts in the 90%, but in the 10%, so there is a higher likelihood of bugs and security flaws throughout the project.
The GPL operates largely under the assumption that given this scenario, the developer would naturally make the Right Decision to contribute the 10% he has to write in return for the 90% he doesn't. But in a commercial environment, the developer does not normally get to *make* this decision, so the GPL merely forces him to write that 90% all over again for no good reason. Even though the developer knows it's a bad course of action, he simply does not have a choice.
And there is the *specific* economic impact of the GPL, distinct from the economic impact of other licenses: the fact that it has compelled a great many businesses to do business *less* efficiently, and to write code that they would not have to write at all without the license that restrains them.
> I look forward with amusement to your next
> attempt to wiggle out from under your own
> words.
If I restate something you misunderstood in a way that I believe you will understand it better, I am not trying to "wiggle out" of anything. Yes, I said exactly what you quoted. You have taken it out of context because you don't understand it. I stand by my original position: the GPL makes it harder to make money from writing code (as opposed to supporting code), and expects that this difficulty will encourage people to contribute their code for free. It will not do this. It will simply encourage people to stop writing code that uses GPL software.
> Your argument seems to be that the GPL license
> is indirectly preventing contributions because
> it cannot be adopted by some organizations
> that might otherwise have had an incentive to
> offer improvements to the community.
Partially, but I think that's really a minor loss, and rather myopic. I think the larger damage is that the developers employed by those organisations are forced to reinvent the wheel over and over again, which wastes our most precious commodity: developer brain-time. Every time a developer has to write a login facility from scratch rather than use open source options, we forever lose that time. It *could* have been used to advance the state of the art, open source or otherwise (the open source world tends to implement good ideas rapidly), or at the very least to do something that would make the developer happier. Happy developers write better code.
I don't think anyone can dispute that rewriting some basic feature from scratch because of a company policy is one of the most mind-numbingly dull tasks ever, and the world would be better off with less of it.
> Companies who contribute to free software
> projects generally do so because the project
> represents non-differentiating technology for
> them.
Exactly! They contribute what they *perceive* to have ZERO COMMERCIAL VALUE. But forcing their work to *actually* have zero commercial value doesn't change their perception.
Case in point, generic Viagra; we all get tons of spam about it, because the people sending that spam think we haven't ordered it because we simply don't know it's available. NO EXPLANATION OF REALITY WILL CONVINCE THEM OTHERWISE.
Same with projects. No matter how many times you explain that nobody will pay $60 for an email client because there are so many excellent free ones, if your client or employer believes he can make $60 a pop from an email client... he'll pay you to build one. (And when nobody will pay $60 for it, he'll blame you.) The converse applies as well; if your customer cannot see the value in a proposed project, he will not pay anyone to build it.
> I guess you never said this
No, I said that. Then I said "And that means smart people will continue to write and use it."
I'm *ultimately* interested in people writing and using the code, not people making money off it. The money is just the carrot on a stick that gets people to write code. Code is good. Things that get people to write code are good. So when people are making money from writing code, that's good. And when people *aren't* writing code because they *can't* make money off it, that's bad.
I believe that people will write code no matter what, but that by sharing our code as widely as possible, we can encourage more people to write NEW code instead of reinventing the wheel all the time.
> Can you name a specific instance in which I
> have even attempted to make business decisions
> on behalf of your clients?
No, but every GPL project out there says I can't get paid for anything using it through proprietary license revenues. So I'd call those a bunch of specific instances where that particular business model has been ruled out, which is a business decision made for anyone using the code. If my client could use the code, but wants proprietary l
> I notice you have retreated from your original
> position, which was that the development teams
> of GPL projects will simply dry up and blow
> away from a lack of proprietary license fees.
That is not and has never been my position. There is no horrible fate awaiting GPL projects. I am simply saying that the GPL is crap and should be killed at our earliest convenience, because it is actively preventing people from contributing to the community.
This is not about money. It's about code. Assume I'm going to write code to implement project X for a client. My client will then sell project X as a proprietary product, because I do not get to tell my client how to run his business.
When project X needs feature Y, I can't use GPL code. If I did, project X would fall under the GPL, and my client would have greater difficulty selling it as a proprietary product. Making life difficult for my client is bad business. So since I can't use GPL code, I have to write feature Y myself.
Effect of the GPL: a programmer who was perfectly willing to use open source code has been forced to reinvent the wheel for no good purpose. My time is wasted, my client gets a mediocre feature, and the community gets jack squat.
Contrast the BSD license. I can incorporate BSD code into my client's project without donating anything to the community. So I can pop it in there to save time and effort. I get my job done faster and better, my client gets a high-quality feature, and... well, the community once again gets squat.
But for all the same Very Good Reasons you outline, my client and I *both* now have a natural interest in contributing code to the community.
And I don't *care* who gets paid or how they're paid or where the money goes. It simply isn't relevant. Proprietary license revenues may not be the best way to get paid, but that's not my decision to make for my clients, and it's not *your* decision to make for them either.
The GPL puts us in the business of telling people their business models are wrong. That's a monumentally stupid business. We should get out of it.
> we would NEVER be in the prediciment
> we are in now
What predicament? I don't have a predicament. I'm perfectly comfortable using Windows *or* Linux. I don't care who "wins", and it wouldn't matter if I did... because neither of them is going anywhere anytime soon.
> morons like you decide to 'look the other
> way' and not realize the ovbiousness of
> MS' crimes that affect everyone
I've gone back and forth a few times about Microsoft. There were times I hated them and never wanted to use another Microsoft product, and there were times I thought they were great and wanted to use nothing *but* Microsoft products.
Then I realised the computer doesn't CARE who wrote the software.
And with that, I was enlightened.
The fifteen-vehicles Voltron rocked.
The five lions Voltron was stupid.
Opinions vary, of course, but I have NEVER known anyone who watched both and preferred the five-lions version. The fifteen-vehicles Voltron series was simply better written and more interesting.
In the line of toys sold here in America in the late eighties, the fifteen-vehicles Voltron was called "Voltron I" and the five-lions Voltron was called "Voltron III". Another toy dubbed "Voltron II" was apparently three humanoid robots that stacked up into a mechanised version of the Hindu goddess Kali; I never saw that one in a show anywhere, and it looked even dumber than the five-lions Voltron.
I bought a five-lions Voltron off the shelf at Toys-R-Us less than five years ago.
> Can you imagine how much it would cost the
> industry AND all government operations if we
> didn't have a de facto standard in the form of
> Microsoft?
There will *always* be a "de facto" standard. That's essentially what "de facto" means. If Microsoft disappeared tomorrow, sure, we would have a period of confusion while the new standard emerged; in the end, however, we would all be just fine.
> most MCSEs won't be able to hack arcane *nix
> systems
In my experience, most MCSEs can't hack squat, and the proportion of high-quality engineers with MCSEs is no higher than it is in the general industry population.
Don't get me wrong, I *like* Microsoft. My company is a Microsoft partner. I think the GPL is stupid, and wish it would just die already so the more-free BSD license could take over. But from a pure engineering standpoint, the industry as a whole doesn't need Microsoft any more than it needs Joe's Bait Shop, and this claim is just another variant of the same tired old "open source doomsday" scenario.
> I understand exactly what you're saying,
> and I'm saying that you're wrong.
But I agree with everything you just said. You're talking about how programmers have jobs and get paid.
What *I'm* talking about is how the open source world gets more and better developers to contribute more and better code.
Apples and oranges.
This is a frequent sticking point for one of my clients. There's someone in his office who simply doesn't understand how I can be posting on Slashdot from the office, yet still be working. As a result, he frequently interrupts me when he thinks I'm not working and have been "playing around" for more than fifteen minutes or so.
/. when I'm working on a hard problem and need to concentrate on it. These interruptions break my flow of concentration. Breaking the flow of concentration costs me twenty to thirty minutes of refocusing time. This impacts productivity.
/., so when you're trying to figure out why productivity is lower than you expect... it's easier to point the finger at something you can measure.
Now, I visit sites like
It is next to impossible to convince anyone that the lost productivity is because I was interrupted, and not because I was on Slashdot. You can't measure that I spent half an hour refocusing my mind on the task at hand after an interruption, but you *can* measure that I spent half an hour on
Amusingly, the three to five interruptions I get each day add up to just short of two hours in wasted time. I wonder if that correlates for anyone else in this study?
> I sell clients on my ability to develop
> software
What exactly do you mean by "develop"?
If you are simply installing and configuring elements of the free enterprise stack, then you are one of those people who "stop writing software so they can do something that makes money".
If you are writing new software, I would assume that you are being paid for it, since you "sell clients" on it -- so you can hardly argue that you "can't make money from software".
In both cases, my original point stands, and your failure to understand it is proof that... well, that you don't understand it. Which is a pretty widespread problem in the open source world.
Actually, I have a somewhat different complaint about those people.
I am not one of them, and no matter how long and hard I work, I will probably never *be* one of them. The same goes for just about anyone else, too.
While there are some few thousand programmers who get paid to write GPL code, they are WEIRD, and their employers are WEIRD, and the reasons they are in that position are WEIRD. There is nothing wrong with that, and I say more power to them.
But it does *not* represent a business model on which I think the world's programmers can hang their futures. We cannot all be Linus Torvalds and Rasmus Lerdorf, any more than we can all be Bill Gates and Paul Allen. Even a *bad* commercial developer can keep a roof over his head and food in his pantry, but you have to be in the upper one-tenth of one percent to make ANY money as an open source developer -- and even then, it takes a damned sizeable piece of pure luck.
The logistics don't scale. You may as well tell your careers advisor that you plan to be a rock star, or join the NBA, or become the President of Burundi: it's simply not a viable plan for your future.
Building a new operating system takes a long time and a lot of money.
Because Windows comes on pretty much every new PC, and Linux is readily available for download, you will probably never get that money back.
OS/2 was a superior operating system to Windows 95, but people didn't buy it. They bought computers with Windows, or they installed Linux from cheap CDs (downloading it wasn't feasible at the time for most people). Now the superior O/S is being folded up and thrown away.
So what about the hardware question? NeXT was a superior operating system on superior hardware. First they stopped making the superior hardware, then they stopped making the superior O/S. Why? No money in it.
Has the world changed? Be was a superior operating system on superior hardware. First they stopped making the superior hardware, then they stopped making the superior O/S. Why? No money in it.
The open source community has some pipe dream that when you can't make money from software, you will contribute your software for free. What actually happens is people stop writing software so they can do something that makes money. And for all the rhetoric about freedom, your scads of users aren't really going to matter when the project has only two developers left working on it... and both of them are investing most of their effort in something profitable.
That's why I believe in the BSD license. Code under the BSD license can still be commercially exploited. That means you can still make money off it. And that means smart people will continue to write and use it.
> I don't think there is anything inherently
> difficult to implement about Shadowrun.
Oh, I'm not saying "you can't build a decking simulation". People have done that. I'm not saying "you can't build a cybernetics system". People have done that, too.
What I *am* saying is that it's effectively impossible to get all of this stuff under one roof and effectively balanced. Pen and paper RPGs rely on a sense of fair play, which computers cannot enforce the way social groups can.
I think Shadowrun is just too much stuff to fit into one box.
Think about it: what makes Shadowrun cool? The computer aspect, the cybernetic aspect, the "awakened" races, the futuristic setting, the megacorp environment, the sprawl and its attendant squalor, the magic... the list just doesn't stop. You simply couldn't make a Shadowrun game that really lived up to the title. Most of the cool stuff won't fit, so you have to pick one or two things to focus your game, and then you just handwave the rest.
Unfortunately, this guarantees that most of the people who see "Shadowrun" on the box and buy the game will feel like their favorite parts got handwaved -- they'll appreciate what they get for a week, and then they'll clue into the fact that there's an awful lot they *didn't* get.
Shadowrun is also eminently twinkable, so I don't really see a MMOG in its future. It just doesn't translate well. At the gaming table, you have real bonds with real people that make a difference in how you behave, but online -- it's all just pixels, and there's no GM to bring the wrath of the heavens down on you when you're being a dick.
When an expert signs a non-competition agreement with his company, two things happen.
1. The expert must stay and work where he is no matter what he has been offered elsewhere.
2. The company does not need to keep pace with the industry's standard compensation.
Consider Bob, an expert in some technical field. He signs a contract with Company X for $85K, because that's a good salary at the time. Several years later, the average salary for what Bob does is $130K because his specialty is very much in demand.
Why would Company X increase Bob's salary? He probably has no other skill with similar earning power, so under his non-competition agreement he can't even earn a comparable salary to what he makes now.
This is, of course, a short-sighted decision. If your employee is not happy because you don't pay him what he's worth, his work will suffer. Employers generally keep their employees up to par by threatening to fire them.
This, again, is a short-sighted decision: if Company X fires Bob, they will have to pay $130K for his replacement. But Bob would be unemployed, and under his non-competition agreement he can't get another job in the same field. Since this is unacceptable to Bob, he stays.
So Company X gets a $130K employee for $85K, albeit grudgingly and with minimal job performance.
Company Y needs someone to do Bob's job. They like Bob. They tell Bob, "we'll pay you 200K to work for us doing this great new thing". Bob wants to leave Company X, but he can't. So Company Y needs to hire someone else.
Who loses? Everyone. Bob gets unfairly lowered pay. Company X gets bad performance due to low morale. Company Y can't hire the right person for the job. And out here in consumer-land, the consumer loses because Company X produces a shoddy product due to bad morale, and Company Y produces a shoddy product due to lack of expertise.
There is no situation where a non-competition agreement provides any benefits to anyone except the expert's employer, and in the long run any limitation of competition has negative impacts on an industry. (I will leave this as an exercise for the reader.)
So clearly, non-competition agreements are pretty much bad for everybody. Non-DISCLOSURE agreements are good, though. I'm hoping this case is the one that establishes once and for all that a non-competition clause in your contract is unconscionable, and therefore unenforceable.
I have four cats and a toddler. My consoles are frequently subjected to unexpected stresses, as the cats knock things off the entertainment center into the path of our little rampaging maniac who will do God only knows what with them.
With the PS2, I'm resigned to buying new controllers every few months. The XBox, on the other hand, has suffered some truly shocking moments -- and I haven't had to replace anything yet. So yes, construction value counts. Ridicule it as much as you like, I have a certain distaste for spending $40 on a new controller three to five times a year. I also have a problem with replacing consoles because the CD drive decided to quit for no good reason; the first two PS2s I lost were prior to the arrival of our little bundle of terror, and they sat calmly and quietly next to the TV until they decided to stop reading various discs. One of them was then misplaced by Sony's warranty fulfillment center. (Judging by what I've heard from other PS2 owners, this is an extremely rare occurrence, so I don't think it was in any way intentional.)
As far as backward compatibility goes, here's my decision matrix.
PS2: Compatible with predecessor, +1
XBox: No predecessor, 0
GC: Incompatible with predecessor, -1
Is that not a reasonable viewpoint?
Other factors were involved in choosing the XBox over the GameCube, of course, but it *was* the backward compatibility question that kept it from being seriously considered for so long.
I'm primarily an RPG fan, as you quite rightly deduce later in your post, and I'm not a big fan of network multiplayer. Don't get me wrong, the Dreamcast was a fantastic piece of hardware, it just wasn't what I personally wanted in a system. I still have a sort of wistful nostalgia about the DC, for some reason, and have been considering picking one up on the used market for no real purpose other than to say I have one.
CD-ROM failures. Laser screwups, alignments, one complete motor burnout.
Yes, it's properly ventilated. I've had zero problems since getting the slimline version, as well.
I see four major factors going into this question.
1. Is it compelling? Does it offer anything significant over what I've already got? The Dreamcast gave me a big "No" on that score.
2. Is it readily available? I *wanted* the PS2 at launch, but Sony didn't ship enough and I got knocked off the waiting list... so I waited well over a year to get one.
3. Is it worth the price? I didn't buy an XBox at launch, but I bought one when the price dropped below $200. I am impressed enough by the XBox to have the 360 reserved, however, and I fully intend to grab it on the day of release; the XBox is *easily* worth twice the price of a PS2 on construction value alone. (I've completely trashed three PS2 consoles. It says something that I bothered to replace them, though.)
4. What can I do with it? If the answer is "nothing" -- no games -- I'm not really interested. So backward compatibility is critical. The GameCube was the last console to enter my arsenal, because I didn't have an existing library it could use. The key factor there was a strong used game selection and a few killer games (e.g. Legend of Zelda: The Wind Waker).
That's what goes into my decisions. YMMV.
The LAN Manager hash algorithm splits a password of up to 14 characters into two blocks of 7 characters, the second block null-padded to size. The LM hash values for single- and dual-character second blocks are well known, so an eight- or nine-character password on Windows using the LM hash is effectively a seven-character password.
This assumes you have some systems which can ONLY use the LM hash. Systems with later capabilities can be forced NEVER to use LM hashing by simply using a 15-character password or longer, which won't fit in an LM hash even if it is enabled (which it shouldn't be these days, *unless* you have legacy systems that require it).
In *real* geek circles, we know that "flash" is the crap overflow in the molding process that leaves little blobby tags of plastic and metal hanging off the sides of models, which must be carefully and completely trimmed away before trying to do anything meaningful.
So I think it's an EXCELLENT choice of terms.
> I don't know that I agree with your conclusion.
It's all about free-as-in-speech. If you let people do whatever they want, you tend to get more useful things than if you try and *compel* people to do what you THINK would be useful.
> without the GPL the only option would be A.
No it wouldn't. There are plenty of options, commercial and otherwise.
Like, for example, the BSD license we were just talking about.
> the GPL must be good for something or it
> wouldn't exist
I suggest that it is good for making people behave the way Richard Stallman wants them to behave, which is not exactly my idea of freedom.
> Its good for the end consumer (the person you
> never mentioned) because they don't have to
> pay to get the work done on GPL software.
I don't really care about free-as-in-beer at the moment, because I can afford all the beer I need. Largely because my software normally *isn't* free-as-in-beer.
> They DO have to pay for BSD code that is used
> in closed software
No, they don't. The code *used* in the closed software is still under the BSD license, and they don't have to pay for it. It's the closed software itself which may be under another license.
The GPL and BSD license come from opposing economic spectra. Under the GPL, code is scarce; you probably don't have much, and need a lot of it to get anything accomplished. Under BSD, code is plentiful; you probably have plenty of it, but need a little extra help to make a deadline. This is exactly why college students, researchers, and hobbyists *love* the GPL: it matches their needs. They have big ideas and big plans, but they simply don't have the expertise or the patience to develop all that big code to go with it. The GPL gives them a way to make a social contract that gives them lots of code in return for what they believe has little comparative value.
I have different needs. I've been in this business a dozen years. The GPL looks entirely different to me. It's not "give me your little snippets of code and I'll give you this massive codebase"... it's "if you want these little snippets of code, you have to give me your massive codebase". And that doesn't seem helpful, and it doesn't seem very friendly, and it sure as hell doesn't look much like freedom. I agree that the BSD license only works if people are fundamentally good, but the GPL license doesn't work at all -- at least, not for any socially mature and desirable goals.