[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Draft summary of Creative Commons 2.0 licenses (version 3)



<quote who="Andrew Suffield" date="2005-03-27 12:05:57 +0100">
> [I am continually amazed by the amount of effort that people will
> exert to avoid fixing bugs, even when that effort exceeds the amount
> required to fix the bug]

Sure. :) I absolutely agree that everything here should be fixed. I'm
just not sure I agree that everything in the critique is a freedom
issue if unfixed.

> We can only accept these in specific cases. For the general case of
> a license which is intended to be applied to works by *other people*
> (such that Creative Commons is *not* the licensor), we have to
> assume the worst, because there will exist at least one licensor who
> *does* mean the worst.
> 
> This not a theory. This is practical experience. This is why pine is
> not free.

Pine is not free because we *know* that the licensor feels that is
non-free. There is a difference between "we know the the licensor
reads this passage as non-free therefore we treat the work as
non-free" -- which I agree with wholeheartedly -- and "we can imagine
a situation where someone might make a wrongheaded and unreasonable
argument that a clearly free clause is non-free therefore *all* works
are non-free by default."

For clauses like this that are in the *vast* majority of cases not
going to be used by people who want do something non-free (e.g., block
private distribution -- do we know of *anyone* that has made this
argument or supported this interpretation?) I think we can pretty
safely treat only those works whose licensor believes in a non-free
interpretation as non-free.

There is some level of unavoidable ambiguity in contracts that we need
to deal with. As a result, contract law law uses things like
"reasonable expectations" to compensate. You can't put "and all of
your money is transfered to me" in your shareware click-wrap and then
successfully sue for me for the contents of my bank account in any
jurisdiction that I know of.

Yes. It could be better and I hope it is fixed. But I'm not sure it's
a freedom issue based on the intent of the authors, the intent of the
vast (complete?) majority of people using the license, and the
reasonable expectations that anyone using the license would have.

> It is entirely possible that some licensor could go to court and say
> "I used the CC licenses in the belief that this was prohibited, and
> with the intent to prohibit it". There is nothing to use in defence
> against this.

Absolutely. And I think that if their argument involved the DRM clause
or the trademark bit in the CC license, they would lose because the
defendant would be able to bring in Larry Lessig, the rest of the CC
board to say they that isn't what they meant and that they didn't
think that was a reasonable interpretation, and because, at the end of
the day, the judge is going to determine whether their reading is
reasonable himself or if the licensee's reasonable expectations were
valid.

We're not working with code here. There's a certain amount of
imprecision and expectations and intent have a long history in contract
law jurisprudence.

> > Is ALLCAPS "NOT A PART OF THE LICENSE", plus statements from the
> > authors, plus a graphical distinction and a explicit statement that CC
> > is not party to the license in the same block of text *really*
> > "sufficiently ambiguous" enough to make this a freedom issue?
> 
> Given the existence of licensors who have included it, in plain text,
> as if it were part of the license? Yes, I would say that is
> sufficiently ambiguous, since not even the licensors can understand
> it's supposed to be disjoint.

I'm not sure that the least common denominator is the best way to
making the decision on whether this is a freedom issue in the
license. Sounds more like a cut and paste error than a real case of
pervasive ambiguity. Point me to someone who has done this and I'll
bet that that a quick email later, the problem will be resolved.

Regards,
Mako


-- 
Benjamin Mako Hill
mako@debian.org
http://mako.yukidoke.org/

Attachment: signature.asc
Description: Digital signature


Reply to: