[DB-SIG] Standardized Date-Time class

[Jeffrey C. Jacobs]

-----Original Message-----
From:	Magnus Lycka [SMTP:magnus.lycka@tripnet.se]
Sent:	Wednesday, December 10, 1997 10:20 AM
To:	db-sig@python.org
Subject:	Re: [DB-SIG] Standardized Date-Time class

At 14:10 1997-12-10 +0200, Hannu Krosing wrote:
>> From my point of view they are worthless if I can't use them =
commercially.
>> I need the revenue from my programming to pay my rent and food. I =
suggest
>> we forget the professor and reinvent the wheel, if the old wheel =
won't be
>> allowed to roll freely...
>
>Correct,
>
>But unless they come with a license that prohibits any and all =
commercial
programming
>after looking at them ;), we may use them to get some good ideas for =
our
own date
>class.

Hm... I think you have to learn to respect copyrights in Estonia
if we are to take you in to the European Community. ;-)

This is really a tricky legal question, and it's naturally difficult
to _catch_ you if you change a reasonable amount of code. Still, if you=20
have seen someone elses code, thought, 'Aha!' and then written your own
similar program, it could certainly be argued that your work is derived
from the program you saw, and thus a violation. If you never saw the =
other
program that can hardly be claimed.

Since it is the source code that is copyrighted it's probably not =
possible
to claim any legal complaints if you only se a program executing and =
then
copy it's function based on percieved behaviour. That's unless you copy =
a=20
screen layout that is considered to be a work of art I guess...

If it's patented, not seeing the original is irrelevant, it's still a=20
violation, but if we are talking about copyrights it is my understanding
that 'inspiration' from reading (or watching) someone elses literary =
work,
be it a book, a movie or a source listing, can mean that you end up in a
situation where you can suddenly be in a legal jam if you create this=20
thing that you might well have written anyway... Knowledge isn't always=20
beneficial...


	Magnus

P.S. I have no legal education, and regardless of the Berne convention
copyright regulations differ between countries, so don't trust me as a
legal authority. I just wanted to make you aware that the problem =
exists.

=20
	Those are very good points, and one thing we have to remember is that =
many countries, such as China, India and Russia, although in words being =
committed to international Copyright law, are often lax in their =
enforcement of such laws, so contrary often times they are to the =
cultural concept of some of the people of some nations.
	I will say that on the specific case of the Reingold-Dershowitz =
Calendrical algorithms, I am now "dirty", having seen the Lisp source of =
the code they are *indending* to patent.  Thus, I am pretty forbidden =
from writing any Calendar converter and distributing it directly, even =
if under the GNU license.  As Magnus has implied, having a binary =
distribution is different than having the source, however, it is not =
perfect.
	One example you can take from a book I once read about the development =
of a microchip which is supposed to emulate some other, rival company =
chip.  The way the company avoids copyright and patent infringement is =
by having an independent entity fully analyze and document the cause and =
effect of every possible input on the chip, and then without letting the =
analyzers contact in any way the engineers, the engineers proceed to =
build a chip which exactly follows the specification defined by the chip =
researchers, who themselves have become "dirty" as they have seen the =
original chip.  Thus in that way, the new chip engineers will have never =
seen the rival chip, and thus be "clean" from any potential lawsuit.
	In software, binary code is sometimes considered clean enough, as the =
cost of reverse-engineering the code directly is usually not as great as =
developing the code oneself, though this again is a practical point, not =
a legal one.  And still direct use of the binary form with be a =
violation of software license if in a commercial context.  Even so, it =
is not feasible to distribute any library in only binary form as part of =
the Python distribution because of cross-platform support, so rather =
than including such code for everyone, it would have to be optional, and =
obtained individually on request.
	Just stepping back to the original point of developing a set Calendar =
converters for Python, the code as I understand it that Christian Egli =
ported from Reingold-Dershowitz is considered in the public domain, as =
the authors are not trying to maintain any hold on the people using it.  =
It is only for the more complicated Chinese, Mayan and Hindu algorithms, =
as well as those for computing Lunar phases and Sunrise/Sunset times =
that they have copyrighted and are trying to patent.  Note though, that =
these algorithms appear at least to some extent in their book, =
"Calendrical Calculations", and as my friend has informed me, the patent =
office does not allow you to patent what has already been published.  =
This was the problem with RSA, which in case you haven't noticed has =
made its way into Python's Cryptography module, despite the original =
authors attempts to prevent its general distribution.  However, as I am =
directly involved in developing a possible C++ implementation of the =
Calendrical algorithms for the authors, I will not be the one to make =
any legal test of their material, and I don't think it's worth any of =
our time for that.
	In conclusion, all I suggest is that any Calendar converters we include =
in Python be modular and inter-changeable, so that people using Python =
commercially can use those in public domain, but need not use the =
copyrighted ones, and people wishing to do Calendrical research can =
request the full Calendar library set, and simply plug it into python as =
if they were part of the standard distribution.  Simply, have =
Gregorian.pyc, Julian.pyc, Hebrew.pyc, Islam.pyc and ISODate.pyc be part =
of the standard distribution, and optionally one can add Hindu1.pyc, =
Hindu2.pyc, French.pyc, and Chinese.pyc to their installation and import =
them as they do the standard Calendar libraries.

			Be Seeing You,

			Jeffrey.

---
~,-;`  The TimeHorse
Sometimes also a Dragon. . .



_______________
DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org
_______________