-Original Message-
From: [EMAIL PROTECTED]
Sent: Monday, October 22, 2001 02:20
This is german and in most EU countries law.
For germany Urheberrechtsgesetz.
E.g. www.recht.de, follow links to Urheberrechtsgesetz.
Unfortunately, I couldn't find anything specific. If you could
-Original Message-
From: [EMAIL PROTECTED]
Above is only ONE implementation lsited, and
java.util.Dictionary is not
abstract but the base class.
According to my knowledge, it is an abstract class. See:
http://java.sun.com/j2se/1.3/docs/api/java/util/Dictionary.html
-Original Message-
From: [EMAIL PROTECTED]
Sent: Monday, October 22, 2001 02:19
If I write a class which extends java.util.Dictionary,
then whose
implementation
of java.util.Dictionary am I adapting:
No-one's.
Is the original work changed? No.
Is the original
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Sunday, October 21, 2001 23:40
The text of Bob's code is not cut and paste, it is not
plagerism, yada yada.
It doesn't have to be Cut Paste. Please see Micro Star v. FormGen:
-Original Message-
From: [EMAIL PROTECTED]
Sent: Monday, October 22, 2001 02:26
For copyright law is only one thing interesting:
If you look at the piece of derived work, can you still see the
original work?
I would argue that it is sufficient that the original class assumes a
-Original Message-
From: Chris Gray
Sent: Monday, October 22, 2001 05:21
Chris, thanks for your email. That was a very good reading.
Yes, java.util.Dictionary is abstract (and contains only
abstract methods), so
any non-abstract class derived from it will need to override
all its
-Original Message-
From: Ken Arromdee
Sent: Monday, October 22, 2001 00:11
When you derive a class, you're creating a copy of the
original class *on your
machine*. That doesn't mean that if you write code that
derives a class, and
distribute the code, you're distributing copies
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 22, 2001 06:06
Every implementation of the Java language contains the
non-abstract class
java.util.Properties, which does in fact implement all the methods of
Dictionary.
So let us suppose
Hi all!
Michael Beck wrote:
For copyright law is only one thing interesting:
If you look at the piece of derived work, can you still see the
original work?
I would argue that it is sufficient that the original class assumes a concrete
or permanent form in the derived class by
-Original Message-
From: Angelo Schneider
Sent: Wednesday, October 24, 2001 08:12
http://eon.law.harvard.edu/openlaw/DVD/cases/Micro_Star_v_Formgen.html
That case is not about derived work but about plain copyright
infringement.
Derived work is something different.
on 24/10/01 1:44 pm, Michael Beck at [EMAIL PROTECTED] wrote:
I don't know, but if had a super-cool grid class,
I certainly would like the copyright to protect me from anyone
buying my grid, creating a subclass, and then marketing it against
me.
Unless they distribute your code without
-Original Message-
From: Rob Myers
Sent: Wednesday, October 24, 2001 08:54
Unless they distribute your code without negotiating a deal
with you (which
is piracy), people will still need to buy your class in order
to use the
oo-derived class. So this would drive sales of your
Michael Beck wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 22, 2001 06:06
Every implementation of the Java language contains the
non-abstract class
java.util.Properties, which does in fact implement all the methods of
I find this thread interesting, and hope that when some consensus is
reached (or the thead dies down and there is perhaps an agreement to
disagree) that someone can summarize the areas of consensus and
disagreement for a layman. (Perhaps the best resting place for
something like that is on a
IANAL, TINLA.
on 24/10/01 2:07 pm, Michael Beck at [EMAIL PROTECTED] wrote:
That doesn't matter. The issue is legal, i.e. does the author holds the right
to future releases of the grid, or can anyone develop new versions of the grid
by using inheritance?
There is no way that they can do
This is not legal advice. No attorney-client relationship is established.
etc etc
From: Michael Beck [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: Is inherited class a derivative work?
Date: Wed, 24 Oct 2001 05:45:38 -0400
[snip]
Of course, by using the
Hi!
This has absolutly nothing to do with inheritance nor, reffering to the
name of this list: licenses.
See below.
Michael Beck wrote:
--
Von: Michael Beck[SMTP:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 24. Oktober 2001 15:07:34
An: [EMAIL PROTECTED]
Betreff: RE:
Chloe Hoffman wrote:
In the case of Java, there seems to be no need to rely on fair use. The
following is from, e.g., the JDK 1.1 documentation:
Sun Microsystems, Inc. (SUN) hereby grants to you a fully-paid,
nonexclusive, nontransferable, perpetual, worldwide limited license (without
the
[EMAIL PROTECTED] wrote:
Why? You, as some others, have suggested that in order to
declare something as
derivative work, it has to contain parts of the original.
The above case shows
that it doesn't have to be the case, that the original part
can assume a
concrete or permanent form by a
On Wednesday 24 October 2001 06:07 am, Michael Beck wrote:
That doesn't matter. The issue is legal, i.e. does the author holds the
right to future releases of the grid, or can anyone develop new versions of
the grid by using inheritance?
A subclass is not a new version of the grid. It is an
On Wednesday 24 October 2001 04:01 pm, Michael Beck wrote:
No, it has nothing to do with it. Otherwise you would imply that every
author not giving away the rights to his/her creation (book, movie, song,
painting, house design, etc.) wants to have a complete megalomaniac
control over their
The `right to derive classes`? I thought someone explained, quite thoughtfully, that
this was NOT a matter of concern under copyright law. In addition, I think it is
unadvisable to make object-oriented programming practices like inheritance,
encapsulation, or polymorphism the subject matter of
22 matches
Mail list logo
