Creative Commons Attribution license element
Evan Prodromou
Hash: SHA1
I'm writing because I've just been made aware of this summary of the
Creative Commons Attribution 1.0 license:
http://lists.debian.org/debian-legal/2004/04/msg00031.html
Let me first note that Creative Commons uses a suite of licenses, with
a number of mix-and-match license elements (Attribution, ShareAlike,
NonCommercial, NoDerivatives). So any CC license that would require
Attribution would also fall under this analysis.
Second, let me note how poorly timed the analysis is. Creative Commons
revised their suite of licenses this year (from 1.0 to 2.0), and this
list was asked to provide comment:
http://lists.debian.org/debian-legal/2004/01/msg00241.html
Making our organization's ideas known to Creative Commons could have
meant a better suite of licenses for the 2.0 release. Instead, the
opportunity was missed. As far as I know, the above-mentioned analysis
wasn't forwarded to Creative Commons before today.
Thirdly, let me say that I disagree with most of the summary. I'll try
and cover the points in detail below:
1) Many DFSG-free licenses require that small portions of text be kept
intact or added to the source code or output of the program. The most
notable examples would be copyright notices, license notification,
warranty disclaimer, and notice of modifications made; the BSD
license(s) and the GPL come to mind immediately.
Putting conditions on modification does not make a license
non-free. We even codify this in DFSG point 4. Patch-only modification
is a condition on modification that we consider acceptable if not
ideal.
Conditions on modification are, of course, a matter of degree. If
conditions are _so_ burdensome as to make modification and
redistribution _impracticable_ -- "You may distribute modified
versions if you square the circle, jump Snake River Canyon on a
motorcycle, travel faster than light" -- then the right to modify is
for all practical purposes not granted.
But requiring attribution to the original author does not appear to me
to be that kind of burden. In particular, the license makes it clear
that you must "give the Original Author credit reasonable to the
medium or means You are utilizing". A Licensor could not abuse this
requirement by making Attribution impractical -- say, by providing a
5-terabyte name or title. Licensees are only required to give
Attribution in a reasonable way.
Let me note here that, although the Open Source Definition is not
identical to the DFSG, the OSI has approved a few licenses that have
equivalent or greater attribution requirements. Most notable is the
Attribution Assurance License template:
http://www.opensource.org/licenses/attribution.php
This is not, of course, canonical for Debian, but it does provide some
suggestion that a group following guidelines similar to ours don't see
a serious problem with requiring attribution. Apache 2.0 also requires
attribution (in the NOTICE file).
2) I agree with this one. The intention appears to be to allow
copyright holders to avoid having their name used in advertisement, a
la the BSD, but in an opt-out rather than opt-in fashion.
However, as stated, it would indeed allow a license holder to prevent
_any_ mention of themselves in derivative works. This could severely
limit the licensee's freedom. An example would be an annotated version
of a work that critiques the writer, or an autobiography that is
revised to include critical comments or facts about the writer.
It would probably be useful to modify the license to show that the
licensor can revoke the Attribution requirements, but not prevent
other mention of their name.
3) As for the trademark clause, I agree that the trademark requirement
is burdensome. HOWEVER, considering that Creative Commons is _not_ a
party to the license, no action by that organization to overstep
trademark bounds could invalidate the license. If A grants B the
rights outlined in Attribution 1.0, no increase in trademark
restrictions by the third-party Creative Commons could revoke those
rights.
So, that's my feedback. I'd like to know what can be done to amend the
analysis and re-open this license (as well as Attribution 2.0,
ShareAlike 1.0, and Attribution-ShareAlike 1.0 and 2.0) for
consideration.
On the Creative Commons side, I'd wonder what opportunity there is to
get Debian's very tardy comments and critiques applied to new versions
of the CC licenses.
~ESP
- --
Evan Prodromou
ev...@debian.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAxeP/ozwefHAKBVERAmHxAJ9Qna+IwzXTEXnGJm+pJD3vPdeQ7ACeNOCC
4FMc8pCK4bDxmzyefv6wlN4=
=xyLh
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-leg...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrew Suffield
> I'm writing because I've just been made aware of this summary of the
> Creative Commons Attribution 1.0 license:
>
> http://lists.debian.org/debian-legal/2004/04/msg00031.html
>
> Let me first note that Creative Commons uses a suite of licenses, with
> a number of mix-and-match license elements (Attribution, ShareAlike,
> NonCommercial, NoDerivatives). So any CC license that would require
> Attribution would also fall under this analysis.
Right, the CC licenses are generally known to be a collection of
non-free licenses.
> Conditions on modification are, of course, a matter of degree.
No, actually, they are matters of form. Not degree. Unacceptable forms
will always be unacceptable regardless of how large or small the
relevant restriction is.
> Let me note here that, although the Open Source Definition is not
> identical to the DFSG, the OSI has approved a few licenses that have
> equivalent or greater attribution requirements.
Yes, OSI does approve of some licenses which we do not. This is not
new. They require less freedom than Debian.
> So, that's my feedback. I'd like to know what can be done to amend the
> analysis and re-open this license (as well as Attribution 2.0,
> ShareAlike 1.0, and Attribution-ShareAlike 1.0 and 2.0) for
> consideration.
We've done these to death already, starting in 2003. They're
non-free. That won't change. Future versions of the licenses will be
considered the same as any license.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
Evan Prodromou
Me> Conditions on modification are, of course, a matter of degree.
AS> No, actually, they are matters of form. Not
AS> degree. Unacceptable forms will always be unacceptable
AS> regardless of how large or small the relevant restriction is.
A fair if fine point.
AS> We've done these to death already, starting in 2003. They're
AS> non-free. That won't change.
Ah. Well, could you respond to my points as to why I think they _are_
free? I disagree with the terms of the summary.
Can you explain to me why requirements to include an author's name
make a license non-free, but requirements to maintain copyright
notices, warranty disclaimers, license notification, and changelogs
are not? At this point, I don't see the serious difference.
AS> Future versions of the licenses will be considered the same as
AS> any license.
Excellent. I think debian-legal's input into the next version of the
CC licenses would be really helpful.
~ESP
--
Evan Prodromou
ev...@debian.org
Andrew Suffield
> AS> We've done these to death already, starting in 2003. They're
> AS> non-free. That won't change.
>
> Ah. Well, could you respond to my points as to why I think they _are_
> free? I disagree with the terms of the summary.
You acknowledged at least two reasons why it was non-free. I didn't
write the summary. The discussions which resulted in the summary are
the significant part, and I dimly recall they had valid points, but
did not follow them closely. Beyond that I'm not personally inclined
to analyse a license which is clearly non-free for other reasons; it's
time-consuming.
Evan Prodromou
AS> Beyond that I'm not personally inclined to analyse a license
AS> which is clearly non-free for other reasons; it's
AS> time-consuming.
No problem; I'm sure someone else will chime in. Thanks for your help
so far.
~ESP
--
Evan Prodromou
Email: ev...@debian.org
Jabber: ev...@jabber.debian.net
MJ Ray
> Second, let me note how poorly timed the analysis is. Creative Commons
> revised their suite of licenses this year (from 1.0 to 2.0), and this
> list was asked to provide comment:
> http://lists.debian.org/debian-legal/2004/01/msg00241.html
You seem to get the basics of these problems in reply to that. Were
they taken into consideration by CC?
It may be "poorly timed" but at least a debian user helped to make it
happen. Please praise Ben Francis and give him due credit for getting
your attention with
http://lists.ibiblio.org/pipermail/cc-licenses/2004-June/000909.html
Equally, let us note that a debian *developer* subscribed to
cc-discuss solicited the views of debian-legal, but did not make sure
our views were clearly known to them. Then again, we're all volunteers
in debian AFAIK, so let's not throw accusations of unprofessional
conduct around.
> [...] As far as I know, the above-mentioned analysis
> wasn't forwarded to Creative Commons before today. [...]
I'm sorry it didn't happen sooner, but I can only do so much at once
and I just assumed that you reported it back to them.
> So, that's my feedback. I'd like to know what can be done to amend the
> analysis and re-open this license (as well as Attribution 2.0,
> ShareAlike 1.0, and Attribution-ShareAlike 1.0 and 2.0) for
> consideration.
Convince enough people that the summary is updated. I still think it
won't be DFSG-free until the "author name purging" part is fixed, so
is there much point? I need to think about your trademark comments
when it's not so hot here.
> On the Creative Commons side, I'd wonder what opportunity there is to
> get Debian's very tardy comments and critiques applied to new versions
> of the CC licenses.
The comments are not tardy, it's just that they don't seem to have got
to cc-discuss before. I assumed that you would be doing that
reporting, in the same way that maintainers asking debian-legal
usually report results to the upstream authors if required. Maybe I
misjudged it, but no-one's dead yet AFAIK, so no need to grieve.
--
MJR/slef
My Opinion Only and possibly not of any group I know.
http://www.ttllp.co.uk/ for creative copyleft computing
Help hack the EuroParl! http://mjr.towers.org.uk/proj/eurovote/
Evan Prodromou
Me> Second, let me note how poorly timed the analysis is.
MR> It may be "poorly timed" but at least a debian user helped to
MR> make it happen. Please praise Ben Francis and give him due
MR> credit for getting your attention with
MR> http://lists.ibiblio.org/pipermail/cc-licenses/2004-June/000909.html
Ben deserves some praise. Nice job, Ben!
MR> Equally, let us note that a debian *developer* subscribed to
MR> cc-discuss solicited the views of debian-legal, but did not
MR> make sure our views were clearly known to them.
Yes, indeed. My grouchiness was unmerited, and I should have been
doing a better job as a conduit between the two groups. I'm now
subscribed to debian-legal and I'll try to keep the lines of
communication open better.
I'm sorry to have been harsh for something that was more or less my
own responsibility.
~ESP
--
Evan Prodromou
Email: ev...@debian.org
Jabber: ev...@jabber.debian.net
MJ Ray
> a number of mix-and-match license elements (Attribution, ShareAlike,
> NonCommercial, NoDerivatives). So any CC license that would require
> Attribution would also fall under this analysis.
Do any SA/NC/ND licences not include attribution?
> http://www.opensource.org/licenses/attribution.php
> This is not, of course, canonical for Debian, but it does provide some
> suggestion that a group following guidelines similar to ours don't see
> a serious problem with requiring attribution.
I don't think OSI follows similar guidelines. Notably, Debian does not
require contributors to its process to use non-free software, defaults
to "no consensus" (sometimes annoyingly so) and only produces licence
summaries if driven.
Even so, I'd be amazed that OSI approved a licence that includes
advertising in the licence and requires a program to do a particular
act, were I not already convinced that OSI has gone bad. The
Initiative Failed a long time ago, it seems. In the words of USPTO:
Opensource is Dead.
> [...] Apache 2.0 also requires attribution (in the NOTICE file).
I still think that licence looks like it has be considered
case-by-case, as there is scope to abuse it.
> 3) As for the trademark clause [...] If A grants B the
> rights outlined in Attribution 1.0, no increase in trademark
> restrictions by the third-party Creative Commons could revoke those
> rights.
Can you explain this more? How is it compliance with the licence not
to obtain "prior written consent of Creative Commons" before using
their trademark in a normally-permitted manner that is not "in
compliance with Creative Commons' then-current trademark usage
guidelines" ?
--
MJR/slef
My Opinion Only and possibly not of any group I know.
http://www.ttllp.co.uk/ for creative copyleft computing
Help hack the EuroParl! http://mjr.towers.org.uk/proj/eurovote/
MJ Ray
>>>>>> "MR" == MJ Ray <m...@dsl.pipex.com> writes:
Please don't SuperCite outgoing email. It is difficult to follow.
> [...] I'm now
> subscribed to debian-legal and I'll try to keep the lines of
> communication open better.
I don't think you mentioned that you weren't subscribed when asking
for comments in January. That may have limited feedback that you saw,
especially as your initial posting address bounced.
Summary: Oh well, let's fix it now.
--
MJR/slef
My Opinion Only and possibly not of any group I know.
http://www.ttllp.co.uk/ for creative copyleft computing
Help hack the EuroParl! http://mjr.towers.org.uk/proj/eurovote/
Nathanael Nerode
Evan Prodromou wrote:
<snip>
> Making our organization's ideas known to Creative Commons could have
> meant a better suite of licenses for the 2.0 release. Instead, the
> opportunity was missed. As far as I know, the above-mentioned analysis
> wasn't forwarded to Creative Commons before today.
How disturbing. I think we thought it had been.
<snip>
> But requiring attribution to the original author does not appear to me
> to be that kind of burden. In particular, the license makes it clear
> that you must "give the Original Author credit reasonable to the
> medium or means You are utilizing". A Licensor could not abuse this
> requirement by making Attribution impractical -- say, by providing a
> 5-terabyte name or title. Licensees are only required to give
> Attribution in a reasonable way.
Actually, I think most of clause 4b is fine; it's only one little bit of it
which is troublesome. I will now analyze it carefully:
>From clause 4b:
>If you distribute, publicly display, publicly perform, or publicly
>digitally perform the Work or any Derivative Works or Collective Works,
>You must keep intact all copyright notices for the Work
So far free.
>and give the Original Author credit reasonable to the medium or means You
>are utilizing by conveying the name (or pseudonym if applicable) of the
>Original Author if supplied;
I think this is a reasonable and free requirement. It's trivial and easy,
and amounts to nothing more than proper attribution.
>the title of the Work if supplied;
This is a stronger requirement, but I also think this is reasonable and a
free requirement. This *does* correspond vaguely to requiring appropriate
references to prior work (as is done in scientific papers), unlike some
other things we've discusses. Also, it's standard practice in the free
software community.
>to the extent reasonably practicable, the Uniform Resource Identifier, if
>any, that Licensor specifies to be associated with the Work, unless such
>URI does not refer to the copyright notice or licensing information for the
>Work;
Well, I think this is barely free, though it's a little silly.
>and in the case of a Derivative Work, a credit identifying the use of the
>Work in the Derivative Work (e.g., "French translation of the Work by
>Original Author," or "Screenplay based on original Work by Original
>Author").
Likewise this is a reasonable and free requirement.
>Such credit may be implemented in any reasonable manner;
Great! In other words, for Debian, we put it in the copyright file along
with all the other credits. Or we put it in a CREDITS file or a
CONTRIBUTORS file or a NOTICES file. Or next to the copyright notices in
the files. Or whatever. Except then there's this next clause....
>provided, however, that in the case of a Derivative Work or Collective
>Work, at a minimum such credit will appear where any other comparable
>authorship credit appears and in a manner at least as prominent as such
>other comparable authorship credit.
*This* is the problem clause. It's unclear to most of us exactly what "any
other comparable authorship credit" means. If it means "the credit given
to any other author who wrote approximately the same amount of the
material" -- then it might possibly be a free requirement, or it might not
(I'm not sure, since I haven't thought about it); but it's ceratinly an
ugly requirement. If it means "the credit given to any other author of the
same work", it certainly isn't. If it means something else, I have no
idea.
With this ambiguity, the "at least as prominent" requirement is then a
potential interpretation nightmare. Suppose, for a silly and extreme
example, you wanted to use a huge hunk of material under this license in a
version of ReiserFS, so that the code under this license needed a
"comparable authorship credit" to Reiser's. Would that mean that the
credit would have to appear in the FS name, so as to be in the same
location and at least as prominent as Reiser's credit? Yeech.
"Prominent" credit requirements are the specific type of credit requirements
we've been objecting to. They cause endless trouble in a way that ordinary
credit requirements do not.
This might be fixable with a clarification, or a lawyer's opinion on what
exactly it *means*, rather than a license change.
Evan wrote:
> 2) I agree with this one. The intention appears to be to allow
> copyright holders to avoid having their name used in advertisement, a
> la the BSD, but in an opt-out rather than opt-in fashion.
>
> However, as stated, it would indeed allow a license holder to prevent
> _any_ mention of themselves in derivative works. This could severely
> limit the licensee's freedom. An example would be an annotated version
> of a work that critiques the writer, or an autobiography that is
> revised to include critical comments or facts about the writer.
>
> It would probably be useful to modify the license to show that the
> licensor can revoke the Attribution requirements, but not prevent
> other mention of their name.
Right. This is the deal-breaker clause, which absolutely must be fixed to
create a free license.
>From clause 4a:
> If You create a Collective Work, upon notice from any Licensor You must,
>to the extent practicable, remove from the Collective Work any reference
>to such Licensor or the Original Author, as requested. If You create a
>Derivative Work, upon notice from any Licensor You must, to the extent
>practicable, remove from the Derivative Work any reference to such
>Licensor or the Original Author, as requested.
Evan wrote:
> 3) As for the trademark clause, I agree that the trademark requirement
> is burdensome.
This isn't supposed to be an actual part of the license, according to the
source code for the web page; this should be fixed so that this is clear
when *viewing* the web page (it is *not* clear now). That doesn't require
changing the license. It does require someone at Creative Commons noticing
and dealing with the issue. :-P
> So, that's my feedback. I'd like to know what can be done to amend the
> analysis and re-open this license (as well as Attribution 2.0,
> ShareAlike 1.0, and Attribution-ShareAlike 1.0 and 2.0) for
> consideration.
Changes and clarifications by Creative Commons, basically.
> On the Creative Commons side, I'd wonder what opportunity there is to
> get Debian's very tardy comments and critiques applied to new versions
> of the CC licenses.
I hope there is some. My previous comments must have been going to the
wrong address or something. You can forward this if you like.
I speak only for myself, of course, etc.
--
There are none so blind as those who will not see.
MJ Ray
wrote:
>> 3) As for the trademark clause, I agree that the trademark
>> requirement
>> is burdensome.
> This isn't supposed to be an actual part of the license, according to
> the
> source code for the web page; [...]
I missed that. I'm not in the habit of reading licence page source
codes in the normal run of things. Yes, it's not clear, as a cursory
glance at copies of the CC licence suggests. I see some Nathanael
Nerode pointed that out on cc-discuss in March... are we talking into
a black hole, or do CC react to that list?
--
MJR/slef
My Opinion Only and possibly not of any group I know.
http://www.ttllp.co.uk/ for creative copyleft computing
Help hack the EuroParl! http://mjr.towers.org.uk/proj/eurovote/
Josh Triplett
> On 2004-06-08 17:06:25 +0100 Evan Prodromou <ev...@debian.org> wrote:
>> a number of mix-and-match license elements (Attribution, ShareAlike,
>> NonCommercial, NoDerivatives). So any CC license that would require
>> Attribution would also fall under this analysis.
>
> Do any SA/NC/ND licences not include attribution?
In the case of the 1.0 licenses, the SA, NC, SA-NC, ND, and NC-ND
licenses did not require attribution, although only the first of these
would have any chance of being Free. In the 2.0 licenses, CC decided
that everyone wanted attribution, so they included it in all their
licenses to reduce the number of different combinations.
> I don't think OSI follows similar guidelines. Notably, Debian does not
> require contributors to its process to use non-free software, defaults
I'm curious, what non-free software is required to contribute to OSI?
- Josh Triplett
Nathanael Nerode
>On the Creative Commons side, I'd wonder what opportunity there is to
>get Debian's very tardy comments and critiques applied to new versions
>of the CC licenses.
Perhaps if they read their own mailing list?...
The trademark issue appears to be an issue solely with the web page
presentation of the license, which should simply be fixed; the trademark
clause is not supposed to be part of the license at all, but the web page
does not make that clear.
I sent a message regarding this to them some time ago, but it seems to have
fallen into a black hole. Perhaps you know someone who could actually get
something done on this point?...
Evan Prodromou
>> a number of mix-and-match license elements (Attribution,
>> ShareAlike, NonCommercial, NoDerivatives). So any CC license
>> that would require Attribution would also fall under this
>> analysis.
MR> Do any SA/NC/ND licences not include attribution?
There were several 1.0 licenses that didn't include Attribution. See
the bottom of this page:
http://creativecommons.org/licenses/
AFAICT, all of them have the revocation requirement. It's not
connected to the Attribution requirement, as I mistakenly stated.
Me> This is not, of course, canonical for Debian, but it does
Me> provide some suggestion that a group following guidelines
Me> similar to ours don't see a serious problem with requiring
Me> attribution.
MR> I don't think OSI follows similar guidelines. [...]
Mu.
Me> 3) As for the trademark clause [...] If A grants B the rights
Me> outlined in Attribution 1.0, no increase in trademark
Me> restrictions by the third-party Creative Commons could revoke
Me> those rights.
MR> Can you explain this more? How is it compliance with the
MR> licence not to obtain "prior written consent of Creative
MR> Commons" before using their trademark in a normally-permitted
MR> manner that is not "in compliance with Creative Commons'
MR> then-current trademark usage guidelines" ?
I just don't think the second paragraph in the trademark box is
binding in any way. After all, Creative Commons (quite wisely) states
that it is not a party to the license. For what reason, then, should
either of the parties be bound by the excessive trademark restriction
paragraph?
I'm just having a hard time seeing the Tentacles of Evil scenario
here. I think the nightmare scenario is that Creative Commons becomes
evil or stupid and declares that noone can use the Creative Commons
trademark that scattered in various places throughout the
licenses. This would mean that if Alice had licensed Work to Bob, Bob
could not comply with the license by passing on license notification
to Charlie, since it includes the string "Creative Commons" in a
couple of places.
But I think Bob isn't bound by Evil Commons's decree in any way --
neither under trademark law, nor under copyright law, nor under the
license agreement. _Alice_ didn't Bob couldn't use the trademark; Evil
Commons did.
I agree that it might not be a good idea on CC's part to claim
privileges beyond trademark's standard requirements, but I don't think
it makes the licenses non-free.
~ESP
--
Evan Prodromou
Email: ev...@debian.org
Jabber: ev...@jabber.debian.net
MJ Ray
> I just don't think the second paragraph in the trademark box is
> binding in any way. After all, Creative Commons (quite wisely) states
> that it is not a party to the license. For what reason, then, should
> either of the parties be bound by the excessive trademark restriction
> paragraph?
It seems it should not be in the licence. I admit, I didn't understand
why it should be part of the licence, from the situation you describe.
Sadly, that doesn't mean that people don't have to comply with the
licence as written. People have added the trademark block to Creative
Commons licences as part of their licence. For example, the subversion
book includes it in their copyright licence at
http://svnbook.red-bean.com/svnbook/ape.html
This bug has spread!
> But I think Bob isn't bound by Evil Commons's decree in any way --
> neither under trademark law, nor under copyright law, nor under the
> license agreement. _Alice_ didn't Bob couldn't use the trademark; Evil
> Commons did.
Why isn't he? Complying with CC's trademark terms is a condition of
the licence Alice used. Being someone else's trademark doesn't excuse
Bob from complying with the copyright licence, including agreeing to
use the CC trademark however it is permitted, does it? It's just that
Alice and CC both need to go evil to attack Bob.
--
MJR/slef
My Opinion Only and possibly not of any group I know.
http://www.ttllp.co.uk/ for creative copyleft computing
Help hack the EuroParl! http://mjr.towers.org.uk/proj/eurovote/
Evan Prodromou
EP> the Creative Commons trademark that [is] scattered in various
EP> nor under the license agreement. _Alice_ didn't [say] Bob couldn't
Sorry, those two omissions were driving me crazy.
Evan Prodromou
Me> On the Creative Commons side, I'd wonder what opportunity there
Me> is to get Debian's very tardy comments and critiques applied to
Me> new versions of the CC licenses.
NN> Perhaps if they read their own mailing list?...
That's a good point; I didn't see any followup on your message to that
list.
Here's a pointer to your message, BTW, for reference:
http://lists.ibiblio.org/pipermail/cc-licenses/2004-January/000320.html
NN> The trademark issue appears to be an issue solely with the web
NN> page presentation of the license, which should simply be
NN> fixed; the trademark clause is not supposed to be part of the
NN> license at all, but the web page does not make that clear.
As far as I can tell, no.
NN> I sent a message regarding this to them some time ago, but it
NN> seems to have fallen into a black hole. Perhaps you know
NN> someone who could actually get something done on this
NN> point?...
I can try to bring the subject up on the cc-licenses list again.
~ESP
--
Evan Prodromou
Email: ev...@debian.org
Jabber: ev...@jabber.debian.net
Nic Suzor
> I can try to bring the subject up on the cc-licenses list again.
I am involved with the adaptation of the CC licences in Australia, and
have raised the issues with the drafting team.
I have also pointed out the problems to our project lead, who intends on
discussing it with CC in Stanford next month. I still suggest that you
raise the issues on the cc-licenses list, however.
nic.
--
Nic Suzor
n...@suzor.com
Evan Prodromou
NN> Actually, I think most of clause 4b is fine; it's only one
NN> little bit of it which is troublesome.
Thanks for your close attention. This is really helpful.
4b> to the extent reasonably practicable, the Uniform Resource
4b> Identifier, if any, that Licensor specifies to be associated
4b> with the Work, unless such URI does not refer to the copyright
4b> notice or licensing information for the Work;
NN> Well, I think this is barely free, though it's a little silly.
It's probably less silly in light of the mechanism Creative Commons
suggests for embedding license info into artifacts with tight space
for metadata:
http://creativecommons.org/technology/embedding
For file formats like MP3/ID3, there's only so much space for rights
info. So, CC recommends storing an URL to the full info.
One thing that bothers me, though, is how this becomes 'barely
free'. I realize that it may be *annoying* or *stupid*, but how is it
*non-free*? I understand how *excessive* conditions on modifications
may make something non-free, but requiring that a verbatim URL be
included with the Work doesn't seem excessive to me.
I also am having a problem with understanding how putting limits on
the modification of metadata (info about the Work) makes something
non-free. This seems to be standard issue with most free licenses (you
have to keep copyright notices, you have to distribute the license
with the work, you have to keep a change history, yadda yadda). I see
where restrictions on the content (can't change function names, can't
change the ending of the short story) are non-free, but I'm not sure I
grok why metadata "invariance" is.
I really need some help getting this straight in my head. What am I
missing, here?
4b> provided, however, that in the case of a Derivative Work or
4b> Collective Work, at a minimum such credit will appear where any
4b> other comparable authorship credit appears and in a manner at
4b> least as prominent as such other comparable authorship credit.
NN> *This* is the problem clause. It's unclear to most of us
NN> exactly what "any other comparable authorship credit" means.
Yes, I see that. Is it "credit for comparable authorship", or "comparable
credit for authorship"? A failure of the appositive!
The "any other ..." part is kind of difficult, too. Does it mean "some
other ..." (credit has to be somewhere), or "every other ..." (anytime
there's credit, this one has to be there, too)?
NN> With this ambiguity, the "at least as prominent" requirement
NN> is then a potential interpretation nightmare. Suppose, for a
NN> silly and extreme example, you wanted to use a huge hunk of
NN> material under this license in a version of ReiserFS, so that
NN> the code under this license needed a "comparable authorship
NN> credit" to Reiser's. Would that mean that the credit would
NN> have to appear in the FS name, so as to be in the same
NN> location and at least as prominent as Reiser's credit? Yeech.
Yeech, yes. Possibly a more appropriate example would be when I
include an Attribution-licensed quote from you (beyond the extent of
fair use) in my book, "The Autobiography of Evan Prodromou". Would I
have to change the title to "The Autobiography of Evan Prodromou and
Nathanael Nerode"?
Again, though, I wonder about the non-free aspects of this. Clumsy and
inaccurate, yes. Non-free...? Would it be non-free because it's not
possible for the licensee to comply because the license is vague?
NN> This isn't supposed to be an actual part of the license,
NN> according to the source code for the web page; this should be
NN> fixed so that this is clear when *viewing* the web page (it is
NN> *not* clear now). That doesn't require changing the license.
NN> It does require someone at Creative Commons noticing and
NN> dealing with the issue. :-P
Probably something as simple as:
"Creative Commons", the Creative Commons logo, and the Some Rights
Reserved logo are trademarks of Creative Commons. Their use is
restricted by Creative Commons <trademark policy> to the extent of
applicable law.
...would work better.
~ESP
--
Evan Prodromou
Email: ev...@debian.org
Jabber: ev...@jabber.debian.net
Andrew Suffield
> One thing that bothers me, though, is how this becomes 'barely
> free'. I realize that it may be *annoying* or *stupid*, but how is it
> *non-free*? I understand how *excessive* conditions on modifications
> may make something non-free, but requiring that a verbatim URL be
> included with the Work doesn't seem excessive to me.
Freedom is a binary test; a work is either free, or it is not. There
is no "partially free" or "semi-free". So "barely free" is "free, but
very close to the line; make this any stronger and it will be
non-free".
> Again, though, I wonder about the non-free aspects of this. Clumsy and
> inaccurate, yes. Non-free...? Would it be non-free because it's not
> possible for the licensee to comply because the license is vague?
Yes; if the licensee cannot comply with the license, then they have no
right to distribute or modify, and that's what we're really interested
in. Analysing the license is merely a means to the end - it's what you
can do with the work that counts.
Licenses which are vague are particularly nasty, because you can go
with the "obvious" interpretation, and then get sued by the copyright
holder who turns out to have a different one. Certainly we've had some
copyright holders applying strange interpretations to apparently free
licenses before now. To provide reasonable assurance to our users that
everything in main is free, we have to take the most pessimistic
interpretation, and see if that is free.
Evan Prodromou
Me> One thing that bothers me, though, is how this becomes 'barely
Me> free'.
AS> Freedom is a binary test; a work is either free, or it is
AS> not. There is no "partially free" or "semi-free". So "barely
AS> free" is "free, but very close to the line; make this any
AS> stronger and it will be non-free".
I understood that part. The part I don't understand is, what line does
the URL requirement get close to? What is the line between acceptable
modification restrictions and unacceptable ones?
I'll try to present one dimension of modification restrictions, being
what type of content those restrictions require to remain in the
modified version:
1. No restrictions on modifications whatsoever.
2. Restrictions to make sure that downstream users get the following
4 things: copyright notices, license notification, changelogs,
warranty disclaimers.
3. Restrictions to make sure that downstream users get general
information about the work (metadata), including the above 4
things, but maybe perhaps some others. Examples: original author
name, original work title, original metadata URL, bug-reporting
site or address, main download site URL.
4. Restrictions that "protect" certain parts of the work itself
(e.g., invariant sections).
5. Restrictions that prevent any modification of the work
whatsoever.
I'd posit that our line for free-vs.-non-free is between 3 and 4 here.
Me> Would it be non-free because it's not possible for the licensee
Me> to comply because the license is vague?
AS> Licenses which are vague are particularly nasty, because you
AS> can go with the "obvious" interpretation, and then get sued by
AS> the copyright holder who turns out to have a different
AS> one. Certainly we've had some copyright holders applying
AS> strange interpretations to apparently free licenses before
AS> now. To provide reasonable assurance to our users that
AS> everything in main is free, we have to take the most
AS> pessimistic interpretation, and see if that is free.
Cool. So, if I can redirect back to the Attribution license, we have a
worst-case interpretation with the Attribution license, where the
author's credits have to be listed in _every_ place other credits are
given, even if those places are possibly inconvenient (file name, work
title). Even though it's vague (could mean "some" places, could mean
"all" places), our New Math set theory teaches us that if we give
credit in all places, we will have also have given credit in some
places. So, by giving credit in _all_ places, we can comply.
Now, given the "all places" idea: is that non-free? It may suck, but
is it non-free?
Nathanael Nerode
Evan Prodromou wrote:
>>>>>> "NN" == Nathanael Nerode <ner...@twcny.rr.com> writes:
>
> NN> Actually, I think most of clause 4b is fine; it's only one
> NN> little bit of it which is troublesome.
>
> Thanks for your close attention. This is really helpful.
>
> 4b> to the extent reasonably practicable, the Uniform Resource
> 4b> Identifier, if any, that Licensor specifies to be associated
> 4b> with the Work, unless such URI does not refer to the copyright
> 4b> notice or licensing information for the Work;
>
> NN> Well, I think this is barely free, though it's a little silly.
>
> It's probably less silly in light of the mechanism Creative Commons
> suggests for embedding license info into artifacts with tight space
> for metadata:
>
> http://creativecommons.org/technology/embedding
>
> For file formats like MP3/ID3, there's only so much space for rights
> info. So, CC recommends storing an URL to the full info.
>
> One thing that bothers me, though, is how this becomes 'barely
> free'. I realize that it may be *annoying* or *stupid*, but how is it
> *non-free*? I understand how *excessive* conditions on modifications
> may make something non-free, but requiring that a verbatim URL be
> included with the Work doesn't seem excessive to me.
What I meant was simply that many similar, but slightly different,
requirements would be non-free. The requirement as is is certainly free.
By 'barely free' I guess I was sloppily trying to discourage people from
taking it, making a stronger requirement loosely based on it, and then
saying "But you said the CC clause was free; why isn't this one?"
Requiring that an arbitrary verbatim URI be "conveyed" with any derived work
is potentially non-free, depending on how arbitrary the URI is. A work
derivative of a large number of works could end up having to carry absurd
numbers of arbitrary URIs with it.
Luckily, this only requires that it be conveyed if the URI refers to the
copyright notice or licensing information for the work; and only "to the
extent reasonably practicable"; so it's free.
> I also am having a problem with understanding how putting limits on
> the modification of metadata (info about the Work) makes something
> non-free.
Well, there are at least two different issues wrapped up in this (possibly
more). Requiring that unmodified metadata be carried around is *not* the
same as restricting the creation of modified metadata.
Requiring that unmodified metadata be carried around alongside derived works
is generally fine IMO *if* the metadata is accurate, really is metadata,
and is otherwise not legally problematic. Many licenses have been very
sloppy about this, requiring text to be carried around which will not be
accurate for reasonable derived works, or which is wholly irrelevant to
some reasonable derived works.
If the creation of certain types of modified metadata is restricted, the
metadata may itself be non-free. The question then becomes (a) whether is
is, and (b) how much, if any, non-free metadata is an acceptable load for a
free work.
> This seems to be standard issue with most free licenses (you
> have to keep copyright notices,
When interpreted to include only accurate copyright notices, this is free.
> you have to distribute the license
> with the work,
The correct license for the work? This is free.
> you have to keep a change history,
This is one of those where it depends on exactly how the requirement is
written. "You must note your changes"? Free. "You must reproduce an
unmodified, and potentially inaccurate and irrelevant, copy of the upstream
ChangeLog?" Not free.
> yadda yadda). I see
> where restrictions on the content (can't change function names, can't
> change the ending of the short story) are non-free, but I'm not sure I
> grok why metadata "invariance" is.
>
> I really need some help getting this straight in my head. What am I
> missing, here?
Hope what I said above helps at least clarify thos issues a little.
Now on to the actual nub of the problem at hand.
> 4b> provided, however, that in the case of a Derivative Work or
> 4b> Collective Work, at a minimum such credit will appear where any
> 4b> other comparable authorship credit appears and in a manner at
> 4b> least as prominent as such other comparable authorship credit.
>
> NN> *This* is the problem clause. It's unclear to most of us
> NN> exactly what "any other comparable authorship credit" means.
>
> Yes, I see that. Is it "credit for comparable authorship", or "comparable
> credit for authorship"? A failure of the appositive!
Yup.
>
> The "any other ..." part is kind of difficult, too. Does it mean "some
> other ..." (credit has to be somewhere), or "every other ..." (anytime
> there's credit, this one has to be there, too)?
Indeed.
> NN> With this ambiguity, the "at least as prominent" requirement
> NN> is then a potential interpretation nightmare. Suppose, for a
> NN> silly and extreme example, you wanted to use a huge hunk of
> NN> material under this license in a version of ReiserFS, so that
> NN> the code under this license needed a "comparable authorship
> NN> credit" to Reiser's. Would that mean that the credit would
> NN> have to appear in the FS name, so as to be in the same
> NN> location and at least as prominent as Reiser's credit? Yeech.
>
> Yeech, yes. Possibly a more appropriate example would be when I
> include an Attribution-licensed quote from you (beyond the extent of
> fair use) in my book, "The Autobiography of Evan Prodromou". Would I
> have to change the title to "The Autobiography of Evan Prodromou and
> Nathanael Nerode"?
Indeed. If this *is* the requirement, it seems self-evidently non-free.
Surely this isn't supposed to be the requirement.... or is it?.... see, we
can't really be sure!
> Again, though, I wonder about the non-free aspects of this. Clumsy and
> inaccurate, yes. Non-free...? Would it be non-free because it's not
> possible for the licensee to comply because the license is vague?
Yes, in a word. If it's impossible for the licensee to know whether s/he's
in compliance or not, it's not in any real sense "free" for the licensee.
If we can't tell what a license means, we interpret it in the most
restrictive manner which seems reasonable. (Unless we have clarification
from the copyright holders as to their interpretation, of course.)
Otherwise, the copyright holder could just say "You misinterpreted the
license; I meant it in a more restrictive manner," and poof, the work turns
out to be non-free.
I hope this bit can be fixed, because I don't *think* that Creative Commons
intended the very restrictive interpretation. (Altough I'm not sure.)
And the trademark bit:
> NN> This isn't supposed to be an actual part of the license,
> NN> according to the source code for the web page; this should be
> NN> fixed so that this is clear when *viewing* the web page (it is
> NN> *not* clear now). That doesn't require changing the license.
> NN> It does require someone at Creative Commons noticing and
> NN> dealing with the issue. :-P
>
> Probably something as simple as:
>
> "Creative Commons", the Creative Commons logo, and the Some Rights
> Reserved logo are trademarks of Creative Commons. Their use is
> restricted by Creative Commons <trademark policy> to the extent of
> applicable law.
>
> ...would work better.
So true. :-)
Nathanael Nerode
>>>>>> "AS" == Andrew Suffield <asuf...@debian.org> writes:
>
> Me> One thing that bothers me, though, is how this becomes 'barely
> Me> free'.
>
> AS> Freedom is a binary test; a work is either free, or it is
> AS> not. There is no "partially free" or "semi-free". So "barely
> AS> free" is "free, but very close to the line; make this any
> AS> stronger and it will be non-free".
>
> I understood that part. The part I don't understand is, what line does
> the URL requirement get close to? What is the line between acceptable
> modification restrictions and unacceptable ones?
>
> I'll try to present one dimension of modification restrictions, being
> what type of content those restrictions require to remain in the
> modified version:
>
> 1. No restrictions on modifications whatsoever.
>
> 2. Restrictions to make sure that downstream users get the following
> 4 things: copyright notices, license notification, changelogs,
> warranty disclaimers.
If accurate for the derived work, only. :-)
> 3. Restrictions to make sure that downstream users get general
> information about the work (metadata), including the above 4
> things, but maybe perhaps some others. Examples: original author
> name, original work title, original metadata URL, bug-reporting
> site or address, main download site URL.
If accurate for the derived work, only. :-)
> 4. Restrictions that "protect" certain parts of the work itself
> (e.g., invariant sections).
>
> 5. Restrictions that prevent any modification of the work
> whatsoever.
>
> I'd posit that our line for free-vs.-non-free is between 3 and 4 here.
If accurate for the derived work, only. :-)
You might look at the Apache License 2.0 for the language about NOTICES
which was put in specifically to avoid requiring the presence of inaccurate
and irrelevant notices.
> Me> Would it be non-free because it's not possible for the licensee
> Me> to comply because the license is vague?
>
> AS> Licenses which are vague are particularly nasty, because you
> AS> can go with the "obvious" interpretation, and then get sued by
> AS> the copyright holder who turns out to have a different
> AS> one. Certainly we've had some copyright holders applying
> AS> strange interpretations to apparently free licenses before
> AS> now. To provide reasonable assurance to our users that
> AS> everything in main is free, we have to take the most
> AS> pessimistic interpretation, and see if that is free.
>
> Cool. So, if I can redirect back to the Attribution license, we have a
> worst-case interpretation with the Attribution license, where the
> author's credits have to be listed in _every_ place other credits are
> given, even if those places are possibly inconvenient (file name, work
> title).
Don't forget prominence. They have to be listed just as prominently as any
other credits, in those places, as well. The only safe way, given the
licence vaguesness, is to list all credits with precisely equal prominence,
regardless of the contributions of the different people.
> Even though it's vague (could mean "some" places, could mean
> "all" places), our New Math set theory teaches us that if we give
> credit in all places, we will have also have given credit in some
> places. So, by giving credit in _all_ places, we can comply.
>
> Now, given the "all places" idea: is that non-free? It may suck, but
> is it non-free?
Yes, because it a requirement which causes a prohibitive burden on the
creator of derivative works. It actually prevents giving appropriate
credit; it may forbid reasonable titles for the work; etc.
--
There are none so blind as those who will not see.