Re: [legal] Bulk contribution barrier to entry

["Geir Magnusson Jr." <ge...@apache.org>]

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
geirm@apache.org