[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What are tainted developers allowed to work on?

From: Mark Wielaard
Subject: Re: What are tainted developers allowed to work on?
Date: Thu, 13 Jan 2005 21:12:30 +0100


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"



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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]