Re: What are tainted developers allowed to work on?

[James Damour]

On Thu, 2005-01-13 at 21:12 +0100, Mark Wielaard wrote:
> Hi,
> 
> On Sun, 2005-01-09 at 18:06 +0100, Mark Wielaard wrote:
> > > If we cannot find a solution on at least one of those points because
> > > of legal uncertainity whom do we have to ask then (FSF legal?)
> > > and who is doing the communication?
> > 
> > That should be me. I will ask FSF legal again if they have anything to
> > add to the above (or if I say something which is completely wrong) and
> > the summary you made of the discussion.
> 
> The reply from licensing was that they had nothing to add to the
> previous email explaining the situation.
> 
> I also wrote the following to a more specific question of helping out on
> GNU Classpath and asked if they could check my answer and point out
> anything I said wrongly or to give any suggestions on how I can
> formulate our rules more clearly. To which the reply was that the
> following explanation is fine.
>         
>         [Can someone who has seen Sun source code for a particular part
>         of the core libraries contribute to GNU Classpath?]
>         
>         Depends. (I will forward a copy of this answer to FSF legal so
>         they can check what I say.)
>         
>         If the developer got access to the source code by signing some
>         contract (like the SCSL) with Sun then it would be best to
>         examine that contract (by FSF legal) before deciding.
>         
>         If the developer just accidentally saw some of the source code
>         and had no intention (and didn't actually) study the
>         implementation (with the intention of contributing to GNU
>         Classpath) there is no problem.
>         
>         Studying a proprietary implementation with the intention of
>         implementing it (better) for GNU Classpath is a clear no-no. The
>         general rule is that if you have looked at or studied any
>         (proprietary) implementation of a package you should not work on
>         that package for GNU Classpath. That is because it would be
>         difficult to proof that you really did an independent
>         implementation. Since what you create might look very similar
>         (which is not unlikely). Working on something completely
>         unrelated is OK (as long as there are no contractual obligations
>         with Sun or some other company to not do this of course).
>         
>         The important thing is that we want to be clear on the fact that
>         we created an independent implementation. We don't want to get
>         into tricky legal situations. We want to avoid risking to go to
>         court over reverse engineering or clean room situation questions
>         if not absolutely necessary. That is why we in general just say
>         "please don't contribute if you looked at other
>         implementations". If someone thinks that their actions might be
>         explained as copying directly or indirectly another
>         (proprietary) implementation then that could be a problem that
>         we want to avoid.
>         
>         FSF Legal will always advise not to take any unnecessary risks
>         that might endanger the (perceived) free software status of a
>         GNU project. (If we might need to go to court to proof that what
>         we did was OK, then don't!)
>         
> I hope these summaries clear up any confusion about the "tainted"
> question.

They did for me.  "Caesar's wife must be above suspicion" is the word of
the day.  Mauve tests and general documentation should be fine... and
Javadocs in packages I have never seen are certainly open.  The rest
raise questions, and the FSF really wants to avoid any question that
could land them in court.
> 
> Cheers,
> 
> Mark

signature.asc
Description: This is a digitally signed message part