It's mainly a good opportunity to correct some sensationalist misreporting:
A written declaration is just that: a declaration. It's not a legislative proposal and has no legislative value. So the title "EU To Monitor All Internet Searches" is complete bullshit. If it is adopted, at most it can be used to remind MEPs later on that they supported this text, and hence should support legislative proposals in the same vein. However...
... as TFA explains, MEPs (Members of the European Parliament) have been misled into signing it, because the statement that "data retention should be extended to search engine queries" is hidden in the text. "Data retention" is not mentioned, it just says, amongst many other statements, "implement Directive 2006/24/EC and extend it to search engines in order to tackle online child pornography and sex offending rapidly and effectively". There are tons of directives and most MEPs won't have looked up what this specific directive is.
Since MEPs have been mostly misled into signing onto that particular statement, it is quite unlikely to have any clout if cited back at them later on. If someone tricked you into signing a declaration containing stuff you don't support, you'd probably not be very motivated to strongly care about it later on either. In that sense, overblowing the whole thing like in this Slashdot summary is completely counterproductive, because you give the MEPs signature more weight and make them actually more bound to it then they would be otherwise!
Christian Engström's blog post (TFA), where he explains how MEPs are misled, is good because it can help getting rid of the declaration altogether by exposing it for the deceit that it is.
This summary on the other hand is just a bunch of misinformation that will cause a lot of misguided mails to be sent. It might also raise awareness and cause MEPs to withdraw their signatures, but it will probably cause at least as many MEPs to disregard the complaints because it will be clear that people sending a mail don't know what the hell they are talking about.
Yes, you cannot just copy the rulebook and include it with your game (nor plagiarise it).
However, that does not mean that another game that follows those exact same rules infringes on the copyright of the former. It's only the expression of the rules that is copyrighted (both in the form of the manual and the game itself), not the rules themselves.
Hence, my original answer still stands: no, gameplay cannot be copyrighted.
If I'm not mistaken, that's an article about board games.
The first paragraph on the linked page is about games in general. Every definition of copyrightable matter I've ever seen also always mention that only the *expression* and not the underlying idea can ever be copyrightable. It's simply one of the fundamental properties of copyright. There's also a UK Court of Appeals ruling confirming that specifically for computer games.
Not sure how video games translate into that, and how that interacts with the DMCA, which covers... Digital... Media... Copyrights...
The DMCA is about the enforcement of copyright. Afaik, it does not extend the scope of what is copyrightable. Computer programs (including games) have been copyrightable since long before the DMCA came into existence.
You believe that gameplay can't be copyrighted. You cherry picked some unnamed and unknown sites that support your believe about gameplay and copyright.
One web search shows as the first hit a nice page from the US Copyright Office that demonstrates he's right. And that's not specific to the US (left as a web search exercise to the reader).
In all fairness, we still have no idea what went wrong. I want BP to be dragged across the coals for this as much as the next guy, but the truth of the matter is that we still don't know why the BOP failed, given that it was designed and certified to protect against this very sort of disaster.
There's at least one survivor who claims that the BOP was punctured weeks before the blast, but that they were pressured in continuing operations regardless because they were running behind schedule and "time is money".
Bummer, so instead of HyperCard Developer, they're peddling HyperCard Player for the iPad?
More like an application to export HyperCard (RunRev) stacks into native iPhone apps.
I don't think a HyperCard player for the iPad is all that interesting (or worthwhile)
At least the people behind one large deployment of iPads in education believe otherwise. I'm also not sure why developing iPhone/iPad apps in a hypertalk-based environment would be less worthwhile than developing them in Objective-C++.
what i want is HyperCard Developer on the iPad --- let's use the thing for actual computing and processing, not just for consumption.
Since Apple forbids interpreting code, JIT compilers, and launching external processes on the iP*, something like that would be even harder to pull off without running afoul of the SDK rules (even with Objective-C that would not be possible).
Stack smashing and buffer over/underruns aren't features, they're *bugs*
So that's why Apple only allows C-based languages for native app development in its new SDK agreement and forbids more highlevel/sandboxed programming environments such as the revTalk language mentioned in the article.
Their product is a development environment to create applications written in a language called revTalk. What the development environment is written in does not really matter, since it probably will run on a Mac or PC rather than on an iPhone or iPad (and it is probably written in C or C++, both of which are "allowed" languages).
What RevRun did was proposing to modify this revTalk language as offered in their revMobile product (removing its cross-platform nature, directly exposing the iPhoneOS APIs, and anything else Apple could want) to make it acceptable to Apple for developing AppStore apps with it.
RevRun did so based on the facts that a) the source language requirement is very new and was introduced after they already had sunk a lot of money into the development of this tool (and there was no hint in previous SDK agreements or even in previous Apple behaviour that the name of the source code language would ever matter in any way) b) Jobs, in all of his defences of the introduction of this measure, has been focussing on how these limitations are required to enable developers to always immediately take advantage of new features and not to be hampered by middleware. So a lot of people (both pro- and anti-Apple) had the impression that the source language condition may not be enforced as stringently if you address these concerns in your development environment (which turns out not to be necessarily the case)
How seriously? I asked them for XCode export during beta and the response was No. The reason being is that it would have broken everything. They basically implemented their own byte code, and shoehorned on LLVM to run it on the fly. It's the reason they got up and running so quick on Android. They basically created their own virtual machine.
No, they used LLVM as a code generator to compile ActionScript into a native ARM binary at product build time. It's just like llvm-gcc, which is shipped by Apple and which you can use from Xcode to build iPhone apps, does not run anything on the fly, but also compiles C/C++/Objective-C straight to machine code when you build your product. The LLVM code generator doesn't care whether a program is originally written in ActionScript or Objective-C. It's only Apple's SDK agreement that does.
I know that the type of analysis that Apple does on the apps, and I know that they can see these static libraries in their apps. I have never had an issue. (I have had issues with them with some even less visible things, down to function calls. I know if they can see the function calls I'm making, they know I'm including static libs.)
They don't. If you call an SDK function, this function is imported via a named symbol. It is trivial to figure out which functions from the SDK you call.
If you use a static library, the linker will simply take the objects from which you reference symbols from that library and add those to your program just like any other program. There is absolutely no way for Apple or anyone else to know that you are using a static library (that's why I mentioned dynamic libraries in my previous post, because with those you can see that a library is used). Especially if you strip symbols (which is the default for distribution builds), there's nothing left that hints at the existence of a static library (except if the library is written in Objective-C, but that's unlikely for a cross-platform library).
Apple is ok with abstraction libraries as long as developers can opt out of that abstraction when they wish in order to support specific new features that might ship with new OS's, or even current features of their choosing.
Please read the article linked in the story's summary. They proposed to Apple to retool their development environment so that it would directly expose the entire iPhone OS API from their development environment. In fact, they offered to do pretty much anything that would be required to get their dev environment approved. The final result was "Steve Jobs has now rejected our proposal and made it clear that he has no interest in having revMobile available on the iPhone or iPad in any form." Note those last two words.
And please actually read the iPhone SDK agreement, in particular Section 3.3. That's what people have to take into account. Your interpretation may be sensible, but that does not help when you are dealing with legal agreements.
There are plenty of abstraction libraries totally supported on the iPhone.
Again: "supported" does not mean "in compliance with the new SDK agreement".
If Flash was just implemented as a library people could use in their apps, there likely wouldn't be much of a problem (especially if there was a swf -> Obj C preprocessor.)
Again: please read the SDK agreement. What you are saying things is in direct contradiction with what that agreement says. I'm going to take Apple's word over yours (even though they reserve to the right to unilaterally change it at any time, so it's not really worth anything).
Please read the article linked from the summary. Really. They proposed to Apple to rewrite their development so that it would no longer be able to create cross-platform apps, so that all iPhone OS API's would be directly exposed, etc. It didn't matter.
I know because I write cross platform static libraries for the iPhone/Mac/Windows and have never had an issue.
And I know people who have written and submitted apps in Pascal, compiled with a third-party compiler (that I ported) and never had an issue either. That does not mean that what they are doing is not in violation of the new SDK agreement, even though Apple would have to do quite a bit of work to automatically detect such apps.
In fact, Apple even has a iPhone static library template built into the SDK.
Static libraries are totally allowed on the iPhone. Cross platform static libraries are allowed.
Of course static libraries are allowed (they're just a collection of object files after all, so it wouldn't make any sense to forbid them -- and moreover, static libraries are the only kind of libraries you can write yourself, since you cannot include self-written dynamic libraries in an iPhone app), but cross-platform layers (in library or any other form) that call any iPhone SDK APIs are no longer allowed by the new SDK agreement.
That said, will Apple be able to detect that you use such a library? Probably not unless you start shouting it from the rooftops. Are you nevertheless violating the new SDK agreement? Probably, yes. Should you care? As an individual developer probably not. Should a company that intends to offer such a framework to other developers care? Probably yes, because if they get called out all of their customers are also in the cold.
Everything that has gotten approved so far uses XCode as a build step. You don't necessarily have to do all your development work in XCode (i.e. Unity game engine),
Where have you seen that Unity has been approved by Apple? All I've seen is the Unity people saying "we think we're fine because Apple can't afford to remove all apps on the appstore that have been built with our engine, but obviously we can't offer any guarantees".
Cross compile to an XCode project with things like static libraries for your runtime and everything will be fine.
I'm not sure how you can interpret an SDK agreement stating, a.o.,
Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine
Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited
as
Applications can be originally written in any language as long as they are translated into an Xcode project and if your compatibility layer is linked in via a static library
This is not about an iPhone app, but about a development environment to create iPhone apps. The company contacted Apple after the SDK agreement changes to determine whether there was any way they could adapt it to the new requirements, and apparently got their final rejection notice from Steve Jobs (see the fine article).
What is more, people who learn with C often develop a control-freak attitude that hinders them in the adoption of such sensible things as e.g. garbage collectors.
While I agree with your other comments, in my experience (as a Pascal compiler developer) many Pascal programmers are just as control-freaky and hostile towards garbage collection and other things they perceive as "useless overhead that only helps stupid programmers". I don't agree with that point of view, but it is quite pervasive.
I don't know about you, but I always spend way more time on debugging than on typing code. If your programming speed is largely limited by how fast you can type in the code: respect!
We also checked out both options for our lab at the university. At that time (3 years back), a PS3 was EUR 600. The only way to get a "cell computer" was via IBM blades. The cheapest blade chassis *without any blade* cost $17,000. I don't remember the price of the individual blades. At that price point, I'm not sure whether using the Cell architecture is still price-efficient (which is presumably the reason why they went with it in the first place; at least it won't be because of how easy it is to program).
although I believe many versions, including Delphi, have implemented their non-standard extensions for this.
Delphi did introduce a lot of non-standard extensions to Pascal (and in fact, the way it implemented support for function pointers is different form the ANSI ISO way). Nowadays, Delphi-style Pascal is however one of the most popular variants around and sort of has evolved into a de facto standard.
I learned Pascal in the early 1980s, when the computer I had was an IBM PC with a 4.77 MHz CPU. I did a lot of programming in Turbo Pascal version 3, but I ended learning C because there were some operations I couldn't do with Turbo Pascal. After I learned C, I never felt the need to use Pascal anymore.
I also learned Pascal first, though it was in the 90's. I now also know both Pascal and C, but still prefer Pascal. Keep in mind that Delphi-style/Object Pascal is more than C. It's more like C with the addition of Java-style OOP.
If only one language is taught, then it should be C for anyone who expects to be a professional programmer, knowing C they can easily pick up any other procedural language. A programmer who doesn't know C is like a doctor who doesn't know anatomy.
I think you could say the same about Delphi-style Pascal. You can go as low level as in C there (and believe me, many people do, which is a pain if you develop a cross-platform Delphi-compatible compiler), and as a bonus you also learn an object model that's pretty much identical to Java's.
Slashdot Mirror
It's mainly a good opportunity to correct some sensationalist misreporting:
Since MEPs have been mostly misled into signing onto that particular statement, it is quite unlikely to have any clout if cited back at them later on. If someone tricked you into signing a declaration containing stuff you don't support, you'd probably not be very motivated to strongly care about it later on either. In that sense, overblowing the whole thing like in this Slashdot summary is completely counterproductive, because you give the MEPs signature more weight and make them actually more bound to it then they would be otherwise!
Christian Engström's blog post (TFA), where he explains how MEPs are misled, is good because it can help getting rid of the declaration altogether by exposing it for the deceit that it is.
This summary on the other hand is just a bunch of misinformation that will cause a lot of misguided mails to be sent. It might also raise awareness and cause MEPs to withdraw their signatures, but it will probably cause at least as many MEPs to disregard the complaints because it will be clear that people sending a mail don't know what the hell they are talking about.
The written rules can be copyrighted.
Yes, you cannot just copy the rulebook and include it with your game (nor plagiarise it).
However, that does not mean that another game that follows those exact same rules infringes on the copyright of the former. It's only the expression of the rules that is copyrighted (both in the form of the manual and the game itself), not the rules themselves.
Hence, my original answer still stands: no, gameplay cannot be copyrighted.
If you could copyright game play, I'd imagine the guys that wrote Wolfenstien3d would have more money than God right now.
Even without copyright on gameplay, John Carmack managed to get pretty close to that given that he has his own aerospace company :)
If I'm not mistaken, that's an article about board games.
The first paragraph on the linked page is about games in general. Every definition of copyrightable matter I've ever seen also always mention that only the *expression* and not the underlying idea can ever be copyrightable. It's simply one of the fundamental properties of copyright. There's also a UK Court of Appeals ruling confirming that specifically for computer games.
Not sure how video games translate into that, and how that interacts with the DMCA, which covers... Digital... Media... Copyrights...
The DMCA is about the enforcement of copyright. Afaik, it does not extend the scope of what is copyrightable. Computer programs (including games) have been copyrightable since long before the DMCA came into existence.
You believe that gameplay can't be copyrighted. You cherry picked some unnamed and unknown sites that support your believe about gameplay and copyright.
One web search shows as the first hit a nice page from the US Copyright Office that demonstrates he's right. And that's not specific to the US (left as a web search exercise to the reader).
In all fairness, we still have no idea what went wrong. I want BP to be dragged across the coals for this as much as the next guy, but the truth of the matter is that we still don't know why the BOP failed, given that it was designed and certified to protect against this very sort of disaster.
There's at least one survivor who claims that the BOP was punctured weeks before the blast, but that they were pressured in continuing operations regardless because they were running behind schedule and "time is money".
Bummer, so instead of HyperCard Developer, they're peddling HyperCard Player for the iPad?
More like an application to export HyperCard (RunRev) stacks into native iPhone apps.
I don't think a HyperCard player for the iPad is all that interesting (or worthwhile)
At least the people behind one large deployment of iPads in education believe otherwise. I'm also not sure why developing iPhone/iPad apps in a hypertalk-based environment would be less worthwhile than developing them in Objective-C++.
what i want is HyperCard Developer on the iPad --- let's use the thing for actual computing and processing, not just for consumption.
Since Apple forbids interpreting code, JIT compilers, and launching external processes on the iP*, something like that would be even harder to pull off without running afoul of the SDK rules (even with Objective-C that would not be possible).
Stack smashing and buffer over/underruns aren't features, they're *bugs*
So that's why Apple only allows C-based languages for native app development in its new SDK agreement and forbids more highlevel/sandboxed programming environments such as the revTalk language mentioned in the article.
Their product is a development environment to create applications written in a language called revTalk. What the development environment is written in does not really matter, since it probably will run on a Mac or PC rather than on an iPhone or iPad (and it is probably written in C or C++, both of which are "allowed" languages).
What RevRun did was proposing to modify this revTalk language as offered in their revMobile product (removing its cross-platform nature, directly exposing the iPhoneOS APIs, and anything else Apple could want) to make it acceptable to Apple for developing AppStore apps with it.
RevRun did so based on the facts that
a) the source language requirement is very new and was introduced after they already had sunk a lot of money into the development of this tool (and there was no hint in previous SDK agreements or even in previous Apple behaviour that the name of the source code language would ever matter in any way)
b) Jobs, in all of his defences of the introduction of this measure, has been focussing on how these limitations are required to enable developers to always immediately take advantage of new features and not to be hampered by middleware. So a lot of people (both pro- and anti-Apple) had the impression that the source language condition may not be enforced as stringently if you address these concerns in your development environment (which turns out not to be necessarily the case)
So would it be accurate to characterize your belief as you only care about things, and think they're bad, if they're illegal?
I guess his D&D characters are always lawful neutral :)
How seriously? I asked them for XCode export during beta and the response was No. The reason being is that it would have broken everything. They basically implemented their own byte code, and shoehorned on LLVM to run it on the fly. It's the reason they got up and running so quick on Android. They basically created their own virtual machine.
No, they used LLVM as a code generator to compile ActionScript into a native ARM binary at product build time. It's just like llvm-gcc, which is shipped by Apple and which you can use from Xcode to build iPhone apps, does not run anything on the fly, but also compiles C/C++/Objective-C straight to machine code when you build your product. The LLVM code generator doesn't care whether a program is originally written in ActionScript or Objective-C. It's only Apple's SDK agreement that does.
I know that the type of analysis that Apple does on the apps, and I know that they can see these static libraries in their apps. I have never had an issue. (I have had issues with them with some even less visible things, down to function calls. I know if they can see the function calls I'm making, they know I'm including static libs.)
They don't. If you call an SDK function, this function is imported via a named symbol. It is trivial to figure out which functions from the SDK you call.
If you use a static library, the linker will simply take the objects from which you reference symbols from that library and add those to your program just like any other program. There is absolutely no way for Apple or anyone else to know that you are using a static library (that's why I mentioned dynamic libraries in my previous post, because with those you can see that a library is used). Especially if you strip symbols (which is the default for distribution builds), there's nothing left that hints at the existence of a static library (except if the library is written in Objective-C, but that's unlikely for a cross-platform library).
Apple is ok with abstraction libraries as long as developers can opt out of that abstraction when they wish in order to support specific new features that might ship with new OS's, or even current features of their choosing.
Please read the article linked in the story's summary. They proposed to Apple to retool their development environment so that it would directly expose the entire iPhone OS API from their development environment. In fact, they offered to do pretty much anything that would be required to get their dev environment approved. The final result was "Steve Jobs has now rejected our proposal and made it clear that he has no interest in having revMobile available on the iPhone or iPad in any form." Note those last two words.
And please actually read the iPhone SDK agreement, in particular Section 3.3. That's what people have to take into account. Your interpretation may be sensible, but that does not help when you are dealing with legal agreements.
There are plenty of abstraction libraries totally supported on the iPhone.
Again: "supported" does not mean "in compliance with the new SDK agreement".
If Flash was just implemented as a library people could use in their apps, there likely wouldn't be much of a problem (especially if there was a swf -> Obj C preprocessor.)
Again: please read the SDK agreement. What you are saying things is in direct contradiction with what that agreement says. I'm going to take Apple's word over yours (even though they reserve to the right to unilaterally change it at any time, so it's not really worth anything).
Please read the article linked from the summary. Really. They proposed to Apple to rewrite their development so that it would no longer be able to create cross-platform apps, so that all iPhone OS API's would be directly exposed, etc. It didn't matter.
I know because I write cross platform static libraries for the iPhone/Mac/Windows and have never had an issue.
And I know people who have written and submitted apps in Pascal, compiled with a third-party compiler (that I ported) and never had an issue either. That does not mean that what they are doing is not in violation of the new SDK agreement, even though Apple would have to do quite a bit of work to automatically detect such apps.
In fact, Apple even has a iPhone static library template built into the SDK.
Static libraries are totally allowed on the iPhone. Cross platform static libraries are allowed.
Of course static libraries are allowed (they're just a collection of object files after all, so it wouldn't make any sense to forbid them -- and moreover, static libraries are the only kind of libraries you can write yourself, since you cannot include self-written dynamic libraries in an iPhone app), but cross-platform layers (in library or any other form) that call any iPhone SDK APIs are no longer allowed by the new SDK agreement.
That said, will Apple be able to detect that you use such a library? Probably not unless you start shouting it from the rooftops. Are you nevertheless violating the new SDK agreement? Probably, yes. Should you care? As an individual developer probably not. Should a company that intends to offer such a framework to other developers care? Probably yes, because if they get called out all of their customers are also in the cold.
Everything that has gotten approved so far uses XCode as a build step. You don't necessarily have to do all your development work in XCode (i.e. Unity game engine),
Where have you seen that Unity has been approved by Apple? All I've seen is the Unity people saying "we think we're fine because Apple can't afford to remove all apps on the appstore that have been built with our engine, but obviously we can't offer any guarantees".
Cross compile to an XCode project with things like static libraries for your runtime and everything will be fine.
I'm not sure how you can interpret an SDK agreement stating, a.o.,
as
Then perhaps the question should be phrased as:
- how would this app need to be created so as to meet the requirements of the license?
That's exactly what they asked Apple, including offering several suggestions of their own. The result, quoting the article:
This is not about an iPhone app, but about a development environment to create iPhone apps. The company contacted Apple after the SDK agreement changes to determine whether there was any way they could adapt it to the new requirements, and apparently got their final rejection notice from Steve Jobs (see the fine article).
Do you actually believe that Steve Jobs personally does all rejection......really?
Do you actually RTFA......really?
No, I'm not new here.
I disagree. First that with C you can make an operating system. That for Pascal is just a dream.
Not really. Seriously, with Delphi-style Pascal you can program at an equally low level as with C (including inline assembler code).
What is more, people who learn with C often develop a control-freak attitude that hinders them in the adoption of such sensible things as e.g. garbage collectors.
While I agree with your other comments, in my experience (as a Pascal compiler developer) many Pascal programmers are just as control-freaky and hostile towards garbage collection and other things they perceive as "useless overhead that only helps stupid programmers". I don't agree with that point of view, but it is quite pervasive.
I don't know about you, but I always spend way more time on debugging than on typing code. If your programming speed is largely limited by how fast you can type in the code: respect!
We also checked out both options for our lab at the university. At that time (3 years back), a PS3 was EUR 600. The only way to get a "cell computer" was via IBM blades. The cheapest blade chassis *without any blade* cost $17,000. I don't remember the price of the individual blades. At that price point, I'm not sure whether using the Cell architecture is still price-efficient (which is presumably the reason why they went with it in the first place; at least it won't be because of how easy it is to program).
I'd say you are 99% right, but not quite. Pascal has a few abstractions that isolate you from the machine, like the set type for instance.
Yes, it has both high a low level abstractions. I meant that you can go as low level as in C. You indeed don't always have to though.
Also, AFAIK, standard Pascal does not have function pointers,
It does have them: http://www.moorecad.com/standardpascal/iso7185.html#6.6.3.4%20Procedural%20parameters
although I believe many versions, including Delphi, have implemented their non-standard extensions for this.
Delphi did introduce a lot of non-standard extensions to Pascal (and in fact, the way it implemented support for function pointers is different form the ANSI ISO way). Nowadays, Delphi-style Pascal is however one of the most popular variants around and sort of has evolved into a de facto standard.
I learned Pascal in the early 1980s, when the computer I had was an IBM PC with a 4.77 MHz CPU. I did a lot of programming in Turbo Pascal version 3, but I ended learning C because there were some operations I couldn't do with Turbo Pascal. After I learned C, I never felt the need to use Pascal anymore.
I also learned Pascal first, though it was in the 90's. I now also know both Pascal and C, but still prefer Pascal. Keep in mind that Delphi-style/Object Pascal is more than C. It's more like C with the addition of Java-style OOP.
You don't seem to be familiar with Pascal/Delphi. It has manual memory management, differentiates between the stack and the heap, has pointers, etc.
If only one language is taught, then it should be C for anyone who expects to be a professional programmer, knowing C they can easily pick up any other procedural language. A programmer who doesn't know C is like a doctor who doesn't know anatomy.
I think you could say the same about Delphi-style Pascal. You can go as low level as in C there (and believe me, many people do, which is a pain if you develop a cross-platform Delphi-compatible compiler), and as a bonus you also learn an object model that's pretty much identical to Java's.