> Please cite to case law that supports this assertion in the manner in which
> you intend to apply it, i.e., that just because software is capable of
> allowing an infringing act to occur, that the user of that software is
> granting such a right.
You just completely ignored the point. The software grants authorization. Below I cite four cases showing deep links are legal.
If you set up a machine to engage in contract negotiation, do you agree that you are bound by the resulting contract?
Are vending machine operators able to sue people who buy candy for theft?
Are banks able to sue people who transfer money using an ATM for bank fraud?
Is Hotmail bound by the terms of its end user contract when someone signs up over the web?
What if I run my own web mail, written by someone else, but otherwise identical to Hotmail, with the same agreement. Can I sue someone for unauthorzied access to a computer system when they use the account the software created for them?
The answer in every case is that consciously using a machine that is capable of creating a contract can result in legal contract obligations. Copyright licensing is one special case of this much more general rule.
> > Denying this point is not even helpful to your argument: if
> > you aren't responsible for your machines actions, then I'm not
> > responsible for my machine's actions either and you have no
> > cause to sue me.
>
> There is a big difference. The infringer actually WROTE the code INTENDING
> the infringement. That is hardly the same thing.
It makes no difference at all who wrote the software. Does it matter who built the vending machine?
The person who uses a tool is repsonsible for the outcome. It is irrelevent whether you built the tool your self, paid someone else to build the tool for you, or chose a pre-made tool that is available on the market. Three identical triplets aquiring three identical tools by each of the three methods just described are legally indistinguishable when they use those tools in identical manner.
> >
> > The law is well settled that if you set a machine running and it acts in
> > accordance with your commands that you are legally obligated by its
> actions.
>
> Please cite the law. Further, it is NOT merely the commands from the user,
> but the commands from third parties, that the server is responding to. Your
> argument is that, just becuase the server CAN respond to third party
> commands, that implies the right for it to do so. That is silly. It's like
> making the auto rental company liable for the driver who runs over a
> pedestrian because the car is CAPABLE of such direction.
Huh? That would be your position where the tool provider (car rental company, here) is liable. My position is that the tool user is liable for his use of the tool.
A web server does not obey "commands" from outside users. Computer security built in to every OS in widespread use guarantees that only commands from an authenticated user will be run. In the case of a web server, those commands involved accepting "input" data over the network. That input data may be a GET "request". It is flat wrong to call it a command.
This is much differnet than when you rent a car. When you rent a car, the terms of your contract authorize you to take command of the vehicle.
I'll cite the case I have before that supports the proposition that a software program can negotiate a contract on its controller's behalf. In Hotmail v. Van$ Money Pie, the court found that VMP breached a contract with Hotmail. The contract in question was formed by Hotmail's server when VMP created the accounts. The court found "that Hotmail complied with the conditions of the contract except those from which its performance was excused". The court's analysis did not turn on whether Hotmail wrote the software.
Now it's your turn to cite something. anything.
Every time I cite the law you make unsubstantiated assertions that the law I cited doesn't apply. To my recollection, you have never once provided any references. I've cited the Hotmail decision. Step Saver, ProCD, various Playboy copyright cases, and the UCC. Below I cite 4 cases directly on point to this whole thread. You've cited nothing.
> > You might as well argue that vending machines don't make sales
> > because machines can't enter you into a contract without synchronous
> > human participation. If you care to dispute this point, please provide
> > some references.
>
> Prove YOUR Point.
I consider the vending machine example obvious. It's hard to take anybody seriously who doesn't think it's creating a contract of sale. Are you actually disputing this? Yes or No?
> It is nearly impossible to prove a negative. I would
> like to see one major court ruling where a user of software was found to
> implicity or explicity grant a license just because their software was able
> to perform an infringing act.
You seem to just not get the idea that we are talking about "authorization". There are no authorized infringing acts, that is an oxymoron.
> > And don't try to confuse the issue: this point is a matter of
> > contract law, not of copyright law.
>
> No kidding. I stated long ago that this was a contract issue. But
> copyright contracts are constrained by copyright law.
That is true. The copyright act preempts certain otherwise valid state laws from transferring copyright ownership. Aside from this completely irrelevant special point, the copyright act defers to the UCC to govern contract formation. I've cited Step Saver and ProCD for the proposition that a UCC analysis is done to identify the existence and terms of a copyright licence.
Do you dispute that the UCC is the governing law regarding whether a licence exists?
> > The copyright act preserves only a right to authorize. Contract law
> > defines how authorization occurs. If you use a machine to negotiate
> > your authority,
>
> In the example being discussed, no machine was used to negotiate any such
> authority. The server was not set up for that purpose, and no such
> indication was shown by the user.
Baffling. The server was set up to execute the HTTP protocol. This means what the HTTP spec says it means in section 1.4.
"The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body content."
Is this paragraph not an accurate factual description of HTTP? Yes or No.
Is a request/response dialogue not a "negotation" for something?
Is a "request" not an attempt to seek authority for that which is requested?
Does an affirmative response (eg "OK") not communicate unambigous granting of authority for that which was requested?
> >
> > I recently posted a written record of McDonald's HTTP authorization (and
> > active participation) in the creation of a copy of their picture on
> > my machine, which clearly and explicitly grants me the right to have
> > a copy made on my machine and to display it with requested referring
> > page.
>
> Case law has NEVER stated that merely because a person's server served an
> image to a third party, that that third party is given a license to use that
> image in its own web page. Because you are asserting it, just provide a few
> case examples. I can hardly provide a few non-examples, now can I?
If by "use" you mean link, then I'll provide four examples, although none say that the link's legality is contingent on having actually been served the image, but rather all say it is legal regardless.
""[H]yperlinking does not itself involve a violation of the Copyright Act (whatever it may do for other claims) since no copying is involved." Tickmaster v Tickets.com
Similar results in EF Cultural Travel BV, et al. v. Zefer Corporation (website bears burden to make additional explicit prohibition on "scrapers", given that it serves up content already)
Similar results in the cases PCM v. Kranten.com (Netherlands) and Verlagsruppe Holtzbrinck v Paperboy.de (German), each of which went to the Supreme Court of their respective countries and upheld deep linking as non-infringing.
And yes, I could reasonably ask you to provide citation for the opposite position. If any of the above cases had dissents, that would be one source.
> Your claim that it is an explicity licensne is ludicrous.
If the law grants person A the exclusive right to authorize XYZ, consider the following dialouge and situation:
person B: hey, person A, can I do XYZ
person A: OK
<<person A and person B cooperate to do XYZ>>
Are you really going to tell me that person B didn't have authorization to do XYZ? If you go back and read the HTTP transaction log I posted of my image download from McDonalds, it pretty much contains syntax to cover all that I am claiming is authorized.
> The only "meaning" is that you requested a copy be made, and a copy was
> made.
That is meaning enough -- it means this is an authorized copy, not an pirated one.
> There is nothing at all in the HTML that says, one way or another,
> that the copy was authorized.
Of course there isn't anything in the HTML. You are describing the job of the HTTP, not HTML. HTML defines presentation. But the name of the specific HTML used is sent as part of the request. Look at the first line of the response header from McDonalds.com that I posted. It says "OK".
Are you arguing that "OK" doesn't mean that it's OK?
Or if it does mean it's OK, are you arguing it still isn't "authorized"?
> > Or as I said before, argue that machine actions don't obligate their human
> > masters in which case you STILL have no cause of action against me when my
> > machine created a copy of your work all by itself.
>
> Case law is still developing, but it is pretty clearly heading in the
> direction opposite you position.
Well, I've named 4 cases that support my position. You've named none. The one that supported your position (Kelly v Arriba) was just vacated.
This archive was generated by hypermail 2.2.0 : Mon Mar 26 2007 - 00:35:50 GMT