Hi, On Tue, 2008-06-24 at 23:30 +0200, Roman Kennke wrote: > IANAL either, but from my understanding this is not the problem. At > least not for contributors. The problem is copyright, and this is > regardless of the license, proprietary or free. If I look at Sun's code > and then go and implement something in GNU Classpath that is very > similar or equal to what I studied before in OpenJDK, I risk to be > blamed for copyright infringement. Yes. This is the real issue. So when someone asks "where is the line", the answer is "if you are implementing something for GNU Classpath, don't study the implementation code from another implementation, you risk coming up with something identical and then the 'ownership and distribution rules' would be in question". So concretely. If you find a bug in GNU Classpath, it is OK if you test against some other implementation and see what it does (run various programs and tests). It isn't OK to go study the other implementation code to see what it precisely does and then write the same code for GNU Classpath. And in all this "common sense" also applies. If the projects are both free software, then obviously one of the intentions was that people are free to study the code and learn from it. And an obviously correct oneliner that is identical (maybe because it was described in Hackers Delight - really cool book btw. - as the obvious hack to implement something) then that isn't a problem of course. If however you can tell that by studying some other code you will end up with an identical paragraph of code in GNU Classpath, then that is a problem. And don't ever take any risk with proprietary code. > Normally in FLOSS projects this is > less of a problem because people have an attitude of sharing anyway, but > as you said, that doesn't count much from a legal POV. Of course, if the > licenses were compatible it would be much easier, we could simply import > the code in question into external/ and be done. Yes. That would indeed be ideal. If another free software project already has better code to do a particular thing just reuse it as is, instead of reimplementing it (given that a reimplementation wouldn't give any other benefits of course - there are lots of reasons for writing something in a cleaner/better/faster/leaner way). The main problem here is whether or not we want to end up with a GPLv2-only code base for libre java. I personally would really like to avoid that and keep the GNU Classpath codebase for those people wanting to upgrade to GPLv3 or later, I believe the compatibility with the Apache license, the explicit patent protection and the clarification of the exception rules are all very important. So, in a way, your mission, if you choose to accept it, is to convince everybody to upgrade to GPLv3 +exception. I'll contact the FSF to see how they can help (GCC is going through an upgrade discussion for GPLv3+exception for the runtime libraries right now, so we can hopefully piggyback on that discussion). Cheers, Mark
