Stefan's headers [was:Names and identifiers]

Peter J. Holzer hjp-python at hjp.at
Sun Jun 10 10:25:24 EDT 2018


On 2018-06-09 10:15:43 +1000, Chris Angelico wrote:
> On Sat, Jun 9, 2018 at 8:19 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> > Chris Angelico <rosuav at gmail.com>:
> >> On Sat, Jun 9, 2018 at 6:59 AM, MRAB <python at mrabarnett.plus.com> wrote:
> >>> So those with the most money can buy the most protection?
> >>
> >> Yes, or more specifically, those who believe they can make the most
> >> money from that protection. Ownership becomes pay-to-win, literally.
> >
> > In the words of Scrooge McDuck:
> >
> >    <URL: https://i.stack.imgur.com/rMeiB.png>
> >
> >
> > But guys, surely you are familiar with the exponential function:
> >
> >  * Everybody can afford a year for $1.
> 
> $1 per what, though? According to GitHub, I have 157 repositories. Is
> that 157 separate things that cost $1 for a single year of protection?
> Or do I pay per file of source code?

When I first read about the scheme Marko is proposing here it was
presented mainly as an alternative of the current patent scheme.
There it is obvious: You pay per patent.

The article also extended it to books. There it is also obvious: You pay
per book.

Patents and books are nice, distinctive "works". You might argue
whether "The Lord of the Rings" is one book or three, and whether each
edition of "Learning Python" (there are now 5 of them) is a separate
book, but these are relatively easy cases.

Software is harder. When software was still sold in a nice box with a
three-ring binder and a few floppies, it was similar to a book: If it
comes in one box, it is one work to be copyrighted.

But with online distribution (not necessarily github) the boundaries
become very fluid. When Debian still contained the Roxen webserver, it
comprised over 100 packages: The maintainer had put every plugin into a
separate package. I did something similar with my qpsmtpd plugins: Each
is in a separate .deb or .rpm file.

There is also the problem of how to treat revisions: If I always
register the newest revision and stop paying for older revisions, is
code I didn't change still protected or not?

I don't remember whether the article addressed these problems. I guess I
should read it again (it was in CACM, a few years ago).

Personally, I would let the author decide what constitutes one work.
If you think your 157 git repos are a single work, register it as one.
Whenever you think you have made enough changes that this is a new work
which should be protected, register it again. And if the fees for your
old versions become too high, let them lapse.


> >  * Every worthwhile creation is worth $1,000 for ten years.
> 
> Not true by a long shot, and if you don't believe me, you can pay me
> $1000 right now for ten years' use of any of my free software.

I think he meant it the other way around: If you can sell your software
for 10 years, you can affort $1000 to have your monopoly protected.


> >  * And if Disney can pay the fee for Mickey Mouse for fifty years, the
> >    United States Government can quit all taxation, pay off the national
> >    debt and buy every American a luxury yacht and a private island in
> >    the Caribbean.
> 
> And if you think that Disney would actually let it compound according
> to your theoretical definition, you're a dupe AND a fool. They'd
> figure out some way to reset the counter every five years.

More likely they would prevent such law from being passed in the first
place.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180610/dc9dbe70/attachment.sig>


More information about the Python-list mailing list