So releasing bundles under Apache license, AL compatible licenses or even binary compatible licenses is permitted at the ASF as shown at [1] This obviously does not cover JNA library for example which is LGPL. So in all cases, if we want to provide users with a bundle, we'd have to do so outside the ASF.
However, there is a workaround, which is to release a file containing the bnd instructions and use the pax wrap url handler [2] to point to this file and wrap the bundle on the fly. The main problem I have with the spring source bundle repository is that it's not synced to central, and we should avoid as much as possible to use other repositories. So this also means that we would be strongly dependant on SpringSource to continue supporting their bundle repo. I think this discussion is broader than just servicemix as more and more Apache projects are switching to OSGi and we need to work together with the other projects I think. So I think we have several questions: 1) how do we want to handle optional depedencies not AL compatible 2) do we want to reuse spring source repo 3) do we want a single location for all our bundles 4) do we want that inside the ASF But I think everything depends on the following question: do we want to provide bundles for our projects, or do we want to provide bundles for our users. The scope of the work will definitely drive answers to #1 which then impacts #4. [1] http://www.apache.org/legal/resolved.html#osgi-category-b [2] http://wiki.ops4j.org/display/paxurl/Wrap+Protocol On Fri, Sep 11, 2009 at 10:19, Gert Vanthienen <[email protected]> wrote: > L.S., > > Last night, I was looking for a bundle for Sun's JNA and I created a > pom.xml for generating it in our own bundles project. However, we can > not release this at Apache because JNA is LGPL-licensed. > > This raises the question if our Apache project is the ideal place for > creating and releasing those bundles. Most of the things we use have > an Apache-compatible license, but for the other stuff we would need to > look for another location. Wouldn't it be a better idea to move all > of the bundles to another location instead of having things at two > distinct locations? Any suggestions on where to move things? > > On the other hand, the SpringSource folks already have a large set of > bundles that are publicly available at > http://www.springsource.com/repository/app/. Do we want to > build/maintain our own bundles next to those available or should we > just use what's available out there? > > Thoughts? > > Gert Vanthienen > ------------------------ > Open Source SOA: http://fusesource.com > Blog: http://gertvanthienen.blogspot.com/ > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
