harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Wielaard <m...@klomp.org>
Subject Re: [legal] Bulk contribution barrier to entry
Date Sat, 29 Oct 2005 13:22:09 GMT
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/

Mime
View raw message