Python obfuscation

Chris Mellon arkanes at
Thu Nov 17 13:41:33 CET 2005

On 17 Nov 2005 01:29:23 -0800, Ben Sizer <kylotan at> wrote:
> Mike Meyer wrote:
> > > Are you claiming therefore that it's more acceptable to you to have to
> > > access the data remotely every time you use the software than once per
> > > install?
> >
> > Alex's solution doesn't require special treatment for disaster
> > recovery and/or planning, and as such is a valid answer to the
> > question. It may be unacceptable for *other* reasons, but it beats
> > dictating a disaster recovery plan for your software to the end user
> > hands down on that basis.
> Sorry, I just don't see this as being a significant difference that
> makes 'access-always' acceptable and 'access rarely' unacceptable.
> > > No, I am just pointing out that you are mixing up the concept of an
> > > actual 'right' such as one embodied in a state's constitution, with an
> > > implied 'right' that is just an exemption from committing an offence.
> > > The term 'right' does not even appear in the relevant part of US
> > > copyright law, except to state that it is a limitation on the copyright
> > > holder's rights.
> >
> > You're still just playing semantic games. The common usage is "fair
> > use rights." If you mean "... without infringing on the end users
> > rights, except for fair use rights", then you should say that.
> Call it what you like; still, I cannot be infringing on your right when
> such a right does not exist to be infringed. If you want to term it a
> 'right', feel free, but that's not what you're granted under US law or
> the Berne Convention. The 'common usage' here leads to a
> misinterpretation of what you're entitled to. What is actually stated
> is a limitation on the copyright holder's exclusive rights, which is a
> very different matter.

Do you have a legal right to wear an orange shirt? To sit backwards in
your chair?

Your rights are anything you can do that is not forbidden - the US
constitution is explicitly designed in this way, something that people
often forget. There is no difference between an "explicit" and an
"inferred" right, by design. If you read the text of the US
constitution, even the phrasing makes this clear. In fact, the format
of the Bill of Rights was considered harmful by some of the founding
fathers, because they felt that people would interpert it exactly as
they have - as enumerating the limits of government power, instead of
enumerating the powers themselves.

Therefore, by extending your rights via DRM, you are infringing upon
the rights of your customers. I *do* have a legal right to backup and
archive my purchased software, just as I have a legal right to write
this email, and I have a legal right to watch a DVD I've purchased.

The very basis of law is about drawing lines between where one persons
rights end and another begins. What (all current) DRM solutions do is
extend the rights of the copyright holder. This, *by definition*,
comes at the expense of the rights of everyone else. The granting of
copyright at all is a limitation of the rights of everyone else, but
one that is legally enshrined and that people (generally) accept as
being in the common good. It's very similar to the concept of private
property. The law grants you the right to keep people from walking
into your house. However, if you decide to build an electric fence
across the sidewalk and into the street, you are infringing on thier
right to walk past.

Further, if you decide to define "right" as something that is
specifically legally protected, then you have no right to embed DRM in
your software at all - you are *explicitly* expanding the rights
granted to you by copyright law, and you do not have explicit legal
rights to do that. Further, you do not have explicit legal rights to
prevent fair-use copying.

> --
> Ben Sizer
> --

More information about the Python-list mailing list