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
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
