Re: Other class libraries
On 24/06/2008, Roman Kennke <[EMAIL PROTECTED]> wrote: > > As we discussed a little on IRC earlier today, it's actually quite a > > ridiculous situation that GNU Classpath and OpenJDK are just about > > under the same license, but because of that 'or later' clause, they > > are incompatible. > > > 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. 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, it's the project-level import I was referred to here. If that were possible, it would automatically remove the possibility of code-copying for the most part. > /Roman > > -- > http://kennke.org/blog/ > > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Other class libraries
> As we discussed a little on IRC earlier today, it's actually quite a > ridiculous situation that GNU Classpath and OpenJDK are just about > under the same license, but because of that 'or later' clause, they > are incompatible. 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. 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. /Roman -- http://kennke.org/blog/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Other class libraries
On 24/06/2008, Roman Kennke <[EMAIL PROTECTED]> wrote: > Hi Andrew, > > > > Since OpenJDK has been released, I've noticed that a tendency has > > arisen to not treat > > that codebase with the same 'don't look if working on the same code' > > approach we had > > when it was proprietary. When working on GNU Classpath, we still need > > to be careful > > about cross-pollination between codebases, even though the OpenJDK > > class libraries > > are under (nearly) the same license. > > > > This also applies for other class libraries, namely Harmony's. > > > So where is the boundary? I already spent significant time studying > OpenJDK's code, in the graphics area (as part of my Challenge project) > as well as several other areas. Am I disqualified now as GNU Classpath > contributor? (Not that I contributed much in the last weeks, but > still...) You are 'walking the line' then too, with the CPStringBuilder > effort (I think this has been 'inspired' by OpenJDK iirc), and as part > of your Challenge project you are also studying a lot of OpenJDK code I > suppose. > > Do we have any strong criteria by which we can measure which > contribution can go in and which can't? > > /Roman > > > -- > http://kennke.org/blog/ > > Hi Roman, I find myself asking the same questions, and this is why I raised the questions. I don't have all the answers either, and I'm sorry if the original mail came across like I was dictating a particular position. That wasn't the intention. FWIW, yes, both you and I have worked on both the Classpath and OpenJDK codebases of late, as have Mark, Mario, Christian and probably others - we're all in this together (although, just to clarify, CPStringBuilder was based on an idea in GCJ and the implementation (and its bugs) are original). I think it's an issue we need to look into, and we need to do so before it's too late. In reality, I don't think Sun is going to come chasing GNU Classpath contributors, if just because the majority are also now OpenJDK contributors (which is half the problem) and it would eradicate all the good work they've done with the Free Java community over the past couple of years. Unfortunately, such suppositions aren't worth much in legal terms (and let's get the obvious IANAL disclaimer in here before I say any more). As we discussed a little on IRC earlier today, it's actually quite a ridiculous situation that GNU Classpath and OpenJDK are just about under the same license, but because of that 'or later' clause, they are incompatible. Ideally, we would have imported a lot of OpenJDK code into GNU Classpath when it was released. Filling the holes in GCJ, for example, with Sun code would probably be a faster method of getting a TCK-passing implementation on non-x86/x86_64 platforms, assuming that such a combination counts as 'sufficiently derived'. In an ideal world, both would be under GPLv3 and we'd share code between the two as intended. On the other side, I've not seen as much code as I'd expect (like the AWT peers) move into OpenJDK either, but I think this is less legal and more process related. Dalibor, could you give us something from Sun's side on this issue? Mark, perhaps you can fill in some of the details I've probably left out, as you're much more aware of these matters than myself? I hope we can come to a decent resolution on this, but I think the issue does need to be discussed openly and as soon as possible. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Other class libraries
On 24/06/2008, Christian Thalinger <[EMAIL PROTECTED]> wrote: > On Tue, 2008-06-24 at 15:20 +0100, Andrew John Hughes wrote: > > Since OpenJDK has been released, I've noticed that a tendency has > > arisen to not treat > > that codebase with the same 'don't look if working on the same code' > > approach we had > > when it was proprietary. When working on GNU Classpath, we still need > > to be careful > > about cross-pollination between codebases, even though the OpenJDK > > class libraries > > are under (nearly) the same license. > > > > This also applies for other class libraries, namely Harmony's. > > > I guess this email came from the Long.signum() discussion we had today > on IRC. Today I noticed that we are failing this one, so I tried with > CACAO/OpenJDK and it worked. Then I had a look at GNU Classpath's code > and it was simply a one-liner. Wondering why it failed, I looked at the > OpenJDK code and asked Mark if we could not simply use that correct > implementation (from OpenJDK). > That's correct, but it's something that's troubled me for a while and with previous patches. > My point is, people are still working like in the "good old" proprietary > way, at least I do. But also back then one-liners haven't been a > problem. > It wasn't that specific case, but it reminded me of the issue in general. And, of course, that particular one-liner is taken from a book anyway! > - twisti > > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Other class libraries
Hi Andrew, > Since OpenJDK has been released, I've noticed that a tendency has > arisen to not treat > that codebase with the same 'don't look if working on the same code' > approach we had > when it was proprietary. When working on GNU Classpath, we still need > to be careful > about cross-pollination between codebases, even though the OpenJDK > class libraries > are under (nearly) the same license. > > This also applies for other class libraries, namely Harmony's. So where is the boundary? I already spent significant time studying OpenJDK's code, in the graphics area (as part of my Challenge project) as well as several other areas. Am I disqualified now as GNU Classpath contributor? (Not that I contributed much in the last weeks, but still...) You are 'walking the line' then too, with the CPStringBuilder effort (I think this has been 'inspired' by OpenJDK iirc), and as part of your Challenge project you are also studying a lot of OpenJDK code I suppose. Do we have any strong criteria by which we can measure which contribution can go in and which can't? /Roman -- http://kennke.org/blog/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Other class libraries
On Tue, 2008-06-24 at 15:20 +0100, Andrew John Hughes wrote: > Since OpenJDK has been released, I've noticed that a tendency has > arisen to not treat > that codebase with the same 'don't look if working on the same code' > approach we had > when it was proprietary. When working on GNU Classpath, we still need > to be careful > about cross-pollination between codebases, even though the OpenJDK > class libraries > are under (nearly) the same license. > > This also applies for other class libraries, namely Harmony's. I guess this email came from the Long.signum() discussion we had today on IRC. Today I noticed that we are failing this one, so I tried with CACAO/OpenJDK and it worked. Then I had a look at GNU Classpath's code and it was simply a one-liner. Wondering why it failed, I looked at the OpenJDK code and asked Mark if we could not simply use that correct implementation (from OpenJDK). My point is, people are still working like in the "good old" proprietary way, at least I do. But also back then one-liners haven't been a problem. - twisti
Other class libraries
Since OpenJDK has been released, I've noticed that a tendency has arisen to not treat that codebase with the same 'don't look if working on the same code' approach we had when it was proprietary. When working on GNU Classpath, we still need to be careful about cross-pollination between codebases, even though the OpenJDK class libraries are under (nearly) the same license. This also applies for other class libraries, namely Harmony's. Thanks, -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Problem with TLS client authentication (bad_certificate)
On Tue, 2008-06-24 at 10:16 +0200, Christian Thalinger wrote: > [Da du ja anscheinend aus Oesterreich bist, antworte ich dir mal > off-list auf Deutsch.] Damn! Sorry list. I wanted to reply in private. - twisti
Re: Problem with TLS client authentication (bad_certificate)
[Da du ja anscheinend aus Oesterreich bist, antworte ich dir mal off-list auf Deutsch.] On Tue, 2008-06-17 at 09:56 +0200, Gerhard Fliess wrote: > Hi, > > I am working an a project that needs TLS with client authentication on > an embedded system (ARM-linux) with keys stored in pkcs12. I have > successfully ported the jamvm and classpath on this plattform. Now > I am working on the TLS part on a virtual machine not directly on the > embedded bord. In this development-environment I am using this setup: > > Client: > > - Debian Linux 2.6.18-6-686 > - jamvm 1.5.1 > - classpath 0.97.1 > - bouncycastle provider bcprov15-139 (pkcs12 support) > > Server: > > - Debian Linux > - Sun jdk 1.6 > > > The problem is, a BAD_CERTIFICATE error occurs during the handshake. > > The client answers server-hello, with write_certificate, > write-client-key-exchange and write_certificate_verify. After that the > client recieves the bad_certificate alert from the server caused by > "certificate verify message signature error". > > The private key of the client is sored in a pkcs12 file loaded via > bcprovider, the trusted key of the server is stored in a gkr. Hallo! Ich weiss zwar nicht ob ich dir mit dem GNU Classpath Problem helfen kann, aber ich wollte einfach mal fragen, was das fuer ein Projekt ist? Und vorallem, wie gross dieses Embedded System ist (CPU, Memory, Flash)? Man koennte das ganze naemlich mit CACAO und OpenJDK auf ARM auch machen... - twisti
