Hello Everyone,
Following the exchanges we had with Calvin on GitHub, I added a DISCLAIMER-WIP
file to the pull request. As the latest release is pretty far from what we have
on the main branch, I'd like to merge this PR and perform an intermediary
release (v0.7.1). Is it possible to publish th
Hello Everyone,
I hope you are doing well. I guess we all have been very busy lately ;-) So let
me resume this thread.
Most of the issues reported in this thread have been addressed [1] or added to
the release checklist [2]. The main one being the inclusion of a DISCLAIMER-WIP
file to the rele
Hello Bertil
Le 22/11/2022 à 21:47, Bertil Chapuis a écrit :
The terms of the EPSG license are restrictive [1]: The data may not be
distributed for profit by any third party. I’m quite amazed to
discover that most geospatial solutions out there are probably
violating this license.
Yes. In t
These clarifications are really interesting. I wasn’t aware of this issue and
assumed that the license of proj4j (MIT) was compatible with Apache. The terms
of the EPSG license are restrictive [1]: The data may not be distributed for
profit by any third party. I’m quite amazed to discover that m
Hello Florian
Le 22/11/2022 à 18:44, Florian Micklich a écrit :
I didn't know that proj4j itself uses EPSG data.
The CSV files in [1] are derived from EPSG tables. The file structures
are different than EPSG database schema, but the data that they contain
are EPSG data. The same information
Hi all,
Hi Martin :)
I didn't know that proj4j itself uses EPSG data. Until now I thought it would
be a good alternative lib besides EPSG approach.
So what would be your advise with proj4(j) and how to handle that kind of
implementation in an Apache project?
Officially it is running on MIT lic
Great job getting this started. Comments are inlined.
Websites referenced:
[1] https://creadur.apache.org/rat/
[2] https://incubator.apache.org/policy/incubation.html#disclaimers
On Sun, Nov 20, 2022 at 4:24 PM Julian Hyde wrote:
> Thanks for creating a process. Now we have a process, we can i
I should have mentioned that much of this “good advice” - from me and other
mentors - can be deferred. I would suggest logging cases and do only those
necessary for the first release. Subsequent releases can be cleaner. As the
mantra goes, “Release early, release often”.
Incubating releases ca
Hi,
Julian Hyde wrote:
> ...Part of the reason that binaries are not part of the release is that
> it's only practical to vote on source code. What you have done here,
> generating and signing binaries from the source code, is about the
> best we can do...
I think Reproducible Builds also help m
Hello Bertil
One thing to keep in mind (maybe not to be resolved in this release, but
before graduation). Proj4J (and its parent PROJ project) includes EPSG
data, so the use of Proj4J dependency implies accepting EPSG terms of
use [1]. PROJ claims to be under MIT license, but in my understandi
Hi,
We are missing disclaimers[1].
We should not include binary code in the source code, I think you
forgot to exclude it(*.jar) when you packaged the source code.
(btw,maven-wrapper is donated to ASF with a version upgraded, we
better upgrade to the new version 3.1.x which was released under the
Thanks for creating a process. Now we have a process, we can iterate.
A few thoughts.
1. On terminology. The release itself consists of the source code,
literally the src.tar.gz file. People incorrectly use the term 'binary
release' but the binaries are just artifacts generated from the
release.
Hello Everyone,
The following draft release has been generated with github actions:
https://github.com/apache/incubator-baremaps/releases/tag/untagged-4d07860016b500637021
We have two distributions (source and binary) created with the maven assembly
plugin. The checksums and signatures are gener
13 matches
Mail list logo
