2017-01-23 13:54 GMT+01:00 Timothy Ward <[email protected]>: > I agree. Additionally we should try to get the OSGi alliance to regularly > build and publish snapshots on their own. > Not having the APIs in apache source would be the best solution. > > Note that this would prevent implementing the API for any OSGi Util > specifications, which include implementation types in the API (e.g. > Promises, Tracker) nor will it work for Felix, (the OSGi API contains > Filter and FrameworkUtil). >
I don't see why not having the API code in the svn tree prohibits the use of implementation types. I think that Christian was saying that if the APIs are consumed from a jar from a maven repository, it's very clear that the code come from the OSGi Alliance, so there's no IP ambiguity anymore. Also, I don't think there's any problem with actually publishing jars which embed the API, even the source code, as it's ASL, the problem is really the IP. > > This is also not what other Apache projects do. Geronimo, for example, > provides Java EE spec APIs. > > Regards, > > Tim > > Sent from my iPhone > > On 23 Jan 2017, at 01:28, Christian Schneider <[email protected]< > mailto:[email protected]>> wrote: > > I agree. Additionally we should try to get the OSGi alliance to regularly > build and publish snapshots on their own. > Not having the APIs in apache source would be the best solution. > > Christian > > On 23.01.2017 10:19, Guillaume Nodet wrote: > As discussed on legal@ (see [1]), and in order to be able to track code IP > correctly, I propose that all commits that includes API code from the OSGi > Alliance are done in separate commit and include a reference to the public > source where the code comes from. > > Thoughts ? > Guillaume > > [1] > http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201701.mbox/% > 3ccaa66tppc9lp71ak4uoxsnz8qzg+bnutyntzspbt+z48dynu...@mail.gmail.com%3e > > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > -- ------------------------ Guillaume Nodet
