Even Rouault writes:
>> But, I'm worried about something different. As a packager, I'd like to
>> know that unless I take the affirmative step of passing --enable-foo,
>> for any GPLish or proprietary foo, I won't end up with a gdal build
>> linked with foo just because it happened to be presen
Folks,
When Andrew first mentioned RFC 34 I skimmed it and was a bit surprised it
existed though perhaps it seemed a wee bit familiar. Now that Even
mentions it was not ever implemented I see that *I* proposed it and
presumably did not actually follow up on implementing it or getting it
adopted.
Hi,
https://gdal.org/development/rfc/rfc34_license_policy.html
As indicated in the top of the RFC, its status is "development" (draft),
which here means stalled/non-adopted given that it was proposed long
time ago. So there's no runtime mechanism to control license compatibility.
But, I'm
Andrew C Aitchison writes:
> On Mon, 1 Mar 2021, Greg Troxel wrote:
>
>> I also was unclear on the optional driver situation. Certainly if
>> drivers can link with proprietary libraries, there is absolutely no
>> reason to object to a driver because it links so an AGPL3 library.
>>
>> I believe
On Mon, 1 Mar 2021, Greg Troxel wrote:
I also was unclear on the optional driver situation. Certainly if
drivers can link with proprietary libraries, there is absolutely no
reason to object to a driver because it links so an AGPL3 library.
I believe that drivers with non-MIT licenses shouldn't
Having ranted earlier about the use of AGPL3 to sell proprietary
licenses, I'd like to say that I'm glad to hear the new library is
"righteous AGPL3" instead of "subversive AGPL3".
I also was unclear on the optional driver situation. Certainly if
drivers can link with proprietary libraries, ther
Hi Jukka,
Thanks, makes a lot of sense. My comments about removing proprietary drivers
weren't meant as a provocation, I'm sorry you received it that way. Just a
thought experiment
to explore possible inconsistency of keeping proprietary drivers while
pushing back
on GPL drivers. But your explana
Hi,
In my opinion it is GDAL's mandate to favor projects that use the same type
of license than GDAL itself. Both proprietary and more copy-left licenses
makes it a bit harder to handle the whole system. Individual developers may
have their own opinions about what licensing model is the best when
Hi Brad,
Definitely makes for an interesting discussion.
A few questions to ponder:
Is it GDAL's mandate to encourage projects with permissive licenses and to,
shall we say,
discourage those with copy-left licenses ? This is how Google and Apple
operate,
but they are for-profit corporations who
I think this will be an interesting issue for the GDAL PMC.
On one hand, AGPL is no worse than some proprietary (optional) dependency
libraries. On the other hand, supporting it in GDAL is
implicitly endorsing the fork, and adds to the proliferation of driver code in
the GDAL/OGR repository. I t
Hi Nyall,
Well, my point is that it's not terribly difficult to make a contribution,
but it does require some hard work,
which few are willing to expend. But, this isn't specific to JPEG 2000 -
it's the case for any FLOSS
project. The JPEG 2000 standard is difficult, but it can be grokked, if I
ma
Hi Aaron!
I'm honestly a little confused reading your reply, as it seems to
contradict itself:
> As for the scarcity of open source expertise along with JPEG 2000, I also
> agree. But the bar to entry
> isn't as high as it used to be - we have high-quality open source
> implementations, so anyo
Hi Even,
Thanks. You have certainly made remarkable improvements to OpenJPEG,
especially
considering the amount of time you were able to spend on the code.
Regarding benchmarking, I totally agree, there are many many different
workflows and configurations.
I chose lossless compression/decompressio
On Sat, Feb 27, 2021 at 1:18 PM Kurt Schwehr wrote:
> I can't touch grok... GNU Affero General Public License
>
No problem, this driver will be optional. The current commercial and open
source drivers are quite good.
>
> On Sat, Feb 27, 2021, 9:50 AM Aaron Boxer wrote:
>
>> Hello Everyone,
>
Greg Troxel-2 wrote
> Even Rouault <
> even.rouault@
> > writes:
>
>> Can you transparently tell us why Grok is AGPL licensed ? Do you sell
>> commercial licenses for people who couldn't comply with the AGPL license
>> ?
>
> Certainly a good question. I have no idea in this case and my comme
Folks,
The GDAL driver code would need to be licensed the same as the rest of GDAL
(which I see from the PR is the case).
It is fine for the Grok library to be under the AGPL as long as it is an
optional dependency of GDAL. Folks who are prepared to comply with it's
license can enable it at buil
Even Rouault writes:
> Can you transparently tell us why Grok is AGPL licensed ? Do you sell
> commercial licenses for people who couldn't comply with the AGPL license ?
Certainly a good question. I have no idea in this case and my comments
should not be taken to imply anything about this pa
Aaron,
benchnmarking exercices are difficult in general, and even more with JPEG2000
and its trillions of possible variants. You would need to specify library
versions, how the library was exercised exactly (gdal_translate or the
XXX_decompress utilities of the library), use of multithreading,
I can't touch grok... GNU Affero General Public License
On Sat, Feb 27, 2021, 9:50 AM Aaron Boxer wrote:
> Hello Everyone,
>
> For those who aren’t aware, there is a pending PR for a new open source
> JPEG 2000 driver, based on the Grok JPEG 2000 library
>
> https://github.com/OSGeo/gdal/pull/3
Hello Everyone,
For those who aren’t aware, there is a pending PR for a new open source
JPEG 2000 driver, based on the Grok JPEG 2000 library
https://github.com/OSGeo/gdal/pull/3449
Notable Library Features:
1. support for reading TLM and PLT markers, for fast random access into
large tiled or
20 matches
Mail list logo
