Other class libraries

[gnu_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.

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

[Christian Thalinger]

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

[Roman Kennke-2]

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/

[gnu_andrew]

On 24/06/2008, Christian Thalinger <twisti@...> 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

[gnu_andrew]

On 24/06/2008, Roman Kennke <roman@...> 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

[Roman Kennke-2]

>  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/

[gnu_andrew]

On 24/06/2008, Roman Kennke <roman@...> 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

[Robert Schuster]

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

[Mark Wielaard]

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

[Dalibor Topic]

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

[Andrew Haley]

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.

[Mark Wielaard]

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

[Andrew Haley]

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.

[Dalibor Topic]

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

[Dalibor Topic]

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
>

[Mario Torre-3]

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: [phone]
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/