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: [cc-licenses] Version 3.0 - Public Discussion
- Date: Sat, 12 Aug 2006 18:15:49 -0400 (EDT)
> The question is really where our control point is. Creative Commons, and
> this mailing list, don't have direct control over what types of DRM are
> created, what computers, portable devices, and entertainment centres
> people buy. Creative Commons does have control over the terms of the
> licenses.
If this piece of the license
: You may not impose any technological measures on
: the Work that restrict the ability of a recipient
: of the Work from You to exercise the rights granted
: to them under the License.4
can be tweaked to enforce the principle that a user
playing a DRM work on a DRM-only player does not restrict
the users ability to copy, distribute, or
create derivative works, >>>of that very same work<<<,
>>>on that very same player<<<, then CC actually CAN
control the problem.
If DRM-Dave has a company that makes DRM players,
and Dave goes out and converts some ShareAlike work
to be DRM'ed so it plays on his hardware, then Dave
must do so in such a way that Share-Alike-Sam can
copy, distribute, and create derivative works, of
that same work, on that same piece of hardware.
Which means Dave does not get an advantage for pulling
a ShareAlike project behind DRM doors.
The only way I see this being a problem is if the
player hardware is DRM-only and the company refuses
to allow anyone to convert a ShareAlike work to
play on the hardware, via DMCA and such.
But if the company is this strict, then that means
they WANT to be the sole source of the ShareAlike
work on their hardware if they could. If they're
not this restrictive, then they'll likely have a
way to play non-DRM files on their player.
If a company is allowed to pull a work into DRM,
and not allow people to copy, distribute, and
create derivatives of that work on that DRM
hardware, then you're allowing proprietary forks
through technical measures.
The ONLY argument I've heard so far to ALLOW this
is because if a company wants to maintain an advantage,
if they want to be the sole source for copies of the
work on their hardware, then you're saying let them
have the advantage so we can at least play the works
on our hardware.
But you're ignoring the loophole you've created.
Let Microsoft create an derivative of Linux and
distribute an executable so at least we can run
our Linux apps on Microsoft. It's OK if they
dont' distribute source code of the executable
because it's more important that we be able to
run Linux applications inside MS-Windows.
If Microsoft wont play inside of copyleft,
then letting the work go outside of copyleft
so Microsoft will use the work, sort of
defeats the whole purpose of copyleft.
I'm not "politicizing" the license, trying to
"fight DRM" with the license. This loophole
creates a vulnerability that a Gift Economy
project may not be able to afford.
Saying a company can't use DRM to take a SA
work private is no more political than saying
Microsoft can't distribute an executable
built with Linux software without distributing
the source code.
I'm not fighting Microsoft or proprietary software
by advocating a copyleft license. I'm saying you
need copyleft to protect the Gift Economy.
And I'm not "Fighting DRM" wtih the license by
saying a company can't use DRM to take a work
private, I'm saying allowing a company to take
a work private and hide it behind DRM is as much
a potential threat to a Gift Economy project
as a proprietary fork.
You're leaving a barn door open by allowing
DRM to be used to take a work private. Unless
people can exercise all rights of the work
on the hardware platform in question, then
it is a potential loophole that could be
exploited against the Gift Economy project.
And since the Gift Economy project specifically
chose ShareAlike to be protected from exploits,
it seems irresponsible to leave a known exploit
in the license.
Otherwise, we might as well lobby to have the
next version of GPL allow microsoft to make
proprietary forks of GPL'ed software on the
argument that it will be more convenient for
some users who use Microsoft software, even
though it could then easily kill the Gift
Economy project that created the GPL software
in the first place.
Greg
--
Wikipedia and the Great Sneetches War
http://www.somerightsreserved.org
-
Re: [cc-licenses] Version 3.0 - Public Discussion
, (continued)
-
Re: [cc-licenses] Version 3.0 - Public Discussion,
Evan Prodromou, 08/11/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, drew Roberts, 08/11/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, Karl Ebener, 08/13/2006
- [cc-licenses] CC 3 and Fair Use [ Was Re: Version 3.0 - Public Discussion], Rob Myers, 08/14/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, Evan Prodromou, 08/14/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, Greg London, 08/14/2006
-
Re: [cc-licenses] Version 3.0 - Public Discussion,
Evan Prodromou, 08/11/2006
-
Re: [cc-licenses] Version 3.0 - Public Discussion,
Rob Myers, 08/12/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, Greg London, 08/12/2006
-
Re: [cc-licenses] Version 3.0 - Public Discussion,
Evan Prodromou, 08/12/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, Greg London, 08/12/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, Evan Prodromou, 08/12/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, drew Roberts, 08/13/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, Greg London, 08/13/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, Greg London, 08/13/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, drew Roberts, 08/13/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, drew Roberts, 08/13/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, Luis Villa, 08/13/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, drew Roberts, 08/13/2006
- Re: [cc-licenses] Version 3.0 - Public Discussion, Rob Myers, 08/13/2006
Archive powered by MHonArc 2.6.24.