On Oct 29, 2005, at 9:22 AM, Mark Wielaard wrote:
Hi Geir,
On Wed, 2005-10-12 at 10:11 -0400, Geir Magnusson Jr. wrote:
For example, create a new subclass of Exception that doesn't look
like ...
public class FooException extends Exception {
public FooException() {
}
public FooException(String message) {
super(message);
}
public FooException(String message, Throwable cause) {
super(message, cause);
}
public FooException(Throwable cause) {
super(cause);
}
}
I've actually been in a situation where a lawyer flagged something
like this as a problem.
Yes, the problem your lawyer has is that if you say you studied an
implementation of FooException from a proprietary implementation and
then come up with a almost similar implementation you have
something to
explain in court if you ever end up in a lawsuit. You may still get
away
with it if you can proof that the implementation the only "obvious"
way
to implement that piece of code. But suddenly you are the person
having
to proof something. That is why projects like GNU Classpath have a
rule
that you cannot study any proprietary implementation. That makes such
potential court cases a lot easier.
It's more subtle than that. It's isn't that you need to have seen
the other code before, the simple fact that it's the same as
something else would be a problem. Yes, it's much easier when a)
you've never seen the code and b) what you are looking at is the
"standard for the trade" way of doing things...
You might also want to look at what Lawrence Rosen said about the
problems with "Residual Rights" and looking at proprietary source code
while working on a Free Software project. See for example his online
book http://www.rosenlaw.com/oslbook.htm page 258 deals with the
case of
implementing 'competing' open source software after looking at
'Shared
Source' code (in this case Microsoft code, but some of the SCSL, JRL,
etc covered code released by Sun have similar issues)
"If you are a software developer who intends to write software that
might potentially compete with Microsoft's copyrights or patents,
there is great risk in looking at Microsoft's source code. Under the
copyright law in the United States, if Microsoft proves that there is
"substantial similarity" between your commercial software and theirs,
you may be an infringer. You may have to prove that you saw and read
Microsoft's source code but that you relied only on intangibles and
only on your memory when you wrote your own software.
That's a difficult evidentiary burden. I'm not sure how even an
experienced programmer can walk that fine line. Perhaps the best way
is simply not to look at Microsoft's source code at all."
I'm familiar with teh problem. That's why we've been talking to sun
about the JRL, and I think that progress has been made in the area of
Residual Rights.
And of course there is the simple observation that we have been
working
for more then 20 years on Free Software now (just 10 for GNU
Classpath,
gcj and kaffe of course) without needing to look at any proprietary
source code. Often producing better, more efficient, robust and
cleaner
code then any proprietary implementation. So why would we start now?
No one is suggesting you do :)
geir
The GNU Classpath developer wiki has more explanations about this
topic:
http://developer.classpath.org/mediation/ClasspathFirstSteps
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
