Dave, we've seen several reports implicating Solaris and Linux specifically in the DoS attacks, and the tools provided by you and the FBI are aimed at Linux and Linux-like operating systems. Are these OSs representative of the actual clients which are being co-opted as zombies to launch the DoS attacks, or are they merely typical upstream or intermediate systems with sufficiently rich toolsets to allow monitoring and filtering of traffic.
Information I'd heard from someone who'd experienced an attack was that clients were in fact most typically Windows machines -- which makes sense as they are very common and very easily compromised. The compromising code was described as a windows or Java virus time bomb, pre-set to launch against a specified site at a specified time -- somewhat different from the "master" and "slave" scenario described in the trinoo papers. Several copies of the virus have been retained. How does this fit with your experience?
I believe the original rationale for disallowing copyright in federal government works was to prevent the government from, say, passing a new law, but not providing legal right for anyone to publish the law. Think through the various wrinkles on that one. There are a number of avenues for abuse.
Note that the prohibition applies only to the US Federal government. State governments may, if allowed under their own statutes, hold copyright in their own work. Other national goverments may also, if allowed under their own statutes, claim copyright in their own works. I believe there have been cases in which each of these mechanisms have been used, most recent on the international scope involving Australia and encryption policy, IIRC.
Note also that the US government can hold copyright if it has been assigned the copyright by the former rights holder.
Not sure what all the legal arguments are, but the case for allowing US Gov't claims to copyright for GPLd works of its own authorship are weak. In many cases, the government is in somewhat the same position as academics who created the BSD and X licenses -- reuse, either under free or proprietary terms, is to be encouraged.
Once code has been authored (or modified) and released under the GPL by another party, the problem should be moot.
What's particulary painful is that this is a clear case in which source distribution would be a major plus. If this code is a work of the US Federal Government, then it is not protected by copyright under 17 USC 105.
Interestingly, this means that the GNU GPL is powerless to protect the work -- something which is public domain cannot be sheltered by copyright -- but it should be eminantly possible to reverse engineer and enhance the program. Modifications themselve should be covered under copyright law, and might be governed by the GPL or another license.
I would be far happier seeing full source to any such tools before installing them on my own systems.
I haven't downloaded Stefan's junkbuster, but reviewing his page:
The current implementation of the main Junkbuster includes an option to replace banners with a 1x1 clear gif, which also sizes to fit. The other options are to substitute a "Junkbuster" image, or the broken icon.
My complaint against long blockfiles is that you start crossing the diminishing returns threshhold, and long lists become difficult to proof. My short list gives ~90%+ effectiveness, and is relatively easy to tune and test. All inclusive lists are interesting, but can be more bug-prone. I've seen a couple of samples posted here which block domains I'd choose not to (netcom.com?!).
I don't know Australian copyright law. Much of copyright law is standardized internationally under the Berne Treaty. I don't know what the status of the DMCA act enacted in 1998 in the US is internationally.
What are known as the anti-circumvention provisions of US law (17 U.S.C. 1201. In part it reads:
No person shall circumvent a technological measure that effectively controls access to a work protected under this title.
If you aren't given licensed access to protected media, you are circumventing the measure. If there are no licensed tools available for Linux, then ipso facto you are violating the above provision if you are viewing CSS protected DVDs on Linux. In the US. Possibly elsewhere.
There are other legal dimensions to the case. Distributing DeCSS code falls under another portion of the same law (scroll down the link provided). Trade secrets law is being used in several instances, this appears to the be hook used to snare Jon Johansen.
Thanks. Cool reference. I'd run across the Netrek authentication concepts a while back. There's also a paper on doing authenticatable distributed computation at the COAST website somewhere. PS format, IIRC.
This is one of the few potentially viable options I see, though there are still a lot of questions to answer for.
One problem is that $20/mo is about the rental cost for, again, new hardware. The average age of installed base is probably in the range of 2-4 years. My own PII/180 is adequate for my own tasks, but is about 1/3 to 1/4 the speed of a new system -- would I get only $5 to $7 per month of credit?
The pricing angle is one that I'm not settled on -- depends on supply and demand. If companies could instantaneously add and remove compute power, the base HW costs would probably work out about right. The convenience value of being able to add and remove capacity rapidly and without physical deployment requirements might make higher rental rates possible, but you've also got to figure overhead and a percentage for the business itself. The business case is slim. Possible, but slim.
YANI -- Yet another harebrained idea: the emerging ASP market coult be modified slightly around this concept. Essentially CoWs, but rentable. This is a more likely doable option IMO.
You mean like, say, VMWare? Hell, isn't a virtual machine the ultimate meta client? Running, of course, a streamlined Linux OS. A Java VM is another option. Both take performance hits.
I was brainstorming around this general idea a while ago. The general problems I came up with were:
Security of the host system.
Authentication of the client application.
Criteria for determining "worthy" projects.
Billing, accounting, or payment tie-ins.
First off, distributed computing is very successful in some closed environments -- POW (pile of workstation) clusters in campus environments are common. A friend at a New Zealand biotech firm distributes Linux boot floppies. At the end of the "work" day, their Windows boxes are rebooted with this floppy installed, a Linux machine springs into place, and a gene sequencing client starts munching away -- the real work day. Similar schemes are pretty common.
In a broader environment with less control the problem becomes tougher. The host machine needs to have some guarantee of security. The client should also be reasonably secure and non-spoofable. There needs to be authentication.
In order to select for worthy (or billable) projects, some sort of voting scheme needs to b e implemented. If this is based on dollars or bill-backs, the small size of the individual contributions, with per-month CPU rental rates rating < $20 for new equipment (essentially the lease cost for hardware) -- means that this is not a way to get rich.
Factor in latency, bandwidth, lossage, and storage factors. It's a complicated problem.
This isn't to say it's not addressable. Distributed Net appears to be actively researching several of these areas. It's quite possible that all that idle CPU time will one day be put to use. But not real soon now.
If a company says it's going to do one thing, then does another, then they're open for a whole mess of legal problems -- misrepresentation, fraud, etc. A legal friend of mine is interested in pursuing this idea on the spam front -- include a header which says "this message is not spam", allowing people to filter on it. Including this header (a non-default, BTW) in mail which is spam then becomes legally actionable.
Similar logic applies to Doubleclick. Do I give them the chance. No.
Most club cards require zero authentication of ID. For years, my local grocery club card was listed as belonging to the CEO of a large IT organization (no, not that one, or that one).
If you're familiar with IT operations, Fred Flintstone (etc.), Test User, Test Account, Admin Account, and similar interesting first/last name combinations can be fun to try.
...that's full agreement with all points above. For Linux users, deploying Junkbuster is as easy as downloading the RPM or DEB file and installing it. For Windows users, either NT or Win9x, you can also use the proxy.
Both the banner and cookie action are way cool. The following blockfile eliminates pretty darned near all the banner ads (and the sites associated with them if a full site or domain is listed). Note that I've allowed banners at a number of Linux-friendly sites, on principle, though you could change this if you wanted.
No, I don't speak Norwegian. But I can make out just enough from what little German I know to see that there are several stories about a programmer name Jon Johansen involving DVDs.
Being vaguely familiar with how patents work, I did a search at the IBM Patent server (http://www.patents.ibm.com/) under the Boolean search tool for "public & key & encryption". This matched 266 items, including items for:
...etc. I'm not saying that each of these is a relevant or blocking patent, but the search space here is huge. It's also possible that there are relevant patents which don't contain the keywords used in my search.
Granted that the search tools are primitive, but is anyone aware of any key patents covering public key encryption as related to web servers, e-commerce, business models, or any related type applications which could still effectively limit access to RSA PKI security for practical purposes?
Under the language "all persons acting in concert with them" (line 28 p1 of brief), VA might be considered a defendant as they are both selling Linux-based systems, and host Chris DiBona's website, and are located in the State of California, hence coming under the jurisdiction of this case.
I believe this establishes a basis for arguing economic harm.
Mind you, I think that stomping on Constitutional free speech rights constitutes major harm as well.
This is a good idea, though there's one immediately apparent problem: Just because a party has the right to sue doesn't mean they have the obligation to sue. MPAA can pick its fights. It hasn't yet picked on the search engines. Rather, they've attacked a handful of loosely organized and likely poorly defended individuals. It's easier to establish a favorable precedent this way.
Though the search engines might be considered possible legal targets based on their actions, their ability to muster legal resources makes them less likely to be considered feasible litigation targets. If this is how the search engines perceive themselves, they're likely to see little direct motivation to get involved in the current cases.
Methinks we need to do some marketing to the search engines.
Or more pointedly, archives such as Remarq and Deja, who directly hold copies of the alleged infringing content.
The fact that the anti-circumvention statute is not yet effective was mentioned in a CNI-Copyright response this morning, with a pointer to the Library of Congress feeback page at http://www.loc.gov/copyright/1201/anticirc.html.
The Copyright Office is first seeking written and reply comments from interested parties in order to elicit information and views on whether noninfringing uses of certain classes of works are, or are likely to be, adversely affected by the prohibition against circumvention of access control technologies. Persons interested in submitting comments should consult the November 24, 1999 notice of inquiry published in the Federal Register. Further background on this rulemaking may also be found in the notice of inquiry.
Comments are due February 10, 2000
Unfortunately, Andy's overlooked the fact that the NY & CT cases are based both on 17 USC 1201(a)(1)(A) and 1201(b)(1) & (2). Reverse engineering applies only to the Norwegian minor who cracked the DVD CSS algorithm. The plaintiffs in the New York and Connecticut cases are charged with violations of 17 USC 1201(b). There is no grace period for violations of this portion of the statute.
other interesting section though, 1201(c)(2):
There is an(2) Nothing in this section shall enlarge or diminish vicarious or contributory liability for copyright infringement in connection with any technology, product, service, device, component, or part thereof.
Among related legal cites, there's a case Lasercomb America v. Reynolds involving allowable licensing conditions in which licensing terms were overturned by the court. Though the scope -- licensing, not copyright -- is different, the conclusion is of interest. Essentially, patent-like protections from deploying technology are not attainable without resorting to patent protection itself.
{96} Overreaching occurs where a license agreement places impermissible restrictions on the licensee's activities relating to the licensed software. Under such circumstances, the license agreement may be invalidated in whole or in part. Common issues where overreaching takes place are prohibitions on reverse-engineering coupled with copying of the program, and non-compete clauses which are anticompetitive.
{97} Often overreaching occurs where the licensor is trying to contractually obtain patent-like protection for licensed software without meeting the rigorous requirements of patent law. It also occurs where the software sought to be protected contains functional elements unprotected under copyright law, and where reverse-engineering is the only method available for the licensee to understand how the licensed software works to achieve compatibility with other components of its computer system.
One wonders if the same logic might be applied to copyright law itself.
Copying DVDs is trivial given either an open-source DVD player or a reeingineered sound/video driver which allows interception of the datastream on its way to your monitor and speakers.
The difference between the two methods is that the DVD player approach is one step closer to source, and nominally provides a higher-quality clone of the original material. However, if the economics of bootlegging are favorable, quashing DeCSS will not protect the movie industry against the purported threat.
The fact remains that the economics of pirating DVDs are overwhelmingly unfavorable to producing cheap knock-off disks. Archival space, duplicating equipment, blanks, and transmission time are currently cost-prohibitive -- it's easier to spend the 15 bucks on a legit version.
This case is not about piracy and bootlegging of content, it's about manufacturer interest in closing out competitive replay technology, especially free technology for which no cost-recapture is possible. The rest of the rhetoric is simply hot air.
What is extremely aggregious is the perversion of copyright law to something which has nothing whatsoever to do with copyright infringement. The legal threats against those who link to DeCSS code is removed from piracy by:
Link to source code.
Compilation of source code to runable machine code.
Aquisition of copyrighted DVD work.
Replay of copyrighted DVD using DeCSS.
Private copy of DVD work (which may well be legal under private use video duplication law) on local storage.
Duplication of DVD work onto new media.
Distribution of said media.
That is SEVEN degrees of seperation from real economic damage. Hello!?
The fact is that what is being called a copyright infringement is, while a technical violation of copyright law, in no way whatsoever actually infringing the copyright of any DVD in existence.
The DeCSS/DVD case revolves around a little-known and recently (Oct, 1998) enacted bit of copyright law known as 17 U.S.C. 1201, Circumvention of copyright protection systems
There is an excellent review and analysis of this law by Professor Pamela Samuelson of the University of California, Berkeley. Her paper Intellectual Property and the Digital Economy: Why the Anti-Circumvention Regulations Need to Be Revised, published last year, takes a long look at the law, its history, and many, many problems. I recommend it strongly to anyone, legal community or lay, who wants an understanding of the problems of the law. Samuelson also presents some of its weaknesses, which may be helpful in developing a legal defense in the California, New York, and Connecticut cases.
It's a long read (40 pages), give it a shot. From the introduction:
The Digital Millennium Copyright Act of 1998 ("DMCA") prohibits the circumvention of technological protection measures used by copyright owners to control access to their works. It also bans devices whose primary purpose is to enable circumvention of technical protection systems. The Clinton administration proposed these anti-circumvention rules as implementations of U.S. obligations under the World Intellectual Property Organization Copyright Treaty. However, the DMCA?s provisions are significantly broader than the treaty required. They violate the Administration?s stated goal of only imposing "predictable, minimalist, consistent, and simple" regulations on the budding digital economy.
Although Congress heeded some concerns of digital economy firms by crafting certain exceptions to authorize legitimate circumvention, those exceptions are overly narrow and shortsighted. They should be supplemented by a more general "other legitimate purposes" exception. The DMCA's anti-device provisions are, moreover, overbroad and unclear, especially on the question whether it is legal to develop a technology necessary to engage in a privileged act of circumvention (e.g., a fair use). Either Congress or the courts will be forced to constrain the reach of the anti-device rules so as not to undermine Congressional intent to preserve fair uses and so as not to harm competition and innovation in the information technology sector. Finally, though the DMCA provides for a study of one class of potentially harmful impacts of the anti-circumvention rules, this study needs to be broadened to consider the full impact of this unprecedented legislation.
Schwab, excellent reporting job. Damn I wish I'd been able to attend the session!
Eblen Moglen, if you don't know, is a Columbia Law School professor, and has provided legal assistance to the FSF for years. His views are rather leftish and he's very much the consumer/public advocate. His legal arguments are superb. I've read his stuff, it would have been wonderful to see him in action.
The DeCSS cases are very interesting in that they're pushing the limits of two rather tenuous legal constructs: shrinkwrap (in particular, American commerce law, which is actually state law, applied against a foreign national minor for actions in a foreign country), and 17 USC 1201, the anti-circumvention measures added to copyright law in 1998 by the DMCA.
Shrinkwrap has been under attack for years. While there is some justification to holding that some legal obligations may be made or liabilities avoided by "shrink wrap" agreements (one landmark case involves cruise ship liability attached to ticket purchase), the extant claims attached to most software these days can only be seen as ludicrous.
The anti-circumvention provisions of copyright have been tested somewhat in actions by Sony against
...and I suppose that if T-shirt slogans are juvinile, that the Vietnam war protesters really didn't warrant serious consideration.
To clarify your points about the GPL vis-a-vis shrinkwrap licenses:
Shrink wrap licenses restrict rights you would otherwise have if the license did not restrict them. Eg: Reverse engineering rights. They also grant other rights.
The GNU GPL grants rights, reserved by Copyright law in a highly uniform fashion worldwide, which you would not have if the license did not grant them to you.
Typical shrinkwrap licenses are subtractive instruments. The GPL is an additive instrument.
One point of disagreement. I think that there are conditions, useful, and very limited, under which shrinkwrap agreements are an acceptable means of reaching a codified agreement between two parties. You do this all the time -- if you park your car in a private lot, buy a movie ticket, book a flight, etc. However, the rights which can be reserved, and the rights you are required to give up, under such agreements should be very tightly limited. I do agree strongly that the current situation involving shrinkwrap/clickwrap licenses is insane, and that the likely changes under UCITA are even worse.
First, do you mean "why do distros come with one installer" or "why do they come with one package manager". There's a difference.
The installer is somewhat insignificant -- you want a piece of software which can boot the system, partition disks, set up some reasonable base defaults, and connect you to a package management system. Ideally you only need do this once. To date I've heard of bootstrap installs (you've got a running system and build a second under it), RH, Debian, YAST, etc., Windows-based installation programs, etc. There are several flavors of installer built around RPM, dpkg, and whatever it is that Slack uses. Reasonably moot issue. Why does everyone seem to have their own? Probably a combination of NIH and support (we support our installer...).
The package management system is a different horse. This is what you're relying on to maintain, upgrade, and verify your system over time. In large part it consists of a package database, some method for identifying dependencies and/or relationships, and possibly some way of resolving them. This isn't a task which is easily split among several systems on a single box.
There are tools for managing packages from one system under another. 'alien' is one such tool, and it permits RPMs to be installed under Debian, and vice versa. But AFIAK, you lose many of the benefits of integrated package management. Ultimately with today's package management architectures, someone's got to rule the roost, and peered administration isn't supported.
Corel's Linux distro is built around Debian. It's one of the most slickified distros out there -- if you believe MSNBC's writeup. If you want Debian package management without the krufty interfaces, give it a whirl.
Slashdot Mirror
Dave, we've seen several reports implicating Solaris and Linux specifically in the DoS attacks, and the tools provided by you and the FBI are aimed at Linux and Linux-like operating systems. Are these OSs representative of the actual clients which are being co-opted as zombies to launch the DoS attacks, or are they merely typical upstream or intermediate systems with sufficiently rich toolsets to allow monitoring and filtering of traffic.
Information I'd heard from someone who'd experienced an attack was that clients were in fact most typically Windows machines -- which makes sense as they are very common and very easily compromised. The compromising code was described as a windows or Java virus time bomb, pre-set to launch against a specified site at a specified time -- somewhat different from the "master" and "slave" scenario described in the trinoo papers. Several copies of the virus have been retained. How does this fit with your experience?
What part of "Gestalt" don't you understand?
I'm missing your meaning here.
I believe the original rationale for disallowing copyright in federal government works was to prevent the government from, say, passing a new law, but not providing legal right for anyone to publish the law. Think through the various wrinkles on that one. There are a number of avenues for abuse.
Note that the prohibition applies only to the US Federal government. State governments may, if allowed under their own statutes, hold copyright in their own work. Other national goverments may also, if allowed under their own statutes, claim copyright in their own works. I believe there have been cases in which each of these mechanisms have been used, most recent on the international scope involving Australia and encryption policy, IIRC.
Note also that the US government can hold copyright if it has been assigned the copyright by the former rights holder.
Not sure what all the legal arguments are, but the case for allowing US Gov't claims to copyright for GPLd works of its own authorship are weak. In many cases, the government is in somewhat the same position as academics who created the BSD and X licenses -- reuse, either under free or proprietary terms, is to be encouraged.
Once code has been authored (or modified) and released under the GPL by another party, the problem should be moot.
What part of "Gestalt" don't you understand?
What's particulary painful is that this is a clear case in which source distribution would be a major plus. If this code is a work of the US Federal Government, then it is not protected by copyright under 17 USC 105.
Interestingly, this means that the GNU GPL is powerless to protect the work -- something which is public domain cannot be sheltered by copyright -- but it should be eminantly possible to reverse engineer and enhance the program. Modifications themselve should be covered under copyright law, and might be governed by the GPL or another license.
I would be far happier seeing full source to any such tools before installing them on my own systems.
IANAL. This is not legal advice.
What part of "Gestalt" don't you understand?
I haven't downloaded Stefan's junkbuster, but reviewing his page:
What part of "Gestalt" don't you understand?
I don't know Australian copyright law. Much of copyright law is standardized internationally under the Berne Treaty. I don't know what the status of the DMCA act enacted in 1998 in the US is internationally.
What are known as the anti-circumvention provisions of US law (17 U.S.C. 1201. In part it reads:
No person shall circumvent a technological measure that effectively controls access to a work protected under this title.
If you aren't given licensed access to protected media, you are circumventing the measure. If there are no licensed tools available for Linux, then ipso facto you are violating the above provision if you are viewing CSS protected DVDs on Linux. In the US. Possibly elsewhere.
There are other legal dimensions to the case. Distributing DeCSS code falls under another portion of the same law (scroll down the link provided). Trade secrets law is being used in several instances, this appears to the be hook used to snare Jon Johansen.
IANAL, this is not legal advice.
What part of "Gestalt" don't you understand?
Thanks. Cool reference. I'd run across the Netrek authentication concepts a while back. There's also a paper on doing authenticatable distributed computation at the COAST website somewhere. PS format, IIRC.
What part of "Gestalt" don't you understand?
This is one of the few potentially viable options I see, though there are still a lot of questions to answer for.
One problem is that $20/mo is about the rental cost for, again, new hardware. The average age of installed base is probably in the range of 2-4 years. My own PII/180 is adequate for my own tasks, but is about 1/3 to 1/4 the speed of a new system -- would I get only $5 to $7 per month of credit?
The pricing angle is one that I'm not settled on -- depends on supply and demand. If companies could instantaneously add and remove compute power, the base HW costs would probably work out about right. The convenience value of being able to add and remove capacity rapidly and without physical deployment requirements might make higher rental rates possible, but you've also got to figure overhead and a percentage for the business itself. The business case is slim. Possible, but slim.
YANI -- Yet another harebrained idea: the emerging ASP market coult be modified slightly around this concept. Essentially CoWs, but rentable. This is a more likely doable option IMO.
What part of "Gestalt" don't you understand?
I was brainstorming around this general idea a while ago. The general problems I came up with were:
First off, distributed computing is very successful in some closed environments -- POW (pile of workstation) clusters in campus environments are common. A friend at a New Zealand biotech firm distributes Linux boot floppies. At the end of the "work" day, their Windows boxes are rebooted with this floppy installed, a Linux machine springs into place, and a gene sequencing client starts munching away -- the real work day. Similar schemes are pretty common.
In a broader environment with less control the problem becomes tougher. The host machine needs to have some guarantee of security. The client should also be reasonably secure and non-spoofable. There needs to be authentication.
In order to select for worthy (or billable) projects, some sort of voting scheme needs to b e implemented. If this is based on dollars or bill-backs, the small size of the individual contributions, with per-month CPU rental rates rating < $20 for new equipment (essentially the lease cost for hardware) -- means that this is not a way to get rich.
Factor in latency, bandwidth, lossage, and storage factors. It's a complicated problem.
This isn't to say it's not addressable. Distributed Net appears to be actively researching several of these areas. It's quite possible that all that idle CPU time will one day be put to use. But not real soon now.
What part of "Gestalt" don't you understand?
If a company says it's going to do one thing, then does another, then they're open for a whole mess of legal problems -- misrepresentation, fraud, etc. A legal friend of mine is interested in pursuing this idea on the spam front -- include a header which says "this message is not spam", allowing people to filter on it. Including this header (a non-default, BTW) in mail which is spam then becomes legally actionable.
Similar logic applies to Doubleclick. Do I give them the chance. No.
Yes, the law can be your friend.
What part of "Gestalt" don't you understand?
If you're familiar with IT operations, Fred Flintstone (etc.), Test User, Test Account, Admin Account, and similar interesting first/last name combinations can be fun to try.
What part of "Gestalt" don't you understand?
...that's full agreement with all points above. For Linux users, deploying Junkbuster is as easy as downloading the RPM or DEB file and installing it. For Windows users, either NT or Win9x, you can also use the proxy.
Both the banner and cookie action are way cool. The following blockfile eliminates pretty darned near all the banner ads (and the sites associated with them if a full site or domain is listed). Note that I've allowed banners at a number of Linux-friendly sites, on principle, though you could change this if you wanted.
/*.*/ad/
/*.*/ads/
/*.*/advert/
/*.*/adverts/
a32.g.a.yimg.com/
ad.*.*
adforce.imgis.com/
adremote.*.*
ads*.*.*
doubleclick.net
image.pathfinder.com/sponsors*
preferences.com
sfgate.com/place-ads
Those few lines block virtually all the ad traffic I see.
For cookies, I block all, then selectively allow a limited number of sites with which I do business. Mostly message boards.
There was a really good program Online Profiling on NPR's Talk of the Nation a couple of months back. Other useful resources are Center for Democracy and Technology, and for a look at the other side, NetworkAdvertising.Org and Direct Marketing Association
If setting up a proxy is too much for you, the following tricks will prevent a permanent cookie file from being generated:
I'm not sure what the corresponding IE trix are. For Linux, lynx and other browsers can use the link to /dev/null trick.
What part of "Gestalt" don't you understand?
No, I don't speak Norwegian. But I can make out just enough from what little German I know to see that there are several stories about a programmer name Jon Johansen involving DVDs.
Try this story or these search results. Hmmm... anyone know a Norwegian Bablefish?
What part of "Gestalt" don't you understand?
Being vaguely familiar with how patents work, I did a search at the IBM Patent server (http://www.patents.ibm.com/) under the Boolean search tool for "public & key & encryption". This matched 266 items, including items for:
...etc. I'm not saying that each of these is a relevant or blocking patent, but the search space here is huge. It's also possible that there are relevant patents which don't contain the keywords used in my search.
Granted that the search tools are primitive, but is anyone aware of any key patents covering public key encryption as related to web servers, e-commerce, business models, or any related type applications which could still effectively limit access to RSA PKI security for practical purposes?
What part of "Gestalt" don't you understand?
Apple lost their "look and feel" in Apple v. Microsoft.
What part of "Gestalt" don't you understand?
Yes, you too can find this via Google, but here is a picking of more relevant material:
What part of "Gestalt" don't you understand?
Under the language "all persons acting in concert with them" (line 28 p1 of brief), VA might be considered a defendant as they are both selling Linux-based systems, and host Chris DiBona's website, and are located in the State of California, hence coming under the jurisdiction of this case.
I believe this establishes a basis for arguing economic harm.
Mind you, I think that stomping on Constitutional free speech rights constitutes major harm as well.
What part of "Gestalt" don't you understand?
This is a good idea, though there's one immediately apparent problem: Just because a party has the right to sue doesn't mean they have the obligation to sue. MPAA can pick its fights. It hasn't yet picked on the search engines. Rather, they've attacked a handful of loosely organized and likely poorly defended individuals. It's easier to establish a favorable precedent this way.
Though the search engines might be considered possible legal targets based on their actions, their ability to muster legal resources makes them less likely to be considered feasible litigation targets. If this is how the search engines perceive themselves, they're likely to see little direct motivation to get involved in the current cases.
Methinks we need to do some marketing to the search engines.
Or more pointedly, archives such as Remarq and Deja, who directly hold copies of the alleged infringing content.
What part of "Gestalt" don't you understand?
The fact that the anti-circumvention statute is not yet effective was mentioned in a CNI-Copyright response this morning, with a pointer to the Library of Congress feeback page at http://www.loc.gov/copyright/1201/anticirc .html.
The Copyright Office is first seeking written and reply comments from interested parties in order to elicit information and views on whether noninfringing uses of certain classes of works are, or are likely to be, adversely affected by the prohibition against circumvention of access control technologies. Persons interested in submitting comments should consult the November 24, 1999 notice of inquiry published in the Federal Register. Further background on this rulemaking may also be found in the notice of inquiry.
Comments are due February 10, 2000
Unfortunately, Andy's overlooked the fact that the NY & CT cases are based both on 17 USC 1201(a)(1)(A) and 1201(b)(1) & (2). Reverse engineering applies only to the Norwegian minor who cracked the DVD CSS algorithm. The plaintiffs in the New York and Connecticut cases are charged with violations of 17 USC 1201(b). There is no grace period for violations of this portion of the statute.
other interesting section though, 1201(c)(2):
There is an(2) Nothing in this section shall enlarge or diminish vicarious or contributory liability for copyright infringement in connection with any technology, product, service, device, component, or part thereof.
(http://www4.law.cornell.edu/uscode/17 /1201.html)
What does this mean?
What part of "Gestalt" don't you understand?
Among related legal cites, there's a case Lasercomb America v. Reynolds involving allowable licensing conditions in which licensing terms were overturned by the court. Though the scope -- licensing, not copyright -- is different, the conclusion is of interest. Essentially, patent-like protections from deploying technology are not attainable without resorting to patent protection itself.
Quoting from http://www.richmond.edu/~jolt/v1i1/l iberman.html:
{96} Overreaching occurs where a license agreement places
impermissible restrictions on the licensee's activities relating
to the licensed software. Under such circumstances, the license
agreement may be invalidated in whole or in part. Common issues where
overreaching takes place are prohibitions on reverse-engineering
coupled with copying of the program, and non-compete clauses which
are anticompetitive.
{97} Often overreaching occurs where the licensor is trying to
contractually obtain patent-like protection for licensed software
without meeting the rigorous requirements of patent law. It
also occurs where the software sought to be protected contains
functional elements unprotected under copyright law, and where
reverse-engineering is the only method available for the licensee to
understand how the licensed software works to achieve compatibility
with other components of its computer system.
One wonders if the same logic might be applied to copyright law itself.
What part of "Gestalt" don't you understand?
Copying DVDs is trivial given either an open-source DVD player or a reeingineered sound/video driver which allows interception of the datastream on its way to your monitor and speakers.
The difference between the two methods is that the DVD player approach is one step closer to source, and nominally provides a higher-quality clone of the original material. However, if the economics of bootlegging are favorable, quashing DeCSS will not protect the movie industry against the purported threat.
The fact remains that the economics of pirating DVDs are overwhelmingly unfavorable to producing cheap knock-off disks. Archival space, duplicating equipment, blanks, and transmission time are currently cost-prohibitive -- it's easier to spend the 15 bucks on a legit version.
This case is not about piracy and bootlegging of content, it's about manufacturer interest in closing out competitive replay technology, especially free technology for which no cost-recapture is possible. The rest of the rhetoric is simply hot air.
What is extremely aggregious is the perversion of copyright law to something which has nothing whatsoever to do with copyright infringement. The legal threats against those who link to DeCSS code is removed from piracy by:
That is SEVEN degrees of seperation from real economic damage. Hello!?
The fact is that what is being called a copyright infringement is, while a technical violation of copyright law, in no way whatsoever actually infringing the copyright of any DVD in existence.
What part of "Gestalt" don't you understand?
The DeCSS/DVD case revolves around a little-known and recently (Oct, 1998) enacted bit of copyright law known as 17 U.S.C. 1201, Circumvention of copyright protection systems
There is an excellent review and analysis of this law by Professor Pamela Samuelson of the University of California, Berkeley. Her paper Intellectual Property and the Digital Economy: Why the Anti-Circumvention Regulations Need to Be Revised , published last year, takes a long look at the law, its history, and many, many problems. I recommend it strongly to anyone, legal community or lay, who wants an understanding of the problems of the law. Samuelson also presents some of its weaknesses, which may be helpful in developing a legal defense in the California, New York, and Connecticut cases.
It's a long read (40 pages), give it a shot. From the introduction:
The Digital Millennium Copyright Act of 1998 ("DMCA") prohibits the circumvention of technological protection measures used by copyright owners to control access to their works. It also bans devices whose primary purpose is to enable circumvention of technical protection systems. The Clinton administration proposed these anti-circumvention rules as implementations of U.S. obligations under the World Intellectual Property Organization Copyright Treaty. However, the DMCA?s provisions are significantly broader than the treaty required. They violate the Administration?s stated goal of only imposing "predictable, minimalist, consistent, and simple" regulations on the budding digital economy.
Although Congress heeded some concerns of digital economy firms by crafting certain exceptions to authorize legitimate circumvention, those exceptions are overly narrow and shortsighted. They should be supplemented by a more general "other legitimate purposes" exception. The DMCA's anti-device provisions are, moreover, overbroad and unclear, especially on the question whether it is legal to develop a technology necessary to engage in a privileged act of circumvention (e.g., a fair use). Either Congress or the courts will be forced to constrain the reach of the anti-device rules so as not to undermine Congressional intent to preserve fair uses and so as not to harm competition and innovation in the information technology sector. Finally, though the DMCA provides for a study of one class of potentially harmful impacts of the anti-circumvention rules, this study needs to be broadened to consider the full impact of this unprecedented legislation.
What part of "Gestalt" don't you understand?
Schwab, excellent reporting job. Damn I wish I'd been able to attend the session!
Eblen Moglen, if you don't know, is a Columbia Law School professor, and has provided legal assistance to the FSF for years. His views are rather leftish and he's very much the consumer/public advocate. His legal arguments are superb. I've read his stuff, it would have been wonderful to see him in action.
The DeCSS cases are very interesting in that they're pushing the limits of two rather tenuous legal constructs: shrinkwrap (in particular, American commerce law, which is actually state law, applied against a foreign national minor for actions in a foreign country), and 17 USC 1201, the anti-circumvention measures added to copyright law in 1998 by the DMCA.
Shrinkwrap has been under attack for years. While there is some justification to holding that some legal obligations may be made or liabilities avoided by "shrink wrap" agreements (one landmark case involves cruise ship liability attached to ticket purchase), the extant claims attached to most software these days can only be seen as ludicrous.
The anti-circumvention provisions of copyright have been tested somewhat in actions by Sony against
...and I suppose that if T-shirt slogans are juvinile, that the Vietnam war protesters really didn't warrant serious consideration.
To clarify your points about the GPL vis-a-vis shrinkwrap licenses:
Typical shrinkwrap licenses are subtractive instruments. The GPL is an additive instrument.
One point of disagreement. I think that there are conditions, useful, and very limited, under which shrinkwrap agreements are an acceptable means of reaching a codified agreement between two parties. You do this all the time -- if you park your car in a private lot, buy a movie ticket, book a flight, etc. However, the rights which can be reserved, and the rights you are required to give up, under such agreements should be very tightly limited. I do agree strongly that the current situation involving shrinkwrap/clickwrap licenses is insane, and that the likely changes under UCITA are even worse.
What part of "Gestalt" don't you understand?
...and when is Malda going to give us real <pre> tags....
!##NETSCAPE
Netscape*drawingArea.translations:#merge\
<Btn1Down>:&nb sp;&nb sp;ArmLink()\n\
<Btn2Down>:&nb sp;&nb sp;ArmLink()\n\
~Shift<Btn1Up>: 
~Shift<Btn2Up>: 
&n bsp;&n bsp;DisarmLink()&n bsp;\n\
Shift<Btn1Up>: ActivateLink(save-only)\
&n bsp;&n bsp;DisarmLink()&n bsp;\n\
Shift<Btn2Up>: ActivateLink(save-only)\
&n bsp;&n bsp;DisarmLink()&n bsp;\n\
<Btn1Motion>:& nbsp;& nbsp;DisarmLinkIfMoved()\n\
<Btn2Motion>:& nbsp;& nbsp;DisarmLinkIfMoved()\n\
<Btn3Motion>:& nbsp;& nbsp;DisarmLinkIfMoved()\n\
<Motion>: 
<Btn3Down>:&nb sp;&nb sp;xfeDoPopup()\n\
<Btn3Up>: 
Ctrl<Btn4Down>:PageUp()\n\
Ctrl<Btn5Down>:PageDown()\ n\
Shift<Btn4Down>:LineUp()\n \
Shift<Btn5Down>:LineDown() \n\
None<Btn4Down>:LineU p()LineUp()LineUp()LineUp()LineUp()LineUp()\n\
None<Btn5Down>:LineD own()LineDown()LineDown()LineDown()LineDown()Line
Alt<Btn4Down>:xfeDoCommand (forward)\n\
Alt<Btn5Down>:xfeDoCommand (back)\n
Shift<Key>space:PageUp()\n\
<Key>space:PageDown()\n\
<Key>BackSpace:xfeDoComman d(back)\n\
!<Key>Left:xfeDoCommand(back)\n\
!<Key>Right:xfeDoCommand(forward )\n
Netscape*globalNonTextTranslations:#merge\
Shift<Btn4Down>:LineUp()\n\
Shift<Btn5Down>:LineDown()\n\
None<Btn4Down>:LineUp()LineUp()LineUp()LineUp()
None<Btn5Down>:LineDown()LineDown()LineDown()Li
Alt<Btn4Down>:xfeDoCommand(forward)\n\
Alt<Btn5Down>:xfeDoCommand(back)\n
Shift<Key>space:PageUp()\n\
<Key>space:PageDown()\n\
!<Key>BackSpace:xfeDoCommand(back)\n\
!<Key>Left:xfeDoCommand(back)\n\
!<Key>Right:xfeDoCommand(forward )\n
#Restricttherangeofsizeincrementsallowed&nbs p;by<fontsize=n>directivesto
#therange80%-120%ratherthan50%-& nbsp;210%.Defaultincrementis20.
#KMSelfWedDec2915:47:57PST1999
Netscape*documentFonts.sizeIncrement:05
#Cleanupthefsckingtoolbar
Netscape*toolBar.search.isEnabled:false
Netscape*toolBar.destinations.isEnabled:false
Netscape*toolBar.myshopping.isEnabled:false
Netscape*toolBar.viewSecurity.isEnabled:false
Netscape*toolBar.print.isEnabled:true
Netscape*toolBar.home.isEnabled:true
#Andsomeotherbraindamage
Netscape*useStdoutDialog:false
Netscape*useStderrDialog:false
Netscape*noAboutSplash:true
#Fonts--dialogsandsuch
Netscape*attachmentProps*XmLabelGadget.fontList
Netscape*AddressBook*mainform.fontList: fixed
Netscape*XmLGrid*fontList: fixed
Netscape*attachItemLabel*fontList: fixed
Netscape*prefs*fontList: fixed
Netscape*statusBar*fontList: fixed
#Documentfonts--scalingdoesn'tappearto takeeffectw/TTFfonts
Netscape*documentFonts.defaultFont*iso-8859-1.p
Netscape*documentFonts.defaultFont*iso-8859-1.f
What part of "Gestalt" don't you understand?
First, do you mean "why do distros come with one installer" or "why do they come with one package manager". There's a difference.
The installer is somewhat insignificant -- you want a piece of software which can boot the system, partition disks, set up some reasonable base defaults, and connect you to a package management system. Ideally you only need do this once. To date I've heard of bootstrap installs (you've got a running system and build a second under it), RH, Debian, YAST, etc., Windows-based installation programs, etc. There are several flavors of installer built around RPM, dpkg, and whatever it is that Slack uses. Reasonably moot issue. Why does everyone seem to have their own? Probably a combination of NIH and support (we support our installer...).
The package management system is a different horse. This is what you're relying on to maintain, upgrade, and verify your system over time. In large part it consists of a package database, some method for identifying dependencies and/or relationships, and possibly some way of resolving them. This isn't a task which is easily split among several systems on a single box.
There are tools for managing packages from one system under another. 'alien' is one such tool, and it permits RPMs to be installed under Debian, and vice versa. But AFIAK, you lose many of the benefits of integrated package management. Ultimately with today's package management architectures, someone's got to rule the roost, and peered administration isn't supported.
Got any better ideas?
What part of "Gestalt" don't you understand?
Corel's Linux distro is built around Debian. It's one of the most slickified distros out there -- if you believe MSNBC's writeup. If you want Debian package management without the krufty interfaces, give it a whirl.
What part of "Gestalt" don't you understand?