Which seems sort of strange. By all reports, Apple makes all their money selling the iPod, and almost nothing on the iTMS. Letting other stores sell music with Apple's copy-prevention would seem to not lose them anything, while making the iPod even more desirable.
Licensing FairPlay to other players, on the other hand, would probably lose them money (unless they set the licensing fees quite high).
There was already a provision that if less than 85% of a specific market isn't able to receive a digital transmission, then the analog transmissions in that market are not required to go dark:
The transition period to DTV is currently scheduled to end on December 31, 2006. This transition period is subject to periodic progress reviews by the FCC to make sure DTV service is widely available. In addition, the Balanced Budget Act of 1997, passed last fall by the Congress, includes provisions that would extend the continuation of analog service beyond the year 2006 deadline if DTV is implemented more slowly than expected. Specific conditions which would extend the transition period include the failure of one or more of the largest TV stations in a market to begin broadcasting digital TV signals through no fault of their own, or fewer than 85% of the TV households in a market are able to receive digital TV signals off the air either with a digital TV set or with an analog set equipped with a converter box or by subscription to a cable-type service that carries the DTV stations in the market.
$400 for a TV isn't really that much. Plenty of people bought 19"-25" TVs at that price range 15-20 years ago, and that's when $400 was worth more than it is today. $400 for a 42" TV (which is what TFA said, not 40") will sell like hotcakes, despite the existence of very low cost competition.
By the way, the phrase is "for all intents and purposes". Widescreen anamorphic DVDs are a good reason to get a widescreen TV, even if it doesn't require HD. Cheap HDTVs will lead to most stuff on TV being in HD. Won't lead to it being any better, but it will probably at least LOOK better.
Right, that's the part that allows other non-GPL material to be on the same media. The test for "mere aggregation" is not clear - some people have tried to claim that you could have "mere aggregation" even in the firmware of a router, where all the different pieces are loaded and run as a single program from the user's point of view. One thing the FSF makes clear is that it is not allowed is to ship off some GPL parts and non-GPL parts, and then have as part of the installation procedure those parts put together into a single executable ("user does the link"). It is fairly clear to most people that the users are free to retrieve various pieces (GPL and GPL-incompatible) from separate sources and put them together however they want, as long as the result isn't distributed.
A big controversy arose once regarding a source distribution, which linked with a restricted library, and was distributed with a free (but not GPLed) library, that came with a script that patched the source to allow it to link to a GPL library instead of the "free non-GPL" library (along with the restricted library). The FSF claimed that the source distribution was a GPL violation, even though it contained not one bit of GPL code (and wasn't distributed with a copy of the GPL library). Their theory was that the code was a derivative of the GPL library because the GPL library had unique function names and parameters, and since the patched code could only link to that library it had to be derivative. When someone wrote a quick-and-dirty replacement of the GPL library (same in basic function, but not as fast and efficient), they dropped their objection. Merely by existing, in the FSF's eyes it changed the original source code from being derivative to non-derivative, even though it wasn't distributed with the source code under dispute. Bizarre.
Gee whiz, I'm sorry for being so last-week. I'm running 10.3.9, the system that the patches that we're discussing are for. I'm looking forward to upgrading to Tiger, but did you really completely rewrite the system for that?
Do you know what a "system call" is? Hint: take a look at/usr/include/sys/syscall.h. It is a call into the kernel, NOT a call to a library routine. In this case, it could be a Unix or Mach system call. Mach processes also communicate using Mach ports, which is used to implement services that would be done by system calls in Unix.
Are you seriously saying that when, say, the Finder is started up, it isn't done by (eventually) executing an execve() Unix system call, which then runs the Unix dynamic loader, maps the executable, loads various dynamic libraries, opens files, and launch other processes, all using Unix system calls? That there's a completely separate mechanism that then somehow calls out to a separate Unix subsystem to add Finder and the Dock to the Unix process list, update all those Unix kernel data structures such as open files belonging to the process, just to maintain Unix compatibility? Does the Finder access files and communicate with processes through mechanisms other than Unix or Mach system calls or Mach messages? Does it get access to and control memory through some mechanism other than Unix memory management calls? The Unix calls themselves almost certainly get much of their work done by calling down to lower layers, and I know that a lot of the low level stuff in OSX is implemented by various services communicating using Mach ports, which does bypass the Unix layer. However, those services are still Unix processes, which make Unix system calls. Note that I'm not saying that Unix and Mach processes are distinct, I'm sure that the task processing and memory management in the Unix layer uses Mach facilities for managing all that.
I can take a Linux kernel, call it "Dave", build a very complex system on top of it, put everything in a directory called "/Dave is Not Unix", but it is still Linux underneath (and Linux is a "Unix-like" operating system). I can take out cron, inetd, rewrite init (one of the few hardcoded file names in the kernel), ignore any type of sh or clone thereof, write my own libraries, create a new language, ignore/dev,/etc,/bin,/lib,/usr, and it is STILL UNIX-LIKE. Adding a bunch of command-line utilities or a few libraries is not "a compatibility layer". Fundamentally, OSX depends on a Unix kernel being there, along with Mach, along with a bunch of OSX libraries. Moving/etc to a separate location and putting in a symbolic link from/etc is absolutely irrelevant, particularly since all the programs that then reference it do so by looking at/etc, NOT/private/etc.
If you stripped out init, how come 'ps 1' shows me/sbin/init? I know a bunch of things (such as cron) apparently have been modified for Tiger, but they're still just running standard Unix processes to provide similar services.
The system boots in Unix, it runs init, it runs various rc scripts which start various services which then become the processes that present a graphical user interface. It has plenty of stuff in/etc. It uses shell scripts and Perl scripts. It Is a Unix-like system in every way. It is also a Mach-based system, as you can do direct Mach system calls as well.
Having X Windows as the graphical interface isn't what makes a system Unix-like. Having a new device-driver architecture doesn't make a system non-Unix-like. OSX, for the most part, is a set of processes and libraries, conventions and file-system layouts, with a Unix-like kernel at the heart of it. If you leave the Unix libraries and config files and executables, and take away the OSX-specific stuff, you're left with a system that is pretty much Unix. How much of OSX is implemented in the kernel and how much is implemented in shared libraries? How many non-Unix non-Mach (i.e. OSX-specific) system calls are there? How much of the system runs directly under Mach instead of running as a Unix process?
I don't understand why you have such a thing about insisting that what is running on a Mac running OSX isn't "Unix-like", when it clearly is. It goes well beyond that, but at its core it is a fully functioning (well, some of the SysV IPC stuff was broken in whatever version I last checked them out, but whatever) Unix environment.
Linux is NOT a "file-by-file" clone of Unix./proc isn't even all that old compared to much that is in Unix. There are many ways of doing bootstrap scripts, cron and inet daemons, run levels, etc. OSX is more traditional than Linux in doing some of that, but the specifics of those aren't what make something Unix-like.
If I boot Linux on a root file system that has/sbin/init being a link to, say, tclsh (or use an "init=/bin/tclsh" on the boot command), with a few libraries in/lib that Tcl needs, and include a Tcl extension that gives access to Unix system calls (such as mounting), add the executables for fsck, and write some scripts for mounting file systems and doing other system initialization, implement common commands in Tcl, etc, I'd still have a "Unix-like" system, even if it is very non-traditionally implemented. I'd have to make sure to have a thread running wait() calls to clean up zombie processes, but that's about the only thing special about init. Given that base, I could add any set of user-land executables and libraries and be as traditional as you like. Lots of ways after that to implement a GUI environment without ever getting down into the kernel. I could base something on Wish, for example. It is the kernel, primarily, that makes it Unix-like, at least at the programming level. The standard Unix command line utilities and libraries are the rest of what makes it Unix-like./dev is a distant third, and/proc doesn't even count./etc is just a place that various programs default to sticking configuration or other data./lib and/usr/lib are often hardcoded into the dynamic loader, but don't need to be. Using a different method for common configuration settings is nothing new - see Yellow Pages, for example (now known as NIS). Writing something in a new language such as Objective C doesn't make a system non-Unix.
I suppose if you had a Unix kernel that used a jvm as init, which then ran everything else on the system (maybe with a few "native" executables such as fsck as "helpers"), you could say it wasn't a very Unix-like system even though it had a Unix kernel. But even then, if there was an escape to launch an arbitrary process and pass the output back through a pipe, I'd still say it was mostly Unix-like.
The Constitutional protection for due process is a restriction against the entire government, not just the courts, and applies to all matters that the government is involved in, not just with regard to citizens. If the executive branch violates that restriction, then the Supreme Court does have jurisdiction as it is a Constitutional matter. Congress isn't allowed to pass laws allowing the executive branch to violate the Constitution, inside or outside the country.
Amendment 5 refers to "no person", not "no citizen". Amendment 14 prohibits States from violating rights guaranteed by the Constitution to citizens, but also prohibits the States from depriving any PERSON (not just citizen) of life/liberty/property without due process, nor deny equal protection under the law to any PERSON within its jurisdiction. Neither limits the rights of non-citizens, either by the States or the Federal government (rights of non-citizens are limited only where a specific right is granted to a "citizen"; most references in the Constitution and the Amendments are to "person" - see for example voting rights, ability to be a Representative or Senator or Vice President or President).
While you're correct that the Federal government doesn't have universal jurisdiction, it only stands to reason that the Judicial branch has universal jurisdiction over the other branches of the government - if the Executive branch can claim that it has jurisdiction in rented land on Cuba, then the Judicial branch surely has jurisdiction over the Executive branch on that same piece of land.
You have to provide more than the modifications, you have to provide all of the source. You can't put up a set of diffs and a link to the original source if you're providing the binary for download.
Sometimes you have to do that, but I prefer instead to make sure that all uses of that buffer don't assume it is zero-terminated unless I can guarantee that it is.
Good example. The person complaining about the x86 growing the stack downward obviously doesn't know that many other architectures do the exact same thing, e.g. PDP-11, 68K, Alpha, PPC. One way to avoid return location overwriting is to have a separate instruction and data stack. Use the instruction stack for return, saved registers, stack links (including data stack), etc. Use the data stack for all programmer-visible local variables. Slightly less efficient, you need two registers for stack pointers, or have to keep reloading the data stack pointer off of the instruction stack. However, you could locate them in the same memory segment (data stack grows upwards, instruction stack grows downwards as usual, extend the memory segment in both directions when you get a fault).
Or don't write stupid code. It really isn't that hard.
No, even if the process was "contaminated", it doesn't show copyright violation. I've read books by Stephen King, it doesn't mean I can't write my own horror novels. The proof is in the similarity of the works, the process being "clean" is only a defense.
The best part of the Eldred decision is that if Congress decides in the future to cut copyright back to 28 years, or to implement some completely different form of copyright, they can do so with no need to worry about "illegal taking of property" considerations. They can make it retroactive to existing works, because the Supreme Court already said they could.
The (L)GPL doesn't make Apple responsible for giving benefit to KDE users. That's not the purpose of the (L)GPL. Apple is responsible for making sure that someone using the code they're distributing can modify it, in this case Safari users (and other Mac OSX clients using the libraries based on KHTML). It certainly doesn't harm the KDE users in any way (and, frankly, it usually isn't that difficult to figure out what changes have been made to a file, given the current file and your own history of revisions). Often it is worthwhile to try to keep your code base synched with the original, but sometimes it creates so much extra work that you shouldn't try. Once you've diverged, your changes become less and less useful to the original project. There's nothing morally or ethically wrong with that (you also lose some benefit for yourself, as you have just as difficult a time merging enhancements or bug fixes from them).
I have a script I sometimes use that takes a file (or set of files) and checks the size of the diff with each version in the RCS/CVS tree, then reports the 5 revisions with the smallest amount of changes. Very effective for identifying an unknown version of a file, whether it has some unchecked-in changes or not.
Providing the complete set of source files is what the (L)GPL requires, not a set of patches.
No, it means *the source code*. I don't edit a CVS file, I don't edit diffs, I edit a source file. The goal of the GPL is that I, someone with a copy of Safari, can get the source code for the program I'm running (or, in the case of the LGPL, those components covered by the LGPL), and be able to make changes to the program I'm running - whether to fix a bug, enhance a feature, or whatever. They don't have to make the changes available to the original programmers at all, they only have to provide the source code that matches a specific binary release. If they release the binary without providing the sources at the time of the release THEN they have to make the complete source files available, but even then they don't have to provide programmer notes, sets of diffs, CVS logs, explanations of why they made the changes (but they can't strip out comments in the source files, either). If comments in the CVS logs contain substantive information documenting code as it is in the source files being released, you could possibly make an argument that those should be included. If it is only documenting why a change was made (e.g. bug tracking number), I don't think that would be required by the (L)GPL.
If you received a binary without the source code, but with an offer (such as a link) to get the source code, AND you are distributing it non-commercially, then you can get by with only providing the original link you got (or other form of offer of the source code "for no more than the cost of distribution"). If, instead, you got the binary along with the source (or the source was available for download at the same time you downloaded the binary), you must either provide the source to anyone who gets a copy from you, or YOU must provide copies of the source for three years to anyone who wants it. If you don't have the source in this situation, you can't re-distribute the binary.
He's also wrong that if you fail to use clean-room reverse-engineering techniques, or a "Chinese wall", you are guilty of copyright violation. Such practices are a good defense against infringement claims, but even without that as a defense you STILL have to show copying. It doesn't change the basic principles of what copying is or what copyright doesn't protect. He seems to think that all you have to show is one manager or programmer who had access to the AT&T protected code base and also had some contact with people working on Linux and *boom* the case is made.
It seems very odd that you have to pay "compensation" for exercising a right. Maybe you should have to pay compensation on every musical instrument you buy, because you might play copyrighted songs on it? Or worse yet, you might not buy commercial CDs because you're too busy creating your own music! Definitely requires compensation, they have a right to your money!
Slashdot Mirror
Which seems sort of strange. By all reports, Apple makes all their money selling the iPod, and almost nothing on the iTMS. Letting other stores sell music with Apple's copy-prevention would seem to not lose them anything, while making the iPod even more desirable.
Licensing FairPlay to other players, on the other hand, would probably lose them money (unless they set the licensing fees quite high).
There was already a provision that if less than 85% of a specific market isn't able to receive a digital transmission, then the analog transmissions in that market are not required to go dark:
(from a FCC info page from 1997.$400 for a TV isn't really that much. Plenty of people bought 19"-25" TVs at that price range 15-20 years ago, and that's when $400 was worth more than it is today. $400 for a 42" TV (which is what TFA said, not 40") will sell like hotcakes, despite the existence of very low cost competition.
By the way, the phrase is "for all intents and purposes". Widescreen anamorphic DVDs are a good reason to get a widescreen TV, even if it doesn't require HD. Cheap HDTVs will lead to most stuff on TV being in HD. Won't lead to it being any better, but it will probably at least LOOK better.
Right, that's the part that allows other non-GPL material to be on the same media. The test for "mere aggregation" is not clear - some people have tried to claim that you could have "mere aggregation" even in the firmware of a router, where all the different pieces are loaded and run as a single program from the user's point of view. One thing the FSF makes clear is that it is not allowed is to ship off some GPL parts and non-GPL parts, and then have as part of the installation procedure those parts put together into a single executable ("user does the link"). It is fairly clear to most people that the users are free to retrieve various pieces (GPL and GPL-incompatible) from separate sources and put them together however they want, as long as the result isn't distributed.
A big controversy arose once regarding a source distribution, which linked with a restricted library, and was distributed with a free (but not GPLed) library, that came with a script that patched the source to allow it to link to a GPL library instead of the "free non-GPL" library (along with the restricted library). The FSF claimed that the source distribution was a GPL violation, even though it contained not one bit of GPL code (and wasn't distributed with a copy of the GPL library). Their theory was that the code was a derivative of the GPL library because the GPL library had unique function names and parameters, and since the patched code could only link to that library it had to be derivative. When someone wrote a quick-and-dirty replacement of the GPL library (same in basic function, but not as fast and efficient), they dropped their objection. Merely by existing, in the FSF's eyes it changed the original source code from being derivative to non-derivative, even though it wasn't distributed with the source code under dispute. Bizarre.
Gee whiz, I'm sorry for being so last-week. I'm running 10.3.9, the system that the patches that we're discussing are for. I'm looking forward to upgrading to Tiger, but did you really completely rewrite the system for that?
Do you know what a "system call" is? Hint: take a look at /usr/include/sys/syscall.h. It is a call into the kernel, NOT a call to a library routine. In this case, it could be a Unix or Mach system call. Mach processes also communicate using Mach ports, which is used to implement services that would be done by system calls in Unix.
Are you seriously saying that when, say, the Finder is started up, it isn't done by (eventually) executing an execve() Unix system call, which then runs the Unix dynamic loader, maps the executable, loads various dynamic libraries, opens files, and launch other processes, all using Unix system calls? That there's a completely separate mechanism that then somehow calls out to a separate Unix subsystem to add Finder and the Dock to the Unix process list, update all those Unix kernel data structures such as open files belonging to the process, just to maintain Unix compatibility? Does the Finder access files and communicate with processes through mechanisms other than Unix or Mach system calls or Mach messages? Does it get access to and control memory through some mechanism other than Unix memory management calls? The Unix calls themselves almost certainly get much of their work done by calling down to lower layers, and I know that a lot of the low level stuff in OSX is implemented by various services communicating using Mach ports, which does bypass the Unix layer. However, those services are still Unix processes, which make Unix system calls. Note that I'm not saying that Unix and Mach processes are distinct, I'm sure that the task processing and memory management in the Unix layer uses Mach facilities for managing all that.
I can take a Linux kernel, call it "Dave", build a very complex system on top of it, put everything in a directory called "/Dave is Not Unix", but it is still Linux underneath (and Linux is a "Unix-like" operating system). I can take out cron, inetd, rewrite init (one of the few hardcoded file names in the kernel), ignore any type of sh or clone thereof, write my own libraries, create a new language, ignore /dev, /etc, /bin, /lib, /usr, and it is STILL UNIX-LIKE. Adding a bunch of command-line utilities or a few libraries is not "a compatibility layer". Fundamentally, OSX depends on a Unix kernel being there, along with Mach, along with a bunch of OSX libraries. Moving /etc to a separate location and putting in a symbolic link from /etc is absolutely irrelevant, particularly since all the programs that then reference it do so by looking at /etc, NOT /private/etc.
If you stripped out init, how come 'ps 1' shows me /sbin/init? I know a bunch of things (such as cron) apparently have been modified for Tiger, but they're still just running standard Unix processes to provide similar services.
The system boots in Unix, it runs init, it runs various rc scripts which start various services which then become the processes that present a graphical user interface. It has plenty of stuff in /etc. It uses shell scripts and Perl scripts. It Is a Unix-like system in every way. It is also a Mach-based system, as you can do direct Mach system calls as well.
Having X Windows as the graphical interface isn't what makes a system Unix-like. Having a new device-driver architecture doesn't make a system non-Unix-like. OSX, for the most part, is a set of processes and libraries, conventions and file-system layouts, with a Unix-like kernel at the heart of it. If you leave the Unix libraries and config files and executables, and take away the OSX-specific stuff, you're left with a system that is pretty much Unix. How much of OSX is implemented in the kernel and how much is implemented in shared libraries? How many non-Unix non-Mach (i.e. OSX-specific) system calls are there? How much of the system runs directly under Mach instead of running as a Unix process?
I don't understand why you have such a thing about insisting that what is running on a Mac running OSX isn't "Unix-like", when it clearly is. It goes well beyond that, but at its core it is a fully functioning (well, some of the SysV IPC stuff was broken in whatever version I last checked them out, but whatever) Unix environment.
Linux is NOT a "file-by-file" clone of Unix. /proc isn't even all that old compared to much that is in Unix. There are many ways of doing bootstrap scripts, cron and inet daemons, run levels, etc. OSX is more traditional than Linux in doing some of that, but the specifics of those aren't what make something Unix-like.
If I boot Linux on a root file system that has /sbin/init being a link to, say, tclsh (or use an "init=/bin/tclsh" on the boot command), with a few libraries in /lib that Tcl needs, and include a Tcl extension that gives access to Unix system calls (such as mounting), add the executables for fsck, and write some scripts for mounting file systems and doing other system initialization, implement common commands in Tcl, etc, I'd still have a "Unix-like" system, even if it is very non-traditionally implemented. I'd have to make sure to have a thread running wait() calls to clean up zombie processes, but that's about the only thing special about init. Given that base, I could add any set of user-land executables and libraries and be as traditional as you like. Lots of ways after that to implement a GUI environment without ever getting down into the kernel. I could base something on Wish, for example. It is the kernel, primarily, that makes it Unix-like, at least at the programming level. The standard Unix command line utilities and libraries are the rest of what makes it Unix-like. /dev is a distant third, and /proc doesn't even count. /etc is just a place that various programs default to sticking configuration or other data. /lib and /usr/lib are often hardcoded into the dynamic loader, but don't need to be. Using a different method for common configuration settings is nothing new - see Yellow Pages, for example (now known as NIS). Writing something in a new language such as Objective C doesn't make a system non-Unix.
I suppose if you had a Unix kernel that used a jvm as init, which then ran everything else on the system (maybe with a few "native" executables such as fsck as "helpers"), you could say it wasn't a very Unix-like system even though it had a Unix kernel. But even then, if there was an escape to launch an arbitrary process and pass the output back through a pipe, I'd still say it was mostly Unix-like.
Big Mac: 576 (292 from fat)
Subway Sandwiches:230-370 calories (30-55 from fat)
Quite a few subway sandwiches have fewer calories total than a Big Mac has in fat, although the Big Mac is lower in sodium, and higher in protein.
Of course, you have to stick with the 6-inch sandwich, and not get mayo or cheese on it.
No, the GPL does not require that everything on the media be GPL-compatible.
The Constitutional protection for due process is a restriction against the entire government, not just the courts, and applies to all matters that the government is involved in, not just with regard to citizens. If the executive branch violates that restriction, then the Supreme Court does have jurisdiction as it is a Constitutional matter. Congress isn't allowed to pass laws allowing the executive branch to violate the Constitution, inside or outside the country.
Amendment 5 refers to "no person", not "no citizen". Amendment 14 prohibits States from violating rights guaranteed by the Constitution to citizens, but also prohibits the States from depriving any PERSON (not just citizen) of life/liberty/property without due process, nor deny equal protection under the law to any PERSON within its jurisdiction. Neither limits the rights of non-citizens, either by the States or the Federal government (rights of non-citizens are limited only where a specific right is granted to a "citizen"; most references in the Constitution and the Amendments are to "person" - see for example voting rights, ability to be a Representative or Senator or Vice President or President).
While you're correct that the Federal government doesn't have universal jurisdiction, it only stands to reason that the Judicial branch has universal jurisdiction over the other branches of the government - if the Executive branch can claim that it has jurisdiction in rented land on Cuba, then the Judicial branch surely has jurisdiction over the Executive branch on that same piece of land.
You have to provide more than the modifications, you have to provide all of the source. You can't put up a set of diffs and a link to the original source if you're providing the binary for download.
Sometimes you have to do that, but I prefer instead to make sure that all uses of that buffer don't assume it is zero-terminated unless I can guarantee that it is.
Good example. The person complaining about the x86 growing the stack downward obviously doesn't know that many other architectures do the exact same thing, e.g. PDP-11, 68K, Alpha, PPC. One way to avoid return location overwriting is to have a separate instruction and data stack. Use the instruction stack for return, saved registers, stack links (including data stack), etc. Use the data stack for all programmer-visible local variables. Slightly less efficient, you need two registers for stack pointers, or have to keep reloading the data stack pointer off of the instruction stack. However, you could locate them in the same memory segment (data stack grows upwards, instruction stack grows downwards as usual, extend the memory segment in both directions when you get a fault).
Or don't write stupid code. It really isn't that hard.
No, even if the process was "contaminated", it doesn't show copyright violation. I've read books by Stephen King, it doesn't mean I can't write my own horror novels. The proof is in the similarity of the works, the process being "clean" is only a defense.
The best part of the Eldred decision is that if Congress decides in the future to cut copyright back to 28 years, or to implement some completely different form of copyright, they can do so with no need to worry about "illegal taking of property" considerations. They can make it retroactive to existing works, because the Supreme Court already said they could.
The (L)GPL doesn't make Apple responsible for giving benefit to KDE users. That's not the purpose of the (L)GPL. Apple is responsible for making sure that someone using the code they're distributing can modify it, in this case Safari users (and other Mac OSX clients using the libraries based on KHTML). It certainly doesn't harm the KDE users in any way (and, frankly, it usually isn't that difficult to figure out what changes have been made to a file, given the current file and your own history of revisions). Often it is worthwhile to try to keep your code base synched with the original, but sometimes it creates so much extra work that you shouldn't try. Once you've diverged, your changes become less and less useful to the original project. There's nothing morally or ethically wrong with that (you also lose some benefit for yourself, as you have just as difficult a time merging enhancements or bug fixes from them).
I have a script I sometimes use that takes a file (or set of files) and checks the size of the diff with each version in the RCS/CVS tree, then reports the 5 revisions with the smallest amount of changes. Very effective for identifying an unknown version of a file, whether it has some unchecked-in changes or not.
Providing the complete set of source files is what the (L)GPL requires, not a set of patches.
No, it means *the source code*. I don't edit a CVS file, I don't edit diffs, I edit a source file. The goal of the GPL is that I, someone with a copy of Safari, can get the source code for the program I'm running (or, in the case of the LGPL, those components covered by the LGPL), and be able to make changes to the program I'm running - whether to fix a bug, enhance a feature, or whatever. They don't have to make the changes available to the original programmers at all, they only have to provide the source code that matches a specific binary release. If they release the binary without providing the sources at the time of the release THEN they have to make the complete source files available, but even then they don't have to provide programmer notes, sets of diffs, CVS logs, explanations of why they made the changes (but they can't strip out comments in the source files, either). If comments in the CVS logs contain substantive information documenting code as it is in the source files being released, you could possibly make an argument that those should be included. If it is only documenting why a change was made (e.g. bug tracking number), I don't think that would be required by the (L)GPL.
What files have been changed, but don't say they've been changed or don't give the date of the change?
If you received a binary without the source code, but with an offer (such as a link) to get the source code, AND you are distributing it non-commercially, then you can get by with only providing the original link you got (or other form of offer of the source code "for no more than the cost of distribution"). If, instead, you got the binary along with the source (or the source was available for download at the same time you downloaded the binary), you must either provide the source to anyone who gets a copy from you, or YOU must provide copies of the source for three years to anyone who wants it. If you don't have the source in this situation, you can't re-distribute the binary.
He's also wrong that if you fail to use clean-room reverse-engineering techniques, or a "Chinese wall", you are guilty of copyright violation. Such practices are a good defense against infringement claims, but even without that as a defense you STILL have to show copying. It doesn't change the basic principles of what copying is or what copyright doesn't protect. He seems to think that all you have to show is one manager or programmer who had access to the AT&T protected code base and also had some contact with people working on Linux and *boom* the case is made.
From the Apple developer notes about RAM on the iMac G5:
RAMJET 256MB for iMac G5 for $39, 512 MB for $69, 1G for $139, 2x1G for $275.
It seems very odd that you have to pay "compensation" for exercising a right. Maybe you should have to pay compensation on every musical instrument you buy, because you might play copyrighted songs on it? Or worse yet, you might not buy commercial CDs because you're too busy creating your own music! Definitely requires compensation, they have a right to your money!
Since it's been shown that Life can implement a Universal Turing Machine, that would be pretty cool. Pretty slow, too!