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. 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." 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? 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/
signature.asc
Description: This is a digitally signed message part
