The reason - they don't have any documents describing the formats.
Except, they do. They've released specs for at least Word97, RTF, and PowerPoint's file formats, the OLE container format, and the Excel chart format. The docs were hosted on MSDN for a few years, even. I'm not saying that these docs are perfect or anything (they're far from it), but they're a decent start. I say this as someone who has used the docs to implement popular F/OSS tools that read and write these formats.
Why do I refer to your statement as a red herring? Because you are ignoring the fact that supporting OOXML doesn't just allow users to have some interaction with the propriatairy MS format it also validates it as being relevant.
Actually, the millions of users with documents in that format validate that it is relevant. The market demand for inter-operability with the format validates it as relevant. AbiWord or some other program supporting the format only confirms that *other people* have deemed it relevant. That's how markets work.
If one grudgingly supports OOXML *the format*, in the interests of allowing users to inter-operate with Microsoft-using colleagues, one need not approve of MS' actions during the "standardization" process or their (you say) lousy "standard". We don't approve of their actions. At all. We do support Jody Goldberg's attempts to extract better documentation from Microsoft. It makes life that much more difficult for them, while making our implementation that much easier.
Because we do this, doesn't mean that we don't whole-heartedly support ODF. In your attempts to show a "red herring", you set up a false dichotomy. (In fact, AbiWord is shipping on the OLPC XO machines with ODF as the default file format, and we're pleased as punch about that.)
Differing, redundant file formats drive market fragmentation and promote vendor lock-in, and should thus be considered evil. However, sticking our heads in the sand and pretending that Microsoft's OOXML won't get significant user uptake is (IMO) an absurd position. The pile of OOXML documents in my wife's inbox are proof enough that it already has. In this case, OOXML's success is measured by how much the community at large uses the file format, not how much you, as an implementer and free software enthusiast, like Microsoft, their actions during the standardization process, or their file format.
Disagree with the bad technical aspects of the OOXML format. Disagree with how Microsoft conducted themselves during the ISO standardization process. Shout it from the rooftops. And wholly support and promote ODF. I think that we're in total agreement on these positions.
But not (grudgingly) supporting the OOXML format hurts your potential users and your quest for openness more than it hurts Microsoft, at least at this point in time. Supporting OOXML allows your products to compete with Microsoft on ease of use, or preferred platform, or etc. It allows your would-be users to transition off of proprietary Microsoft products and "standards" and onto free-er platforms and standards. Like GNU/Linux and ODF.
The important part is to note the verb's tense. MSFT said "we asked OLPC to add a SD card". The OLPC folks complied, and the slot's been there for a while.
Since I develop some software that's made its way onto the laptop, I managed to pick up a B2 machine a few months ago, complete with SD slot (in the most awkward place - under the monitor but above the keyboard. almost impossible to get to).
1: The "non-starter" speed. Even with the quickstarter, OpenOffice.org does not start that fast enough for me.
From go-oo.org/discover: "Go-oo starts faster"
3: Beauty. Heck, the [ugly and huge] icons on Linux can be made better looking.
One of the major projects that Novell's team has been doing is improving OOo's look and feel. This includes better GTK+ widget theme integration, icon-theme integration, use of native dialogs and file system abstractions (eg. gnome-vfs), and use of sophisticated layout containers, instead of VB-style hardcoded widget sizes.
Unfortunately, the US Constitution doesn't consider Habeas Corpus a right. It's also not in the Bill of Rights, as I think you're implying. It's in Article 1, Section 9:
"The privilege of the writ of habeas corpus shall not be suspended, unless when in cases of rebellion or invasion the public safety may require it."
However, the 14th Amendment does say that "nor shall any state deprive any person of [sic] liberty [sic] without due process of law; nor deny to any person within its jurisdiction the equal protection of the laws."
This has come up before and I believe a judge ruled that prices are facts, and facts cannot be copyrighted. That applies to the ISBN number as well.
You're thinking of Feist v. Rural, where the US Supreme Court ruled that it was ok to copy and re-publish a database of telephone numbers. Since facts are purely copied from the world around us, Justice O'Connor concluded, "the sine qua non of copyright is originality".
So, while it's true that iWorks is the only real option for editing them now, it shouldn't be too hard to convert them in the future - you can probably get them into ODF with some simple scripts, or potentially even simple XSL transforms.
In my experience, these things are never simple. You'd think "hey, turning OOXML or ODF into AbiWord's format should be a simple XSL transform or a few simple scripts. They're all XML formats, after all." Where in reality, it's more like 10k lines of C++ code to do a halfway decent job.
Moreover, they are strongly implying that ODF is a lame duck, and that OXML has "more features" and is "richer." They are trying to paint ODF as the poor-man's format, with OXML being the format you use when you're serious.
But OOXML's spec is 10x longer than ODF's, so it must have 10x more features!
Three years ago at my last apartment, I signed up for Comcast Internet. I didn't have a Windows partition on my PC, so they couldn't complete the setup. I called customer support, told them that I was running Firefox on Linux. They said that they didn't officially support that kind of installation, but hey, all the install program does is change your browser's proxy settings and visit a web page. Support told me the proxy server's IP and what URL to visit. 5 minutes later, I'm surfing the web.
Sure, it would've been nice if the installer had instructions for those of us who don't choose to use IE on Windows, especially since the procedure is so simple. But all told, the experience wasn't a bad one. And I didn't feel discriminated against.
Women certainly value good pay and stability, and this study isn't questioning that. Rather, it is saying that opening a book and saying, "Look ladies, we have good pay and stability" isn't the deal maker that it is for men. Socially, women can afford (more than men) to demand additional perks from a job. We're all familiar with the list: flexible hours, jobs that focus more on interpersonal communication, etc. Again, a total generalization but true when looked at as a total generalization.
If this is the case (not saying that it is or isn't, FWIW), then what does that say about women's attitudes in general toward pay equality? Traditionally, the purported 20-30% salary gap between men and women has been a women's rights rallying point.
Here are some comments by EntropyMan @ Digg that highlight the the underlying issues that 60 Minutes (at best) glossed over.
If Intel -- which is not in the business of selling laptops, and is in fact losing money on every laptop sold -- wants to get its processors -- its actual business -- into the hands of the world's kids, all it had to do was offer its CPUs to OLPC at a lower volume price than AMD. It would be in the market with first mover advantage, AMD would be out, and Intel would win this round without breaking any laws.
Instead, it builds a whole new laptop and dumps it at a massive discount below cost wherever OLPC tries to sell theirs. OLPC can't use the heavily discounted Intel CPUs in those, because Intel effectively won't let them.
If I were Intel, I'd be peeved that the (potentially) largest laptop roll-out ever won't be using my chips. But the free-market solution to that is "simple": make better performing, lower wattage chips at a lower price than AMD's Geodes, and make them in bulk. They've shown that they can do that with your high-end chips. They could do it for the low-end market too if they wanted to. Let Intel's products compete on their own merits or let their laptops compete at their fair-market value. *That's* competition. What Intel's doing is predatory poaching of an emerging market.
Wait. I can't just memorize a list from one book and put it in another book. That's copyright infringement. In order for it not to be copyright infringement, I need to make sure that my sources all memorized the pronunciations from different sources. That's going to be difficult.
That's not how copyright law works, at least in the USA. Lists are facts. Facts are not copyrightable, nor are compilations thereof. Mainly because copyright isn't determined by the "sweat of the brow" rule, but rather "the sine qua non of copyright is originality." (Justice O'Connor)
The relevant SCOTUS case on this is Feist v. Rural.
pthread_cond_timedwait() waits on a condition variable, which basically signals that a mutex has been released. Win32 calls these things "events". It is not the same thing as joining on a thread. Joining a thread means "I'm waiting for this thread to exit, so that I can capture its return value."
Sure, you could implement something like pthread_join_with_timeout() using a conditional inside the thread. But you'd need to do that manually, as pthreads doesn't provide a primitive for that particular use-case AFAIK.
Maybe you have in mind an argument you're not making, but I don't see any sufficient basis for your broad contention that using a file format based on an internal representation is a "darn good idea".
He's not saying that the file format has to be an unreadable dump of the Word Processor's in-memory representation. Merely, the file format has to coincide with the application's view of the world. *Everything* that the application can do is (un)serializable to that format. It's like speaking in your native tongue. You're good at it.
When you start using someone else's file format, your worldview is a bit changed. Maybe it supports fewer formatting options for lists. Or one of your idioms (say, a floating textbox frame) isn't directly translatable to their file format, so you have to "fake it" or otherwise find a compromise fall-back solution. For instance, I can conduct a reasonable conversation in (say) German, but English is my native language, and sometimes things will get lost, mis-interpreted, or dumbed-down in the translation.
Avoiding dataloss is perhaps the best reason for having a native file format, at least for existing applications. Inter-operability is a darn good reason for supporting other people's file formats, especially "open" ones like ODF. Just don't think of it as your native tongue. Your application wasn't designed with that in mind.
Can I draw diagrams with RTF? Can I have a ToC? Can I do complex styling? Can I have a "galery" of styles? Can I include images? No. RTF is not a solution.
Actually, you can. RTF can express most (if not all) of what the Microsoft Word format can. Let me answer your objections using excerpts from the RTF 1.8 specification:
The \tc control word introduces a table of contents entry, which can be used to build the actual table of contents.
The \stylesheet control word introduces the style sheet group, which contains definitions and descriptions of the various styles used in the document.
An RTF file can include pictures created with other applications. These pictures can be in hexadecimal (the default) or binary format. Pictures are destinations and begin with the \pict control word.
\dgmt creates diagrams. \pict of subtype \*metafile supports vector drawings, in case that's what you meant by "diagrams".
Now how does this apply to Linux? In Free Software Happy Land, you have the source to all the software on your system, so with the ability to recompile you don't need binary backward compatability.
This is still a huge problem in Free Software Happy Land, and there's a good reason why the GTK+/GNOME and the QT/KDE folks strive *really hard* to maintain API and ABI compatibility between releases.
If your program relies upon a shared library, and that library breaks ABI compatibility, though, you're still screwed. Sure, there are work-arounds if you control your program's sources - you could statically link things in, or do some LD_PRELOAD hack to load the right version of the right shared libraries. But this assumes that you have a lot under your control. You might not have this luxury if you're using a 3rd-party proprietary library or program.
But then there's also API breakage, which is a major part of "backwards compatibility" that must be taken into account. If the kernel syscall numbers (or the arguments thereto) change, there's major breakage. inotify vs. dnotify vs. fam? udev vs. static dev? Does your program assume that/dev/fd0 is the floppy drive?
In short, the solution isn't always as simple as "just recompile your apps against the newer library".
"But it's not rational for the country's non-voters to expect that voters' engagement in the political process will necessarily bring about a better outcome for them."
It's hard to disagree with that. But it's also not rational for the country's non-voters to expect that random or uninformed voting will necessarily benefit them either. Would that be statistically different than if they had not voted in the first place?
The right course in a democracy is to educate the electorate on the issues and convince them that it is in their best interests to vote based on an analysis of those issues. We need to convince the greater electorate to become the "rational, self-interested actors" that Klein refers to in his article. In theory, that's what TV and Radio Ads do. In theory there is no difference between theory and practice. But, in practice, there is.
NBC's Monday Night headliner, "Studio 60 on the Sunset Strip", is a show about how studios desperately need to attract and retain good writing and producing talent and stop showing so much reality TV garbage. Clearly, the NBC execs aren't watching their own network, making this whole debacle fraught with irony.
It also supports the PDF 1.4 drawing model. With a few add-ins (like XFORMs) and improvements to its multi-page specification, it could really compete in PDF's or XPS' marketspace.
I'm confused by those who think that Google isn't unambiguously in the clear here. Not because they're doing it for a scholarly purpose. Or because they're only reproducing a terse portion of the work. Or not even because what Google is doing can't possibly affect these author's past decisions to create their works, and thus retroactively disincentivize their respective work's creation (ahem, Sonny Bono CTEA, I'm looking at you here...).
I think that if you're arguing those points, perhaps you're looking at this from the correct perspective. I invite you to look outside the box. Sure, Google might (or might not) win on the above points alone. But I don't think that Google is copying expressive works. Google is copying databases of words.
In the case of Rural v. Feist, the Court ruled that databases (in that case, telephone directories) were not entitled to copyright protection, as they contained little (if any) expressive content. Copyright protects expression fixed in a tangible media, and even then only within certain limitations.
Here, I believe that Google is treating otherwise expressive, copyrighted texts as databases, thus stripping them of their expressivity in the context of the texts' uses. I think that the use of a derivitive work matters a great deal in determining that work's expressivity before the Court. That the use of a work has a transformative effect on the expressivity of that work, possibly even voiding that work's expressiveness in a given context. In Google's case, the works are copied - perhaps verbatim - but their expressiveness is lost in the process. Granted, this may seem non-obvious.
The search results page rendered by Google most likely have some expressiveness, and would be copyrightable. The texts that Google OCR'd are expressive and copyrightable. But Google's treatment of these texts as search indexes - reverse text lookup databases - is in itself not expressive. They're just unexpressive token sequences, capable of being searched. It is in the translation from meaningful, expressive words into an ordered sequence of cold, machine-searchable tokens that the work loses its expressivity. Note that this distinction would still attach copyright protection to things like eBooks, as the purpose of eBooks is to convey expressivity to a human reader via an electronic medium. The purpose of the tokens is to convey an ordered sequence of words to a machine algorithm incapable of appreciating the work's expressivity or content in any way that we'd call "meaningful".
From that, we're left to conclude that the tokens "John Galt" appearing on page 1 of Ayn Rand's "Atlas Shrugged" next to the tokens "Who is" is merely a fact, absent any inherent meaningful expressivity. And absent this expressivity, copyright doesn't attach to this sentence (which, fwiw, is probably considerably too short for copyright to attach to, anyway). Facts - even collections of facts - simply aren't protected under copyright law.
In the end, Google's Print project is just a fact retrieval system - in essence, no different from the index in the back of the book that they're OCR'ing. Copyright law needn't get involved, because at no point does it affix to what Google is doing.
Speaking of history lessons and facts, let's not forget that RMS needed to due everything short of suing NeXt to open the Objective C compiler's and runtime's sources:
NeXt didn't want to contribute their code back to the Free Software movement. They even had some sneaky attempts (shipping just the.o files) to keep it proprietary. Only when lawyers got involved, did NeXt release their changes. They gave something back to the gcc community only when a gun was to their head.
The consumers don't want competition. We want reliable, fast, inexpensive internet access. If competition is the means to that ends, then great. If government intervention will deliver it, that's great too. Whatever it takes to get me what I want.
Slashdot Mirror
Except, they do. They've released specs for at least Word97, RTF, and PowerPoint's file formats, the OLE container format, and the Excel chart format. The docs were hosted on MSDN for a few years, even. I'm not saying that these docs are perfect or anything (they're far from it), but they're a decent start. I say this as someone who has used the docs to implement popular F/OSS tools that read and write these formats.
http://www.wotsit.org/list.asp?fc=10
http://www.wotsit.org/list.asp?fc=6
Actually, the millions of users with documents in that format validate that it is relevant. The market demand for inter-operability with the format validates it as relevant. AbiWord or some other program supporting the format only confirms that *other people* have deemed it relevant. That's how markets work.
If one grudgingly supports OOXML *the format*, in the interests of allowing users to inter-operate with Microsoft-using colleagues, one need not approve of MS' actions during the "standardization" process or their (you say) lousy "standard". We don't approve of their actions. At all. We do support Jody Goldberg's attempts to extract better documentation from Microsoft. It makes life that much more difficult for them, while making our implementation that much easier.
Because we do this, doesn't mean that we don't whole-heartedly support ODF. In your attempts to show a "red herring", you set up a false dichotomy. (In fact, AbiWord is shipping on the OLPC XO machines with ODF as the default file format, and we're pleased as punch about that.)
Differing, redundant file formats drive market fragmentation and promote vendor lock-in, and should thus be considered evil. However, sticking our heads in the sand and pretending that Microsoft's OOXML won't get significant user uptake is (IMO) an absurd position. The pile of OOXML documents in my wife's inbox are proof enough that it already has. In this case, OOXML's success is measured by how much the community at large uses the file format, not how much you, as an implementer and free software enthusiast, like Microsoft, their actions during the standardization process, or their file format.
Disagree with the bad technical aspects of the OOXML format. Disagree with how Microsoft conducted themselves during the ISO standardization process. Shout it from the rooftops. And wholly support and promote ODF. I think that we're in total agreement on these positions.
But not (grudgingly) supporting the OOXML format hurts your potential users and your quest for openness more than it hurts Microsoft, at least at this point in time. Supporting OOXML allows your products to compete with Microsoft on ease of use, or preferred platform, or etc. It allows your would-be users to transition off of proprietary Microsoft products and "standards" and onto free-er platforms and standards. Like GNU/Linux and ODF.
Dominic Lachowicz, core AbiWord developer
This is old news.
The important part is to note the verb's tense. MSFT said "we asked OLPC to add a SD card". The OLPC folks complied, and the slot's been there for a while.
Since I develop some software that's made its way onto the laptop, I managed to pick up a B2 machine a few months ago, complete with SD slot (in the most awkward place - under the monitor but above the keyboard. almost impossible to get to).
See http://www.laptop.org/laptop/hardware/specs.shtml, under the "external connectors" section.
"Drat! I knew I should have showed him Electro-Gonorrhea: The Noisy Killer."
/me queues up for his Lucy Liu-Bot
From go-oo.org/discover: "Go-oo starts faster"
One of the major projects that Novell's team has been doing is improving OOo's look and feel. This includes better GTK+ widget theme integration, icon-theme integration, use of native dialogs and file system abstractions (eg. gnome-vfs), and use of sophisticated layout containers, instead of VB-style hardcoded widget sizes.
Unfortunately, the US Constitution doesn't consider Habeas Corpus a right. It's also not in the Bill of Rights, as I think you're implying. It's in Article 1, Section 9:
"The privilege of the writ of habeas corpus shall not be suspended, unless when in cases of rebellion or invasion the public safety may require it."
However, the 14th Amendment does say that "nor shall any state deprive any person of [sic] liberty [sic] without due process of law; nor deny to any person within its jurisdiction the equal protection of the laws."
In my experience, these things are never simple. You'd think "hey, turning OOXML or ODF into AbiWord's format should be a simple XSL transform or a few simple scripts. They're all XML formats, after all." Where in reality, it's more like 10k lines of C++ code to do a halfway decent job.
Care to explain people's general indifference to click-through EULAs then, and the generally nasty stuff in them?
But OOXML's spec is 10x longer than ODF's, so it must have 10x more features!
*ducks*
Three years ago at my last apartment, I signed up for Comcast Internet. I didn't have a Windows partition on my PC, so they couldn't complete the setup. I called customer support, told them that I was running Firefox on Linux. They said that they didn't officially support that kind of installation, but hey, all the install program does is change your browser's proxy settings and visit a web page. Support told me the proxy server's IP and what URL to visit. 5 minutes later, I'm surfing the web.
Sure, it would've been nice if the installer had instructions for those of us who don't choose to use IE on Windows, especially since the procedure is so simple. But all told, the experience wasn't a bad one. And I didn't feel discriminated against.
If this is the case (not saying that it is or isn't, FWIW), then what does that say about women's attitudes in general toward pay equality? Traditionally, the purported 20-30% salary gap between men and women has been a women's rights rallying point.
If I were Intel, I'd be peeved that the (potentially) largest laptop roll-out ever won't be using my chips. But the free-market solution to that is "simple": make better performing, lower wattage chips at a lower price than AMD's Geodes, and make them in bulk. They've shown that they can do that with your high-end chips. They could do it for the low-end market too if they wanted to. Let Intel's products compete on their own merits or let their laptops compete at their fair-market value. *That's* competition. What Intel's doing is predatory poaching of an emerging market.
pthread_cond_timedwait() waits on a condition variable, which basically signals that a mutex has been released. Win32 calls these things "events". It is not the same thing as joining on a thread. Joining a thread means "I'm waiting for this thread to exit, so that I can capture its return value."
Sure, you could implement something like pthread_join_with_timeout() using a conditional inside the thread. But you'd need to do that manually, as pthreads doesn't provide a primitive for that particular use-case AFAIK.
He's not saying that the file format has to be an unreadable dump of the Word Processor's in-memory representation. Merely, the file format has to coincide with the application's view of the world. *Everything* that the application can do is (un)serializable to that format. It's like speaking in your native tongue. You're good at it.
When you start using someone else's file format, your worldview is a bit changed. Maybe it supports fewer formatting options for lists. Or one of your idioms (say, a floating textbox frame) isn't directly translatable to their file format, so you have to "fake it" or otherwise find a compromise fall-back solution. For instance, I can conduct a reasonable conversation in (say) German, but English is my native language, and sometimes things will get lost, mis-interpreted, or dumbed-down in the translation.
Avoiding dataloss is perhaps the best reason for having a native file format, at least for existing applications. Inter-operability is a darn good reason for supporting other people's file formats, especially "open" ones like ODF. Just don't think of it as your native tongue. Your application wasn't designed with that in mind.
Dom Lachowicz, AbiWord developer
Actually, you can. RTF can express most (if not all) of what the Microsoft Word format can. Let me answer your objections using excerpts from the RTF 1.8 specification:
The \tc control word introduces a table of contents entry, which can be used to build the actual table of contents.
The \stylesheet control word introduces the style sheet group, which contains definitions and descriptions of the various styles used in the document.
An RTF file can include pictures created with other applications. These pictures can be in hexadecimal (the default) or binary format. Pictures are destinations and begin with the \pict control word.
\dgmt creates diagrams. \pict of subtype \*metafile supports vector drawings, in case that's what you meant by "diagrams".
Check out http://www.microsoft.com/downloads/thankyou.aspx?
This is still a huge problem in Free Software Happy Land, and there's a good reason why the GTK+/GNOME and the QT/KDE folks strive *really hard* to maintain API and ABI compatibility between releases.
If your program relies upon a shared library, and that library breaks ABI compatibility, though, you're still screwed. Sure, there are work-arounds if you control your program's sources - you could statically link things in, or do some LD_PRELOAD hack to load the right version of the right shared libraries. But this assumes that you have a lot under your control. You might not have this luxury if you're using a 3rd-party proprietary library or program.
But then there's also API breakage, which is a major part of "backwards compatibility" that must be taken into account. If the kernel syscall numbers (or the arguments thereto) change, there's major breakage. inotify vs. dnotify vs. fam? udev vs. static dev? Does your program assume that /dev/fd0 is the floppy drive?
In short, the solution isn't always as simple as "just recompile your apps against the newer library".
"But it's not rational for the country's non-voters to expect that voters' engagement in the political process will necessarily bring about a better outcome for them."
It's hard to disagree with that. But it's also not rational for the country's non-voters to expect that random or uninformed voting will necessarily benefit them either. Would that be statistically different than if they had not voted in the first place?
The right course in a democracy is to educate the electorate on the issues and convince them that it is in their best interests to vote based on an analysis of those issues. We need to convince the greater electorate to become the "rational, self-interested actors" that Klein refers to in his article. In theory, that's what TV and Radio Ads do. In theory there is no difference between theory and practice. But, in practice, there is.
Like it or not, they'll be distributing "derivative works" of the cake in the next few hours...
*ducks*
NBC's Monday Night headliner, "Studio 60 on the Sunset Strip", is a show about how studios desperately need to attract and retain good writing and producing talent and stop showing so much reality TV garbage. Clearly, the NBC execs aren't watching their own network, making this whole debacle fraught with irony.
It also supports the PDF 1.4 drawing model. With a few add-ins (like XFORMs) and improvements to its multi-page specification, it could really compete in PDF's or XPS' marketspace.
I'm confused by those who think that Google isn't unambiguously in the clear here. Not because they're doing it for a scholarly purpose. Or because they're only reproducing a terse portion of the work. Or not even because what Google is doing can't possibly affect these author's past decisions to create their works, and thus retroactively disincentivize their respective work's creation (ahem, Sonny Bono CTEA, I'm looking at you here...).
I think that if you're arguing those points, perhaps you're looking at this from the correct perspective. I invite you to look outside the box. Sure, Google might (or might not) win on the above points alone. But I don't think that Google is copying expressive works. Google is copying databases of words.
In the case of Rural v. Feist, the Court ruled that databases (in that case, telephone directories) were not entitled to copyright protection, as they contained little (if any) expressive content. Copyright protects expression fixed in a tangible media, and even then only within certain limitations.
Here, I believe that Google is treating otherwise expressive, copyrighted texts as databases, thus stripping them of their expressivity in the context of the texts' uses. I think that the use of a derivitive work matters a great deal in determining that work's expressivity before the Court. That the use of a work has a transformative effect on the expressivity of that work, possibly even voiding that work's expressiveness in a given context. In Google's case, the works are copied - perhaps verbatim - but their expressiveness is lost in the process. Granted, this may seem non-obvious.
The search results page rendered by Google most likely have some expressiveness, and would be copyrightable. The texts that Google OCR'd are expressive and copyrightable. But Google's treatment of these texts as search indexes - reverse text lookup databases - is in itself not expressive. They're just unexpressive token sequences, capable of being searched. It is in the translation from meaningful, expressive words into an ordered sequence of cold, machine-searchable tokens that the work loses its expressivity. Note that this distinction would still attach copyright protection to things like eBooks, as the purpose of eBooks is to convey expressivity to a human reader via an electronic medium. The purpose of the tokens is to convey an ordered sequence of words to a machine algorithm incapable of appreciating the work's expressivity or content in any way that we'd call "meaningful".
From that, we're left to conclude that the tokens "John Galt" appearing on page 1 of Ayn Rand's "Atlas Shrugged" next to the tokens "Who is" is merely a fact, absent any inherent meaningful expressivity. And absent this expressivity, copyright doesn't attach to this sentence (which, fwiw, is probably considerably too short for copyright to attach to, anyway). Facts - even collections of facts - simply aren't protected under copyright law.
In the end, Google's Print project is just a fact retrieval system - in essence, no different from the index in the back of the book that they're OCR'ing. Copyright law needn't get involved, because at no point does it affix to what Google is doing.
Speaking of history lessons and facts, let's not forget that RMS needed to due everything short of suing NeXt to open the Objective C compiler's and runtime's sources:
l
.o files) to keep it proprietary. Only when lawyers got involved, did NeXt release their changes. They gave something back to the gcc community only when a gun was to their head.
http://www.fsf.org/licensing/essays/pragmatic.htm
NeXt didn't want to contribute their code back to the Free Software movement. They even had some sneaky attempts (shipping just the
The consumers don't want competition. We want reliable, fast, inexpensive internet access. If competition is the means to that ends, then great. If government intervention will deliver it, that's great too. Whatever it takes to get me what I want.