Rights vs Responsibilities (Was: To Al Kossow at bitsavers)

Mouse mouse at Rodents-Montreal.ORG
Sun Nov 15 17:53:55 CST 2015

> [...] IP rights over software vs what seems, at the moment in all
> legislation which is relevant, to the total lack of any
> responsibilities by the owner of the software.

This is an interesting point, which I had not thought of, nor seen
raised elsewhere, before.

On the one hand, it's true in general that any system involving rights
without associated responsibilities grows concomitant abuses.
(Responsibilities without corresponding rights is a different bag of
problems, but not very relevant here.)

On the other hand, you need to be very careful exactly what
responsibilities you impose, or this could have an even more deadening
effect on software creation than existing IP law.

Of course, depending on your biases and what software creation would be
impacted by the details in question, you may consider such deadening a
Good Thing.  (For example, I personally wouldn't mind making it more
expensive to create, or at least commercially distribute, closed-source
software, provided it doesn't also impact open-source software.)  I
suspect this is a case of "ask five people, get at least six answers".

> The days when the internet was composed of [...]

This is a specious argument; not all software has anything to do with
the Internet.  (I don't think this will stop being so, either, despite
all the Internet-of-things advocates trying to, basically, do that.)

> Most large software packages have some software bugs.

Most?  All, I would say.  I doubt there exists nontrivial software
without bugs - and I'm not sure about trivial software, either, though
it's possible a few of the smallest examples qualify.

> If all of the code had to be published, it would be

a substantial, possibly unjustifiable, cost in some cases.  Consider
someone making, oh, say, thermostats.  They don't distribute their
software except embedded within their devices.  Why should they have to
provide for software distribution channels?

Consider the same thing, only instead of ROM code and a microprocessor
core, they have a FPGA that loads its config from flash.

Consider the same thing, only the FPGA config is in mask-programmed

Consider it with a mask-programmed gate array instead of an FPGA.

Consider the same thing implemented with discrete logic.

Where do you draw the line between "software" and "not software"?

> To often it takes users to protest for a long time for changes to be
> made.

Why is this a bad thing?  In some cases it can be, certainly, but I'm
far from convinced it always is.

Your argument here, again, appears to be designed around the "end user
running software on a general-purpose desktop computer" paradigm.  You
need to take into account the rest of the software out there if you
want your changeas to be a serious contender in the real world - or at
least you need to explain why it's OK to ignore those things.

> The point I am making is that perhaps instead of just complaining, a
> group could be formed which produces actual changes in the laws which
> govern software.

There's another point: copyright applies to a lot more than software.
You need to make sure your changes are at least tolerable for other
copyrighted things, or else you need to somehow manage to draw a line
between "software" and "not-software" (a notoriously hard line to draw;
consider the famous t-shirt which had an implementation of RSA bar-code
printed onto it).

> Would it be possible to form a group which produces advice for
> changes in the laws that would be beneficial to all parties and
> provide owners of copyright and IP over software benefits at the same
> time that the users also benefit.

I doubt it, largely because it seems to me that at least two of the
affected groups have more or less diametrically opposed interests.
(Mind you, I'd love to be proved wrong in this regard.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

More information about the cctalk mailing list