Google
  Web www.spinics.net

Re: Other class libraries

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


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



[Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux