Re: [cp-patches] Other class libraries
On Tue, 2008-07-01 at 11:42 +0100, Andrew Haley wrote:
> Hmm, I'm not sure that explanations should be punted to unfree
> documentation. If the logic is so obscure that it needs a
> reference, then it perhaps should be spelled out.
Here's the patch for Integer. I have also added a Mauve test.
- twisti
---
Index: ChangeLog
===
RCS file: /sources/classpath/classpath/ChangeLog,v
retrieving revision 1.9670
diff -u -3 -p -r1.9670 ChangeLog
--- ChangeLog 1 Jul 2008 10:43:47 - 1.9670
+++ ChangeLog 1 Jul 2008 10:55:09 -
@@ -1,3 +1,9 @@
+2008-07-01 Christian Thalinger <[EMAIL PROTECTED]>
+
+ * java/lang/Integer.java (signum): Implemented properly as
+ described in Hacker's Delight Section 2-7, plus Andrew Haley's
+ explanation.
+
2008-07-01 Andrew Haley <[EMAIL PROTECTED]>
* java/lang/Long.java: Comment change only.
Index: java/lang/Integer.java
===
RCS file: /sources/classpath/classpath/java/lang/Integer.java,v
retrieving revision 1.39
diff -u -3 -p -r1.39 Integer.java
--- java/lang/Integer.java 6 Jun 2008 00:23:50 - 1.39
+++ java/lang/Integer.java 1 Jul 2008 10:55:09 -
@@ -687,7 +687,14 @@ public final class Integer extends Numbe
*/
public static int signum(int x)
{
-return (x >> 31) - (-x >> 31);
+return (x >> 31) | (-x >>> 31);
+
+// The LHS propagates the sign bit through every bit in the word;
+// if X < 0, every bit is set to 1, else 0. if X > 0, the RHS
+// negates x and shifts the resulting 1 in the sign bit to the
+// LSB, leaving every other bit 0.
+
+// Hacker's Delight, Section 2-7
}
/**
Re: [cp-patches] Other class libraries
Christian Thalinger wrote:
> On Fri, 2008-06-27 at 10:21 +0100, Andrew John Hughes wrote:
>> I thought you already had :D
>
> No, but I did now.
> diff -u -3 -p -r1.26 Long.java
> --- java/lang/Long.java 18 Apr 2008 21:00:11 - 1.26
> +++ java/lang/Long.java 1 Jul 2008 08:11:42 -
> @@ -689,7 +689,8 @@ public final class Long extends Number i
> */
>public static int signum(long x)
>{
> -return (int)(x >> 63) - (int)(-x >> 63);
> +// Hacker's Delight, Section 2-7
> +return (int) ((x >> 63) | (-x >>> 63));
>}
Hmm, I'm not sure that explanations should be punted to unfree
documentation. If the logic is so obscure that it needs a
reference, then it perhaps should be spelled out.
I'm committing this patch.
Andrew.
2008-07-01 Andrew Haley <[EMAIL PROTECTED]>
* java/lang/Long.java: Comment change only.
Index: java/lang/Long.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/Long.java,v
retrieving revision 1.27
diff -u -r1.27 Long.java
--- java/lang/Long.java 1 Jul 2008 08:12:31 - 1.27
+++ java/lang/Long.java 1 Jul 2008 10:35:48 -
@@ -689,8 +689,14 @@
*/
public static int signum(long x)
{
-// Hacker's Delight, Section 2-7
return (int) ((x >> 63) | (-x >>> 63));
+
+// The LHS propagates the sign bit through every bit in the word;
+// if X < 0, every bit is set to 1, else 0. if X > 0, the RHS
+// negates x and shifts the resulting 1 in the sign bit to the
+// LSB, leaving every other bit 0.
+
+// Hacker's Delight, Section 2-7
}
/**
Re: Other class libraries
On Fri, 2008-06-27 at 10:21 +0100, Andrew John Hughes wrote:
> I thought you already had :D
No, but I did now.
- twisti
---
Index: ChangeLog
===
RCS file: /cvsroot/classpath/classpath/ChangeLog,v
retrieving revision 1.9667
diff -u -3 -p -r1.9667 ChangeLog
--- ChangeLog 30 Jun 2008 01:12:46 - 1.9667
+++ ChangeLog 1 Jul 2008 08:11:42 -
@@ -1,3 +1,8 @@
+2008-07-01 Christian Thalinger <[EMAIL PROTECTED]>
+
+ * java/lang/Long.java (signum): Implemented properly as described
+ in Hacker's Delight Section 2-7.
+
2008-06-30 Andrew John Hughes <[EMAIL PROTECTED]>
PR classpath/35237:
Index: java/lang/Long.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/Long.java,v
retrieving revision 1.26
diff -u -3 -p -r1.26 Long.java
--- java/lang/Long.java 18 Apr 2008 21:00:11 - 1.26
+++ java/lang/Long.java 1 Jul 2008 08:11:42 -
@@ -689,7 +689,8 @@ public final class Long extends Number i
*/
public static int signum(long x)
{
-return (int)(x >> 63) - (int)(-x >> 63);
+// Hacker's Delight, Section 2-7
+return (int) ((x >> 63) | (-x >>> 63));
}
/**
Re: Other class libraries
2008/6/27 Christian Thalinger <[EMAIL PROTECTED]>: > On Tue, 2008-06-24 at 18:45 +0200, Christian Thalinger wrote: >> I guess this email came from the Long.signum() discussion we had today > > Ehh... will someone actually fix this bug? Otherwise I'll do it in the > Hackers Delight/OpenJDK way. > > - twisti > > I thought you already had :D -- 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 Tue, 2008-06-24 at 18:45 +0200, Christian Thalinger wrote: > I guess this email came from the Long.signum() discussion we had today Ehh... will someone actually fix this bug? Otherwise I'll do it in the Hackers Delight/OpenJDK way. - twisti
Re: Other class libraries
Andrew John Hughes wrote: 2008/6/25 dalibor topic <[EMAIL PROTECTED]>: Well I suppose the question is more 'how much OpenJDK is needed to be substantially derived?' It's hard to draw a minimum requirement line, so I guess it'll be a case-by-case decision, when necessary. I think a the majority of regular cases are obvious, though. Is the TCK license available for general consumption yet? Sure, it's been available since August 2007: http://*openjdk*.java.net/legal/*openjdk*-*tck*-*license*.pdf I'm slightly less perturbed by aph telling me that you do actually get source code. The fact that a myth to the contrary could permeate to me just shows the problems with such NDA stuff... ;) You'll have to check out the GB meeting's notes for more specific details on the NDA stuff. To say I'm not happy it's there would be an euphemism, but as far as TCK NDA stuff goes, it has been clarified by Sun in the discussin with the GB and stripped down to a very specific form. cheers, dalibor topic
Re: Other class libraries
2008/6/25 dalibor topic <[EMAIL PROTECTED]>: > Andrew John Hughes wrote: >> >> 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? >> > > I'm not sure on which one: > > * whether combining a GPLd VM with OpenJDK class library would be > sufficiently derived > as far ar the OCTLA goes? > > Yes, please see the GB minutes > http://openjdk.java.net/groups/gb/2007-08-23.html#license-eligibility . > Well I suppose the question is more 'how much OpenJDK is needed to be substantially derived?' I suspect just having something like jaxws + cacao + classpath is not enough for example, while jaxws + hotspot + classpath would be. Is the TCK license available for general consumption yet? I'm slightly less perturbed by aph telling me that you do actually get source code. The fact that a myth to the contrary could permeate to me just shows the problems with such NDA stuff... ;) > * whether GPLv2 + Classpath exception and GPLv2 or later + Classpath > exception are incompatible? > > IANAL, but I'd say quite clearly no, they are compatible as you can pick v2 > regardless of what later later versions say in classpath's case. > This was mjw's interpretation, but I think, as pointed out here and in other threads, that it's more a policy-level issue (FSF/Sun) and I didn't comprehend that we need GPLv3+exception not GPLv3 for some reason. > * whether classpath or openjdk will be under GPLv3? > > It's always hard to predict the future, but I guess a lot of that will > depend on the ongoing work the FSF is doing to unify the exception language > around gcc, when it is ready for public review, and how it turns out - don't > understimate the scope of that work, it's been going on for a long time, as > readers of the autoconf lists know. It will also depend on what the actual > effects of the v3 version of the exceptions would be on v2 only users, or > VMs that have v2-only dependencies. Think VM-as-Linux-kernel-module > scenarios, or Kaffe. > Solaris should clearly just go GPLv3 and we should all switch to that, if Linux is going to stick with GPLv2 ;) > * whether FSF will accept GPLv2+Classpath exception code from openjdk into > classpath? > > Hard to say. I'm not quite sure what we'd gain from duplicating the same > code in several places though - if we want to turn classpath into an icedtea > like wrapper around bits and pieces from openjdk, we can do that without > copying and pasting openjdk code over into another repository (we've got > enough third party code in classpath as it is, imho). if there are bits from > openjdk that make sense to depend on as a 'source plug' for classpath, then > we could go the icepick route, for example, and wrap them up accordingly. > I wasn't thinking of duplicating or trashing code. More just of plugging the vast holes that I don't think there are sufficient people working on Classpath to fill any more e.g. jaxws as mentioned above. > * whether gcj will lose its own copy of classpath and be able to use an > installed one or an alternative class library? > > Hard to say. But it's basically the pragmatic reason why openjdk code hasn't > flown into classpath: it wouldn't look very good to have gplv2 only code in > a gplv3 gcc/gcj. That's a policy decision forced by the current architecture > of gcj - if the tight coupling between the class library and gcj was removed > (see JamVM, Cacao, etc.), that particular dilemma would not present itself > as such. This is actually something I'd be interested in looking at, if only I had the time. >> >> 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. > > I don't really see a pressing need to discuss classpath's licensing while > the FSF is working on an update of the license, which will hopefully be > available for (public) review soon. > Well this thread pretty much satisfies me. I think we just need to make these issues, that have been mentioned occasionally and vaguely,
Re: Other class libraries
Il giorno mar, 24/06/2008 alle 22.18 +0100, Andrew John Hughes ha scritto: Hi Andrew! > both the Classpath and OpenJDK codebases of late, as have Mark, Mario, > Christian and probably others I don't, when I change code in OpenJDK I do this blindly :) On the other hand, you have my word (legally speaking, I guess it's the only thing I can do that is valid, but ianal you know...), that I don't copy code back and forth, or take inspiration for fixing nasty bugs, the codebases are anyway completely different, except for some one liners, which, as twisti said, are not a problem anyway. > 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. FWIW I would not deny my ok in changing the "or later" in "/dev/null" if that can help. > 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. Some work is done in that respect, see our peer project. We are mixing stuff, we screw, we fix, we can do that in our respective codebases, and anytime we are ready we release the code as the GPL requires, so this is only a legal problem with the Free Software Foundation hosted repository, that we want to fix of course, but I don't feel like a terrible blocker. Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-53 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Geschäftsführer: Dr. James J. Hunt Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/
Re: Other class libraries
dalibor topic wrote: Andrew John Hughes wrote: Dalibor, could you give us something from Sun's side on this issue? I'm not sure on which one: * whether combining a GPLd VM with OpenJDK class library would be sufficiently derived as far ar the OCTLA goes? Yes, please see the GB minutes http://openjdk.java.net/groups/gb/2007-08-23.html#license-eligibility . And I should point out that that bit is the only thing I can give you from Sun's side. Anything below that is my personal opinion as a Classpath developer - I'm posting this so that people don't get confused between the multiple hats I'm wearing here, when I say 'we' below. We as in 'we, the classpath developers'. I was posting from my Kaffe.org address, but I'm not sure a lot of people would catch something that subtle. cheers, dalibor topic * whether GPLv2 + Classpath exception and GPLv2 or later + Classpath exception are incompatible? IANAL, but I'd say quite clearly no, they are compatible as you can pick v2 regardless of what later later versions say in classpath's case. * whether classpath or openjdk will be under GPLv3? It's always hard to predict the future, but I guess a lot of that will depend on the ongoing work the FSF is doing to unify the exception language around gcc, when it is ready for public review, and how it turns out - don't understimate the scope of that work, it's been going on for a long time, as readers of the autoconf lists know. It will also depend on what the actual effects of the v3 version of the exceptions would be on v2 only users, or VMs that have v2-only dependencies. Think VM-as-Linux-kernel-module scenarios, or Kaffe. * whether FSF will accept GPLv2+Classpath exception code from openjdk into classpath? Hard to say. I'm not quite sure what we'd gain from duplicating the same code in several places though - if we want to turn classpath into an icedtea like wrapper around bits and pieces from openjdk, we can do that without copying and pasting openjdk code over into another repository (we've got enough third party code in classpath as it is, imho). if there are bits from openjdk that make sense to depend on as a 'source plug' for classpath, then we could go the icepick route, for example, and wrap them up accordingly. * whether gcj will lose its own copy of classpath and be able to use an installed one or an alternative class library? Hard to say. But it's basically the pragmatic reason why openjdk code hasn't flown into classpath: it wouldn't look very good to have gplv2 only code in a gplv3 gcc/gcj. That's a policy decision forced by the current architecture of gcj - if the tight coupling between the class library and gcj was removed (see JamVM, Cacao, etc.), that particular dilemma would not present itself as such. 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. I don't really see a pressing need to discuss classpath's licensing while the FSF is working on an update of the license, which will hopefully be available for (public) review soon. cheers, dalibor topic
Re: Other class libraries
Hi Andrew, On Wed, 2008-06-25 at 11:32 +0100, Andrew Haley wrote: > > 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. > > Obviously not, no. However, there is an enormous gulf between > studying and copying, and you are muddying the waters by failing to > distinguish between them. Sorry, it wasn't my intention to muddy any waters. What I meant is that while writing code for gnu classpath you are studying code from another implementation in a way which might lead to ending up with the exact same implementation is a no-no. Studying free software code in general of course is precisely why we write free software in the first place. studying code to then copy it almost literally and putting a different author contribution, copyright and distribution terms on it isn't though. > We run the risk of being in the situation where everyone is free to > study OpenJDK except Classpath developers. I don't think this is > justified by copyright law. You are taking an extreme interpretation > of the law which I do not believe is in the best interests of the GNU > project and GNU Classpath. It's always tempting to say "let's err on > the side of safety", but in my opinion this is too far. OK, where would you like the safety side to be? > Obviously, coming up with something identical and checking it in to > GNU Classpath would not be allowed. But it's much more reasonable to > say "don't do that, then" I believe that is what I am saying yes. > than to forbid free software programmers > from studying free software. Put that way, it's plainly absurd, but > that is what you are saying. I don't understand what you are saying here. Cheers, Mark
Re: Other class libraries
Robert Schuster wrote: 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). If that is the problem couldn't we get an official stance from Sun that prevents that? Something saying: "if some part of code from GNU Classpath looks similar to code in OpenJDK the FSF is not sued for copyright infringement". Dalibor? IANAL, but that wouldn't seem to be very useful in practice - it would be an attempt to have a very vague 'technical' solution for the lack of working 'social' ones. For Classpath, fortunately, we have a working social solution: Mark ;) In general, if you are not completely sure about whether you can contribute a specific piece of code to GNU Classpath, please ask Mark about it. He gets to set the bright lines of what's an acceptable contribution policy for Classpath, and he's done a remarkably good job at that as the project's maintainer, I think. 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? I am a bit confused about Sun's attitude towards (L)GPLv3. I hope http://www.sun.com/software/opensource/java/faq.jsp#g34 helps, for the time being that the FSF is working on the draft update of the exception language for V3. Once that's finished, I think it would make a lot of sense to evaluate what the effects would be for the existing scenarios of VMs using GNU Classpath, and the same for OpenJDK, and hopefully come to the same conclusions, due to a mutually fruitful discussion of the implications of the license during its (public) drafting/comment process. But the FSF has not started that comment process yet (and I'm sure the FSF has good reasons to take its time to do it right), so there is not much one can really say about it. If you are looking for a broader, independent evaluation of Sun's attitude to GPLv3, Palamida, the site tracking GPLv3 conversions, lists Sun as a significant adopter of GPLv3 in GPLv3's first six months, at http://gpl3.blogspot.com/2007/12/gplv3-year-in-review.html cheers, dalibor topic
Re: Other class libraries
Mark Wielaard wrote: > On Wed, 2008-06-25 at 11:32 +0100, Andrew Haley wrote: >>> 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. >> Obviously not, no. However, there is an enormous gulf between >> studying and copying, and you are muddying the waters by failing to >> distinguish between them. > > Sorry, it wasn't my intention to muddy any waters. What I meant is that > while writing code for gnu classpath you are studying code from another > implementation in a way which might lead to ending up with the exact > same implementation is a no-no. Studying free software code in general > of course is precisely why we write free software in the first place. > studying code to then copy it almost literally and putting a different > author contribution, copyright and distribution terms on it isn't > though. Thank you. That is perfectly reasonable, and much clearer than what you said before. Previously you said "don't study the implementation code from another implementation, you risk coming up with something identical". >> We run the risk of being in the situation where everyone is free to >> study OpenJDK except Classpath developers. I don't think this is >> justified by copyright law. You are taking an extreme interpretation >> of the law which I do not believe is in the best interests of the GNU >> project and GNU Classpath. It's always tempting to say "let's err on >> the side of safety", but in my opinion this is too far. > > OK, where would you like the safety side to be? That of reasonableness; study other free software, but don't copy it. The difference between research and plagiarism. >> Obviously, coming up with something identical and checking it in to >> GNU Classpath would not be allowed. But it's much more reasonable to >> say "don't do that, then" > > I believe that is what I am saying yes. OK. Andrew.
Re: Other class libraries
Mark Wielaard wrote: > 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. Obviously not, no. However, there is an enormous gulf between studying and copying, and you are muddying the waters by failing to distinguish between them. We run the risk of being in the situation where everyone is free to study OpenJDK except Classpath developers. I don't think this is justified by copyright law. You are taking an extreme interpretation of the law which I do not believe is in the best interests of the GNU project and GNU Classpath. It's always tempting to say "let's err on the side of safety", but in my opinion this is too far. Obviously, coming up with something identical and checking it in to GNU Classpath would not be allowed. But it's much more reasonable to say "don't do that, then" than to forbid free software programmers from studying free software. Put that way, it's plainly absurd, but that is what you are saying. Andrew.
Re: Other class libraries
Andrew John Hughes wrote: 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? I'm not sure on which one: * whether combining a GPLd VM with OpenJDK class library would be sufficiently derived as far ar the OCTLA goes? Yes, please see the GB minutes http://openjdk.java.net/groups/gb/2007-08-23.html#license-eligibility . * whether GPLv2 + Classpath exception and GPLv2 or later + Classpath exception are incompatible? IANAL, but I'd say quite clearly no, they are compatible as you can pick v2 regardless of what later later versions say in classpath's case. * whether classpath or openjdk will be under GPLv3? It's always hard to predict the future, but I guess a lot of that will depend on the ongoing work the FSF is doing to unify the exception language around gcc, when it is ready for public review, and how it turns out - don't understimate the scope of that work, it's been going on for a long time, as readers of the autoconf lists know. It will also depend on what the actual effects of the v3 version of the exceptions would be on v2 only users, or VMs that have v2-only dependencies. Think VM-as-Linux-kernel-module scenarios, or Kaffe. * whether FSF will accept GPLv2+Classpath exception code from openjdk into classpath? Hard to say. I'm not quite sure what we'd gain from duplicating the same code in several places though - if we want to turn classpath into an icedtea like wrapper around bits and pieces from openjdk, we can do that without copying and pasting openjdk code over into another repository (we've got enough third party code in classpath as it is, imho). if there are bits from openjdk that make sense to depend on as a 'source plug' for classpath, then we could go the icepick route, for example, and wrap them up accordingly. * whether gcj will lose its own copy of classpath and be able to use an installed one or an alternative class library? Hard to say. But it's basically the pragmatic reason why openjdk code hasn't flown into classpath: it wouldn't look very good to have gplv2 only code in a gplv3 gcc/gcj. That's a policy decision forced by the current architecture of gcj - if the tight coupling between the class library and gcj was removed (see JamVM, Cacao, etc.), that particular dilemma would not present itself as such. 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. I don't really see a pressing need to discuss classpath's licensing while the FSF is working on an update of the license, which will hopefully be available for (public) review soon. cheers, dalibor topic
Re: Other class libraries
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
Re: Other class libraries
Hi. Andrew John Hughes schrieb: > 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 am also in this camp. :) > 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). If that is the problem couldn't we get an official stance from Sun that prevents that? Something saying: "if some part of code from GNU Classpath looks similar to code in OpenJDK the FSF is not sued for copyright infringement". Dalibor? > 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? I am a bit confused about Sun's attitude towards (L)GPLv3. They have projects using only the GPLv2 (PhoneME), GPLv2 with an exception (OpenJDK) and soon they will also have the first project under the LGPLv3 namely OpenOffice.org. The missing 'or later' clause was the first thing that bothered me back then at FOSDEM'07. Too bad that this is such a hurdle these days ... :( Regards Robert signature.asc Description: OpenPGP digital signature
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
