I second Puja's confusion. I've been going off this article [1] from gnu.org:
""" The LGPL and Java ... The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java's “import” functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link. The application is then generally a derivative work of the library. So, the copyright holder for the library must authorize distribution of the work. The LGPL permits this distribution. """ --Aaron [1] https://www.gnu.org/licenses/lgpl-java.html On Fri, Oct 7, 2016 at 7:47 AM Puja Valiyil <[email protected]> wrote: > I don't think I follow. The source references an lgpl Api, and we are > publishing binary that references it in nexus. Are you sure it's not an > issue? > > Sent from my iPhone > > > On Oct 6, 2016, at 10:36 PM, Seetharam Venkatesh <[email protected]> > wrote: > > > > If it's a runtime dependency, you are fine. Apache only supports source > releases. We vote on source tar ball and not binary artifacts. > > > > Makes sense? > > > > Sent from my iPhone, > > Venkatesh > > > >> On Oct 6, 2016, at 12:40 PM, David Lotts <[email protected]> wrote: > >> > >> Yes, geotools is a runtime dependency. No geotools source code is > >> distributed. > >> > >> By that I mean: Geotools source code is not in our source code > repository. > >> Only references: imports in our *.java files and dependencies entries in > >> our pom.xml. Because of this maven will package geotools JARs > (binaries) > >> in our shaded/uber JAR and WAR files that we distribute. > >> > >> With option 1 or 2 as discussed, maven will exclude the geotools jars in > >> our JARs and WARs. Users of Rya can follow some instructions that we > >> provide to add "-P indexing" (or similar) to their Maven build command > >> create their own jar/war containing the optional Rya features and > geotools > >> binaries. > >> > >> Your "you should be okay." mean which of these???? > >> A. option 1 and option 2 will work around the issue and we should > proceed > >> before we release, > >> - OR - > >> B. We are already in compliance and this is not a blocker for release > as > >> long as we are not redistributing geotools source code. > >> > >> Hopeful for interpretation B, but expecting and happy with A. > >> > >> david. > >> > >> On Thu, Oct 6, 2016 at 1:22 PM, Seetharam Venkatesh < > [email protected]> > >> wrote: > >> > >>> Quick question - geotools is a runtime dependency? Are you shipping the > >>> source code? If not, you should be okay. > >>> > >>> Sent from my iPhone, > >>> Venkatesh > >>> > >>>> On Oct 6, 2016, at 7:52 AM, Puja Valiyil <[email protected]> wrote: > >>>> > >>>> Hi everyone, > >>>> Talking with Aaron, it seems like there were two paths forward for > >>>> refactoring in order to create a release. To refresh everyone's > memory, > >>>> the issue was that the geo-indexing extensions to Rya pull in > geotools, > >>>> which prohibits us from releasing Rya under an Apache 2 license. > There > >>> may > >>>> be some more particulars that I'm glossing over -- someone please > chime > >>> in > >>>> if they feel it is key to the discussion. > >>>> The two paths forward we had were: > >>>> 1. Make all of the indexing project and its downstream dependencies > >>>> optional and exclude them from a release > >>>> -- The indexing project includes several "optional" extensions to Rya > >>>> (advanced indexing strategies). Prior to Rya becoming an apache > project, > >>>> these indexing extensions were optional and there was a separate > profile > >>>> for including them. This option involves reverting back to that > mindset. > >>>> The main argument against this is that these indexing > >>> strategies/extensions > >>>> are not in fact optional but are "core" to Rya and can't be excluded. > >>>> > >>>> 2. Refactor Rya to pull geoindexing into a separate project and > exclude > >>>> that project from the release. > >>>> - We could refactor Rya to have geoindexing be its own project and > add a > >>>> profile to include that in the build. This would invovle moving the > >>> class > >>>> mvm.rya.indexing.GeoIndexer and packages mem.rya.indexing.accumulo.geo > >>> and > >>>> mvm.rya.indexing.mongodb.geo to a separate project and then > >>> removing/moving > >>>> references to geoindexing anywhere else. Another option is to > refactor > >>> the > >>>> GeoIndexer interface to remove the geotools dependency. > >>>> > >>>> I think #1 is a good immediate path for a release and that #2 is a > good > >>>> longer term path forward. Since it's probably in our best interests > as a > >>>> community to get an apache release sooner rather than later, I'd > rather > >>> us > >>>> go with #1 since it would quicker. I also think that most users of > Rya > >>>> would be ok with excluding the indexing project since it is not core > >>>> functionality for Rya. While #2 is a better long term plan, it > involves > >>>> some pretty extensive refactoring that would be difficult to do well > in a > >>>> timely manner. > >>>> > >>>> Any thoughts? > >>> >
