Well, the administrative cost of collecting the tax exists no matter how you enforce it. You could also put the responsibility on the customer in the EU, but that would effectively mean a much higher price for the customer (because he has to take into account the paperwork whenever buying from the US). In fact, if collected from the EU buyer rather than the US seller, the effective per buyer costs are likely to be much higher, so that seems like a poor option. Since the law applies to electronic transactions, most likely you are going to see very simple electronic clearinghouses for this kind of thing that makes it easy for any US company to administer these taxes.
I think the EU might have given US businesses a choice: collect the tax yourself or let your customers pay them. Note, however, that small businesses (less than $100k in EU sales) seem to be exempt from the law altogether.
As for enforceability, a US company doing business with someone in the EU does fall under EU jurisdiction, and the EU certainly has lots of means at their disposal for enforcement. Taxation of on-line software sales may not be feasible at all, but to the degree that it is feasible, it can be applied uniformly to EU and non-EU purchases.
If you do business with EU citizens on-line, those customers are subject to EU jurisdiction. The EU can certainly prohibit them from doing business with you unless you collect sales tax, and they can enforce that with penalties on the customers.
The EU could also seize your European assets. If you don't have any, you are at least still relying on EU law to protect your copyrights, patents, and contractual enforcement.
I think it's the US that doesn't get it. Charging taxes on locally produced products but giving imports a tax break is irrational and harmful tax policy. The fact that this policy exists among US states is some political and legal idiosyncracy of the US federal system. European nations hopefully are above that kind of nonsense.
[Sales tax is] very inefficient: for starters it's inconvenient to me to go into a convenience store, grab a bag of Doritos marked $0.99, and have to pay more than a dollar.
[Without sales tax] Doritos cost $0.99 instead of $1.06. Everything costs what it says it costs.
Almost all other countries in the world list prices including sales tax.
Why is the US different? We can only guess. But my distinct impression is that US businesses try to trick and deceive customers any way they can, and listing prices without sales tax does trick people again and again. And the US legislatures don't seem to have an interest in putting an end to this consumer-hostile practice by legislating it away (it's a form of deceptive advertising).
Even with sales tax, your store could price the Doritos at $0.92 pre-tax, so that they come out to a round dollar after tax.
Systems like Condor already provide process migration for native code on Linux and other platforms. Much of the Plan 9 functionality has also been implemented as shared libraries for UNIX by people at Bell Labs (Practial Resuable UNIX Software). And Java provides a similar kind of environment with already a lot more software available for it than Plan 9. Erlang also has extensive support for distributed computing and runs on top of standard platforms.
There is no question that Plan 9 is more elegant and clean, but it also lacks a lot of functionality. Whether it's easier to add all that stuff to Plan 9 (and whether the result will still be elegant and clean), or whether it's easier to add Plan 9 ideas to Linux, to me, is still an open question. Both paths would lead to roughly the same end result: a complex system with better support for distributed computing.
Either way, the open source release of Plan 9 is a good starting point because it gets those ideas out into the mainstream.
Plan 9 used to come with a C-like language called Alef. Alef included a simple form of template, a simple form of dynamically typed pointer, a bit more built-in error checking than C, and nice support for coroutines. Altogether, very nice, clean, small, and potentially very useful.
But I can't find it in the distribution and even the papers or other references seem to have disappeared from the Plan 9 site. (You can still get a copy of the reference manual in Google's cache by searching for "alef language"; it's the first hit).
That's a shame, because Plan 9 otherwise seems pretty poor when it comes to anything higher level than C.
Making software even harder to install and content even harder to use means even more opportunity for free software and free content.
The only thing we have to be vigilant about is that the distribution channels themselves remain open for open source and open content.
Audio indicates the risks of what can happen: MP3 media, MP3 players, and digital audio recorders have been deliberately crippled for the commercial interests of the record industry. Just doesn't just restrict sharing of copyrighted content under fair use provisions, it also limits access to the market of the very people who operate outside the major record labels. By making recording and distribution more painful and costly, the record industry inhibits low cost and free recordings.
So, as a user, I don't worry about this kind of nonsense--it will merely spur the development of cheaper or free alternatives. I do worry when these people go out and try to restrict the distribution of information in general because that keeps new competitors out of the market and has far reaching consequences for a free society in general.
Plan 9 is a very interesting system and I'm glad it seems to have been released in an open source form. I think it will take some time to sort through a number of issues, though:
Is the license acceptable? Does it contain unforeseen gotchas?
Is the system up to snuff in terms of performance? For example, many of its protocols are text based, and while that really simplifies things, for some applications, it may impose too much overhead. Is its multiprocessor support adequate?
Are there enough drivers for it? Can Linux or BSD drivers be adapted easily?
Does it contain limitations that are too painful to live with? For example, I remember someone working on Plan 9 (Pike?) saying that "sparse address spaces are bad for you" and that "you can always figure out how to do something without them". Well, I can, but I may not want to when porting a big, existing software system.
Is the windowing system really usable? These days, a good windowing system should support antialiased and zoomable 2D graphics (X11 squeezes by for now with GLIB) and a toolkit with things like trees and grids. 8 1/2 seems a little primitive; can it be brought up to speed? Can we port GTK to it? What about OpenGL support?
Is Plan 9 really usable for things like web services? Distributed computation?
So, I suggest people beat away on it, try to port stuff to it, run the license past their corporate lawyers, and share what they find.
Again, on the whole, I think this is very positive. But it may also turn out to be too late: Linux and similar systems also have evolved and included some really innovative stuff (e.g., ReiserFS). At least, with its general availability, Plan 9 may influence the future evolution of Linux and other open source OS'es. A lot of the functionality of Plan 9 can actually also be provided on top of a standard UNIX kernel without kernel modifications.
Incidentally, on the license front, Bell Labs still seems to have a few problems; consider this part from the release notes:
If I were a commercial developer and wanted to develop in a Windows-like environment, why would I buy this stuff? Kylix and Qt development licenses together probably cost more than an excellent Windows environment or even an MSDN subscription, and I end up working in a non-standard environment with less functionality.
I would likely be better off getting the Windows tools, developing on Windows, and delivering my code on Linux using one of the free or commercial Windows compatibility libraries for Linux. For those who like that development style, MSDN is a really good deal (incidentally, I'm an MSDN member).
OTOH, those of us who don't like the Windows development style use Linux precisely because the Linux development tools are different from the Borland/Microsoft style tools. In different words, if I thought Windows was better technically or for development, I would already be using it, and so would most other Linux users, I suspect.
Those Linux zealots brought you Linux in the first place. If you think they don't know what they are doing, why don't you just keep using those other "far, far advanced systems" you keep talking about?
But you are right to some degree: this draws a line in the sand. Linux was built by its users for themselves, and those folks have little use for Kylix and similar tools. Commercial use of Linux has little to do with that. So, we really have two separate communities, where the commercial community happens to be using a lot of tools developed by the open source community.
Maybe this is not a stable long term situation and the commercial community will branch off; it's up to them. But either way, traditional Linux users will continue doing what they are doing.
As for being "far far behind", I don't consider Borland's or Microsoft's tools particularly good: they are poor clones of 20 year old technology, they cause lots of software maintenance problems, and they generate user interfaces that rank low on several aspects of usability. It may be what users are used to, but it certainly isn't "good" or "new".
Pike is right in as much that Linux doesn't contain radical innovation. But neither does Windows NT. Both are really just incremental enhancement on tried-and-true OS technology. But between the two, Linux need not fear comparison.
Pike is also right that the community needs to explore more unorthodox ideas and do research for the longer term. He is also right that startups suck energy from research.
But when it comes down to it, a lot of his complaints are colored by his particular environment. AT&T used to get monopoly profits, so they were wealthy and didn't have to give a damn about dealing with the business side of things. And they didn't. Well, welcome to the real world. Most researchers have had to figure out for decades how to balance real world demands with a research program. Pike should perhaps learn this if he wants to stay in this business.
Pike also used to work in the early days of systems research when there were a lot of low-hanging fruit. Well, systems research is a lot harder now because most of the easy stuff has been done. These days, any progress requires a lot of complex interdisciplinary skills and work: algorithms, systems, statistics, HCI, etc. You're lucky if you get out one good paper per year these days.
Yes, today's systems research is tedious, hard, long term, and not well funded. But there is more work to be done than ever, and a lot of really interesting and important work. And, you know what, it actually is happening. Maybe not where Pike is working, but at lots of other places.
If there is one complaint I would have is that the open source community isn't more innovative. A lot of open source projects are merely clones of existing systems, often existing open source systems. Open source developers could actually focus more on the future.
anonymous file swapping--no good for executables
on
Gnutella VBS Worm
·
· Score: 2
Gnutella doesn't have much in the way of authentication or signatures for the files people download. That isn't a problem for MP3's--if you thought you downloaded Metallica and you get Pocahontas instead, nothing has been damaged. But for executables and some kinds of documents, it's a big problem.
Pike, Python, Perl, Tcl, JavaScript, Ruby, etc. are all very similar: dynamically typed, byte code interpreted, procedural/OO languages.
In addition, there is a plethora of interesting, powerful interpreters for languages that go beyond traditional scripting: EiC (ANSI C interpreter), CINT (C++ interpreter), Hugs/Haskell, CAML-Light, Scheme, Icon, CLisp/CommonLisp, Squeak/Smalltalk-80, etc.
Next time you feel the urge to invent a new scripting language, think about doing something genuinely new, rather than coming up with a language that is merely an incompatible, incremental improvement of something existing.
If you can't formulate some new idea that your language implements that isn't easily added to Python or Perl, I'd say, don't bother and work on one of the existing languages instead. Many of the existing languages need more libraries and better foreign function interfaces, and several of the existing languages would benefit from new implementations in C++ and/or Java, etc.
I'm not sure why any country would think that being home to Microsoft is so great. Microsoft doesn't have a lot of employees, and they are likely not to want to pay a lot of taxes wherever they move. Having them relocate into your community would just add a large number of rather wealthy individuals to a small area, which isn't necessarily good.
In the US, in general, you don't need a license to use a trademark to refer to the trademarked product, even in a negative way. Companies do it all the time in comparative advertising. The purpose of a trademark is to identify the origins of a product to a buyer unambiguously and clearly, nothing more.
Well, we have already hashed out the dangers of UCITA, and I agree that it sets a dangerous precedent. However, legal contracts require more than just reading something or doing something, and what is enforceable under a legal contract is also limited. "You agree to give me $1000 if you read this." is not an enforceable contract.
While in the long run, doing something legal or political about UCITA may be a good thing, in the short run, you have a much more direct weapon at your disposal: don't do business with companies that you know impose onerous or overly complex contracts.
Miller's claim is that their license agreement is harmless and doesn't impose any significant conditions on you, so you shouldn't mind agreeing to it. He isn't claiming that they can't make you agree to it in this way. I'm saying that Miller is wrong and that their license agreement may seriously limit what you can say about their products, and if that bothers you (it bothers me), just don't do business with them. There may be other "hidden" agreements of unknown legal validity, but this one you know about, and this one you can do something about.
If we keep publicizing companies bad license agreements and consistently don't buy their products, this practice will stop sooner or later.
Apogee can reserve the right to ban negative reviews as part of a contract. That practice is fairly widespread for commercial software and has been around for decades.
The license agreement is a legal contract between you and Apogee: in return for using their web site or their software, you agree to certain terms. In some areas, the agreement grants you extra rights (the right to use their software, the right to access their web site), in other areas it limits what you can do with their intellectual property.
In particular, within some limits, without a separate contract, anybody has the right to use their trademarks in the context of making negative comments about their products. But that right can certainly be curtailed if you enter into a contract with the trademark holder. Those kinds of limitations are a priori valid, although in specific cases they may be invalid or unenforceable.
As for Miller, he is not a lawyer, and even if he were, his opinion on the matter wouldn't be relevant. Nor, in fact, does my opinion on it matter. What matters for this agreement is what matters for any legal agreement: do you understand the terms, can you fulfill your part of the agreement, and what are your risks. If you can't answer those questions, don't enter into the agreement.
Don't sign or otherwise agree to a contract if you don't understand it or don't like its terms.
(Disclaimer: I'm not a lawyer. For legal advice, see a professional.)
There are a variety of pretty straightforward techniques to present two separate images to a viewer in front of a flat display. You can get some idea from the 3D postcards and photographs with the riged surface: they use small cylindrical lenses to accomplish this.
Trouble is: when looking at realistic scenes, motion parallax (i.e., what happens to the image when you move your head slightly), not stereo, is probably the primary motion cue. Stereo cues in the kinds of scenes you get from 3D games are likely more confusing than immersive, since they often simply reinforce the impression of looking at a tiny, toy-like scene. If you want that kind of appearance, you can already get simple LCD shutter glasses for relatively little money, but they probably haven't caught on for a reason.
The best solution for immersive 3D games is head mounted displays, which give you excellent head tracking and motion parallax. The next most important cue is likely peripheral vision, which is a bigger engineering challenge. Once you have a head-mounted display, adding stereo is technically easy (but increases the cost somewhat since you need two displays).
Contrary to what Scott Miller seems to think, licenses and contracts have definite meanings. Furthermore, if you agree to a license, you are presumed to have understood it and its implications.
The Apogee license is pretty clear and you don't need a legal degree to understand it. Some of its provisions may turn out to be unenforceable and their remedies may be limited, but to predict that you do need a legal degree.
By default, you should assume that the most restrictive reading of a license is the one that is legally binding. Explanations from vendors or sales people that "it isn't quite like that" and that "they would never enforce it that strictly" are disingenuous; their statements aren't legally binding, they want you money, if they are wrong, they have you by the balls (good for them), and if push comes to shove, you are still looking at a lengthy legal battle to fight something like that through.
If you don't like what a license says, don't agree to the license and don't buy the product. A bad/defective license is worse than a defective product.
(As for the Apogee license itself, you may be able to cancel it by destroying the game media. Afterwards, I believe you ought to be able to say whatever you want to about their product within the bounds of trademark law; but I'm not a lawyer, so get professional legal advice before doing anything like that.)
As I understand it, Apogee can't "license" the use of their trademarks in normal discourse. Trademarks are there to identify products; the intent is that the consumer won't get confused about what product you are talking about, but as long as you use the trademark to refer to the correct product, and as long as you are otherwise fair, I believe you should be able to make both positive and negative comments.
It seems to me that many downloads and swaps of MP3s are "fair use". Can I give a CD to a friend or relative? Donate it to a public library? Why not an MP3 file?
The notion that sharing content in this way is illegal seems to have been created by the content industry, who would like to see content licensed preferably to individuals and maybe even on a pay-per-view basis.
Maybe what sites like Napster should do is to create a simple "license manager" scheme that ensures that multiple individuals don't listen to the same recording at the same time. It seems to me that the intent of traditional copyright law would be satisfied that way and the music industry wouldn't have a leg to stand on. Of course, if that catches on widely, their sales would still plummet precipitously, because nationwide people would only listen to a small number of copies of most recordings simultaneously.
Federated search engines aren't exactly a new idea. The reason why they haven't been used much on the web are issues related to quality of service, reliability, spamming, and revenue sharing. Those could be worked out, but web search engines seem to have found it easier to just centralize resources. Federated search has been more popular within particular communities (e.g., scientific literature, intranet sharing), and for integrating a few top search engines (MetaCrawler etc.). For more information, type "federated search" into Google.
What makes Python a great language is its simplicity, both at the level of implementation and at the level of the language.
What I hope to see for Python 3000 is mostly cleanups that weren't possible in earlier versions because of backwards incompatibility: a simpler, leaner implementation with a "nicer" interface to C++ code, lexical scoping rules, and a simple full garbage collector in place of reference counting. Moving the NumPy numerical array type into the core would also help with creating numerical extensions. But that's largely all I would like to see in the next major release of Python.
I'm not sure that the transition to BeOpen.com of the development effort is altogether a good thing. If this results in extra resources and they are focussed on enhancing Python, Python may become too complex and featureful; a number of other languages that started out like Python have gone down that road and become marginalized. Or Python may simply end up being a side-line for some other business, just like what seems to have happened with Scriptics and Tcl.
Python is Guido's baby, and it's his to decide where to take it. But I hope he'll keep these kinds of concerns in mind.
I made a comment about the quality of European patent examinations, not European patent law.
But let's talk about law. I think your comment is pretty characteristic of the irrational polemics that surround many of these discussions. You paint first-to-invent as a small inventor vs. big company issue and try to gain sympathy and support for the current US patent system by trying to get sympathy for a hypothetical small inventor that might get harmed under a particular set of circumstances by a big company.
Of course, you provide no support, not even anecdotal, for your situation. If we analyze it theoretically, I would think the small inventor is much more likely to be harmed by first-to-invent: big companies are much more likely to have the paper trail to document first-to-invent and much more likely to have the legal muscle to push through a first-to-invent case. Unlike first-to-file, first-to-invent is a fuzzy and complex doctrine, and those kinds of legal complexities favor interests with good legal support.
Of course, implicit in your statement is also the assumption that the delay for the small inventor is caused by the inadequate legal representation he has for the preparation of his patent. I think we should ask why the inventor ought to require complex legal assistance for filing a patent in the first place. That, too, strikes me as a serious flaw, in particular in the US patent system, something that greatly stacks the deck against the small inventor. If you are concerned about small inventors, address that issue.
So, in short, yes I favor first-to-file because it's easy to understand and easy to adjudicate. I also think the US notion that you can patent within a year of publication is wrong because it makes it even easier for companies to get their patented technology into standards without anybody knowing until it's too late.
I'm not sure what you mean by "business law patents", but if you are referring to "business method patents", I don't see what the problem is. Business methods aren't chemical process methods, and the patent office ought to have no problem distinguishing the two; allowing one does not in any way require allowing the other. I don't know what the current status of business method patents is in Europe, but I would be surprised if they were allowed.
In fact, chemical process patents are, in my opinion, far preferable to the patents on chemical substances themselves that are allowed now; the whole reason industry hasn't been satisfied with chemical process patents is because they feel that chemical process patents do not afford enough of a monopolistic protection--clever competitors have become increasingly good at finding alternative chemical processes, so that effectively process patents were much more short-lived.
I don't know what your background is or whether you have ever even written a patent. But perhaps you should seek the cause for the "closed minded responses" from engineers in the insubstantial nature of your own arguments. If you want to make arguments about protecting small inventors, I suggest you support them with actual facts: how frequently do these cases arise, who usually wins them, etc.
As for me, I'll stick to what I observe directly, and that is that European patent examinations appear to be significantly more skilled and careful than US patent examinations. It won't fix the US patent system, but I think it would certainly help if examinations could be brought up at least to that level of care.
Normal rules of free speech or various rights don't apply in general when dealing with companies. eBay is not obligated to deal in Microsoft products, even if they are completely legitimate.
That's the problem in general with creating large, private entities: they are not subject to many of the laws and protections for individuals that we have achieved in civil society over the centuries.
So, in the short term, this should be an inducement to use companies other than eBay for auctioning, not only because they won't list Microsoft or Scientology products, but because preserving a diversity of services is important in general. In the long term, we should work towards more legal requirements on private companies that perform important social and economic functions in our society; eBay is a free marketplace, and it ought to be subject to strict regulations that ensures that they perform that kind of function equitably and without favoring particular companies
Slashdot Mirror
I think the EU might have given US businesses a choice: collect the tax yourself or let your customers pay them. Note, however, that small businesses (less than $100k in EU sales) seem to be exempt from the law altogether.
As for enforceability, a US company doing business with someone in the EU does fall under EU jurisdiction, and the EU certainly has lots of means at their disposal for enforcement. Taxation of on-line software sales may not be feasible at all, but to the degree that it is feasible, it can be applied uniformly to EU and non-EU purchases.
The EU could also seize your European assets. If you don't have any, you are at least still relying on EU law to protect your copyrights, patents, and contractual enforcement.
I think it's the US that doesn't get it. Charging taxes on locally produced products but giving imports a tax break is irrational and harmful tax policy. The fact that this policy exists among US states is some political and legal idiosyncracy of the US federal system. European nations hopefully are above that kind of nonsense.
Almost all other countries in the world list prices including sales tax.
Why is the US different? We can only guess. But my distinct impression is that US businesses try to trick and deceive customers any way they can, and listing prices without sales tax does trick people again and again. And the US legislatures don't seem to have an interest in putting an end to this consumer-hostile practice by legislating it away (it's a form of deceptive advertising).
Even with sales tax, your store could price the Doritos at $0.92 pre-tax, so that they come out to a round dollar after tax.
There is no question that Plan 9 is more elegant and clean, but it also lacks a lot of functionality. Whether it's easier to add all that stuff to Plan 9 (and whether the result will still be elegant and clean), or whether it's easier to add Plan 9 ideas to Linux, to me, is still an open question. Both paths would lead to roughly the same end result: a complex system with better support for distributed computing.
Either way, the open source release of Plan 9 is a good starting point because it gets those ideas out into the mainstream.
But I can't find it in the distribution and even the papers or other references seem to have disappeared from the Plan 9 site. (You can still get a copy of the reference manual in Google's cache by searching for "alef language"; it's the first hit).
That's a shame, because Plan 9 otherwise seems pretty poor when it comes to anything higher level than C.
The only thing we have to be vigilant about is that the distribution channels themselves remain open for open source and open content.
Audio indicates the risks of what can happen: MP3 media, MP3 players, and digital audio recorders have been deliberately crippled for the commercial interests of the record industry. Just doesn't just restrict sharing of copyrighted content under fair use provisions, it also limits access to the market of the very people who operate outside the major record labels. By making recording and distribution more painful and costly, the record industry inhibits low cost and free recordings.
So, as a user, I don't worry about this kind of nonsense--it will merely spur the development of cheaper or free alternatives. I do worry when these people go out and try to restrict the distribution of information in general because that keeps new competitors out of the market and has far reaching consequences for a free society in general.
So, I suggest people beat away on it, try to port stuff to it, run the license past their corporate lawyers, and share what they find.
Again, on the whole, I think this is very positive. But it may also turn out to be too late: Linux and similar systems also have evolved and included some really innovative stuff (e.g., ReiserFS). At least, with its general availability, Plan 9 may influence the future evolution of Linux and other open source OS'es. A lot of the functionality of Plan 9 can actually also be provided on top of a standard UNIX kernel without kernel modifications.
Incidentally, on the license front, Bell Labs still seems to have a few problems; consider this part from the release notes:
I would likely be better off getting the Windows tools, developing on Windows, and delivering my code on Linux using one of the free or commercial Windows compatibility libraries for Linux. For those who like that development style, MSDN is a really good deal (incidentally, I'm an MSDN member).
OTOH, those of us who don't like the Windows development style use Linux precisely because the Linux development tools are different from the Borland/Microsoft style tools. In different words, if I thought Windows was better technically or for development, I would already be using it, and so would most other Linux users, I suspect.
But you are right to some degree: this draws a line in the sand. Linux was built by its users for themselves, and those folks have little use for Kylix and similar tools. Commercial use of Linux has little to do with that. So, we really have two separate communities, where the commercial community happens to be using a lot of tools developed by the open source community.
Maybe this is not a stable long term situation and the commercial community will branch off; it's up to them. But either way, traditional Linux users will continue doing what they are doing.
As for being "far far behind", I don't consider Borland's or Microsoft's tools particularly good: they are poor clones of 20 year old technology, they cause lots of software maintenance problems, and they generate user interfaces that rank low on several aspects of usability. It may be what users are used to, but it certainly isn't "good" or "new".
Pike is also right that the community needs to explore more unorthodox ideas and do research for the longer term. He is also right that startups suck energy from research.
But when it comes down to it, a lot of his complaints are colored by his particular environment. AT&T used to get monopoly profits, so they were wealthy and didn't have to give a damn about dealing with the business side of things. And they didn't. Well, welcome to the real world. Most researchers have had to figure out for decades how to balance real world demands with a research program. Pike should perhaps learn this if he wants to stay in this business.
Pike also used to work in the early days of systems research when there were a lot of low-hanging fruit. Well, systems research is a lot harder now because most of the easy stuff has been done. These days, any progress requires a lot of complex interdisciplinary skills and work: algorithms, systems, statistics, HCI, etc. You're lucky if you get out one good paper per year these days.
Yes, today's systems research is tedious, hard, long term, and not well funded. But there is more work to be done than ever, and a lot of really interesting and important work. And, you know what, it actually is happening. Maybe not where Pike is working, but at lots of other places.
If there is one complaint I would have is that the open source community isn't more innovative. A lot of open source projects are merely clones of existing systems, often existing open source systems. Open source developers could actually focus more on the future.
Gnutella doesn't have much in the way of authentication or signatures for the files people download. That isn't a problem for MP3's--if you thought you downloaded Metallica and you get Pocahontas instead, nothing has been damaged. But for executables and some kinds of documents, it's a big problem.
In addition, there is a plethora of interesting, powerful interpreters for languages that go beyond traditional scripting: EiC (ANSI C interpreter), CINT (C++ interpreter), Hugs/Haskell, CAML-Light, Scheme, Icon, CLisp/CommonLisp, Squeak/Smalltalk-80, etc.
Next time you feel the urge to invent a new scripting language, think about doing something genuinely new, rather than coming up with a language that is merely an incompatible, incremental improvement of something existing.
If you can't formulate some new idea that your language implements that isn't easily added to Python or Perl, I'd say, don't bother and work on one of the existing languages instead. Many of the existing languages need more libraries and better foreign function interfaces, and several of the existing languages would benefit from new implementations in C++ and/or Java, etc.
I'm not sure why any country would think that being home to Microsoft is so great. Microsoft doesn't have a lot of employees, and they are likely not to want to pay a lot of taxes wherever they move. Having them relocate into your community would just add a large number of rather wealthy individuals to a small area, which isn't necessarily good.
In the US, in general, you don't need a license to use a trademark to refer to the trademarked product, even in a negative way. Companies do it all the time in comparative advertising. The purpose of a trademark is to identify the origins of a product to a buyer unambiguously and clearly, nothing more.
While in the long run, doing something legal or political about UCITA may be a good thing, in the short run, you have a much more direct weapon at your disposal: don't do business with companies that you know impose onerous or overly complex contracts.
Miller's claim is that their license agreement is harmless and doesn't impose any significant conditions on you, so you shouldn't mind agreeing to it. He isn't claiming that they can't make you agree to it in this way. I'm saying that Miller is wrong and that their license agreement may seriously limit what you can say about their products, and if that bothers you (it bothers me), just don't do business with them. There may be other "hidden" agreements of unknown legal validity, but this one you know about, and this one you can do something about.
If we keep publicizing companies bad license agreements and consistently don't buy their products, this practice will stop sooner or later.
The license agreement is a legal contract between you and Apogee: in return for using their web site or their software, you agree to certain terms. In some areas, the agreement grants you extra rights (the right to use their software, the right to access their web site), in other areas it limits what you can do with their intellectual property.
In particular, within some limits, without a separate contract, anybody has the right to use their trademarks in the context of making negative comments about their products. But that right can certainly be curtailed if you enter into a contract with the trademark holder. Those kinds of limitations are a priori valid, although in specific cases they may be invalid or unenforceable.
As for Miller, he is not a lawyer, and even if he were, his opinion on the matter wouldn't be relevant. Nor, in fact, does my opinion on it matter. What matters for this agreement is what matters for any legal agreement: do you understand the terms, can you fulfill your part of the agreement, and what are your risks. If you can't answer those questions, don't enter into the agreement.
Don't sign or otherwise agree to a contract if you don't understand it or don't like its terms.
(Disclaimer: I'm not a lawyer. For legal advice, see a professional.)
Trouble is: when looking at realistic scenes, motion parallax (i.e., what happens to the image when you move your head slightly), not stereo, is probably the primary motion cue. Stereo cues in the kinds of scenes you get from 3D games are likely more confusing than immersive, since they often simply reinforce the impression of looking at a tiny, toy-like scene. If you want that kind of appearance, you can already get simple LCD shutter glasses for relatively little money, but they probably haven't caught on for a reason.
The best solution for immersive 3D games is head mounted displays, which give you excellent head tracking and motion parallax. The next most important cue is likely peripheral vision, which is a bigger engineering challenge. Once you have a head-mounted display, adding stereo is technically easy (but increases the cost somewhat since you need two displays).
The Apogee license is pretty clear and you don't need a legal degree to understand it. Some of its provisions may turn out to be unenforceable and their remedies may be limited, but to predict that you do need a legal degree.
By default, you should assume that the most restrictive reading of a license is the one that is legally binding. Explanations from vendors or sales people that "it isn't quite like that" and that "they would never enforce it that strictly" are disingenuous; their statements aren't legally binding, they want you money, if they are wrong, they have you by the balls (good for them), and if push comes to shove, you are still looking at a lengthy legal battle to fight something like that through.
If you don't like what a license says, don't agree to the license and don't buy the product. A bad/defective license is worse than a defective product.
(As for the Apogee license itself, you may be able to cancel it by destroying the game media. Afterwards, I believe you ought to be able to say whatever you want to about their product within the bounds of trademark law; but I'm not a lawyer, so get professional legal advice before doing anything like that.)
As I understand it, Apogee can't "license" the use of their trademarks in normal discourse. Trademarks are there to identify products; the intent is that the consumer won't get confused about what product you are talking about, but as long as you use the trademark to refer to the correct product, and as long as you are otherwise fair, I believe you should be able to make both positive and negative comments.
The notion that sharing content in this way is illegal seems to have been created by the content industry, who would like to see content licensed preferably to individuals and maybe even on a pay-per-view basis.
Maybe what sites like Napster should do is to create a simple "license manager" scheme that ensures that multiple individuals don't listen to the same recording at the same time. It seems to me that the intent of traditional copyright law would be satisfied that way and the music industry wouldn't have a leg to stand on. Of course, if that catches on widely, their sales would still plummet precipitously, because nationwide people would only listen to a small number of copies of most recordings simultaneously.
Federated search engines aren't exactly a new idea. The reason why they haven't been used much on the web are issues related to quality of service, reliability, spamming, and revenue sharing. Those could be worked out, but web search engines seem to have found it easier to just centralize resources. Federated search has been more popular within particular communities (e.g., scientific literature, intranet sharing), and for integrating a few top search engines (MetaCrawler etc.). For more information, type "federated search" into Google.
What I hope to see for Python 3000 is mostly cleanups that weren't possible in earlier versions because of backwards incompatibility: a simpler, leaner implementation with a "nicer" interface to C++ code, lexical scoping rules, and a simple full garbage collector in place of reference counting. Moving the NumPy numerical array type into the core would also help with creating numerical extensions. But that's largely all I would like to see in the next major release of Python.
I'm not sure that the transition to BeOpen.com of the development effort is altogether a good thing. If this results in extra resources and they are focussed on enhancing Python, Python may become too complex and featureful; a number of other languages that started out like Python have gone down that road and become marginalized. Or Python may simply end up being a side-line for some other business, just like what seems to have happened with Scriptics and Tcl.
Python is Guido's baby, and it's his to decide where to take it. But I hope he'll keep these kinds of concerns in mind.
But let's talk about law. I think your comment is pretty characteristic of the irrational polemics that surround many of these discussions. You paint first-to-invent as a small inventor vs. big company issue and try to gain sympathy and support for the current US patent system by trying to get sympathy for a hypothetical small inventor that might get harmed under a particular set of circumstances by a big company.
Of course, you provide no support, not even anecdotal, for your situation. If we analyze it theoretically, I would think the small inventor is much more likely to be harmed by first-to-invent: big companies are much more likely to have the paper trail to document first-to-invent and much more likely to have the legal muscle to push through a first-to-invent case. Unlike first-to-file, first-to-invent is a fuzzy and complex doctrine, and those kinds of legal complexities favor interests with good legal support.
Of course, implicit in your statement is also the assumption that the delay for the small inventor is caused by the inadequate legal representation he has for the preparation of his patent. I think we should ask why the inventor ought to require complex legal assistance for filing a patent in the first place. That, too, strikes me as a serious flaw, in particular in the US patent system, something that greatly stacks the deck against the small inventor. If you are concerned about small inventors, address that issue.
So, in short, yes I favor first-to-file because it's easy to understand and easy to adjudicate. I also think the US notion that you can patent within a year of publication is wrong because it makes it even easier for companies to get their patented technology into standards without anybody knowing until it's too late.
I'm not sure what you mean by "business law patents", but if you are referring to "business method patents", I don't see what the problem is. Business methods aren't chemical process methods, and the patent office ought to have no problem distinguishing the two; allowing one does not in any way require allowing the other. I don't know what the current status of business method patents is in Europe, but I would be surprised if they were allowed.
In fact, chemical process patents are, in my opinion, far preferable to the patents on chemical substances themselves that are allowed now; the whole reason industry hasn't been satisfied with chemical process patents is because they feel that chemical process patents do not afford enough of a monopolistic protection--clever competitors have become increasingly good at finding alternative chemical processes, so that effectively process patents were much more short-lived.
I don't know what your background is or whether you have ever even written a patent. But perhaps you should seek the cause for the "closed minded responses" from engineers in the insubstantial nature of your own arguments. If you want to make arguments about protecting small inventors, I suggest you support them with actual facts: how frequently do these cases arise, who usually wins them, etc.
As for me, I'll stick to what I observe directly, and that is that European patent examinations appear to be significantly more skilled and careful than US patent examinations. It won't fix the US patent system, but I think it would certainly help if examinations could be brought up at least to that level of care.
That's the problem in general with creating large, private entities: they are not subject to many of the laws and protections for individuals that we have achieved in civil society over the centuries.
So, in the short term, this should be an inducement to use companies other than eBay for auctioning, not only because they won't list Microsoft or Scientology products, but because preserving a diversity of services is important in general. In the long term, we should work towards more legal requirements on private companies that perform important social and economic functions in our society; eBay is a free marketplace, and it ought to be subject to strict regulations that ensures that they perform that kind of function equitably and without favoring particular companies