harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dalibor Topic <robi...@kaffe.org>
Subject Re: [Licensing] Fresh start
Date Mon, 05 Dec 2005 04:01:07 GMT
On Sun, Dec 04, 2005 at 11:15:42AM -0800, Leo Simons wrote:
> On Sun, Dec 04, 2005 at 01:50:35PM -0500, Davanum Srinivas wrote:
> > Just remember, it has to go both ways :)
> 
> Baby steps :-)

All the way ;)

> 
> > Apache code in classpath and
> > classpath code in Harmony. We can't just push things so that it is a
> > one way street. So far what i have not heard is how/what can be done
> > to enable Classpath to use the tons of jakarta code and other Apache
> > code.
> 
> there's been several options discussed, actually. They just look very
> "expensive" or not without problems. Eg
> 
> -> change the Apache License to be GPL-compatible
> -> write a GPL-compatible interface into which you can plug Apache
>    licensed code
> -> hope that GPLv3 is GPL-compatible
> -> change the Classpath license to be AL-compatible (not feasible since
>    it makes classpath incompatible with other parties)
>

Oh, for cross-mixing in general, there is no practical legal problem in mixing the 
code under both ASLv2 and GPL2+linking exception, as both licenses permit linking 
without imposing any restrictions on the license of the other part. There are 
political issues at each organisation, but those are fixable, to a large degree.

In essence, the major baby step for Harmony is ASF allowing Harmony to use GNU 
Classpath's code. That seems to be the easiest goal to achieve, so we should get
that going.

For code to flow into GNU Classpath, the FSF usually wants copyright assignments,
to make sure that they can actually relicense it, when they need to change the
exception text to accomodate the needs of the ASF, for example, without having to
go through a huge dance of contacting everyone and convincing them that working 
with the ASF is a good thing(TM).

On the other hand, one can license one's own contributed code in any way to 
anyone else, so, as the ASF only wants a license to deal in the code, it works 
out pretty trivially to satify the requirements for both. 

The ASF and FSF processes are plug-compatible. ;) 

> > How about a plan of attack?
> 
> Is always good!
> 

My plan is to go for gold regarding the GPL+linking exception. It's a pretty 
clean cut issue, given ASF's shipping of gcc built binaries in the past years,
and the obvious desire to continue doing so. In particular since some founding 
ASF memebers have built businesses around the Apache httpd project, it would be
pretty odd to see them stand by letting the ASF decide that shipping gcc-built
httpd is not OK.

Armchair lawyering is armchair lawyering, but pragmatic business is 
pragmatic business. ;)

> > Anthony, Dalibor and Mark can try hard to
> > lobby FSF's GPL v3 effort to be as compatible as possible with ASL
> > 2.0?
> 
> Actually, anyone and everyone can and should do that, since the FSF is going
> to be following a very open process to GPL v3. We should all chime in!

Definitely! Go and make ASF's needs heard, the process is going to be pretty
huge, and noone can represent ASF's interests better than its members.

I know that my participation in the Apache Software License v2.0 process was 
fun, and I ended up getting whacked for cross-posting "Dudes, go talk with the
Apaches about ther new license NOW!" mails all over the various GNU Classpath 
and Kaffe related lists. Too bad that Apache compatibility test code license 
never saw any TCK being released under it, afair.

As for GPLv3, addressing the patent clauses in ASL2 and friends is definitely 
something that's on the agenda, afaik, so I am sure that issue will be worked
out. From where I stand, it does not seem to be too hard to add a "special 
exception" clause to the GPLv3, for example, to allow linking to such code. 

> > If we get thru in one piece till GPL v3 gets out, then
> > we can investigate if Classpath can switch to use Xerces/Xalan etc
> > from Apache.
> 
> s/switch/provide an option/.
> 

I believe some people were already shipping GNU Classpath based runtimes in 
that configuration, as some J2EE servers had specific X/X needs that GNU
JAXP didn't/doesn't have.

In any case it shouldn't be hard to switch the JAXP implementation, and I'd
expect Harmony to use ASF's own.

> > In the parallel, let's see how LGPL bridge policy works
> > in the real world usage (once Apache-Legal formulates it and announces
> > it). At that point we can eval options on both sides and see how best
> > to go forward.
> 
> yup. With you there.
> 

same here. we need a lgpl policy for the permanent issue of hibernate 
anyway, then we can piggyback off the decision being made and see what
and how we do it.

> > Stating the obvious, since none of the legal stuff is driven by anyone
> > on this list,
> 
> Actually, I think there's several people here driving it. I'm trying :-)
> 

Me too ;)

> > we should move forward with technical solutions...stuff
> > that geir has always pushed for.
> > 
> > Is there a better plan of attack?
> 
> I think that these things can and should happen in parallel. Technical
> stuff is good. By all means. We shouldn't be waiting with technical stuff
> because of "legal hope".

Definitely. Waiting is boring ;) The ASF licensed contributions need to be
consolidated, and we need to start building some test snaps, as Geir 
proposed, for gump and people to play with.

cheers,
dalibor topic

> 
> - LSD
> 

Mime
View raw message