cc-licenses AT lists.ibiblio.org
Subject: Development of Creative Commons licenses
List archive
- From: "Greg London" <email AT greglondon.com>
- To: "Discussion on the Creative Commons license drafts" <cc-licenses AT lists.ibiblio.org>
- Subject: Re: Rationale for CC's GFDL recommendation
- Date: Sun, 20 Mar 2005 10:05:38 -0500 (EST)
Daniel Carrera said:
> Greg London wrote:
>
>> Isn't the only issue around FDL being free the invariant sections?
> http://people.debian.org/~srivasta/Position_Statement.html
++ DRM Restriction
++ You may not use technical measures to obstruct or control the
++ reading or further copying of the copies you make or distribute.
I dunno, but I don't read this as meaning I cannot keep a private
copy of the work behind a firewall. I read it as meaning I cannot
add any technical measures to the file itself. If one wants to
take an extremely literal interpretation, one could argue that if
I print out a paper copy of a FDL work and keep it in my living
room, then I would need to keep my front door unlocked lest someone
claim my deadbolt is an "obstruction" to the document.
I can only hope that common sense hasn't completely left the legal
system such that this interpretation is possible.
++ Transparent and Opaque copies
++ The requirements for redistributors should .. not to force users
++ to download the transparent form even if they don't want it.
If someone really supports free documentation, they would never
"force" their users to download something they didn't want.
If someone like Microsoft decided to use an FDL document, and
they didn't want people to download the transparent copy, they
might decide to bundle the opaque and tranparent copy together
and hope that the resulting gigabyte file will be too big for
people to want to download. But if there is really anything of
value in teh file, then all it takes is one person with enough
patience to download it, then he can separate the files and
offer teh opaque version on his own website with a URL to the
transparent copy.
I cannot see this being a legitimate problem in any real world
situation.
++ we cannot accept works that include "Invariant Sections"
++ and similar unmodifiable components into our distribution
That the license ALLOWS invariant sections is separate from
whether or not the author INVOKES the invariant clauses of
the license.
One could argue that the BSD license is also not free
because it ALLOWS someone to slap "All Rights Reserved"
on their copy. Public Domain style license allow proprietary
versions. Whether or not it is free is really a matter of
whether or not the author INVOKES that option.
Declaring FDL non-free because of a license OPTION is
losing focus of the big picture.
Overall, I could see having the language fo the license
changed to clarify that the anti-drm clause does not
require me to leave my front door unlocked, just to clarify
it for the literalists who are looking for problems.
But I do not see any real problem with the FDL being free
as it is now.
> I don't think so. Debian legal doesn't have a problem with attribution.
> And the copyright notice provides attribution *anyways*.
CC-Attribution is something above and beyond a copyright notice.
copyright notices can be passive. you can embed them as you
go along and just leave them.
Attribution is active. If you put one name on the front cover,
you have to put everyone's name on the front cover. Which makes
it difficult to honor in a large project. Which means that the
best way to deal with attribution is to attribute everyone
equally by not attributing anyone at all. i.e. keep an appendix at
the back that has people's names on it and you maintain that.
But then if you're going to do that, it's back to being like
a passive copyright notice. And if that's the case, then why
bother with Attribution?
-
Rationale for CC's GFDL recommendation,
Henri Sivonen, 03/19/2005
-
Re: Rationale for CC's GFDL recommendation,
Greg London, 03/19/2005
-
Re: Rationale for CC's GFDL recommendation,
Daniel Carrera, 03/19/2005
-
Re: Rationale for CC's GFDL recommendation,
drew Roberts, 03/20/2005
- Re: Rationale for CC's GFDL recommendation, Daniel Carrera, 03/20/2005
-
Re: Rationale for CC's GFDL recommendation,
Greg London, 03/20/2005
-
Re: Rationale for CC's GFDL recommendation,
Daniel Carrera, 03/20/2005
- Re: Rationale for CC's GFDL recommendation, Greg London, 03/20/2005
-
Re: Rationale for CC's GFDL recommendation,
Daniel Carrera, 03/20/2005
-
Re: Rationale for CC's GFDL recommendation,
drew Roberts, 03/20/2005
-
Re: Rationale for CC's GFDL recommendation,
Daniel Carrera, 03/19/2005
-
Re: Rationale for CC's GFDL recommendation,
Greg London, 03/19/2005
Archive powered by MHonArc 2.6.24.