[gdal-dev] New JPEG 2000 Driver

[jratike80]

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 it comes
to principles, but I would rather see GDAL as a project to be neutral "We
prefer BSD, but we respect also libraries with other licensing models. To
respect does not mean that we want all of them incorporated". 

If a project selects BSD it is clear from the beginning that anything that
is allowed by the license may happen. 

I don't agree that GDAL supports proprietary drivers more than copy-left
drivers. We have told you that it is quite OK to have a new JP2Grok even we
would prefer to see improvements in JP2OpenJPEG because it is BSD like the
rest of GDAL. And that we are a bit sad because of AGPL and there are users
who can't use Grok, but nothing harder than that. That we prefer BSD is
consistent to our message to the MapInfo team that suggested to add a new
proprietary driver https://github.com/OSGeo/gdal/pull/3447.

To suggest that we should remove all existing proprietary drivers if we are
not very eager in accepting one more JPEG2000 driver is obviously meant to
be a provocation but I do not know how to react.

GDAL project does not easily drop existing good drivers which have an
established user base. We may drop JP2KAK some day because it is not really
actively maintained but it is quite a good driver even it does not utilize
some improvements introduced in latest latest KDU SDK versions. So perhaps
it is kept as long as it is possible to compile. If Kakadu was open source
we would be in the situation that you described "If driver A is faster and
more feature rich than driver B, they will want driver A." Unfortunaly very
few users can afford to select driver A in this case.

We do remove old drivers https://github.com/OSGeo/gdal/pull/3505 and it
means goodbye to Jasper.

-Jukka Rahkonen-


boxerab wrote
> 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 clearly have a vested interest in
> permissive open source.
> GDAL is a non-profit, open source project. Also, most GDAL users are not
> GDAL developers,
> and many of these users have no strong feelings about licensing as long as
> they can get their work done.
> If driver A is faster and more feature rich than driver B, they will want
> driver A.
> 
> Is it legitimate to take OpenJPEG, close the source, improve the code and
> add features,
> and then sell the result without contributing these improvements back to
> OpenJPEG?
> Indeed, it is legitimate, permitted, and encouraged by the BSD license.
> And
> many have
> done so. Likewise with relicensing under a different FLOSS license, as
> long
> as BSD terms are
> respected.
> 
> If GDAL supports proprietary drivers but rejects open source drivers
> because they are copy-left,
> this doesn't seem consistent to me. Perhaps all proprietary drivers should
> be removed, if
> that is the desire of the project? Keeping JP2KAK and rejecting JP2Grok
> seems a bit hard
> to fathom to me.
> 
> As for proliferation of driver code, the Jasper driver seems to be on the
> way out, as Jasper
> code is dangerously insecure and filled with bugs. So, JP2Grok would
> simply
> take its place.
> 
> My two cents.
> 
> Aaron
> 
> 
> On Sun, Feb 28, 2021 at 8:15 PM Brad Hards <

> bradh@

> > wrote:
> 
>> 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 think this could
>> reasonably be decided either way.
>>
>> Brad
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> 

> gdal-dev at .osgeo

>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> 
> _______________________________________________
> gdal-dev mailing list

> gdal-dev at .osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html