Venkatesh is right in that the only "official" release in the ASF's eyes
is the source release. Any JARs you publish are supplementary and
technically not subject to the rules of Apache releases.
The area I'm still trying to fully grok is that the source-release you
publish must also create artifacts which are properly licensed[1]. Right
now, that means including numerous incompatible dependencies, and, thus,
does not meet the requirements of the ASL and the ASF.
Regarding David's last question: I would assume that the license applies
to both the source code and binary forms of the geo-related artifacts
that you are currently bundling in Rya. GPL is forcing that the source
code for those artifacts be available, but is not implying that the
license only applies to the code in source form.
"A" and 1/2 would be how I expected this to go forward (although, I'm
not sure how "removing GeoIndexing" evolved into "removing Indexing" --
are they so intertwined?). The area that currently makes me feel awkward
is how to interpret "optional dependencies". If every user of Rya would
just be building this support anyways, that's skirting a very gray area
in my current understanding of what is allowed.
- Josh
[1] http://www.apache.org/dev/licensing-howto.html#binary
Puja Valiyil 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<vseetha...@gmail.com> 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<dlo...@gmail.com> 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<vseetha...@gmail.com>
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<puja...@gmail.com> 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?
