On the one hand, Java uses pretty much the same object model as Pascal/Delphi (single inheritance, interfaces). On the other hand, unlike in Java you can program at the same low level in Pascal/Delphi as in C if you want to (yes, Pascal/Delphi has pointers, and you can also do pointer arithmetic if you want to). So I'd disagree with your claim that none of the allowed languages allow low-level programming.
why don't you see how the others got around it. Flash is out, but there are others that Apple has approved./me looks at Unity...
Can you point me to a statement from Apple to that effect? All I could find is a blog post from the Unity people saying that they think they are fine because Apple can't afford to pull all apps using their engine from the AppStore. That's not really a solid basis to work with. FWIW, they haven't done that either with apps containing Pascal code (most likely because they're simply completely oblivious to that fact).
If Apple reserves the right to remove all apps containing compiled Pascal code (or the Unity engine) from the AppStore at any time, I don't consider that "getting around it". It's just ignoring it and hoping you (and in particular your users) will be fine. The elephant remains in the room though.
The fact that I can't even discuss this on the iPhone developer forums without first signing the new developer agreement (and thereby make it illegal for me to continue working on that project) only adds insult to the injury.
You need to reread the developers agreement rather than going by what you read on some website. You're simply wrong on this one.
I have read and reread the agreement (I am a registered/paying iPhone developer after all, and I'm not letting this money go to waste just for the purpose of getting snarky replies on slashdot). I have also sent a message to ADC asking for clarification and did not get an answer other than the boilerplate "we have sent your comments to the appropriate department".
So please do enlighten me how an SDK agreement that states the following explicitly allows anyone to use it for compiling programs not originally written in any of the sanctioned languages (emphases and square brackets comments mine):
1.1 Acceptance
In order to use the Apple Software [i.e., the SDK] and related services, You must first agree to this License Agreement.
3.3 Program Requirements for Applications
Any Application developed using this Apple Software must meet all of the following criteria and requirements, as they may be modified by Apple from time to time:
3.3.1. [...] Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine
Our compiler is self-hosting, but it makes use of the SDK's assembler and linker to create object files and binaries, and the apps it produces obviously link against the SDK's libraries.
I'm sorry to hear that. I use FPC for my 'amusement' coding quite a bit, having been a huge TP fan back in the 80s and early 90s. FPC is some fun stuff.
Glad to hear that:)
Incidentally, the whole C++ library name hashing issue (that was my understanding of the issue), that prevented use of things like wxWidgets with FPC appears to have been conquered at some level. Or am I interpreting the Obj-C interface wrong?
C++ and Objective-C are quite different beasts. The main problem with interfacing with C++ is that there are about as many C++ ABIs as there are C++ compilers (and then some, since a C++ ABI can change when a new version of a C++ compiler comes out). This concerns name mangling, but also VMT layouts, exception handling, etc. In general, you cannot even use C++ code compiled by different compilers together. A person has been working lately on adding support for the current G++ ABI to FPC though, and simple class importing and (non-virtual) method calling already works.
For Objective-C, there are basically only two ABIs: NeXTStep/Apple's and GNUStep's. Currently, we only support Apple's (we do support it on all Mac OS X platforms though, both past and present). And we also created an Objective-Pascal dialect around it.
It makes plenty of sense if you don't assume that the iPhone will always have same CPU architecture.
And if you assume that contemporary compiler technology is adequate to squeeze all necessary performance out of high level code even when running heavy-duty code on embedded devices. If they just want to guarantee easy portability of the engine to new architectures, then a) they should also mandata that all code is written in an endian-neutral way b) they could also mandate that for each bit of assembler, you must also write and include in your source code an equivalent high level version
The above would look absurd in an SDK agreement, but frankly I don't see how it a) essentially differs from what Apple is mandating right now b) how it would not achieve the same things that Apple uses to justify for these restrictions (namely improving their freedom to innovate)
The developer agreement does not make it illegal for someone to work on other projects. It doesn't even make it illegal for you to install Pascal apps on your iPhone. It does mean that Apple won't approve Pascal apps on the iPhone, and you won't get them into the app store. But you are being a bit hysterical to think that joining the developer program in any way affects what else you do.
The new agreement forbids using the SDK to compile programs that are not originally written in any of the approved languages:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
(emphasis mine). Of course, Apple cannot check what I do if I don't submit any apps to the AppStore, but I would definitely be in violation with the new SDK agreement if I first agreed to the new terms and then continued compiling and running Pascal programs on my iPod.
If you're generating arm assembly, can't you just dump that to C file and wrap it using the GCC inline keyword?
Unfortunately, the SDK agreement explicitly says that the code must be originally written in one of the approved languages (C, C++, Objective-C). And yes, technically this means that any use of inline assembler is forbidden (e.g. to optimize part of a 3D engine, even the rest is completely written in C), which does not make any sense whatsoever either.
Apple's new terms forbid applications written in any language that is not called C, C++ or Objective-C. For example, I work on the Free Pascal Compiler and added iPhone support a couple of years ago (it compiles straight to ARM assembler, no intermediate code or frameworks are involved). Most people that use it write their GUI in Objective-C and reuse Delphi or other existing Pascal code for their backend, just like other people would reuse C or C++ code.
But simply because FPC stands for Free Pascal Compiler rather than for Fast Progressive C, this way of working is no longer allowed. That just does not make any sense to me. Why on earth would the name of the programming language matter in any way? I could understand it if they would limit you to using their tool chain (although I'd still disagree with it), but limiting to a particular set of programming languages?
The fact that I can't even discuss this on the iPhone developer forums without first signing the new developer agreement (and thereby make it illegal for me to continue working on that project) only adds insult to the injury.
The scary part is that the parent is modded insightful instead of funny. There are many documented cases of the CIA, NSA, US Department of Commerce and other US entities (both governmental and non-governmental) committing industrial espionage in various forms (breaking into networks, tapping into video conferences, phone tapping, planting microphones and cameras,...). See e.g. the list under "Published cases" in the Echelon report by the European Parliament.
So please stop acting like Virgin Mary already, it doesn't become you.
Given that apparently no such reactor has been actually used for power production, at best it might be a safe alternative. In case you forgot, they also claimed that reprocessing plants were safe (and for many years denied that the leukaemia cases had anything to do with the plants).
TFA also says that there were concerns about the safety and quality of research done (in the "history" section near the end. Regardless of the veracity of these claims, the conflicts of interests that are described there seem pretty clear cut.
And of course there's still waste afterwards. It's less than with traditional plants and it's "only" highly radioactive for 200 - 400 years (as opposed to 10,000), but that's still a long time and even low-grade radioactive waste is dangerous (again, see e.g. La Hague & Sellafield).
And after that, you have to enrich the output from the fast-breeder reactor in a reprocessing plant before it is usable again in a regular nuclear power plant. Unfortunately, these reprocessing plants dump large amounts of low-radioactive waste in the environment both via water and air. As a result the childhood leukaemia cases around La Hague and Sellafield are much higher than in other places in Europe.
"I don't understand what the hell this all means" is not the same as "detailed".
Infringement would require some effort; anticipation (every limitation appearing in a single document, arranged in the same manner as the claim) is unlikely.
Which part of the claim exactly distinguishes it from how pretty much the every parallelised map-reduce framework probably works? I don't see it.
I do (iPod Touch). Initially mainly from Baen/Webscription.net, nowadays also a lot from Project Gutenberg. It's mainly a lot easier to carry around than library books. I basically stopped going to the public library since I started reading this way.
Do you carry around one of those magnifying screens from "Brazil"?
Actually, it works surprisingly well for me (I'm 30). A colleague of mine, who's in his early fifties, can't read the text without scaling it to the point where you have so little text on a screen that it becomes useless though.
The natural world may only be approximated using a mathematical framework (at least at present), but the devices that we create based on that knowledge is a direct application of the mathematical models.
No, they are a direct application of the laws of physics (and its manifestation in chemistry, biology,...). These laws and their applications are described by mathematical models because those are a lot more efficient to work with (and to automate) than equivalent natural language descriptions, but the underlying novel insights are based on experimentation in the real world, not regarding maths (maths are just used to describe/generalise the observations from said experiments).
So say you have an algorithm, and claim that it is nothing more than math. You can implement that algorithm in a programming language, convert it to machine language for a general purpose processor, implement it as a giant logic table in an FPGA, implement it using TTL logic circuits, or make a custom ASIC of the same logic. Many algorithms, such as signal processing, can be implemented to within a desired precision with either digital or analog filters. There are also mechanical implementations of the same ideas - mechanical calculators are obvious, but even simple things like automatic valves may be more robust in for certain applications than converting to the electronic/digital realm and back again. At what point do you draw the line and say that it is no longer just a mathematical algorithm?
There are definitely grey areas and there is no way to draw a 100% clear line (even if you don't consider the issue of software patents at all; it's simply the nature of civil law), but as far as I am concerned the cases that you mention are not necessarily hard to classify.
Whether you implement an algorithm in software or in an ASIC or in an analog filter should be irrelevant. If your contribution only lies in the algorithm, then this is what should be considered for testing the patentability requirements. If you also contribute a completely novel way of building an ASIC or an analog filter, then you'd be crazy to only claim that novel hardware in combination with a particular algorithm rather than the hardware on its own (since the latter would cover any usage).
Conversely, if you figure out that you need 2 parts of Pb and 3 parts of Na to make 2 parts of Au, the fact that you can express this using a mathematical formula does not render this knowledge unpatentable (just like describing it in English does not render it unpatentable, even though text cannot be patented -- what you are patenting is not the description, but what is described). And performing this chemical reaction under control of a computer program would not render this process non-infringing simply because the basic knowledge is described in the form of a computer program and applied under computer-control.
There are other examples, such as the psycho-acoustic model used by MP3 compression. While MP3 compression is usually implemented completely in software and a psycho-acoustic model is a mathematical model, this model is based on new knowledge about the physical world and hence a patent on that would not necessarily be a math patent (of course, there are other problems that pop up in this case, such as interoperability/network effects).
Another example is anti-lock braking: it's virtually always performed under software control, but the actual invention is that by measuring the heat caused by the friction between the wheel and the brake you can determine whether you are skidding or not (and again, whether you perform this process via software, hardware or anything else is irrelevant as to whether or not it infringes, as long as the patent claims are drafted properly).
You don't seem to understand the Curry-Howard correspondence.
You don't seem to understand that I was only pointing that forbidding patents on math does not automatically remove all science fields mentioned in the XKCD comic from patentability, in order to defang the argument that opposing software patents because they are math patents is equivalent to opposing patents on anything, because all sciences are supposedly math.
I did not say or even intend to imply that software isn't math. Just google for my name (from my email address) in combination with "software patents" and you'll see that I would be one of the last people in the world to advocate software patentability.
Well, that or you intended to reply to the GP instead of to me.
No. We can describe/approximate almost all sciences using math, just like we can describe them using English or any other language. That does not mean that everything is math or linguistics.
So, the question, as always is where does one draw the line. There is no reason to throw the baby out with the bathwater.
Finally, I'll note that only the tiniest minority of patents ever see the light of day. Most collect dust on someone's shelf.
And all money invested in drafting those patents, applying for them, reviewing them and renewing them is a massive waste of both private and government resources that could have been spent on actually useful stuff.
When the FFII asked the EU Council of Ministers for opening up the documents regarding the ACTA negotiations, the Council refused, with (a.o.) the argument that this "might affect relations with the third parties concerned".
So the US can't release it because others might object, and the EU can't for the same reason. Inquiring minds want to know which mysterious third country is kicking both the US and the EU into submission. Canada?
The choice of implementation for computer functions is a pure economic choice which mainly has to do with cost, speed, and flexibility.
That's absolutely correct. And the reason that people choose software when they can get away with it, is because it generally much cheaper, faster to implement and more flexible. Which in turn results in completely economic effects of patent claims that include software implementations compared to claims that only cover hardware implementations.
The whole argument about software companies also performing state-of-the-art R&D should be irrelevant from a patents-point-of-view. Patents are not a natural right (they're not awarded because someone deserves them for whatever reason), but they are purely economic tools. And blunt and wide-reaching ones at that. Applying blunt and wide-reaching tools without discrimination just because some things are alike in terms of intellectual achievement does not necessarily have the same economic effects. Again: patents are not rewards, they're tools, to be applied with care where it makes macro-economic sense, not to protect certain business models at the cost of a huge overhead for an entire sector of industry.
And according to various economic studies (also includes citations from some political documents, feel free to ignore those), patents indeed don't have overall positive effects on in the software field. In fact, the 2003 report on innovation from the FTC came to the conclusion that patents are not very important to innovation in the semiconductor industry either (although slightly more so than in case of software, and their downsides are slightly less detrimental in that case). So the whole comparison with hardware and software does not necessarily lead to the conclusion that the author of the article envisions...
I think you are confusing the Commission with the Council of Ministers. The Commission is completely unelected.
The Council of Ministers, as the name says, consists of ministers from the member states' governments. These ministers differ depending on the topic that's being discussed, but they're always ministers.
So unless your ministers are unelected (depending on the country either directly or indirectly), it's not really correct to describe them as "an unelected body of the usual group of money-grabbing power-hungry and our of touch morons who do whatever you want if you've got the cash."
That said, it is true that the Council is used a lot by member states to launder legislation that they would never even dare to propose in their own country. Later on they will then claim at home that they are obliged "by Europe" to implement these unpopular measures nationally, while they themselves are the reason that "Europe" does so.
The Lisbon Treaty also has a downside in this respect in that it makes many decisions require less stringent majorities (or a majority rather than unanimity). The result is that it takes more countries to oppose bad proposals, and generally that delegations will be less likely to even try to oppose something, because this costs political capital and there is less chance to win anyway.
They never did that for the "Bush chimp" pictures.
They probably didn't it for the Michelle Obama picture either. If you read the FA, it says that they couldn't reach Google for comment.
Meanwhile, this article from yesterday says that the blog which hosted the picture simply removed the it, and that Google subsequently started updating its search index. Hence, it no longer lists that picture among its top results, since no other top-ranked site has that image.
The distortion by LCD's not running at their resolution are way worse than that. Hell, we even got a bug report from someone about our graph unit supposedly being buggy because text rendered in full screen mode was illegible, while the only problem was that he was using an 800x600 resolution on an LCD monitor with a different native size.
If you download the attachment to that bug report and unzip it, there's a picture of the screen inside. And in fact, it does look quite bad. Of course, there's nothing that we can do about that.
Slashdot Mirror
On the one hand, Java uses pretty much the same object model as Pascal/Delphi (single inheritance, interfaces). On the other hand, unlike in Java you can program at the same low level in Pascal/Delphi as in C if you want to (yes, Pascal/Delphi has pointers, and you can also do pointer arithmetic if you want to). So I'd disagree with your claim that none of the allowed languages allow low-level programming.
why don't you see how the others got around it. Flash is out, but there are others that Apple has approved. /me looks at Unity ...
Can you point me to a statement from Apple to that effect? All I could find is a blog post from the Unity people saying that they think they are fine because Apple can't afford to pull all apps using their engine from the AppStore. That's not really a solid basis to work with. FWIW, they haven't done that either with apps containing Pascal code (most likely because they're simply completely oblivious to that fact).
If Apple reserves the right to remove all apps containing compiled Pascal code (or the Unity engine) from the AppStore at any time, I don't consider that "getting around it". It's just ignoring it and hoping you (and in particular your users) will be fine. The elephant remains in the room though.
You need to reread the developers agreement rather than going by what you read on some website. You're simply wrong on this one.
I have read and reread the agreement (I am a registered/paying iPhone developer after all, and I'm not letting this money go to waste just for the purpose of getting snarky replies on slashdot). I have also sent a message to ADC asking for clarification and did not get an answer other than the boilerplate "we have sent your comments to the appropriate department".
So please do enlighten me how an SDK agreement that states the following explicitly allows anyone to use it for compiling programs not originally written in any of the sanctioned languages (emphases and square brackets comments mine):
1.1 Acceptance
In order to use the Apple Software [i.e., the SDK] and related services, You must first agree to this License Agreement.
3.3 Program Requirements for Applications
Any Application developed using this Apple Software must meet all of the following criteria and requirements, as they may be modified by Apple from time to time:
3.3.1. [...] Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine
Our compiler is self-hosting, but it makes use of the SDK's assembler and linker to create object files and binaries, and the apps it produces obviously link against the SDK's libraries.
I'm sorry to hear that. I use FPC for my 'amusement' coding quite a bit, having been a huge TP fan back in the 80s and early 90s. FPC is some fun stuff.
Glad to hear that :)
Incidentally, the whole C++ library name hashing issue (that was my understanding of the issue), that prevented use of things like wxWidgets with FPC appears to have been conquered at some level. Or am I interpreting the Obj-C interface wrong?
C++ and Objective-C are quite different beasts. The main problem with interfacing with C++ is that there are about as many C++ ABIs as there are C++ compilers (and then some, since a C++ ABI can change when a new version of a C++ compiler comes out). This concerns name mangling, but also VMT layouts, exception handling, etc. In general, you cannot even use C++ code compiled by different compilers together. A person has been working lately on adding support for the current G++ ABI to FPC though, and simple class importing and (non-virtual) method calling already works.
For Objective-C, there are basically only two ABIs: NeXTStep/Apple's and GNUStep's. Currently, we only support Apple's (we do support it on all Mac OS X platforms though, both past and present). And we also created an Objective-Pascal dialect around it.
It makes plenty of sense if you don't assume that the iPhone will always have same CPU architecture.
And if you assume that contemporary compiler technology is adequate to squeeze all necessary performance out of high level code even when running heavy-duty code on embedded devices. If they just want to guarantee easy portability of the engine to new architectures, then
a) they should also mandata that all code is written in an endian-neutral way
b) they could also mandate that for each bit of assembler, you must also write and include in your source code an equivalent high level version
The above would look absurd in an SDK agreement, but frankly I don't see how it
a) essentially differs from what Apple is mandating right now
b) how it would not achieve the same things that Apple uses to justify for these restrictions (namely improving their freedom to innovate)
The developer agreement does not make it illegal for someone to work on other projects. It doesn't even make it illegal for you to install Pascal apps on your iPhone. It does mean that Apple won't approve Pascal apps on the iPhone, and you won't get them into the app store. But you are being a bit hysterical to think that joining the developer program in any way affects what else you do.
The new agreement forbids using the SDK to compile programs that are not originally written in any of the approved languages:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
(emphasis mine). Of course, Apple cannot check what I do if I don't submit any apps to the AppStore, but I would definitely be in violation with the new SDK agreement if I first agreed to the new terms and then continued compiling and running Pascal programs on my iPod.
If you're generating arm assembly, can't you just dump that to C file and wrap it using the GCC inline keyword?
Unfortunately, the SDK agreement explicitly says that the code must be originally written in one of the approved languages (C, C++, Objective-C). And yes, technically this means that any use of inline assembler is forbidden (e.g. to optimize part of a 3D engine, even the rest is completely written in C), which does not make any sense whatsoever either.
Apple's new terms forbid applications written in any language that is not called C, C++ or Objective-C. For example, I work on the Free Pascal Compiler and added iPhone support a couple of years ago (it compiles straight to ARM assembler, no intermediate code or frameworks are involved). Most people that use it write their GUI in Objective-C and reuse Delphi or other existing Pascal code for their backend, just like other people would reuse C or C++ code.
But simply because FPC stands for Free Pascal Compiler rather than for Fast Progressive C, this way of working is no longer allowed. That just does not make any sense to me. Why on earth would the name of the programming language matter in any way? I could understand it if they would limit you to using their tool chain (although I'd still disagree with it), but limiting to a particular set of programming languages?
The fact that I can't even discuss this on the iPhone developer forums without first signing the new developer agreement (and thereby make it illegal for me to continue working on that project) only adds insult to the injury.
With everyone saying ARM is so efficient how are we to know that Google is not investing in ARM to make more energy efficient ARM based servers?
It's definitely a market that ARM itself is also targeting: ftp://ftp.cordis.europa.eu/pub/fp7/ict/docs/computing/arm-emre-ozer_en.pdf (see e.g. the EuroCloud project mentioned on slide 3)
Also, those cars have very strong fronts, because they don't take damage from there too.
They're made of black boxes from old airplanes.
The scary part is that the parent is modded insightful instead of funny. There are many documented cases of the CIA, NSA, US Department of Commerce and other US entities (both governmental and non-governmental) committing industrial espionage in various forms (breaking into networks, tapping into video conferences, phone tapping, planting microphones and cameras, ...). See e.g. the list under "Published cases" in the Echelon report by the European Parliament.
So please stop acting like Virgin Mary already, it doesn't become you.
You do not necessarily need to reprocess fuel in large plants if you use http://en.wikipedia.org/wiki/Integral_Fast_Reactor for example.
So there are alternatives, and pretty safe ones.
Given that apparently no such reactor has been actually used for power production, at best it might be a safe alternative. In case you forgot, they also claimed that reprocessing plants were safe (and for many years denied that the leukaemia cases had anything to do with the plants).
TFA also says that there were concerns about the safety and quality of research done (in the "history" section near the end. Regardless of the veracity of these claims, the conflicts of interests that are described there seem pretty clear cut.
And of course there's still waste afterwards. It's less than with traditional plants and it's "only" highly radioactive for 200 - 400 years (as opposed to 10,000), but that's still a long time and even low-grade radioactive waste is dangerous (again, see e.g. La Hague & Sellafield).
You put the waste into a fast-breeder reactor.
And after that, you have to enrich the output from the fast-breeder reactor in a reprocessing plant before it is usable again in a regular nuclear power plant. Unfortunately, these reprocessing plants dump large amounts of low-radioactive waste in the environment both via water and air. As a result the childhood leukaemia cases around La Hague and Sellafield are much higher than in other places in Europe.
That's one heck of a detailed claim.
"I don't understand what the hell this all means" is not the same as "detailed".
Infringement would require some effort; anticipation (every limitation appearing in a single document, arranged in the same manner as the claim) is unlikely.
Which part of the claim exactly distinguishes it from how pretty much the every parallelised map-reduce framework probably works? I don't see it.
Who reads a book on an iPod or phone?! Seriously?
I do (iPod Touch). Initially mainly from Baen/Webscription.net, nowadays also a lot from Project Gutenberg. It's mainly a lot easier to carry around than library books. I basically stopped going to the public library since I started reading this way.
Do you carry around one of those magnifying screens from "Brazil"?
Actually, it works surprisingly well for me (I'm 30). A colleague of mine, who's in his early fifties, can't read the text without scaling it to the point where you have so little text on a screen that it becomes useless though.
The natural world may only be approximated using a mathematical framework (at least at present), but the devices that we create based on that knowledge is a direct application of the mathematical models.
No, they are a direct application of the laws of physics (and its manifestation in chemistry, biology, ...). These laws and their applications are described by mathematical models because those are a lot more efficient to work with (and to automate) than equivalent natural language descriptions, but the underlying novel insights are based on experimentation in the real world, not regarding maths (maths are just used to describe/generalise the observations from said experiments).
So say you have an algorithm, and claim that it is nothing more than math. You can implement that algorithm in a programming language, convert it to machine language for a general purpose processor, implement it as a giant logic table in an FPGA, implement it using TTL logic circuits, or make a custom ASIC of the same logic. Many algorithms, such as signal processing, can be implemented to within a desired precision with either digital or analog filters. There are also mechanical implementations of the same ideas - mechanical calculators are obvious, but even simple things like automatic valves may be more robust in for certain applications than converting to the electronic/digital realm and back again. At what point do you draw the line and say that it is no longer just a mathematical algorithm?
There are definitely grey areas and there is no way to draw a 100% clear line (even if you don't consider the issue of software patents at all; it's simply the nature of civil law), but as far as I am concerned the cases that you mention are not necessarily hard to classify.
Whether you implement an algorithm in software or in an ASIC or in an analog filter should be irrelevant. If your contribution only lies in the algorithm, then this is what should be considered for testing the patentability requirements. If you also contribute a completely novel way of building an ASIC or an analog filter, then you'd be crazy to only claim that novel hardware in combination with a particular algorithm rather than the hardware on its own (since the latter would cover any usage).
Conversely, if you figure out that you need 2 parts of Pb and 3 parts of Na to make 2 parts of Au, the fact that you can express this using a mathematical formula does not render this knowledge unpatentable (just like describing it in English does not render it unpatentable, even though text cannot be patented -- what you are patenting is not the description, but what is described). And performing this chemical reaction under control of a computer program would not render this process non-infringing simply because the basic knowledge is described in the form of a computer program and applied under computer-control.
There are other examples, such as the psycho-acoustic model used by MP3 compression. While MP3 compression is usually implemented completely in software and a psycho-acoustic model is a mathematical model, this model is based on new knowledge about the physical world and hence a patent on that would not necessarily be a math patent (of course, there are other problems that pop up in this case, such as interoperability/network effects).
Another example is anti-lock braking: it's virtually always performed under software control, but the actual invention is that by measuring the heat caused by the friction between the wheel and the brake you can determine whether you are skidding or not (and again, whether you perform this process via software, hardware or anything else is irrelevant as to whether or not it infringes, as long as the patent claims are drafted properly).
You don't seem to understand the Curry-Howard correspondence.
You don't seem to understand that I was only pointing that forbidding patents on math does not automatically remove all science fields mentioned in the XKCD comic from patentability, in order to defang the argument that opposing software patents because they are math patents is equivalent to opposing patents on anything, because all sciences are supposedly math.
I did not say or even intend to imply that software isn't math. Just google for my name (from my email address) in combination with "software patents" and you'll see that I would be one of the last people in the world to advocate software patentability.
Well, that or you intended to reply to the GP instead of to me.
As eloquently illustrated here: http://xkcd.com/435/, everything is math.
No. We can describe/approximate almost all sciences using math, just like we can describe them using English or any other language. That does not mean that everything is math or linguistics.
So, the question, as always is where does one draw the line. There is no reason to throw the baby out with the bathwater.
That baby already drowned ages ago.
government resources that could have been spent on actually useful stuff.
Where have you been?
In a world that's not ruled by Faux News.
Finally, I'll note that only the tiniest minority of patents ever see the light of day. Most collect dust on someone's shelf.
And all money invested in drafting those patents, applying for them, reviewing them and renewing them is a massive waste of both private and government resources that could have been spent on actually useful stuff.
When the FFII asked the EU Council of Ministers for opening up the documents regarding the ACTA negotiations, the Council refused, with (a.o.) the argument that this "might affect relations with the third parties concerned".
So the US can't release it because others might object, and the EU can't for the same reason. Inquiring minds want to know which mysterious third country is kicking both the US and the EU into submission. Canada?
The choice of implementation for computer functions is a pure economic choice which mainly has to do with cost, speed, and flexibility.
That's absolutely correct. And the reason that people choose software when they can get away with it, is because it generally much cheaper, faster to implement and more flexible. Which in turn results in completely economic effects of patent claims that include software implementations compared to claims that only cover hardware implementations.
The whole argument about software companies also performing state-of-the-art R&D should be irrelevant from a patents-point-of-view. Patents are not a natural right (they're not awarded because someone deserves them for whatever reason), but they are purely economic tools. And blunt and wide-reaching ones at that. Applying blunt and wide-reaching tools without discrimination just because some things are alike in terms of intellectual achievement does not necessarily have the same economic effects. Again: patents are not rewards, they're tools, to be applied with care where it makes macro-economic sense, not to protect certain business models at the cost of a huge overhead for an entire sector of industry.
And according to various economic studies (also includes citations from some political documents, feel free to ignore those), patents indeed don't have overall positive effects on in the software field. In fact, the 2003 report on innovation from the FTC came to the conclusion that patents are not very important to innovation in the semiconductor industry either (although slightly more so than in case of software, and their downsides are slightly less detrimental in that case). So the whole comparison with hardware and software does not necessarily lead to the conclusion that the author of the article envisions...
I think you are confusing the Commission with the Council of Ministers. The Commission is completely unelected.
The Council of Ministers, as the name says, consists of ministers from the member states' governments. These ministers differ depending on the topic that's being discussed, but they're always ministers.
So unless your ministers are unelected (depending on the country either directly or indirectly), it's not really correct to describe them as "an unelected body of the usual group of money-grabbing power-hungry and our of touch morons who do whatever you want if you've got the cash."
That said, it is true that the Council is used a lot by member states to launder legislation that they would never even dare to propose in their own country. Later on they will then claim at home that they are obliged "by Europe" to implement these unpopular measures nationally, while they themselves are the reason that "Europe" does so.
The Lisbon Treaty also has a downside in this respect in that it makes many decisions require less stringent majorities (or a majority rather than unanimity). The result is that it takes more countries to oppose bad proposals, and generally that delegations will be less likely to even try to oppose something, because this costs political capital and there is less chance to win anyway.
They never did that for the "Bush chimp" pictures.
They probably didn't it for the Michelle Obama picture either. If you read the FA, it says that they couldn't reach Google for comment.
Meanwhile, this article from yesterday says that the blog which hosted the picture simply removed the it, and that Google subsequently started updating its search index. Hence, it no longer lists that picture among its top results, since no other top-ranked site has that image.
I.o.w.: nothing to see here, move along now.
They got a design patent. That's something complete different from a regular patent.
The distortion by LCD's not running at their resolution are way worse than that. Hell, we even got a bug report from someone about our graph unit supposedly being buggy because text rendered in full screen mode was illegible, while the only problem was that he was using an 800x600 resolution on an LCD monitor with a different native size.
If you download the attachment to that bug report and unzip it, there's a picture of the screen inside. And in fact, it does look quite bad. Of course, there's nothing that we can do about that.