And there's good reason that we're not a pure democracy. Look it up if you care to know.
While I am familiar with the original rationalizations, I don't find the current mutation of the system to be particularly admirable. The feds have grown from a sideshow to a huge, uncontrollable, unstoppable force in less than one hundred years; the states are the subject of everything from federal blackmail to outright dictatorship. Various good things about the founding documents have been hugely watered down. They have also been misrepresented, as have some of the people who created those documents.
Of course, the founding documents themselves are several hundred years old. They are based on no longer-extant demographics and communications issues. They fail to anticipate many current serious issues. The various documents themselves have gaping holes in the reasoning they formalize. They were never perfect, as with most human endeavor. I get all that just fine. However, that doesn't solve the current problem, which is a mostly out of control government.
None of which inclines me to let the presumption that we are a democracy pass. We're not. I said so.
...the defining charactoristic(sic) is something that you cannot apply scientific rigor to.
Actually, it is. We call it "irrationality." A belief in something that has no falsifiable basis in reality.
This is what the other posters are alluding to when they handwave about it is no surprise that Utah would pass a censorship bill such as this one -- it's a "mommy law", where the state (or the nation) attempts to be everybody's mommy. By its very nature, it is defective, repressive and -- here we have it -- irrational.
This is why Democracy is a lousy form of government.
Utah, and the US in general, are not examples of democracy. They are both degenerate examples of a republic. Your representatives decide what is going to happen, not you. Their votes count; you don't even get one. What you can do, perhaps, is throw the perpetrators out next time there is a round of elections. But then again, party politics can prevent that, too. You're not in control. That's what a republic is about -- the citizens don't have any direct control at all. At least unless they are willing to pick up weapons and change the system.
does the physical distance between you and your partner make any difference?
Of course -- latency will affect your perception of your partner's reactions, and the delivery of your response to your partner. How could it not make a difference?
The further away you are in space, the more latency you'll have to deal with. That's just with normal EM delivery of information. Add communications paths with uncertain and variable delivery times (like the Internet) and you'd really have some challenging changes in perception to deal with.
Oh, you mean like the GPL and LGPL, tools that seem to be designed to put roadblocks in place with the idea of keeping commercial applications away from Linux?
I used to think that. Then I realized that the GPL/LGPL were products designed to keep lawyers in business, then it all made sense.:-)
But you're probably right, as lawyers don't benefit from the fragging, but corporations do.
And then... in the SOVIET UNION, PPU upgrades are... wait a sec... OK, the designs are stolen from the US but then can't be manufactured because there is no technological infrastructure, only chess players and factory managers who make quota on paper, but used the last quarter's allocation to build a dacha on the land where the PPU factory was supposed to go. But then they import them on the black market anyway. PPU? Nichevo, tovarisch!
In fact it only impacts patents in the LGPL'd component. This is not an obstacle.
Of course it's an obstacle. It is the obstacle. The idea here is that if the software were actually free to use, you could use it. Here is a case where you can't use it, so it isn't free. If the software was PD, they could use it. Freely! That's why PD is better, and that's why LGPL isn't free.
There is *nothing* problematic with Microsoft distributing starbc32.dll with Microsoft Office unless they feel that Star Basic itself infringes on their patents
No. That's not the problem. The problem occurs if they have patents on their item that when subsequently linked with the LGPL'd component creates a unit they cannot further hand off. Then there is a problem, and the specific problem is this means there are limited ways you can use the LGPL'd component, which is exactly what I've been telling you all along. LGPL is a way to encumber software, not make it free. PD makes it free.
Where does freedom degrade into a predatory anarchy where the large players use your work as a free subsidy for their operations without making reciprocal contributions? I am not saying you can't avoid this with a PD release, but it is a lot harder.
Freedom means the large players don't get to tell you what to do. You probably like that part of it. But freedom also means you don't get to tell the large players what to do. If you make software free, that means that people can do anything with it, and that's making you nervous. You think freedom is good for you, but not for someone else who might do something you don't approve of with the software in question. That's a pretty restrictive approach to take to freedom, at least in my view.
Furthermore, it is unbalanced. Some little guy at home can use your LGPL'd software -- mod it, compile it, use it to further himself -- without ever returning anything "to the community", and I don't see the FSF telling that guy he can't use it because he's some kind of a leech. If I give the little guy a PD item, he can do whatever with it, and the big player can too, and so can you, and so can I. That is balanced. That is... freedom.:-)
Now, further, if the large player does (whatever) with the PD wares, so what? Does that mean you can't also do whatever? No. It's PD. You can do anything you want. No one is stopping you. That's the point. You have freedom to act. So do the big players, and the middling players, and the small players, and yet the lawyers have little to do. Sounds like win-win-win to me, which is why I choose the PD road for myself when I am moved to contribute.
The PD release has one freedom that a BSD license does not--- the right to sue you.
Holy Darwinian Evolution, Batman -- you sure are under some mistaken impressions. Anyone can sue you for anything. Any time, any reason, usually in a seriously inconvenient venue, and they can cause you one hell of a lot of discomfort. There is no magic barrier to lawsuits. If there were one, it'd surely involve high explosives, rather than paperwork. When the sides are unbalanced (as they always are when big players are involved) winning depends only on how much money, time and lawyerly "talent" you have available to grease the system. You don't have to "win" in court, you "win" by delay, upping the expense ante, and forcing a settlement. There is nothing, and I mean absolutely nothing, that makes a PD item any more vulnerable to a lawsuit than an LGPL'd item -- the LGPL'd item just gives the lawyers more to sink their vicious little teeth into.
Good luck even finding the author of the PD item. If he's not a fame-sucker, there's no certainty you'd know where it came from (nor, probably, should you, in order to protect honest productive citizens from the hugely broken and mismanaged l
"
if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.
"
This is one "for-example" provided by the FSF of pitfalls that await use of LGPL products -- it is not a specific restriction, it is a consequence that they have taken the time to illustrate for the users of LGPL'd materials. There are others. In order to determine what those others are under the laws that apply to your in your jurisdiction(s), a team of IP lawyers is required.
PD, on the other hand, says "here it is, do whatever you like, enjoy, bye."
PD is "free." LGPL is "encumbered."
The FSF makes the following statement in the context of explaining the LGPL:
If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License).
What I say to other developers is this:
If you develop a new library, and you want it to be of the greatest possible use to the public, make it PD so that everyone can
really be free to redistribute and change the library without being limited to only certain types of redistribution and change.
The LGPL is a force for retardation of progress masquerading as a force for freedom. I find it reprehensible as such; some developers will decide to use it under the mistaken impression that they are creating free software, when what they are creating is encumbered software. Few people actually read the license, fewer still think through to the implied consequences. So they go with the media hype, which in this case is the description of the LGPL as providing the "greatest possible use" which is clearly nonsense. The greatest possible use, and freedom, will be provided by a PD release. There's no way around it.
...nothing in the LGPL prevents you from implimenting it as is for another product.
The great-grandparent talked about linking LGPL to commercial software, using Microsoft's Office product as the specific example.
One concrete demonstration of how this is not so is as follows: The LGPL contains terms that disallow linking with anything that incorporates certain types of software patents (as many things, most certainly including MS Office, and our some of own products, do.) That means no LGPL linking. Period.
Certainly linking / using with other LGPL'd software should work out fine. That's quite different than the specific assertion that LGPL'd software could be used as part of MS Office, though. It can't. It can't be used with ours, either -- our stuff is image manipulation software, and we've got numerous formal types of IPp wrapped around it, including software patents. That's perfectly ok with me (I own the company, so that's the key issue in my situation) because I'm not looking to use LGPL'd software, but it still remains a salient point.
So. LGPL is in no way a panacea that allows things to be used "as they are." It has pitfalls. That was one; there are others. It can't be (legally) used in the free and open manner that was described in the GGp, which is all I was saying, really.
I land either one side of the line or the other. If I'm going to give away the sweat of my brow, then I will actually do so without reservation - by using PD terms. If I want to go commercial, I'll stay on the closed source, IPp, and trade secret side of the line. LGPL'ing isn't of interest to me except as an intellectual curiosity. I spoke up because it was being misrepresented, and I felt it was worth pointing out.
I haven't confused anything. The grandparent made a statement about the LGPL that was in error - I corrected that statement, and added a few opinionated (but correct) observations about FOSS in the context of the grandparent's assertion.
As for me, I'm not looking for code at all. I'm just interested in the various paths the FOSS movement is following because I'm working on a PD (not licensed, because of the limitations) production of my own.
However, I do find it amusing that the "free" in "free software" actually means "legally encumbered and often impossible to use." That's double-plus ungood think at its best. But that's what happens when you get lawyers involved. Shakespeare's character had it right.
The fact that it is released under the LGPL means that there is nobody preventing you from integrating it with, say, Gnumeric, AbiWord, KOfffice, or even MS Office.
Actually, the fact that is it LGPL'd is exactly what prevents it from being integrated with a lot of things. The LGPL imposes numerous limitations upon exactly how, and under what circumstances, an LGPL'd product can be integrated with another product.
If people really want code to be integrated with other products, they'll release it PD, no restrictions, end of story. Then you're free to integrate it with whatever you want. All this licensing crap is just more foolishness designed to keep lawyers in the most recent year's Mercedes. Don't believe me? Go and actually read the LGPL. It is not a "free lunch" for integration. It is legal pitfall after legal pitfall which require careful legal evaluation before you could possibly consider integrating an LGPL'd component into a commercial product.
If open source people get serious about wanting their code integrated into big, serious applications, licenses like the LGPL will fall by the wayside. Until then, they're just hawking yet another version of proprietary code with the inherent costs moved over to the legal department.
Speaking, of course, as a commercial developer who has read the LGPL quite carefully.:-)
...is cause me to drive. For instance, in the last 12 months, I've driven back and forth from Montana to Pennsylvania once, and back forth from Montana to Massachusetts once. And lots of driving about the midwest. Going to Arizona this spring for the Quartzite mineral show. I've not ridden in a commercial aircraft since the fall of 2001, and I don't think I will be doing so in the foreseeable future, either.
In the process of all this driving, I've rediscovered a lot of musical favorites, learned about XM and Sirius, had a blast with GPS, goofed about with wifi in various hotels and parking lots, and generally had a whole lot of fun. And didn't spend too much money for my comfort level, but no matter what I spent, $0 of it went to the airlines, which suits me just fine. And I wrote the trips off, so less went to the government at the same time. Double win.
When you put up with those same idiots ignoring how bad a job the agencies they are responsible for are doing
When you put up with those same idiots passing laws which put them in the position of being your "mommy"
In short, the voters deserve this. And more. When it reaches an intolerable level for the average fool on the street, or enough of the not-so-average types unify and take up arms, it'll change. Until then, of course the government is irrational and stupid. Look who runs it.
Since the 70's, in fact. I presently own a decent sized software company, among other things. Where efficiency is paramount; we do graphics. Don't even worry about my ability to code. I was prodding punch cards at IBM when 5 meg drives were the size of dishwashers, and sounded like them, too. I've written tons of many kinds of assembler, entirely too much C, fortran, lisp, lots of various flavors of SQL, too, too much scripting and batching (a very wide range from JCL to python), I've even written a couple of compilers and assemblers (and I'm not talking about making "compilers" with yacc, I'm talking about writing them from scratch -- I was doing hashing when almost no one knew what hashing even was.) I've written CAD apps, graphics, AI and AL, e-commerce and accounting, inventory control, CNC controller OS and drivers, various microcontroller apps and OS's, hypertext systems, a couple of emulators (6809 and 68000 emulations... and I'm pleased to report that even after almost a decade, my 6809 emulation remains widely recognized as the fasted 6809 emulation out there based on C), several commercial arcade games, including some for which I did the computer designs for Centuri and Techstar, documentation systems, a couple of commercial database engines (one small, one quite large) -- I've not just "used" these things, mind you, but written them -- I know just a little bit about efficiency and reasonable program flow. For many years I did computer hardware and electronic design as an EE, too, though I've long since lost interest there.
So that's where I'm coming from when I say that if the state doesn't have a sales tax, and you are doing the math as if they do anyway, you're writing software poorly. If the state doesn't do tax, the number in the table had better be zero, and you should have a nice efficient boolean out there to tell you so, and there is no need to do the math (and several reasons not to.) You don't need either the multiply or the addition in that case; all you need is a compare and a branch, which are a huge amount faster. The boolean could be fetched with the numbers in the same query (if you don't have a few bytes of memory you can afford tie up) and that fetch should be just about free. Unless you don't care if your code is efficient. And if that's the case, we're back to a very basic level of coding technique. Not uncommon, but not impressive, either. Which is fine if that's how you want to write, but again, don't expect me to take you seriously. There is no need for "re-coding" the application just because you wrote efficient code, either. That's patently ridiculous. The user enters the table, the program takes one swipe at it to set the booleans on the way out of changing the table, and every operation from there on out is more efficient.
I sure do miss the days when people had an intuitive grasp on what was happening when they wrote code. Too many people just fling things around and ignore the dynamics and resource issues. CPU cycles and resources aren't free. Just a little extra effort and comprehension on the programmers part saves time and resources over and over again, time and resources that can be used for other things. Write it once the best you can and you'll be rewarded over and over again. Think about storage, stacks, CPU demands, examine your paths to see if there are reasonable shortcuts (like, not multiplying by zero and then adding the product of that to something else... it's going to still be zero after all, for crying out loud...:-) Think of it as "extreme programming." It didn't used to be, but it sure is today in this world of bloated limpware.
No. You don't "work with them", because they don't exist. Furthermore, as you claim to be "calculating zero" in a case when the answer is always zero... you can't possibly expect me to take anything else you say seriously.:-)
is your need to save on swapping out machines worth bringing forward an older architecture and all its flaws that could be resolved by a fresh design?
No. But this isn't a prerequisite in any case. There are three obvious ways to bring compatability in:
Make the new hardware == the old hardware, plus more stuff. This is the most restrictive choice, and I doubt anyone would seriously consider it these days, as there are some new ideas that can most likely make or break new hardware. This is what Intel has been doing with x86; and it is annoying, no question about it. It is also why the cell design could take Intel to the mat if they continue this behaviour.
Add the old hardware to the new hardware. The Ps2 did this -- there is actually a Ps1 in there, separate from the Ps2. This is expensive in parts and space, but it considerably reduces the need for compatibility between the new design and the old design and so it is an attractive option anyway. Also, the cost is defrayed by time -- it's considerably less expensive to put the functionality of a Ps2 on a board today than it was when the Ps2 was released.
Emulate. This is the most attractive option by far in terms of console cost; on the other hand, it requires the most out of the new hardware, as emulation at speed typically requires a whole lot more horsepower than the original machine had (I'm speaking authoritatively as an author of a number of software-based emulation engines.) The up side of that is no customer is likely to object to a new machine that is powerful enough to actually emulate the old one at speed. The down side of that is that despite the hype, we don't typically see performance leaps of that magnitude in the five years or so that seem to be a console release cycle. Is the cell such a performance leap? I somehow doubt it, but it'd be delightful if it was. Is the next XB powerpc such a performance leap? Judging by current Mac windows emulation capabilities... I think not. But again, I am ready to be proven wrong, and I'd be happy as hell about it, too.
Why is backwards-compatibility such a big deal for consoles?
Because...
...not everyone has room for multiple consoles, and moving them around is hard on the machines and the connectors (and the cables, though they're relatively inexpensive.) Moving them around is also annoying.
...not everyone can afford multiple consoles, and selling an earlier one can offset the cost of a new one. But if your game library will be rendered useless by selling the console, then you can't sell it, which means you can't offset the price of the new one, which means you're probably not going to get the new one.
...people with the above concerns don't want to throw their investment in games out the window. It's not just the money -- it's the time invested at getting good at them, too.
...you can only attach so much to your master A/V component in a reasonable/comprehensible fashion. For instance, I have three game systems attached already - XB, Ps2, G/c - as well as XM, Sirius, CD, DVD, a couple of audio processors, an HDTV, a satellite TV component, a VCR, a turntable, an MP3/network component and a security monitor switching system.
...you can only load up just so many machines on your entertainment center before it gets out of hand. This isn't the same problem as the number of inputs on your A/V system -- this is about available shelf and controller/wiring storage/tucking space. Not everyone has an entertainment center the size of Siberia, though I'm very happy to say I do.:-)
...controller compatibility can be an issue as sort of a subset of backwards compatibility. I own several dance mats, the eye-toy, some RF controllers and of course the standard controllers. I'm used to them; they're warm and fuzzy, as it were. If controller compatibility is maintained, then you're 1-up on your new console in the "I have goodies" sense.
...current customers take it as a sign of committment from the vendor that they were thinking about the people who already gave them $$$ when the new machine was designed, and this is a very good deal for the vendor (and probably exactly why the ps2 plays the vast majority of ps1 games.)
...current game vendors can continue to create games for the "old" architecture, selling into both the old market and the new market while they learn how to handle the new hardware. This was true before, but it is especially true now -- the better ps2 games are really pretty nice looking. I wouldn't be the least bit offended if some fair percentage of "new game" ps3 gameplay looked and felt like ps2 gameplay, my concern is actually being able to play the game, more than anything else. I would be offended if the fifty-plus ps2 games I have were unable to run on the ps3 (which seems quite likely at this point, we'll see.) My investment in the XB isn't that large, and in the G/c, almost nothing, so my annoyance will scale accordingly.:-)
...people who cannot afford the new hardware can still enjoy new releases that run on the previous generation because the developers are still coding for it (there are still ps1 games coming out, for instance... the ps2 is a big reason why)
...for some people, the old console may move to the kids room, where it continue to be used, and where new games for a different age group will continue to be appreciated -- new games that will cease to come much sooner if the hardware is no longer developed for. Again, see the development history of new games for the ps1 to understand why this is a factor.
...when production stops on a particular generation of hardware, as the machines die, it typically becomes more difficult to repair or replace them. If the new generation of hardware is compatible, the failure of an old machine is not t
Slashdot Mirror
While I am familiar with the original rationalizations, I don't find the current mutation of the system to be particularly admirable. The feds have grown from a sideshow to a huge, uncontrollable, unstoppable force in less than one hundred years; the states are the subject of everything from federal blackmail to outright dictatorship. Various good things about the founding documents have been hugely watered down. They have also been misrepresented, as have some of the people who created those documents.
Of course, the founding documents themselves are several hundred years old. They are based on no longer-extant demographics and communications issues. They fail to anticipate many current serious issues. The various documents themselves have gaping holes in the reasoning they formalize. They were never perfect, as with most human endeavor. I get all that just fine. However, that doesn't solve the current problem, which is a mostly out of control government.
None of which inclines me to let the presumption that we are a democracy pass. We're not. I said so.
Actually, it is. We call it "irrationality." A belief in something that has no falsifiable basis in reality.
This is what the other posters are alluding to when they handwave about it is no surprise that Utah would pass a censorship bill such as this one -- it's a "mommy law", where the state (or the nation) attempts to be everybody's mommy. By its very nature, it is defective, repressive and -- here we have it -- irrational.
Utah, and the US in general, are not examples of democracy. They are both degenerate examples of a republic. Your representatives decide what is going to happen, not you. Their votes count; you don't even get one. What you can do, perhaps, is throw the perpetrators out next time there is a round of elections. But then again, party politics can prevent that, too. You're not in control. That's what a republic is about -- the citizens don't have any direct control at all. At least unless they are willing to pick up weapons and change the system.
No, it goes like this:
That remark was decidedly off-color.
Of course -- latency will affect your perception of your partner's reactions, and the delivery of your response to your partner. How could it not make a difference?
The further away you are in space, the more latency you'll have to deal with. That's just with normal EM delivery of information. Add communications paths with uncertain and variable delivery times (like the Internet) and you'd really have some challenging changes in perception to deal with.
I used to think that. Then I realized that the GPL/LGPL were products designed to keep lawyers in business, then it all made sense. :-)
But you're probably right, as lawyers don't benefit from the fragging, but corporations do.
(ducks and runs)
CONNECTION LOS#$%& #$^ @#^@ @
Calm down. Rights come from the sysadmin.
And then... in the SOVIET UNION, PPU upgrades are... wait a sec... OK, the designs are stolen from the US but then can't be manufactured because there is no technological infrastructure, only chess players and factory managers who make quota on paper, but used the last quarter's allocation to build a dacha on the land where the PPU factory was supposed to go. But then they import them on the black market anyway. PPU? Nichevo, tovarisch!
Of course it's an obstacle. It is the obstacle. The idea here is that if the software were actually free to use, you could use it. Here is a case where you can't use it, so it isn't free. If the software was PD, they could use it. Freely! That's why PD is better, and that's why LGPL isn't free.
No. That's not the problem. The problem occurs if they have patents on their item that when subsequently linked with the LGPL'd component creates a unit they cannot further hand off. Then there is a problem, and the specific problem is this means there are limited ways you can use the LGPL'd component, which is exactly what I've been telling you all along. LGPL is a way to encumber software, not make it free. PD makes it free.
Freedom means the large players don't get to tell you what to do. You probably like that part of it. But freedom also means you don't get to tell the large players what to do. If you make software free, that means that people can do anything with it, and that's making you nervous. You think freedom is good for you, but not for someone else who might do something you don't approve of with the software in question. That's a pretty restrictive approach to take to freedom, at least in my view.
Furthermore, it is unbalanced. Some little guy at home can use your LGPL'd software -- mod it, compile it, use it to further himself -- without ever returning anything "to the community", and I don't see the FSF telling that guy he can't use it because he's some kind of a leech. If I give the little guy a PD item, he can do whatever with it, and the big player can too, and so can you, and so can I. That is balanced. That is... freedom. :-)
Now, further, if the large player does (whatever) with the PD wares, so what? Does that mean you can't also do whatever? No. It's PD. You can do anything you want. No one is stopping you. That's the point. You have freedom to act. So do the big players, and the middling players, and the small players, and yet the lawyers have little to do. Sounds like win-win-win to me, which is why I choose the PD road for myself when I am moved to contribute.
Holy Darwinian Evolution, Batman -- you sure are under some mistaken impressions. Anyone can sue you for anything. Any time, any reason, usually in a seriously inconvenient venue, and they can cause you one hell of a lot of discomfort. There is no magic barrier to lawsuits. If there were one, it'd surely involve high explosives, rather than paperwork. When the sides are unbalanced (as they always are when big players are involved) winning depends only on how much money, time and lawyerly "talent" you have available to grease the system. You don't have to "win" in court, you "win" by delay, upping the expense ante, and forcing a settlement. There is nothing, and I mean absolutely nothing, that makes a PD item any more vulnerable to a lawsuit than an LGPL'd item -- the LGPL'd item just gives the lawyers more to sink their vicious little teeth into.
Good luck even finding the author of the PD item. If he's not a fame-sucker, there's no certainty you'd know where it came from (nor, probably, should you, in order to protect honest productive citizens from the hugely broken and mismanaged l
This is one "for-example" provided by the FSF of pitfalls that await use of LGPL products -- it is not a specific restriction, it is a consequence that they have taken the time to illustrate for the users of LGPL'd materials. There are others. In order to determine what those others are under the laws that apply to your in your jurisdiction(s), a team of IP lawyers is required.
PD, on the other hand, says "here it is, do whatever you like, enjoy, bye."
PD is "free." LGPL is "encumbered."
The FSF makes the following statement in the context of explaining the LGPL:
What I say to other developers is this:
The LGPL is a force for retardation of progress masquerading as a force for freedom. I find it reprehensible as such; some developers will decide to use it under the mistaken impression that they are creating free software, when what they are creating is encumbered software. Few people actually read the license, fewer still think through to the implied consequences. So they go with the media hype, which in this case is the description of the LGPL as providing the "greatest possible use" which is clearly nonsense. The greatest possible use, and freedom, will be provided by a PD release. There's no way around it.
The great-grandparent talked about linking LGPL to commercial software, using Microsoft's Office product as the specific example.
One concrete demonstration of how this is not so is as follows: The LGPL contains terms that disallow linking with anything that incorporates certain types of software patents (as many things, most certainly including MS Office, and our some of own products, do.) That means no LGPL linking. Period.
Certainly linking / using with other LGPL'd software should work out fine. That's quite different than the specific assertion that LGPL'd software could be used as part of MS Office, though. It can't. It can't be used with ours, either -- our stuff is image manipulation software, and we've got numerous formal types of IPp wrapped around it, including software patents. That's perfectly ok with me (I own the company, so that's the key issue in my situation) because I'm not looking to use LGPL'd software, but it still remains a salient point.
So. LGPL is in no way a panacea that allows things to be used "as they are." It has pitfalls. That was one; there are others. It can't be (legally) used in the free and open manner that was described in the GGp, which is all I was saying, really.
I land either one side of the line or the other. If I'm going to give away the sweat of my brow, then I will actually do so without reservation - by using PD terms. If I want to go commercial, I'll stay on the closed source, IPp, and trade secret side of the line. LGPL'ing isn't of interest to me except as an intellectual curiosity. I spoke up because it was being misrepresented, and I felt it was worth pointing out.
As for me, I'm not looking for code at all. I'm just interested in the various paths the FOSS movement is following because I'm working on a PD (not licensed, because of the limitations) production of my own.
However, I do find it amusing that the "free" in "free software" actually means "legally encumbered and often impossible to use." That's double-plus ungood think at its best. But that's what happens when you get lawyers involved. Shakespeare's character had it right.
Actually, the fact that is it LGPL'd is exactly what prevents it from being integrated with a lot of things. The LGPL imposes numerous limitations upon exactly how, and under what circumstances, an LGPL'd product can be integrated with another product.
If people really want code to be integrated with other products, they'll release it PD, no restrictions, end of story. Then you're free to integrate it with whatever you want. All this licensing crap is just more foolishness designed to keep lawyers in the most recent year's Mercedes. Don't believe me? Go and actually read the LGPL. It is not a "free lunch" for integration. It is legal pitfall after legal pitfall which require careful legal evaluation before you could possibly consider integrating an LGPL'd component into a commercial product.
If open source people get serious about wanting their code integrated into big, serious applications, licenses like the LGPL will fall by the wayside. Until then, they're just hawking yet another version of proprietary code with the inherent costs moved over to the legal department.
Speaking, of course, as a commercial developer who has read the LGPL quite carefully. :-)
In the process of all this driving, I've rediscovered a lot of musical favorites, learned about XM and Sirius, had a blast with GPS, goofed about with wifi in various hotels and parking lots, and generally had a whole lot of fun. And didn't spend too much money for my comfort level, but no matter what I spent, $0 of it went to the airlines, which suits me just fine. And I wrote the trips off, so less went to the government at the same time. Double win.
The government is out of control, IMHO.
In short, the voters deserve this. And more. When it reaches an intolerable level for the average fool on the street, or enough of the not-so-average types unify and take up arms, it'll change. Until then, of course the government is irrational and stupid. Look who runs it.
Since the 70's, in fact. I presently own a decent sized software company, among other things. Where efficiency is paramount; we do graphics. Don't even worry about my ability to code. I was prodding punch cards at IBM when 5 meg drives were the size of dishwashers, and sounded like them, too. I've written tons of many kinds of assembler, entirely too much C, fortran, lisp, lots of various flavors of SQL, too, too much scripting and batching (a very wide range from JCL to python), I've even written a couple of compilers and assemblers (and I'm not talking about making "compilers" with yacc, I'm talking about writing them from scratch -- I was doing hashing when almost no one knew what hashing even was.) I've written CAD apps, graphics, AI and AL, e-commerce and accounting, inventory control, CNC controller OS and drivers, various microcontroller apps and OS's, hypertext systems, a couple of emulators (6809 and 68000 emulations... and I'm pleased to report that even after almost a decade, my 6809 emulation remains widely recognized as the fasted 6809 emulation out there based on C), several commercial arcade games, including some for which I did the computer designs for Centuri and Techstar, documentation systems, a couple of commercial database engines (one small, one quite large) -- I've not just "used" these things, mind you, but written them -- I know just a little bit about efficiency and reasonable program flow. For many years I did computer hardware and electronic design as an EE, too, though I've long since lost interest there.
So that's where I'm coming from when I say that if the state doesn't have a sales tax, and you are doing the math as if they do anyway, you're writing software poorly. If the state doesn't do tax, the number in the table had better be zero, and you should have a nice efficient boolean out there to tell you so, and there is no need to do the math (and several reasons not to.) You don't need either the multiply or the addition in that case; all you need is a compare and a branch, which are a huge amount faster. The boolean could be fetched with the numbers in the same query (if you don't have a few bytes of memory you can afford tie up) and that fetch should be just about free. Unless you don't care if your code is efficient. And if that's the case, we're back to a very basic level of coding technique. Not uncommon, but not impressive, either. Which is fine if that's how you want to write, but again, don't expect me to take you seriously. There is no need for "re-coding" the application just because you wrote efficient code, either. That's patently ridiculous. The user enters the table, the program takes one swipe at it to set the booleans on the way out of changing the table, and every operation from there on out is more efficient.
I sure do miss the days when people had an intuitive grasp on what was happening when they wrote code. Too many people just fling things around and ignore the dynamics and resource issues. CPU cycles and resources aren't free. Just a little extra effort and comprehension on the programmers part saves time and resources over and over again, time and resources that can be used for other things. Write it once the best you can and you'll be rewarded over and over again. Think about storage, stacks, CPU demands, examine your paths to see if there are reasonable shortcuts (like, not multiplying by zero and then adding the product of that to something else... it's going to still be zero after all, for crying out loud... :-) Think of it as "extreme programming." It didn't used to be, but it sure is today in this world of bloated limpware.
No. You don't "work with them", because they don't exist. Furthermore, as you claim to be "calculating zero" in a case when the answer is always zero... you can't possibly expect me to take anything else you say seriously. :-)
You exaggerate. All 50 states don't have sales taxes. Montana, for instance, has no sales tax.
Excellent point, and one I am sure that the manufacturers should consider. Thanks!
No. But this isn't a prerequisite in any case. There are three obvious ways to bring compatability in:
Because...
Until then, football on television is just one more motivation to sit down and read a book or go surf the net.