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/Community] Fresh start
Date Tue, 06 Dec 2005 05:30:54 GMT
On Mon, Dec 05, 2005 at 02:33:06PM -0500, Davanum Srinivas wrote:
> 
> Again stating the obvios, *IF* there is a firewall, companies can
> choose to build their stuff to conform to the firewall and Yes, i'd
> like to make sure that firewall is *NOT* under GPL+Exception, but be
> under something neutral like MIT/X. Which is exactly what Stefano and
> Geir have been saying all along.
> 

Technically speaking, I'm not sure if the whole licensing logjam around
the VM interface is not essentially a red herring. If my mental model of
where we want to go with respect to OSGi is correct, in essence 

a) partition the class library along some borders into bundles
b) have a small enough core (library) to run the OSGi service to load
the bundles of the rest of the class library.

I'd hope that the VM interface is sufficiently defined by saying "the absolute
core classes necessary to run a minimal OSGi implementation", which would
translate to "OSGi/Minimum-1.1 execution requirements" being the fundamental 
VM interface, as that's what's needed to run a minimal OSGi implementation 
that takes care of all the rest wrt to handling bundles, as far as I can
guess. I hope Tim will correct me if I am wrong. The minimal 'profile'
is, afaict, a small subset of io, lang, lang.*, net, util and security
packages.

It would, I believe, be easiest to say, the VM interface are those
classes, rather than following the OSGi convention of enumerating the
methods along with the classes.

With that out of the way, the real challenge would be finding nice ways
to partition the remaining class libraries, and as you've noted before, one 
obvious area to go for are the xml classes. Tim posted a writeup of a
few more ideas, which looked pretty cool. 

On the implementation side, Harmony is already in great shape with the
contributions from IBM and Intel, though I do not know if they allow us
to run a minimal OSGi implementation yet. So another challenge would be
to fill in the gaps, if there are any. 

Finally, we'd need to have our own, ASLv2 licensed OSGi implementation.
I am not sure if there is one, but I hope Geir knows more. 

So, this would be my outline for the VM interface, as I have it in my
mind, 1000ft view, circumventing all licensing issues by using OSGi on
top of a minimal set of classes we assume as given.

How a VM implements those classes, under which license, is not our
problem. Harmony will have all those classes under ASLv2, other 
projects will have GNU Classpath's implementation under GPL+linking 
exception, different projects may chose to use the old Kaffe or gcj
code, or take the BSD-licensed code from Wonka as a basis for their
efforts. 

Does it sound feasible? I believe it is the easiest way to go forward
fast, rather than getting stuck on who owns what under which license and
how they may or may not interact. Harmony already has a sizeable chunk
of the minimal needed set of classes, and so has GNU Classpath, 
nevermind potential contributors using proprietary implementations.

cheers,
dalibor topic

P.S. Sorry for interrupting a community discussion with technical
content. ;)

> Yes, we can give our input in GPLv3 rounds and try to make things
> happen. But i can't bet the farm that a GPLv3+Exception would be
> palatable a downstream user of harmony. can i?
> 
> BTW, If i have to rip out gnu jaxp (to reduce footprint / remove hard
> coded references to gnu jaxp), it means i am modifying classpath,
> which means i have additional obligations under GPL.
> 
> -- dims
> 
> On 12/5/05, Mark Wielaard <mark@klomp.org> wrote:
> > Hi Davanum,
> >
> > On Mon, 2005-12-05 at 09:45 -0500, Davanum Srinivas wrote:
> > > Personally, i'd like to see progress on the "VM Interface" ASAP, that
> > > would go a long way to removing the mistrust. That would enable
> > > harmony VM to use unmodified classpath stuff as-is for development
> > > purposes and can act as a firewall till the licenses get sorted out.
> >
> > I am afraid this is ignoring part of the community trust issues and just
> > hoping technology will solve it all. But sure, the current VM interface
> > for GNU Classpath is described at:
> > http://www.gnu.org/software/classpath/docs/vmintegration.html
> > This is a living document and interface. We learn all the time about
> > needs of different runtimes and execution engines. And new stuff gets
> > added with each release of course. Just today a new section on the
> > recently added instrumentation hooks was added (already in CVS, website
> > will update in about 2 hours).
> >
> > > See snippet from Leo's email:
> > > "Mark told me someone tried something like that a year or two ago
> > > already. I forgot whom or what it was called, but I'd suggest trying
> > > to learn about it and if it failed, why."
> >
> > I believe that was after 2 beers :) And I don't know exactly which part
> > of the conversation this was about. I know I said how interesting it was
> > the Anthony Green came up with freevm.org and now Stefano Mazzocchi came
> > up with openvm.org. Both wanting to bridge the gap and bringing it onto
> > a higher level to be "above all parties". In the end freevm.org both
> > succeeded and failed. It failed because freevm.org is no longer, it
> > succeeded because we decided we didn't need anything "above" GNU
> > Classpath, gcj and Kaffe, but that we would just cooperate as is.
> >
> > > If i see some componentization such that i can drop in say
> > > xalan/xerces and not use classpath's built-in stuff (this would end
> > > users can mix and match stuff to make their distribution) that would
> > > be even better. But "VM Interface" is priority #1.
> >
> > gcj for example has a switch/system-property -Dendorsed.dirs which
> > allows for this.
> >
> > Cheers,
> >
> > Mark
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.2 (GNU/Linux)
> >
> > iD8DBQBDlIcnxVhZCJWr9QwRAlovAKCfX0HDfd7vc9C3/y0fV4x5R4zMOQCggY7A
> > ZMkkfSQmhMHuRJLZPUmvjZc=
> > =lSja
> > -----END PGP SIGNATURE-----
> >
> >
> >
> 
> 
> --
> Davanum Srinivas : http://wso2.com/blogs/

Mime
View raw message