Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Tobias Rapp]

On 05.04.2016 12:12, Kieran Kunhya wrote:


Yes. Well, AGPL extends the definition of distribution to include use over
the network.



Would we need then to send a copy of the AGPL to every viewer of our
channels?
How do we even know who they are when it's a terrestrial (OTA) broadcast?
Should we just send one to every citizen on earth just in case?



+1

Also its not clear to me how the term "use over the network" would apply 
in this case. What about:


a) FFmpeg+Grok application encoding data live and streaming it to the 
user's computer


b) FFmpeg+Grok application encoding data onto the local disk, some other 
application (web server) streaming it to the user's computer


c) FFmpeg+Grok application encoding data onto some storage server, some 
other application transferring it to the user's computer 
hours/days/years after the encoding


I assume that you (Aaron) want make sure that the possibly modified 
source is available in scenario (a) and maybe also in scenario (b). But 
obviously scenario (c) would be a nightmare (backtracking the source 
version which was used to create a specific file). The problem is that 
the AGPL doesn't draw a good line between the scenarios.


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Reimar Döffinger]

On Tue, Apr 05, 2016 at 09:54:45AM +, Carl Eugen Hoyos wrote:
> Aaron Boxer  gmail.com> writes:
> 
> > I still think the advantages (i.e. closing the application 
> > server loophole)c outweigh this disadvantage.
> 
> I believe the mistake you make here is the main reason for 
> this whole fruitless discussion including the misunderstandings.

I wouldn't call it "mistake" but rather a
difference in opinion, but otherwise +1.
In my view it is "closing a loophole by throwing
your users under the bus", and while the license is
very vague in any reading of it the effectiveness
of closing the loophole seems proportional to the
throwing under the bus...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Ronald S. Bultje]

Hi,

On Tue, Apr 5, 2016 at 6:15 AM, wm4  wrote:

> On Tue, 05 Apr 2016 10:12:09 +
> Kieran Kunhya  wrote:
>
> > >
> > > Yes. Well, AGPL extends the definition of distribution to include use
> over
> > > the network.
> >
> >
> > Would we need then to send a copy of the AGPL to every viewer of our
> > channels?
> > How do we even know who they are when it's a terrestrial (OTA) broadcast?
> > Should we just send one to every citizen on earth just in case?
>
> Permanently overlay a text rendering of the AGPL over the channel.
>
> No really, why do you want your lib to be AGPL? It only causes problems.


I want to ++ this, because it will get ignored. Aaron: we really encourage
you to work on j2k, but we also encourage you to do so with a more liberal
license (e.g. GPL, or possibly even LGPL) for the final product. AGPL is a
bloody pain. Why do you want AGPL so much? Did the so-called loophole hurt
you personally in some way? Or is this all theoretical?

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[wm4]

On Tue, 05 Apr 2016 10:12:09 +
Kieran Kunhya  wrote:

> >
> > Yes. Well, AGPL extends the definition of distribution to include use over
> > the network.  
> 
> 
> Would we need then to send a copy of the AGPL to every viewer of our
> channels?
> How do we even know who they are when it's a terrestrial (OTA) broadcast?
> Should we just send one to every citizen on earth just in case?

Permanently overlay a text rendering of the AGPL over the channel.

No really, why do you want your lib to be AGPL? It only causes problems.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Kieran Kunhya]

>
> Yes. Well, AGPL extends the definition of distribution to include use over
> the network.


Would we need then to send a copy of the AGPL to every viewer of our
channels?
How do we even know who they are when it's a terrestrial (OTA) broadcast?
Should we just send one to every citizen on earth just in case?

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Carl Eugen Hoyos]

Aaron Boxer  gmail.com> writes:

> I still think the advantages (i.e. closing the application 
> server loophole)c outweigh this disadvantage.

I believe the mistake you make here is the main reason for 
this whole fruitless discussion including the misunderstandings.

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Carl Eugen Hoyos]

Aaron Boxer  gmail.com> writes:

> I also want to reiterate that because FFmpeg can be distributed 
> under GPL v3, and Grok is licensed under the AGPL, there are no 
> licensing issues regarding distributing FFmpeg together with Grok.

As was already discussed before, this is simply not true:
The GPLv2 (which is possibly the most often used license 
for FFmpeg but in any case a possible license) is not 
compatible with the AGPL.

> +enabled libopenjpeg   && { check_lib openjpeg-2.1/openjpeg.h 
> opj_version -lopenjp2 -ldl ||

This is unneeded for libopenjpeg and therefore not acceptable 
afaict. Is Grok part of any major distribution?

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Timothy Gu]

On Mon, Apr 04, 2016 at 06:06:28PM -0400, Aaron Boxer wrote:
> I could  give you an OS image that has a version of FFmpeg that uses
> proprietary codecs.

Aside from Carl's comment, please define "proprietary codecs." Proprietary
codecs have different licenses, just like how both ISC and GNU AGPL are
"open-source" licenses.

In fact, let me list out all the possibilities for such a "proprietary codec"
you can possibly talk about:

- cuda: No OS I know distribute CUDA by default. Not even Ubuntu.
- faac: Ditto.
- nvenc: Ditto.
- fdk-aac: The OS can distribute it legally if GPL is not enabled.
- openssl: Ditto.

Some other proprietary libraries not listed here do not need
"--enabled-nonfree" since they are system libraries (explicitly excluded in
GPL), and are irrelevant to this discussion.

> If you run it without knowing and without paying license, then you have a
> similar problem.

False. For all the libraries above, running alone does not pose any problems
with licensing.

cuda: "2.1  Rights and Limitations of Grant.  NVIDIA hereby grants Customer
the following non-exclusive, non-transferable right to use the SOFTWARE, with
the following limitations:" 2.1.1 says users cannot copy NVIDIA products.
2.1.2 gives an additional permission for Linux users. 2.1.3 concerns reverse
engineering, separation of components, and rentals.

faac: "ISO/IEC gives users of the MPEG-2 NBC/MPEG-4 Audio standards free
license to this software module or modifications thereof for use in hardware
or software products claiming conformance to the MPEG-2 NBC/ MPEG-4 Audio
standards."

nvenc: "Subject to Licensee’s compliance with the terms of this Agreement,
NVIDIA grants to Licensee a nonexclusive, non-transferable, worldwide,
royalty-free, fully paid-up license and right to install, use, reproduce,
display, perform, modify the Source Code of the Software" Limitations do not
include running.

fdk-aac: "Redistribution and use in source and binary forms, with or without
modification, are permitted without payment of copyright license fees provided
that you satisfy the following conditions" For the five conditions that
follow, 1, 2, and 4 concern only redistribution, and 3 and 5 concern only
documentation and advertising.

openssl: The clauses that makes OpenSSL GPL-incompatible are about
advertising.

> Should we then ban closed source codecs from FFmpeg?

No. Why ban them if it's perfectly legal to run them?

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 6:54 PM, Timothy Gu  wrote:

> Hi,
>
> On Mon, Apr 04, 2016 at 03:54:11PM -0400, Aaron Boxer wrote:
> > >
> > > >
> > > > The following changes were made:
> > > >
> > > > 1. Removed bpp (redundant as this information is already stored in
> > > precision)
> > >
> > > Does compilation still work without this change?
> > >
> >
> > Yes.
>
> Then the change is unrelated, and either needs to be in a separate patch or
> not commited at all.
>
> > >
> > > Does the compilation of OpenJPEG break _now_ without the patch? If so,
> > > submit
> > > a bug report, if not, then this change merits further discussion.
> > >
> >
> > Compilation against OpenJPEG master is broken, but everything works with
> > the latest release
> > of OpenJPEG (2.1)
>
> Would be great if you post the compilation log and file a ticket.
>
> > >
> > > If there isn't a way to detect Grok from OpenJPEG, there should be one.
> > >
> > > If it is not clear to you why we are so against AGPL, it is because it
> > > incurs
> > > additional restrictions on the work that we don't consider to be in the
> > > spirit
> > > of free software, regardless of what FSF says. But I think you already
> know
> > > about that.
> > >
> >
> > Why do you consider it to not be in the spirit of free software?
> > So far, nobody has given me a convincing argument against the use of  the
> > AGPL.
>
> I believe most members of the FFmpeg community consider free software the
> same
> way Linus Torvalds (among others) considers it: share the
> sources/modifications if you are distributing them, and do whatever you
> want
> with it if you are not.
>

Yes. Well, AGPL extends the definition of distribution to include use over
the network.


>
> We have no problem whatsoever with the entities using FFmpeg on their
> server
> without distributing the binaries or releasing their sources, or
> tivoization
> (which is a related, but different issue). Sure, it's better if they submit
> the patches, and we think that they are missing out by not submitting them,
> but we don't have any problems with it.
>

Fair enough.

>
> We do have a problem with the people that are preventing others from using
> the
> software under the aforementioned legitimate circumstances. For existing
> non-free software, we really don't have a choice, and it is clear to the
> user
> that such a copy of FFmpeg is non-free. But licenses like AGPL which claim
> it
> is "free" but fail our criteria of freedom are deemed to be "evil." In
> fact,
> AGPL is much more restrictive than most non-free licenses we deal with,
> since
> it concerns use in addition to distribution (see also Reimar's comments).
>

I see. So, licenses that fail your criteria of freedom are considered
"evil".
That is a pretty black and white view of the software world.
Also, I would point out that proprietary licenses most definitely restrict
use in addition to distribution.


>
> Moving forward, thanks to the explicit GPL compatibility shoehorned into
> Chapter 13 of AGPLv3, there isn't anything that makes us license our _own
> work_ as AGPL simply because FFmpeg binary is linked to an AGPL work (in
> fact,
> we cannot relicense our own code from LGPL to AGPLv3 like we can from LGPL
> to
> GPL). But using such a resultant mixture of licenses isn't something we
> want
> our users, personal or enterprise, to deal with.
>
>
This is a bit like parents thinking if they don't tell their kids about
sex, then they won't have sex.
We all know how that turns out.



> And that is why we are making more fuss about AGPL than most non-free
> libraries.
>
> Well, I don't want to flog a dead horse, so I guess we can all end the
discussion here:

Interesting points were raised, and  I learned some new things about
licensing.

Cheers,
Aaron





> Timothy
>
> P.S. I am not a lawyer.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 6:19 PM, Carl Eugen Hoyos  wrote:

> Aaron Boxer  gmail.com> writes:
>
> > I could  give you an OS image that has a version of
> > FFmpeg that uses proprietary codecs.
>
> You could, but you are not allowed to.
>

True.

Well, I guess you have come up with one disadvantage of the AGPL vs. GPL3:

1) You could receive a copy of FFmpeg that has an AGPL component, which the
person who
gave you the copy did not tell you about, and if you run this copy over the
network, and someone uses it
and asks you for source code, and you don't give it to them (because you
don't believe you are required to do so),
and if that person later discovers that your copy has an AGPL component,
then you are violating the AGPL.

I still think the advantages (i.e. closing the application server loophole)
outweigh this disadvantage.

Cheers,
Aaron
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Timothy Gu]

Hi,

On Mon, Apr 04, 2016 at 03:54:11PM -0400, Aaron Boxer wrote:
> >
> > >
> > > The following changes were made:
> > >
> > > 1. Removed bpp (redundant as this information is already stored in
> > precision)
> >
> > Does compilation still work without this change?
> >
> 
> Yes.

Then the change is unrelated, and either needs to be in a separate patch or
not commited at all.

> >
> > Does the compilation of OpenJPEG break _now_ without the patch? If so,
> > submit
> > a bug report, if not, then this change merits further discussion.
> >
> 
> Compilation against OpenJPEG master is broken, but everything works with
> the latest release
> of OpenJPEG (2.1)

Would be great if you post the compilation log and file a ticket.

> >
> > If there isn't a way to detect Grok from OpenJPEG, there should be one.
> >
> > If it is not clear to you why we are so against AGPL, it is because it
> > incurs
> > additional restrictions on the work that we don't consider to be in the
> > spirit
> > of free software, regardless of what FSF says. But I think you already know
> > about that.
> >
> 
> Why do you consider it to not be in the spirit of free software?
> So far, nobody has given me a convincing argument against the use of  the
> AGPL.

I believe most members of the FFmpeg community consider free software the same
way Linus Torvalds (among others) considers it: share the
sources/modifications if you are distributing them, and do whatever you want
with it if you are not.

We have no problem whatsoever with the entities using FFmpeg on their server
without distributing the binaries or releasing their sources, or tivoization
(which is a related, but different issue). Sure, it's better if they submit
the patches, and we think that they are missing out by not submitting them,
but we don't have any problems with it.

We do have a problem with the people that are preventing others from using the
software under the aforementioned legitimate circumstances. For existing
non-free software, we really don't have a choice, and it is clear to the user
that such a copy of FFmpeg is non-free. But licenses like AGPL which claim it
is "free" but fail our criteria of freedom are deemed to be "evil." In fact,
AGPL is much more restrictive than most non-free licenses we deal with, since
it concerns use in addition to distribution (see also Reimar's comments).

Moving forward, thanks to the explicit GPL compatibility shoehorned into
Chapter 13 of AGPLv3, there isn't anything that makes us license our _own
work_ as AGPL simply because FFmpeg binary is linked to an AGPL work (in fact,
we cannot relicense our own code from LGPL to AGPLv3 like we can from LGPL to
GPL). But using such a resultant mixture of licenses isn't something we want
our users, personal or enterprise, to deal with.

And that is why we are making more fuss about AGPL than most non-free
libraries.

Timothy

P.S. I am not a lawyer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Carl Eugen Hoyos]

Aaron Boxer  gmail.com> writes:

> I could  give you an OS image that has a version of 
> FFmpeg that uses proprietary codecs.

You could, but you are not allowed to.

Carl Eugen 




___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Apr 4, 2016 5:12 PM, "Reimar Döffinger"  wrote:
>
> On Mon, Apr 04, 2016 at 03:48:38PM -0400, Aaron Boxer wrote:
> > On Mon, Apr 4, 2016 at 3:16 PM, Reimar Döffinger <
reimar.doeffin...@gmx.de>
> > wrote:
> >
> > > The really huge, gigantic, elephant sized issue with AGPL for me is
> > > that it is _completely_ unclear to me what you actually have to
> > > do to fulfill the license requirements of that "frankenmonster".
> > >
> >
> > Read the license, then.
>
> Which tells me exactly NOTHING.
> It says each piece is covered by ITS license.
> I.e. there isn't ONE license that covers the whole
> thing?!
> Their nice compatibility matrix shows what applies for
> other license combinations, but they left the AGPLv3
> out of that one!
> The license also never defines what exactly
> "if you modify the Program" would mean
> (so, if a company, for example Canonical, modified it and
> never gave me the source or even told me it was modified,
> is only the company in trouble or am I too? If I am,
> that's a problem, if I am not that's a loophole almost
> as big as the one it meant to fix).

Good question. There are legal grey zones for all licences. Doesn't mean we
have to stop using them

>
> > > No restrictions on use makes GPL very simple: if you don't
> > > redistribute, you don't need to do anything.
> > > What if you somehow got an OS image that happens to use
> > > a FFmpeg compiled against AGPL components (without you being
> > > aware, since you never use or care about the AGPL parts)
> > > and then use FFmpeg to stream over the net (or even your proprietary
> > > code), are you suddenly in violation of the license?
> > >
> >
> > What if you get a version of FFmeg compiled against GPLv3, without being
> > aware that this is the case,
> > and then combine it with a proprietary application ?  Same situation.
>
> No, absolutely no problem. None at all. Completely fine.
> Sure if you pass it on you have to check things (but also,
> only if you distribute the FFmpeg compiled as GPLv3, not if
> you simply distribute your binary, and also not if you
> distribute e.g. within your organization).
> And by accident distributing binary doesn't really happen,
> whereas accidentally having a server service run or exposed
> wider than expected happens all the time.
>
> > If the answer is "yes", I am against such a version of FFmpeg
> > > working without each _use_ of it requiring a special action
> > > that confirms users are aware of the license obligations.
> > >
> >
> > The same logic applies to GPLv3 distributions of FFmpeg.
>
> There is NO way that simply RUNNING a GPLv3 version of FFmpeg
> EVER triggers ANY license obligation.
> 

I could  give you an OS image that has a version of FFmpeg that uses
proprietary codecs. If you run it without knowing and without paying
license, then you have a similar problem.  Should we then ban closed source
codecs from FFmpeg?

Cheers,
Aaron

___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Reimar Döffinger]

On Mon, Apr 04, 2016 at 03:48:38PM -0400, Aaron Boxer wrote:
> On Mon, Apr 4, 2016 at 3:16 PM, Reimar Döffinger 
> wrote:
> 
> > The really huge, gigantic, elephant sized issue with AGPL for me is
> > that it is _completely_ unclear to me what you actually have to
> > do to fulfill the license requirements of that "frankenmonster".
> >
> 
> Read the license, then.

Which tells me exactly NOTHING.
It says each piece is covered by ITS license.
I.e. there isn't ONE license that covers the whole
thing?!
Their nice compatibility matrix shows what applies for
other license combinations, but they left the AGPLv3
out of that one!
The license also never defines what exactly
"if you modify the Program" would mean
(so, if a company, for example Canonical, modified it and
never gave me the source or even told me it was modified,
is only the company in trouble or am I too? If I am,
that's a problem, if I am not that's a loophole almost
as big as the one it meant to fix).

> > No restrictions on use makes GPL very simple: if you don't
> > redistribute, you don't need to do anything.
> > What if you somehow got an OS image that happens to use
> > a FFmpeg compiled against AGPL components (without you being
> > aware, since you never use or care about the AGPL parts)
> > and then use FFmpeg to stream over the net (or even your proprietary
> > code), are you suddenly in violation of the license?
> >
> 
> What if you get a version of FFmeg compiled against GPLv3, without being
> aware that this is the case,
> and then combine it with a proprietary application ?  Same situation.

No, absolutely no problem. None at all. Completely fine.
Sure if you pass it on you have to check things (but also,
only if you distribute the FFmpeg compiled as GPLv3, not if
you simply distribute your binary, and also not if you
distribute e.g. within your organization).
And by accident distributing binary doesn't really happen,
whereas accidentally having a server service run or exposed
wider than expected happens all the time.

> If the answer is "yes", I am against such a version of FFmpeg
> > working without each _use_ of it requiring a special action
> > that confirms users are aware of the license obligations.
> >
> 
> The same logic applies to GPLv3 distributions of FFmpeg.

There is NO way that simply RUNNING a GPLv3 version of FFmpeg
EVER triggers ANY license obligation.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 1:51 PM, Timothy Gu  wrote:

> On Sun, Apr 03, 2016 at 05:34:15PM -0400, Aaron Boxer wrote:
>
> > From d12c685578f21b403f6c03505edd84db367306c5 Mon Sep 17 00:00:00 2001
> > From: Aaron Boxer 
> > Date: Sun, 27 Mar 2016 00:15:20 -0400
>
> > Subject: [PATCH] Support the following jpeg 2000 codecs:
> >
> > a) latest release of openjpeg (2.1)
> > b) master branch of openjpeg
> > c) grok (https://github.com/GrokImageCompression/grok)
>
> The commit message should be changed to:
>
> build: Support additional OpenJPEG-compatible libraries
>
> Support OpenJPEG 2.1, master, as well as Grok.
>

No problem.


>
> >
> > The following changes were made:
> >
> > 1. Removed bpp (redundant as this information is already stored in
> precision)
>
> Does compilation still work without this change?
>

Yes.



>
> > 2. Removed OPJ_STATIC flag in configure: in master branch of openjpeg
> and in
> > grok, this flag indicates a static build, so codec API functions are
> marked
> > as hidden. This prevents FFmpeg from using a dynamic build of these
> codecs.
>
> This will break Windows DLL MinGW support. See
>
> https://github.com/uclouvain/openjpeg/blob/master/src/lib/openjp2/openjpeg.h#L79-L108
> .
> When Windows is used and OPJ_STATIC is not defined, __declspec(dllimport)
> is used, which asks GCC to mangle
> the symbol name when compiling. However, under MinGW environment, such
> mangling doesn't work, since the DLL is all that is needed for linking
> under
> MinGW.
>

Let me look into this.


>
> Does the compilation of OpenJPEG break _now_ without the patch? If so,
> submit
> a bug report, if not, then this change merits further discussion.
>


Compilation against OpenJPEG master is broken, but everything works with
the latest release
of OpenJPEG (2.1)



>
> > 3. link to libdl. This is needed by grok, as it supports a plugin
> > architecture that allows plugins to be dynamically loaded at runtime.
>
> Is there a way to detect Grok? Linking to a library that is unnecessary
> for a
> specific case doesn't sound appealing to me.
>

Currently no way of detecting Grok vs OpenJPEG


>
> Also it should be made clear that if Grok is linked into FFmpeg, the
> resulting
> binary is a mixture of AGPL and GPL works. If --enable-gpl or
> --enable-version3 is not enabled, the compilation should fail.
>

No problem.


>
> If there isn't a way to detect Grok from OpenJPEG, there should be one.
>
> If it is not clear to you why we are so against AGPL, it is because it
> incurs
> additional restrictions on the work that we don't consider to be in the
> spirit
> of free software, regardless of what FSF says. But I think you already know
> about that.
>

Why do you consider it to not be in the spirit of free software?
So far, nobody has given me a convincing argument against the use of  the
AGPL.

Cheers,
Aaron



"I disapprove of what you say, but I will defend to the death your right to
say it"
Voltaire





>
> Timothy
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 3:16 PM, Reimar Döffinger 
wrote:

> On Mon, Apr 04, 2016 at 10:51:23AM -0700, Timothy Gu wrote:
> > On Sun, Apr 03, 2016 at 05:34:15PM -0400, Aaron Boxer wrote:
> > Also it should be made clear that if Grok is linked into FFmpeg, the
> resulting
> > binary is a mixture of AGPL and GPL works. If --enable-gpl or
> > --enable-version3 is not enabled, the compilation should fail.
> >
> > If there isn't a way to detect Grok from OpenJPEG, there should be one.
> >
> > If it is not clear to you why we are so against AGPL, it is because it
> incurs
> > additional restrictions on the work that we don't consider to be in the
> spirit
> > of free software, regardless of what FSF says. But I think you already
> know
> > about that.
>
> The really huge, gigantic, elephant sized issue with AGPL for me is
> that it is _completely_ unclear to me what you actually have to
> do to fulfill the license requirements of that "frankenmonster".
>

Read the license, then.


> No restrictions on use makes GPL very simple: if you don't
> redistribute, you don't need to do anything.
> What if you somehow got an OS image that happens to use
> a FFmpeg compiled against AGPL components (without you being
> aware, since you never use or care about the AGPL parts)
> and then use FFmpeg to stream over the net (or even your proprietary
> code), are you suddenly in violation of the license?
>

What if you get a version of FFmeg compiled against GPLv3, without being
aware that this is the case,
and then combine it with a proprietary application ?  Same situation.


If the answer is "yes", I am against such a version of FFmpeg
> working without each _use_ of it requiring a special action
> that confirms users are aware of the license obligations.
>

The same logic applies to GPLv3 distributions of FFmpeg.

Aaron
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Reimar Döffinger]

On Mon, Apr 04, 2016 at 10:51:23AM -0700, Timothy Gu wrote:
> On Sun, Apr 03, 2016 at 05:34:15PM -0400, Aaron Boxer wrote:
> Also it should be made clear that if Grok is linked into FFmpeg, the resulting
> binary is a mixture of AGPL and GPL works. If --enable-gpl or
> --enable-version3 is not enabled, the compilation should fail.
> 
> If there isn't a way to detect Grok from OpenJPEG, there should be one.
> 
> If it is not clear to you why we are so against AGPL, it is because it incurs
> additional restrictions on the work that we don't consider to be in the spirit
> of free software, regardless of what FSF says. But I think you already know
> about that.

The really huge, gigantic, elephant sized issue with AGPL for me is
that it is _completely_ unclear to me what you actually have to
do to fulfill the license requirements of that "frankenmonster".
No restrictions on use makes GPL very simple: if you don't
redistribute, you don't need to do anything.
What if you somehow got an OS image that happens to use
a FFmpeg compiled against AGPL components (without you being
aware, since you never use or care about the AGPL parts)
and then use FFmpeg to stream over the net (or even your proprietary
code), are you suddenly in violation of the license?
If the answer is "yes", I am against such a version of FFmpeg
working without each _use_ of it requiring a special action
that confirms users are aware of the license obligations.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Timothy Gu]

On Sun, Apr 03, 2016 at 05:34:15PM -0400, Aaron Boxer wrote:

> From d12c685578f21b403f6c03505edd84db367306c5 Mon Sep 17 00:00:00 2001
> From: Aaron Boxer 
> Date: Sun, 27 Mar 2016 00:15:20 -0400

> Subject: [PATCH] Support the following jpeg 2000 codecs:
> 
> a) latest release of openjpeg (2.1)
> b) master branch of openjpeg
> c) grok (https://github.com/GrokImageCompression/grok)

The commit message should be changed to:

build: Support additional OpenJPEG-compatible libraries

Support OpenJPEG 2.1, master, as well as Grok.

> 
> The following changes were made:
> 
> 1. Removed bpp (redundant as this information is already stored in precision)

Does compilation still work without this change?

> 2. Removed OPJ_STATIC flag in configure: in master branch of openjpeg and in
> grok, this flag indicates a static build, so codec API functions are marked
> as hidden. This prevents FFmpeg from using a dynamic build of these codecs.

This will break Windows DLL MinGW support. See
https://github.com/uclouvain/openjpeg/blob/master/src/lib/openjp2/openjpeg.h#L79-L108.
When Windows is used and OPJ_STATIC is not defined, __declspec(dllimport) is 
used, which asks GCC to mangle
the symbol name when compiling. However, under MinGW environment, such
mangling doesn't work, since the DLL is all that is needed for linking under
MinGW.

Does the compilation of OpenJPEG break _now_ without the patch? If so, submit
a bug report, if not, then this change merits further discussion.

> 3. link to libdl. This is needed by grok, as it supports a plugin
> architecture that allows plugins to be dynamically loaded at runtime.

Is there a way to detect Grok? Linking to a library that is unnecessary for a
specific case doesn't sound appealing to me.

Also it should be made clear that if Grok is linked into FFmpeg, the resulting
binary is a mixture of AGPL and GPL works. If --enable-gpl or
--enable-version3 is not enabled, the compilation should fail.

If there isn't a way to detect Grok from OpenJPEG, there should be one.

If it is not clear to you why we are so against AGPL, it is because it incurs
additional restrictions on the work that we don't consider to be in the spirit
of free software, regardless of what FSF says. But I think you already know
about that.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Michael Niedermayer]

Hi

On Mon, Apr 04, 2016 at 10:32:24AM -0400, Aaron Boxer wrote:
[...]

> Someone has mentioned the extra effort required to make the source
> available over the network.
> I would be happy to work on this.

its maybe not the right thread to discuss this (as people look at
it from a agpl dislike biased point of view)
but speaking just for myself here, i think making it possible (not
legally binding) to get the source out of a binary FFmpeg and even
over the network sounds like a potentially interresting feature


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Nicolas George]

Le sextidi 16 germinal, an CCXXIV, Aaron Boxer a écrit :
> You are right, I don't understand.  So far, nobody has provided a
> reasonable explanation for why AGPL is not acceptable, while GPL v3 is.

GPLv3 is already there, the question to accept it or not is not on the
table. Maybe if the question was raised today we would reject it too.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

Hi Josh,


On Mon, Apr 4, 2016 at 9:30 AM, Josh de Kock  wrote:

> On 04/04/2016 14:21, Aaron Boxer wrote:
> > All of your arguments could be applied equally to GPL v3 components. And
> > yet,
> > FFmpeg is happy to allow distribution under GPL v3. So, I don't see what
> > the problem is here.
> The problem is AGPL can make certain builds of FFmpeg _unusable_, it's a
> pain to work with. Most of all, people just don't want AGPL in FFmpeg.
> As wm4 said: "If you really want your lib to be useful, you should
> relicense it to LGPL2.1 or later".
> >
> > Yes, Google has a no-AGPL policy, so they won't be able to use it. I am
> > sure they will
> > survive somehow without my J2k codec.
> A lot of people could survive without it. In-fact, I reckon everyone who
> is currently using FFmpeg could.
>
> On 04/04/2016 14:24, Aaron Boxer wrote:
> > Of course, it is not my place to say what should happen with the
> > project.
> > I just want to make sure everyone understands the issues involved
> > before making a decision.
> I'm almost 100% sure they do, I think it's you who rather doesn't
> understand the issues involved with putting AGPL into FFmpeg.
>


You are right, I don't understand.  So far, nobody has provided a
reasonable explanation for
why AGPL is not acceptable, while GPL v3 is.

Someone has mentioned the extra effort required to make the source
available over the network.
I would be happy to work on this.

The only other possible explanation is that people would like to make use
of the GPLv3
loophole whereby one can use GPL v3 code over the network and not be
required to
make code modifications available.

Google, for example, which makes its $$ on closed services that use GPL
code, clearly will not tolerate
AGPL.


So, is this the reason why some are opposed to AGPL ?  There is nothing
wrong with this, it is allowed by the license,
just want to be clear.

Anyways,  I am happy to maintain my two-line fork of FFmpeg if this patch
is not accepted.

And, by the way, these changes will be needed in the future when OpenJPEG
releases its next version,
or FFmpeg will not work with OpenJPEG dynamic builds.

Kind Regards,
Aaron













>
> Josh
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Josh de Kock]

On 04/04/2016 14:21, Aaron Boxer wrote:
> All of your arguments could be applied equally to GPL v3 components. And
> yet,
> FFmpeg is happy to allow distribution under GPL v3. So, I don't see what
> the problem is here.
The problem is AGPL can make certain builds of FFmpeg _unusable_, it's a
pain to work with. Most of all, people just don't want AGPL in FFmpeg.
As wm4 said: "If you really want your lib to be useful, you should
relicense it to LGPL2.1 or later".
> 
> Yes, Google has a no-AGPL policy, so they won't be able to use it. I am
> sure they will
> survive somehow without my J2k codec.
A lot of people could survive without it. In-fact, I reckon everyone who
is currently using FFmpeg could.

On 04/04/2016 14:24, Aaron Boxer wrote:
> Of course, it is not my place to say what should happen with the
> project.
> I just want to make sure everyone understands the issues involved
> before making a decision.
I'm almost 100% sure they do, I think it's you who rather doesn't
understand the issues involved with putting AGPL into FFmpeg.

Josh



signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Ronald S. Bultje]

Hi,

On Mon, Apr 4, 2016 at 9:21 AM, Aaron Boxer  wrote:

> Hi Ronald,
>
>
> On Mon, Apr 4, 2016 at 8:56 AM, Ronald S. Bultje 
> wrote:
>
> > Hi,
> >
> > On Mon, Apr 4, 2016 at 8:43 AM, Aaron Boxer  wrote:
> >
> > > Hi Ronald,
> > >
> > >
> > > On Mon, Apr 4, 2016 at 8:34 AM, Ronald S. Bultje 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > On Mon, Apr 4, 2016 at 7:59 AM, Aaron Boxer 
> wrote:
> > > >
> > > > > On Mon, Apr 4, 2016 at 7:13 AM, wm4  wrote:
> > > > >
> > > > > > On Sun, 3 Apr 2016 17:31:25 -0400
> > > > > > Aaron Boxer  wrote:
> > > > > >
> > > > > > > Hi Folks,
> > > > > > >
> > > > > > > Here is a small patch to get FFmpeg working with both OpenJPEG
> > > master
> > > > > and
> > > > > > > Grok master, for J2K support.  The comment on the commit has
> all
> > of
> > > > the
> > > > > > > details; the main change is to remove the OPJ_STATIC flag from
> > > > > configure,
> > > > > > > so that FFmpeg can be configured with a dynamic build of both
> > > codecs.
> > > > > > >
> > > > > > > I also want to reiterate that because FFmpeg can be distributed
> > > under
> > > > > GPL
> > > > > > > v3, and Grok is licensed under the AGPL, there are no licensing
> > > > issues
> > > > > > > regarding distributing FFmpeg together with Grok.
> > > > > > >
> > > > > > > Quoting from Wikipedia:
> > > > > > >
> > > > > > > "By contrast, GPLv3 and AGPLv3 each include clauses (in section
> > 13
> > > of
> > > > > > each
> > > > > > > license) that together achieve a form of mutual compatibility
> for
> > > the
> > > > > two
> > > > > > > licenses. These clauses explicitly allow the "conveying
> > > > > > > " of a work formed
> > by
> > > > > > linking
> > > > > > > code licensed under the one license against code licensed under
> > the
> > > > > other
> > > > > > > license,[3]
> > > > > > > <
> > > > >
> > >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-3
> > > > > > >
> > > > > > > despite the licenses otherwise not allowing relicensing under
> the
> > > > terms
> > > > > > of
> > > > > > > each other.[4]
> > > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > > > > >
> > > > > > > In this way, the copyleft of each license is relaxed to allow
> > > > > > distributing
> > > > > > > such combinations.[4] "
> > > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > > > > >
> > > > > > >
> > > > > > > So, this patch will expand the choice of J2K codecs for all
> users
> > > who
> > > > > use
> > > > > > > FFmpeg under the GPLv3 license.
> > > > > >
> > > > > > AGPL is evil. That alone warrants creating a better, actually
> free
> > > > > > version of the decoder.
> > > > > >
> > > > >
> > > > > The only difference between AGPL and GPL is the proviso that users
> > > > > connecting to a program using AGPL code
> > > > > must be provided with the full source code for the program. This is
> > to
> > > > > close the loophole in the GPL where
> > > > > someone can take free software, put it in the "cloud", and then
> treat
> > > it
> > > > as
> > > > > closed, non-free software, because they
> > > > > do not have to distribute modifications.
> > > > >
> > > > > Please explain why you think this is a Bad Thing (TM)  ?
> > > >
> > > >
> > > > Because it's a fork, not in the codebase sense but in the licensing
> > > sense,
> > > > but the effect is the same. We will not be able to combine multiple
> > > > branches of the fork because each of them is only compatible in its
> own
> > > > direction - "LGPL code can be merged into AGPL code to create AGPL
> > code"
> > > > but not the other way around.
> > > >
> > > > That is fundamentally unfair for those of us that actually _want_ a
> > > > LGPLv2.1-or-later codebase. Why would you get all our spoils but not
> > the
> > > > other way around?
> > > >
> > >
> > > Sorry, I was wrong in my original statements. I've learned a bit more
> > about
> > > how these
> > > licenses work.
> > >
> > > This is not a fork. FSF allows GPL 3 and AGPL 3 code to be combined.
> > > If FFmpeg can be distributed according to GPL 3, then it can included
> > AGPL
> > > 3 code.
> > >
> > > Very simple.
> >
> >
> > Oh, no, no, no. Very simple for _you_, with your _simple_ goal of using
> > ffmpeg and profiting from it by AGPL'ing your component.
> >
> > But for me, as a maintainer, can I combine GPLv2 with AGPLv3? For
> example,
> > can I link a GPLv2 application with a AGPLv3 build of ffmpeg and
> distribute
> > the result? Can I link an AGPLv3 build of ffmpeg with a closed-source
> > application and distribute the result? Can "big" users of ffmpeg,
> companies
> > that fund out project (through e.g. GSoC), like, say, Google, 

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

Hi Hendrik,

On Mon, Apr 4, 2016 at 9:06 AM, Hendrik Leppkes  wrote:

> On Mon, Apr 4, 2016 at 2:49 PM, Aaron Boxer  wrote:
> > On Mon, Apr 4, 2016 at 5:37 AM, Michael Niedermayer
> 
> > wrote:
> >
> >> On Sun, Apr 03, 2016 at 05:31:25PM -0400, Aaron Boxer wrote:
> >> > Hi Folks,
> >> >
> >> > Here is a small patch to get FFmpeg working with both OpenJPEG master
> and
> >> > Grok master, for J2K support.  The comment on the commit has all of
> the
> >> > details; the main change is to remove the OPJ_STATIC flag from
> configure,
> >> > so that FFmpeg can be configured with a dynamic build of both codecs.
> >> >
> >>
> >> > I also want to reiterate that because FFmpeg can be distributed under
> GPL
> >> > v3, and Grok is licensed under the AGPL, there are no licensing issues
> >> > regarding distributing FFmpeg together with Grok.
> >>
> >> FFmpeg support a wide varity of network protools, from low level
> >> tcp to higher level http, ftp, rtp, rtsp, rtmp, mms, ...
> >>
> >> the AGPL requires "if you modify the Program, your modified version must
> >> prominently offer all users interacting with it remotely through a
> computer
> >> network (if your version supports such interaction) an opportunity to
> >> receive the Corresponding Source of your version by providing access to
> the
> >> Corresponding Source from a network server at no charge, through some
> >> standard or customary means of facilitating copying of software."
> >>
> >> yet you here suggest to link AGPL software to GPL where the GPL sw
> >> will not offer any source though any of its quite numerous network
> >> interfaces
> >>
> >> Iam no lawyer so i dont know if you can do that or not but
> >> either the combination needs to offer source code through its network
> >> protocols or you just suggested to circumvent your own licenses main
> >> point
> >>
> >>
> > Here is clarification from the horse's mouth AKA FSF:
>
> You should understand one thing:
> For us, its not really about if its legally possible to link to such a
> library, but if we want to open the door to such licensed libraries.
> And the answer to that question seems to go in favor of no.
>
>
Of course, it is not my place to say what should happen with the project.
I just want to make sure everyone understands the issues involved
before making a decision.

Cheers,
Aaron




> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

Hi Ronald,


On Mon, Apr 4, 2016 at 8:56 AM, Ronald S. Bultje  wrote:

> Hi,
>
> On Mon, Apr 4, 2016 at 8:43 AM, Aaron Boxer  wrote:
>
> > Hi Ronald,
> >
> >
> > On Mon, Apr 4, 2016 at 8:34 AM, Ronald S. Bultje 
> > wrote:
> >
> > > Hi,
> > >
> > > On Mon, Apr 4, 2016 at 7:59 AM, Aaron Boxer  wrote:
> > >
> > > > On Mon, Apr 4, 2016 at 7:13 AM, wm4  wrote:
> > > >
> > > > > On Sun, 3 Apr 2016 17:31:25 -0400
> > > > > Aaron Boxer  wrote:
> > > > >
> > > > > > Hi Folks,
> > > > > >
> > > > > > Here is a small patch to get FFmpeg working with both OpenJPEG
> > master
> > > > and
> > > > > > Grok master, for J2K support.  The comment on the commit has all
> of
> > > the
> > > > > > details; the main change is to remove the OPJ_STATIC flag from
> > > > configure,
> > > > > > so that FFmpeg can be configured with a dynamic build of both
> > codecs.
> > > > > >
> > > > > > I also want to reiterate that because FFmpeg can be distributed
> > under
> > > > GPL
> > > > > > v3, and Grok is licensed under the AGPL, there are no licensing
> > > issues
> > > > > > regarding distributing FFmpeg together with Grok.
> > > > > >
> > > > > > Quoting from Wikipedia:
> > > > > >
> > > > > > "By contrast, GPLv3 and AGPLv3 each include clauses (in section
> 13
> > of
> > > > > each
> > > > > > license) that together achieve a form of mutual compatibility for
> > the
> > > > two
> > > > > > licenses. These clauses explicitly allow the "conveying
> > > > > > " of a work formed
> by
> > > > > linking
> > > > > > code licensed under the one license against code licensed under
> the
> > > > other
> > > > > > license,[3]
> > > > > > <
> > > >
> > https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-3
> > > > > >
> > > > > > despite the licenses otherwise not allowing relicensing under the
> > > terms
> > > > > of
> > > > > > each other.[4]
> > > > > > <
> > > > >
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > > > >
> > > > > > In this way, the copyleft of each license is relaxed to allow
> > > > > distributing
> > > > > > such combinations.[4] "
> > > > > > <
> > > > >
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > > > >
> > > > > >
> > > > > > So, this patch will expand the choice of J2K codecs for all users
> > who
> > > > use
> > > > > > FFmpeg under the GPLv3 license.
> > > > >
> > > > > AGPL is evil. That alone warrants creating a better, actually free
> > > > > version of the decoder.
> > > > >
> > > >
> > > > The only difference between AGPL and GPL is the proviso that users
> > > > connecting to a program using AGPL code
> > > > must be provided with the full source code for the program. This is
> to
> > > > close the loophole in the GPL where
> > > > someone can take free software, put it in the "cloud", and then treat
> > it
> > > as
> > > > closed, non-free software, because they
> > > > do not have to distribute modifications.
> > > >
> > > > Please explain why you think this is a Bad Thing (TM)  ?
> > >
> > >
> > > Because it's a fork, not in the codebase sense but in the licensing
> > sense,
> > > but the effect is the same. We will not be able to combine multiple
> > > branches of the fork because each of them is only compatible in its own
> > > direction - "LGPL code can be merged into AGPL code to create AGPL
> code"
> > > but not the other way around.
> > >
> > > That is fundamentally unfair for those of us that actually _want_ a
> > > LGPLv2.1-or-later codebase. Why would you get all our spoils but not
> the
> > > other way around?
> > >
> >
> > Sorry, I was wrong in my original statements. I've learned a bit more
> about
> > how these
> > licenses work.
> >
> > This is not a fork. FSF allows GPL 3 and AGPL 3 code to be combined.
> > If FFmpeg can be distributed according to GPL 3, then it can included
> AGPL
> > 3 code.
> >
> > Very simple.
>
>
> Oh, no, no, no. Very simple for _you_, with your _simple_ goal of using
> ffmpeg and profiting from it by AGPL'ing your component.
>
> But for me, as a maintainer, can I combine GPLv2 with AGPLv3? For example,
> can I link a GPLv2 application with a AGPLv3 build of ffmpeg and distribute
> the result? Can I link an AGPLv3 build of ffmpeg with a closed-source
> application and distribute the result? Can "big" users of ffmpeg, companies
> that fund out project (through e.g. GSoC), like, say, Google, use AGPLv3
> builds of ffmpeg without a change in their respective requirements for
> complying with the license terms?
>
> Or, to say it differently: who profits from AGPLv3 components? FFmpeg? Or
> just you? I think it's just you, and that's extremely selfish. It's not in
> the best interest of our project to accept AGPLv3 components, it's only in
> your self-interest that it be accepted. 

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Hendrik Leppkes]

On Mon, Apr 4, 2016 at 2:49 PM, Aaron Boxer  wrote:
> On Mon, Apr 4, 2016 at 5:37 AM, Michael Niedermayer 
> wrote:
>
>> On Sun, Apr 03, 2016 at 05:31:25PM -0400, Aaron Boxer wrote:
>> > Hi Folks,
>> >
>> > Here is a small patch to get FFmpeg working with both OpenJPEG master and
>> > Grok master, for J2K support.  The comment on the commit has all of the
>> > details; the main change is to remove the OPJ_STATIC flag from configure,
>> > so that FFmpeg can be configured with a dynamic build of both codecs.
>> >
>>
>> > I also want to reiterate that because FFmpeg can be distributed under GPL
>> > v3, and Grok is licensed under the AGPL, there are no licensing issues
>> > regarding distributing FFmpeg together with Grok.
>>
>> FFmpeg support a wide varity of network protools, from low level
>> tcp to higher level http, ftp, rtp, rtsp, rtmp, mms, ...
>>
>> the AGPL requires "if you modify the Program, your modified version must
>> prominently offer all users interacting with it remotely through a computer
>> network (if your version supports such interaction) an opportunity to
>> receive the Corresponding Source of your version by providing access to the
>> Corresponding Source from a network server at no charge, through some
>> standard or customary means of facilitating copying of software."
>>
>> yet you here suggest to link AGPL software to GPL where the GPL sw
>> will not offer any source though any of its quite numerous network
>> interfaces
>>
>> Iam no lawyer so i dont know if you can do that or not but
>> either the combination needs to offer source code through its network
>> protocols or you just suggested to circumvent your own licenses main
>> point
>>
>>
> Here is clarification from the horse's mouth AKA FSF:

You should understand one thing:
For us, its not really about if its legally possible to link to such a
library, but if we want to open the door to such licensed libraries.
And the answer to that question seems to go in favor of no.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[wm4]

On Mon, 4 Apr 2016 08:43:10 -0400
Aaron Boxer  wrote:

> Sorry, I was wrong in my original statements. I've learned a bit more about
> how these
> licenses work.
> 
> This is not a fork. FSF allows GPL 3 and AGPL 3 code to be combined.
> If FFmpeg can be distributed according to GPL 3, then it can included AGPL
> 3 code.
> 
> Very simple.

FFmpeg is mainly distributed as "LGPL2.1 or later". If you really want
your lib to be useful, you should relicense it to LGPL2.1 or later
(which is the most compatible GPL license possible).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Ronald S. Bultje]

Hi,

On Mon, Apr 4, 2016 at 8:43 AM, Aaron Boxer  wrote:

> Hi Ronald,
>
>
> On Mon, Apr 4, 2016 at 8:34 AM, Ronald S. Bultje 
> wrote:
>
> > Hi,
> >
> > On Mon, Apr 4, 2016 at 7:59 AM, Aaron Boxer  wrote:
> >
> > > On Mon, Apr 4, 2016 at 7:13 AM, wm4  wrote:
> > >
> > > > On Sun, 3 Apr 2016 17:31:25 -0400
> > > > Aaron Boxer  wrote:
> > > >
> > > > > Hi Folks,
> > > > >
> > > > > Here is a small patch to get FFmpeg working with both OpenJPEG
> master
> > > and
> > > > > Grok master, for J2K support.  The comment on the commit has all of
> > the
> > > > > details; the main change is to remove the OPJ_STATIC flag from
> > > configure,
> > > > > so that FFmpeg can be configured with a dynamic build of both
> codecs.
> > > > >
> > > > > I also want to reiterate that because FFmpeg can be distributed
> under
> > > GPL
> > > > > v3, and Grok is licensed under the AGPL, there are no licensing
> > issues
> > > > > regarding distributing FFmpeg together with Grok.
> > > > >
> > > > > Quoting from Wikipedia:
> > > > >
> > > > > "By contrast, GPLv3 and AGPLv3 each include clauses (in section 13
> of
> > > > each
> > > > > license) that together achieve a form of mutual compatibility for
> the
> > > two
> > > > > licenses. These clauses explicitly allow the "conveying
> > > > > " of a work formed by
> > > > linking
> > > > > code licensed under the one license against code licensed under the
> > > other
> > > > > license,[3]
> > > > > <
> > >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-3
> > > > >
> > > > > despite the licenses otherwise not allowing relicensing under the
> > terms
> > > > of
> > > > > each other.[4]
> > > > > <
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > > >
> > > > > In this way, the copyleft of each license is relaxed to allow
> > > > distributing
> > > > > such combinations.[4] "
> > > > > <
> > > >
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > > >
> > > > >
> > > > > So, this patch will expand the choice of J2K codecs for all users
> who
> > > use
> > > > > FFmpeg under the GPLv3 license.
> > > >
> > > > AGPL is evil. That alone warrants creating a better, actually free
> > > > version of the decoder.
> > > >
> > >
> > > The only difference between AGPL and GPL is the proviso that users
> > > connecting to a program using AGPL code
> > > must be provided with the full source code for the program. This is to
> > > close the loophole in the GPL where
> > > someone can take free software, put it in the "cloud", and then treat
> it
> > as
> > > closed, non-free software, because they
> > > do not have to distribute modifications.
> > >
> > > Please explain why you think this is a Bad Thing (TM)  ?
> >
> >
> > Because it's a fork, not in the codebase sense but in the licensing
> sense,
> > but the effect is the same. We will not be able to combine multiple
> > branches of the fork because each of them is only compatible in its own
> > direction - "LGPL code can be merged into AGPL code to create AGPL code"
> > but not the other way around.
> >
> > That is fundamentally unfair for those of us that actually _want_ a
> > LGPLv2.1-or-later codebase. Why would you get all our spoils but not the
> > other way around?
> >
>
> Sorry, I was wrong in my original statements. I've learned a bit more about
> how these
> licenses work.
>
> This is not a fork. FSF allows GPL 3 and AGPL 3 code to be combined.
> If FFmpeg can be distributed according to GPL 3, then it can included AGPL
> 3 code.
>
> Very simple.


Oh, no, no, no. Very simple for _you_, with your _simple_ goal of using
ffmpeg and profiting from it by AGPL'ing your component.

But for me, as a maintainer, can I combine GPLv2 with AGPLv3? For example,
can I link a GPLv2 application with a AGPLv3 build of ffmpeg and distribute
the result? Can I link an AGPLv3 build of ffmpeg with a closed-source
application and distribute the result? Can "big" users of ffmpeg, companies
that fund out project (through e.g. GSoC), like, say, Google, use AGPLv3
builds of ffmpeg without a change in their respective requirements for
complying with the license terms?

Or, to say it differently: who profits from AGPLv3 components? FFmpeg? Or
just you? I think it's just you, and that's extremely selfish. It's not in
the best interest of our project to accept AGPLv3 components, it's only in
your self-interest that it be accepted. And _that_'s a fundamental problem.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 5:37 AM, Michael Niedermayer 
wrote:

> On Sun, Apr 03, 2016 at 05:31:25PM -0400, Aaron Boxer wrote:
> > Hi Folks,
> >
> > Here is a small patch to get FFmpeg working with both OpenJPEG master and
> > Grok master, for J2K support.  The comment on the commit has all of the
> > details; the main change is to remove the OPJ_STATIC flag from configure,
> > so that FFmpeg can be configured with a dynamic build of both codecs.
> >
>
> > I also want to reiterate that because FFmpeg can be distributed under GPL
> > v3, and Grok is licensed under the AGPL, there are no licensing issues
> > regarding distributing FFmpeg together with Grok.
>
> FFmpeg support a wide varity of network protools, from low level
> tcp to higher level http, ftp, rtp, rtsp, rtmp, mms, ...
>
> the AGPL requires "if you modify the Program, your modified version must
> prominently offer all users interacting with it remotely through a computer
> network (if your version supports such interaction) an opportunity to
> receive the Corresponding Source of your version by providing access to the
> Corresponding Source from a network server at no charge, through some
> standard or customary means of facilitating copying of software."
>
> yet you here suggest to link AGPL software to GPL where the GPL sw
> will not offer any source though any of its quite numerous network
> interfaces
>
> Iam no lawyer so i dont know if you can do that or not but
> either the combination needs to offer source code through its network
> protocols or you just suggested to circumvent your own licenses main
> point
>
>
Here is clarification from the horse's mouth AKA FSF:

http://www.gnu.org/licenses/gpl-faq.html#AGPLv3CorrespondingSource

Under AGPLv3, when I modify the Program under section 13, what
Corresponding Source does it have to offer? (#AGPLv3CorrespondingSource
)

“Corresponding Source” is defined in section 1 of the license, and you
should provide what it lists. So, if your modified version depends on
libraries under other licenses, such as the Expat license or GPLv3, the
Corresponding Source should include those libraries (unless they are System
Libraries). If you have modified those libraries, you must provide your
modified source code for them.

The last sentence of the first paragraph of section 13 is only meant to
reinforce what most people would have naturally assumed: even though
combinations with code under GPLv3 are handled through a special exception
in section 13, the Corresponding Source should still include the code that
is combined with the Program this way. This sentence does not mean that you
*only* have to provide the source that's covered under GPLv3; instead it
means that such code is *not* excluded from the definition of Corresponding
Source.


In GPLv3 and AGPLv3, what does it mean when it says “notwithstanding any
other provision of this License”? (#v3Notwithstanding
)

This simply means that the following terms prevail over anything else in
the license that may conflict with them. For example, without this text,
some people might have claimed that you could not combine code under GPLv3
with code under AGPLv3, because the AGPL's additional requirements would be
classified as “further restrictions” under section 7 of GPLv3. This text
makes clear that our intended interpretation is the correct one, and you
can make the combination.

This text only resolves conflicts between different terms of the license.
When there is no conflict between two conditions, then you must meet them
both. These paragraphs don't grant you carte blanche to ignore the rest of
the license—instead they're carving out very limited exceptions.
Under AGPLv3, when I modify the Program under section 13, what
Corresponding Source does it have to offer? (#AGPLv3CorrespondingSource
)

“Corresponding Source” is defined in section 1 of the license, and you
should provide what it lists. So, if your modified version depends on
libraries under other licenses, such as the Expat license or GPLv3, the
Corresponding Source should include those libraries (unless they are System
Libraries). If you have modified those libraries, you must provide your
modified source code for them.

The last sentence of the first paragraph of section 13 is only meant to
reinforce what most people would have naturally assumed: even though
combinations with code under GPLv3 are handled through a special exception
in section 13, the Corresponding Source should still include the code that
is combined with the Program this way. This sentence does not mean that you
*only* have to provide the source that's covered under GPLv3; instead it
means that such code is *not* excluded from the definition of Corresponding
Source.

So, if I distribute both GPL 3 and APGL 3 code 

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

Hi Ronald,


On Mon, Apr 4, 2016 at 8:34 AM, Ronald S. Bultje  wrote:

> Hi,
>
> On Mon, Apr 4, 2016 at 7:59 AM, Aaron Boxer  wrote:
>
> > On Mon, Apr 4, 2016 at 7:13 AM, wm4  wrote:
> >
> > > On Sun, 3 Apr 2016 17:31:25 -0400
> > > Aaron Boxer  wrote:
> > >
> > > > Hi Folks,
> > > >
> > > > Here is a small patch to get FFmpeg working with both OpenJPEG master
> > and
> > > > Grok master, for J2K support.  The comment on the commit has all of
> the
> > > > details; the main change is to remove the OPJ_STATIC flag from
> > configure,
> > > > so that FFmpeg can be configured with a dynamic build of both codecs.
> > > >
> > > > I also want to reiterate that because FFmpeg can be distributed under
> > GPL
> > > > v3, and Grok is licensed under the AGPL, there are no licensing
> issues
> > > > regarding distributing FFmpeg together with Grok.
> > > >
> > > > Quoting from Wikipedia:
> > > >
> > > > "By contrast, GPLv3 and AGPLv3 each include clauses (in section 13 of
> > > each
> > > > license) that together achieve a form of mutual compatibility for the
> > two
> > > > licenses. These clauses explicitly allow the "conveying
> > > > " of a work formed by
> > > linking
> > > > code licensed under the one license against code licensed under the
> > other
> > > > license,[3]
> > > > <
> > https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-3
> > > >
> > > > despite the licenses otherwise not allowing relicensing under the
> terms
> > > of
> > > > each other.[4]
> > > > <
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > >
> > > > In this way, the copyleft of each license is relaxed to allow
> > > distributing
> > > > such combinations.[4] "
> > > > <
> > >
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > > >
> > > >
> > > > So, this patch will expand the choice of J2K codecs for all users who
> > use
> > > > FFmpeg under the GPLv3 license.
> > >
> > > AGPL is evil. That alone warrants creating a better, actually free
> > > version of the decoder.
> > >
> >
> > The only difference between AGPL and GPL is the proviso that users
> > connecting to a program using AGPL code
> > must be provided with the full source code for the program. This is to
> > close the loophole in the GPL where
> > someone can take free software, put it in the "cloud", and then treat it
> as
> > closed, non-free software, because they
> > do not have to distribute modifications.
> >
> > Please explain why you think this is a Bad Thing (TM)  ?
>
>
> Because it's a fork, not in the codebase sense but in the licensing sense,
> but the effect is the same. We will not be able to combine multiple
> branches of the fork because each of them is only compatible in its own
> direction - "LGPL code can be merged into AGPL code to create AGPL code"
> but not the other way around.
>
> That is fundamentally unfair for those of us that actually _want_ a
> LGPLv2.1-or-later codebase. Why would you get all our spoils but not the
> other way around?
>

Sorry, I was wrong in my original statements. I've learned a bit more about
how these
licenses work.

This is not a fork. FSF allows GPL 3 and AGPL 3 code to be combined.
If FFmpeg can be distributed according to GPL 3, then it can included AGPL
3 code.

Very simple.

Cheers,
Aaron



>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Ronald S. Bultje]

Hi,

On Mon, Apr 4, 2016 at 7:59 AM, Aaron Boxer  wrote:

> On Mon, Apr 4, 2016 at 7:13 AM, wm4  wrote:
>
> > On Sun, 3 Apr 2016 17:31:25 -0400
> > Aaron Boxer  wrote:
> >
> > > Hi Folks,
> > >
> > > Here is a small patch to get FFmpeg working with both OpenJPEG master
> and
> > > Grok master, for J2K support.  The comment on the commit has all of the
> > > details; the main change is to remove the OPJ_STATIC flag from
> configure,
> > > so that FFmpeg can be configured with a dynamic build of both codecs.
> > >
> > > I also want to reiterate that because FFmpeg can be distributed under
> GPL
> > > v3, and Grok is licensed under the AGPL, there are no licensing issues
> > > regarding distributing FFmpeg together with Grok.
> > >
> > > Quoting from Wikipedia:
> > >
> > > "By contrast, GPLv3 and AGPLv3 each include clauses (in section 13 of
> > each
> > > license) that together achieve a form of mutual compatibility for the
> two
> > > licenses. These clauses explicitly allow the "conveying
> > > " of a work formed by
> > linking
> > > code licensed under the one license against code licensed under the
> other
> > > license,[3]
> > > <
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-3
> > >
> > > despite the licenses otherwise not allowing relicensing under the terms
> > of
> > > each other.[4]
> > > <
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > >
> > > In this way, the copyleft of each license is relaxed to allow
> > distributing
> > > such combinations.[4] "
> > > <
> >
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> > >
> > >
> > > So, this patch will expand the choice of J2K codecs for all users who
> use
> > > FFmpeg under the GPLv3 license.
> >
> > AGPL is evil. That alone warrants creating a better, actually free
> > version of the decoder.
> >
>
> The only difference between AGPL and GPL is the proviso that users
> connecting to a program using AGPL code
> must be provided with the full source code for the program. This is to
> close the loophole in the GPL where
> someone can take free software, put it in the "cloud", and then treat it as
> closed, non-free software, because they
> do not have to distribute modifications.
>
> Please explain why you think this is a Bad Thing (TM)  ?


Because it's a fork, not in the codebase sense but in the licensing sense,
but the effect is the same. We will not be able to combine multiple
branches of the fork because each of them is only compatible in its own
direction - "LGPL code can be merged into AGPL code to create AGPL code"
but not the other way around.

That is fundamentally unfair for those of us that actually _want_ a
LGPLv2.1-or-later codebase. Why would you get all our spoils but not the
other way around?

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 3:39 AM, Tobias Rapp  wrote:

> On 04.04.2016 02:36, Aaron Boxer wrote:
>
>> [...]
>>
> >
>
>> Thanks, Michael. Here is an updated patch with the bpp change removed.
>>
>> Aaron
>>
>> From fb7551a8f9fe6a5317f01c9f33a76f8ae67ad979 Mon Sep 17 00:00:00 2001
>> From: Aaron Boxer 
>> Date: Sun, 3 Apr 2016 20:30:04 -0400
>> Subject: [PATCH] Support the following jpeg 2000 codecs:
>>
>> a) latest release of openjpeg (2.1)
>> b) master branch of openjpeg
>> c) grok (https://github.com/GrokImageCompression/grok)
>>
>> The following changes were made:
>>
>> 1. Removed OPJ_STATIC flag in configure: in master branch of openjpeg and
>> in grok, this flag indicates a static build, so codec API functions are
>> marked as hidden. This prevents FFmpeg from using a dynamic build of these
>> codecs.
>> 2. link to libdl. This is needed by grok, as it supports a plugin
>> architecture that allows plugins to be dynamically loaded at runtime.
>>
>> I have tested these changes with openjpeg 2.1, openjpeg master, and grok
>> master.Test was to make sure ./configure and make showed no errors, and
>> then to decompress a J2K file.  Everything worked for all three
>> configurations, with no errors.
>> ---
>>  configure   | 2 +-
>>  libavcodec/libopenjpegdec.c | 2 +-
>>  libavcodec/libopenjpegenc.c | 2 +-
>>  3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 94a66d8..4e81385 100755
>> --- a/configure
>> +++ b/configure
>> @@ -5561,7 +5561,7 @@ enabled libopencv && { check_header
>> opencv2/core/core_c.h &&
>>   require opencv opencv2/core/core_c.h
>> cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
>> require_pkg_config opencv opencv/cxcore.h
>> cvCreateImageHeader; }
>>  enabled libopenh264   && require_pkg_config openh264
>> wels/codec_api.h WelsGetCodecVersion
>> -enabled libopenjpeg   && { check_lib openjpeg-2.1/openjpeg.h
>> opj_version -lopenjp2 -DOPJ_STATIC ||
>> +enabled libopenjpeg   && { check_lib openjpeg-2.1/openjpeg.h
>> opj_version -lopenjp2 -ldl ||
>>
>
> This breaks (cross-)compilation of FFmpeg and OpenJpeg-2.1 with mingw-64
> on my machine.
>

Thanks, I will take a look.

Cheers,
Aaron
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 5:37 AM, Michael Niedermayer 
wrote:

> On Sun, Apr 03, 2016 at 05:31:25PM -0400, Aaron Boxer wrote:
> > Hi Folks,
> >
> > Here is a small patch to get FFmpeg working with both OpenJPEG master and
> > Grok master, for J2K support.  The comment on the commit has all of the
> > details; the main change is to remove the OPJ_STATIC flag from configure,
> > so that FFmpeg can be configured with a dynamic build of both codecs.
> >
>
> > I also want to reiterate that because FFmpeg can be distributed under GPL
> > v3, and Grok is licensed under the AGPL, there are no licensing issues
> > regarding distributing FFmpeg together with Grok.
>
> FFmpeg support a wide varity of network protools, from low level
> tcp to higher level http, ftp, rtp, rtsp, rtmp, mms, ...
>
> the AGPL requires "if you modify the Program, your modified version must
> prominently offer all users interacting with it remotely through a computer
> network (if your version supports such interaction) an opportunity to
> receive the Corresponding Source of your version by providing access to the
> Corresponding Source from a network server at no charge, through some
> standard or customary means of facilitating copying of software."
>
> yet you here suggest to link AGPL software to GPL where the GPL sw
> will not offer any source though any of its quite numerous network
> interfaces
>
> Iam no lawyer so i dont know if you can do that or not but
> either the combination needs to offer source code through its network
> protocols or you just suggested to circumvent your own licenses main
> point
>
>
The GPL v3 code would continue to be bound by GPL v3,(no need to distribute
source if connected over network) and the AGPL
code would continue to be bound by AGPL (must distribute source if
connected over network)

I will try to get clarification from FSF.

Cheers,
Aaron


>
> >
> > Quoting from Wikipedia:
>
> quoting Wikipedia as well
> https://en.wikipedia.org/wiki/Wikipedia:Legal_disclaimer
>
> WIKIPEDIA DOES NOT GIVE LEGAL OPINIONS
>
> Wikipedia contains articles on many legal topics; however, no warranty
> whatsoever is made that any of the articles are accurate. There is
> absolutely no assurance that any statement contained in an article touching
> on legal matters is true, correct or precise. Law varies from place to
> place and it evolves over time—sometimes quite quickly. Even if a statement
> made about the law is accurate, it may only be accurate in the jurisdiction
> of the person posting the information; as well, the law may have changed,
> been modified or overturned by subsequent development since the entry was
> made on Wikipedia.
>
> The legal information provided on Wikipedia is, at best, of a general
> nature and cannot substitute for the advice of a licensed professional,
> i.e., by a competent authority with specialised knowledge who can apply it
> to the particular circumstances of your case. Please contact a local bar
> association, law society or similar association of jurists in your legal
> jurisdiction to obtain a referral to a competent legal professional if you
> do not have other means of contacting an attorney-at-law, lawyer, civil law
> notary, barrister or solicitor.
>
> Neither the individual contributors, system operators, developers, nor
> sponsors of Wikipedia nor anyone else connected to Wikipedia can take any
> responsibility for the results or consequences of any attempt to use or
> adopt any of the information or disinformation presented on this web site.
>
> Nothing on Wikipedia.org or of any project of Wikimedia Foundation, Inc.,
> should be construed as an attempt to offer or render a legal opinion or
> otherwise engage in the practice of law.
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No great genius has ever existed without some touch of madness. --
> Aristotle
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Mon, Apr 4, 2016 at 7:13 AM, wm4  wrote:

> On Sun, 3 Apr 2016 17:31:25 -0400
> Aaron Boxer  wrote:
>
> > Hi Folks,
> >
> > Here is a small patch to get FFmpeg working with both OpenJPEG master and
> > Grok master, for J2K support.  The comment on the commit has all of the
> > details; the main change is to remove the OPJ_STATIC flag from configure,
> > so that FFmpeg can be configured with a dynamic build of both codecs.
> >
> > I also want to reiterate that because FFmpeg can be distributed under GPL
> > v3, and Grok is licensed under the AGPL, there are no licensing issues
> > regarding distributing FFmpeg together with Grok.
> >
> > Quoting from Wikipedia:
> >
> > "By contrast, GPLv3 and AGPLv3 each include clauses (in section 13 of
> each
> > license) that together achieve a form of mutual compatibility for the two
> > licenses. These clauses explicitly allow the "conveying
> > " of a work formed by
> linking
> > code licensed under the one license against code licensed under the other
> > license,[3]
> >  >
> > despite the licenses otherwise not allowing relicensing under the terms
> of
> > each other.[4]
> > <
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> >
> > In this way, the copyleft of each license is relaxed to allow
> distributing
> > such combinations.[4] "
> > <
> https://en.wikipedia.org/wiki/Affero_General_Public_License#cite_note-fsf2-4
> >
> >
> > So, this patch will expand the choice of J2K codecs for all users who use
> > FFmpeg under the GPLv3 license.
>
> AGPL is evil. That alone warrants creating a better, actually free
> version of the decoder.
>

The only difference between AGPL and GPL is the proviso that users
connecting to a program using AGPL code
must be provided with the full source code for the program. This is to
close the loophole in the GPL where
someone can take free software, put it in the "cloud", and then treat it as
closed, non-free software, because they
do not have to distribute modifications.

Please explain why you think this is a Bad Thing (TM)  ?




> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[wm4]

On Sun, 3 Apr 2016 17:31:25 -0400
Aaron Boxer  wrote:

> Hi Folks,
> 
> Here is a small patch to get FFmpeg working with both OpenJPEG master and
> Grok master, for J2K support.  The comment on the commit has all of the
> details; the main change is to remove the OPJ_STATIC flag from configure,
> so that FFmpeg can be configured with a dynamic build of both codecs.
> 
> I also want to reiterate that because FFmpeg can be distributed under GPL
> v3, and Grok is licensed under the AGPL, there are no licensing issues
> regarding distributing FFmpeg together with Grok.
> 
> Quoting from Wikipedia:
> 
> "By contrast, GPLv3 and AGPLv3 each include clauses (in section 13 of each
> license) that together achieve a form of mutual compatibility for the two
> licenses. These clauses explicitly allow the "conveying
> " of a work formed by linking
> code licensed under the one license against code licensed under the other
> license,[3]
> 
> despite the licenses otherwise not allowing relicensing under the terms of
> each other.[4]
> 
> In this way, the copyleft of each license is relaxed to allow distributing
> such combinations.[4] "
> 
> 
> So, this patch will expand the choice of J2K codecs for all users who use
> FFmpeg under the GPLv3 license.

AGPL is evil. That alone warrants creating a better, actually free
version of the decoder.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Michael Niedermayer]

On Sun, Apr 03, 2016 at 05:31:25PM -0400, Aaron Boxer wrote:
> Hi Folks,
> 
> Here is a small patch to get FFmpeg working with both OpenJPEG master and
> Grok master, for J2K support.  The comment on the commit has all of the
> details; the main change is to remove the OPJ_STATIC flag from configure,
> so that FFmpeg can be configured with a dynamic build of both codecs.
> 

> I also want to reiterate that because FFmpeg can be distributed under GPL
> v3, and Grok is licensed under the AGPL, there are no licensing issues
> regarding distributing FFmpeg together with Grok.

FFmpeg support a wide varity of network protools, from low level
tcp to higher level http, ftp, rtp, rtsp, rtmp, mms, ...

the AGPL requires "if you modify the Program, your modified version must 
prominently offer all users interacting with it remotely through a computer 
network (if your version supports such interaction) an opportunity to receive 
the Corresponding Source of your version by providing access to the 
Corresponding Source from a network server at no charge, through some standard 
or customary means of facilitating copying of software."

yet you here suggest to link AGPL software to GPL where the GPL sw
will not offer any source though any of its quite numerous network
interfaces

Iam no lawyer so i dont know if you can do that or not but
either the combination needs to offer source code through its network
protocols or you just suggested to circumvent your own licenses main
point


> 
> Quoting from Wikipedia:

quoting Wikipedia as well
https://en.wikipedia.org/wiki/Wikipedia:Legal_disclaimer

WIKIPEDIA DOES NOT GIVE LEGAL OPINIONS

Wikipedia contains articles on many legal topics; however, no warranty 
whatsoever is made that any of the articles are accurate. There is absolutely 
no assurance that any statement contained in an article touching on legal 
matters is true, correct or precise. Law varies from place to place and it 
evolves over time—sometimes quite quickly. Even if a statement made about the 
law is accurate, it may only be accurate in the jurisdiction of the person 
posting the information; as well, the law may have changed, been modified or 
overturned by subsequent development since the entry was made on Wikipedia.

The legal information provided on Wikipedia is, at best, of a general nature 
and cannot substitute for the advice of a licensed professional, i.e., by a 
competent authority with specialised knowledge who can apply it to the 
particular circumstances of your case. Please contact a local bar association, 
law society or similar association of jurists in your legal jurisdiction to 
obtain a referral to a competent legal professional if you do not have other 
means of contacting an attorney-at-law, lawyer, civil law notary, barrister or 
solicitor.

Neither the individual contributors, system operators, developers, nor sponsors 
of Wikipedia nor anyone else connected to Wikipedia can take any responsibility 
for the results or consequences of any attempt to use or adopt any of the 
information or disinformation presented on this web site.

Nothing on Wikipedia.org or of any project of Wikimedia Foundation, Inc., 
should be construed as an attempt to offer or render a legal opinion or 
otherwise engage in the practice of law.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Tobias Rapp]

On 04.04.2016 02:36, Aaron Boxer wrote:

[...]

>

Thanks, Michael. Here is an updated patch with the bpp change removed.

Aaron

From fb7551a8f9fe6a5317f01c9f33a76f8ae67ad979 Mon Sep 17 00:00:00 2001
From: Aaron Boxer 
Date: Sun, 3 Apr 2016 20:30:04 -0400
Subject: [PATCH] Support the following jpeg 2000 codecs:

a) latest release of openjpeg (2.1)
b) master branch of openjpeg
c) grok (https://github.com/GrokImageCompression/grok)

The following changes were made:

1. Removed OPJ_STATIC flag in configure: in master branch of openjpeg and in 
grok, this flag indicates a static build, so codec API functions are marked as 
hidden. This prevents FFmpeg from using a dynamic build of these codecs.
2. link to libdl. This is needed by grok, as it supports a plugin architecture 
that allows plugins to be dynamically loaded at runtime.

I have tested these changes with openjpeg 2.1, openjpeg master, and grok 
master.Test was to make sure ./configure and make showed no errors, and then to 
decompress a J2K file.  Everything worked for all three configurations, with no 
errors.
---
 configure   | 2 +-
 libavcodec/libopenjpegdec.c | 2 +-
 libavcodec/libopenjpegenc.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 94a66d8..4e81385 100755
--- a/configure
+++ b/configure
@@ -5561,7 +5561,7 @@ enabled libopencv && { check_header opencv2/core/core_c.h 
&&
  require opencv opencv2/core/core_c.h 
cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
require_pkg_config opencv opencv/cxcore.h 
cvCreateImageHeader; }
 enabled libopenh264   && require_pkg_config openh264 wels/codec_api.h 
WelsGetCodecVersion
-enabled libopenjpeg   && { check_lib openjpeg-2.1/openjpeg.h opj_version 
-lopenjp2 -DOPJ_STATIC ||
+enabled libopenjpeg   && { check_lib openjpeg-2.1/openjpeg.h opj_version 
-lopenjp2 -ldl ||


This breaks (cross-)compilation of FFmpeg and OpenJpeg-2.1 with mingw-64 
on my machine.



check_lib openjpeg-2.0/openjpeg.h opj_version 
-lopenjp2 -DOPJ_STATIC ||
check_lib openjpeg-1.5/openjpeg.h opj_version 
-lopenjpeg -DOPJ_STATIC ||
check_lib openjpeg.h opj_version -lopenjpeg 
-DOPJ_STATIC ||
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 65167e6..f116c8b 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -24,7 +24,7 @@
  * JPEG 2000 decoder using libopenjpeg
  */

-#define  OPJ_STATIC
+

 #include "libavutil/common.h"
 #include "libavutil/imgutils.h"
diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
index 56c8219..e55 100644
--- a/libavcodec/libopenjpegenc.c
+++ b/libavcodec/libopenjpegenc.c
@@ -24,7 +24,7 @@
  * JPEG 2000 encoder using libopenjpeg
  */

-#define  OPJ_STATIC
+

 #include "libavutil/avassert.h"
 #include "libavutil/common.h"
--
2.6.3.windows.1



Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

On Sun, Apr 3, 2016 at 7:02 PM, Michael Bradshaw  wrote:

> Tested with OpenJPEG 1.5, 2.0, and 2.1 on OS X with clang. Correctly
> decoded and re-encoded the balloon.jp2 sample.
>

Thanks for testing.



>
> On Sun, Apr 3, 2016 at 2:34 PM, Aaron Boxer  wrote:
> > From d12c685578f21b403f6c03505edd84db367306c5 Mon Sep 17 00:00:00 2001
> > From: Aaron Boxer 
> > Date: Sun, 27 Mar 2016 00:15:20 -0400
> > Subject: [PATCH] Support the following jpeg 2000 codecs:
> >
> > a) latest release of openjpeg (2.1)
> > b) master branch of openjpeg
> > c) grok (https://github.com/GrokImageCompression/grok)
>
> I'm curious what others think: if Grok requires FFmpeg to use GPLv3,
> should an explicit check be added in ./configure to require
> --enable-gpl --enable-version3? Or should the check not be added,
> since FFmpeg is expecting the OpenJPEG library and the user is
> replacing it with something else, so the onus is on them to remember
> to add those flags when configuring?
>

We could add an --enable=libgrok option that would essentially configure
for openjpeg 2.1
but add   --enable-gpl --enable-version3 .  I don't want to presume that I
can have my own configure
setting at this stage :) but it would make this explicit for the user.


>  #include "libavutil/avassert.h"
> >  #include "libavutil/common.h"
> > @@ -276,7 +276,6 @@ static opj_image_t *mj2_create_image(AVCodecContext
> *avctx, opj_cparameters_t *p
> >
> >  for (i = 0; i < numcomps; i++) {
> >  cmptparm[i].prec = desc->comp[i].depth;
> > -cmptparm[i].bpp  = desc->comp[i].depth;
>
> bpp is needed by opj_j2k_is_cinema_compliant in OpenJPEG 2.1. I'd
> rather not remove this line.
>


Thanks, Michael. Here is an updated patch with the bpp change removed.

Aaron


0001-Support-the-following-jpeg-2000-codecs.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Michael Bradshaw]

Tested with OpenJPEG 1.5, 2.0, and 2.1 on OS X with clang. Correctly
decoded and re-encoded the balloon.jp2 sample.

On Sun, Apr 3, 2016 at 2:34 PM, Aaron Boxer  wrote:
> From d12c685578f21b403f6c03505edd84db367306c5 Mon Sep 17 00:00:00 2001
> From: Aaron Boxer 
> Date: Sun, 27 Mar 2016 00:15:20 -0400
> Subject: [PATCH] Support the following jpeg 2000 codecs:
>
> a) latest release of openjpeg (2.1)
> b) master branch of openjpeg
> c) grok (https://github.com/GrokImageCompression/grok)

I'm curious what others think: if Grok requires FFmpeg to use GPLv3,
should an explicit check be added in ./configure to require
--enable-gpl --enable-version3? Or should the check not be added,
since FFmpeg is expecting the OpenJPEG library and the user is
replacing it with something else, so the onus is on them to remember
to add those flags when configuring?

>
> The following changes were made:
>
> 1. Removed bpp (redundant as this information is already stored in precision)
> 2. Removed OPJ_STATIC flag in configure: in master branch of openjpeg and in 
> grok, this flag indicates a static build, so codec API functions are marked 
> as hidden. This prevents FFmpeg from using a dynamic build of these codecs.
> 3. link to libdl. This is needed by grok, as it supports a plugin 
> architecture that allows plugins to be dynamically loaded at runtime.
>
> I have tested these changes with openjpeg 2.1, openjpeg master, and grok 
> master.Test was to make sure ./configure and make showed no errors, and then 
> to decompress a J2K file.  Everything worked for all three configurations, 
> with no errors.
> ---
>  configure   | 2 +-
>  libavcodec/libopenjpegdec.c | 2 +-
>  libavcodec/libopenjpegenc.c | 3 +--
>  3 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/configure b/configure
> index 94a66d8..4e81385 100755
> --- a/configure
> +++ b/configure
> @@ -5561,7 +5561,7 @@ enabled libopencv && { check_header 
> opencv2/core/core_c.h &&
>   require opencv opencv2/core/core_c.h 
> cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
> require_pkg_config opencv opencv/cxcore.h 
> cvCreateImageHeader; }
>  enabled libopenh264   && require_pkg_config openh264 wels/codec_api.h 
> WelsGetCodecVersion
> -enabled libopenjpeg   && { check_lib openjpeg-2.1/openjpeg.h opj_version 
> -lopenjp2 -DOPJ_STATIC ||
> +enabled libopenjpeg   && { check_lib openjpeg-2.1/openjpeg.h opj_version 
> -lopenjp2 -ldl ||
> check_lib openjpeg-2.0/openjpeg.h opj_version 
> -lopenjp2 -DOPJ_STATIC ||
> check_lib openjpeg-1.5/openjpeg.h opj_version 
> -lopenjpeg -DOPJ_STATIC ||
> check_lib openjpeg.h opj_version -lopenjpeg 
> -DOPJ_STATIC ||
> diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
> index 65167e6..f116c8b 100644
> --- a/libavcodec/libopenjpegdec.c
> +++ b/libavcodec/libopenjpegdec.c
> @@ -24,7 +24,7 @@
>   * JPEG 2000 decoder using libopenjpeg
>   */
>
> -#define  OPJ_STATIC
> +
>
>  #include "libavutil/common.h"
>  #include "libavutil/imgutils.h"
> diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
> index 56c8219..720eda0 100644
> --- a/libavcodec/libopenjpegenc.c
> +++ b/libavcodec/libopenjpegenc.c
> @@ -24,7 +24,7 @@
>   * JPEG 2000 encoder using libopenjpeg
>   */
>
> -#define  OPJ_STATIC
> +
>
>  #include "libavutil/avassert.h"
>  #include "libavutil/common.h"
> @@ -276,7 +276,6 @@ static opj_image_t *mj2_create_image(AVCodecContext 
> *avctx, opj_cparameters_t *p
>
>  for (i = 0; i < numcomps; i++) {
>  cmptparm[i].prec = desc->comp[i].depth;
> -cmptparm[i].bpp  = desc->comp[i].depth;

bpp is needed by opj_j2k_is_cinema_compliant in OpenJPEG 2.1. I'd
rather not remove this line.

>  cmptparm[i].sgnd = 0;
>  cmptparm[i].dx = sub_dx[i];
>  cmptparm[i].dy = sub_dy[i];
> --
> 2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

Hi Folks,

Here is a small patch to get FFmpeg working with both OpenJPEG master and
Grok master, for J2K support.  The comment on the commit has all of the
details; the main change is to remove the OPJ_STATIC flag from configure,
so that FFmpeg can be configured with a dynamic build of both codecs.

I also want to reiterate that because FFmpeg can be distributed under GPL
v3, and Grok is licensed under the AGPL, there are no licensing issues
regarding distributing FFmpeg together with Grok.

Quoting from Wikipedia:

"By contrast, GPLv3 and AGPLv3 each include clauses (in section 13 of each
license) that together achieve a form of mutual compatibility for the two
licenses. These clauses explicitly allow the "conveying
" of a work formed by linking
code licensed under the one license against code licensed under the other
license,[3]

despite the licenses otherwise not allowing relicensing under the terms of
each other.[4]

In this way, the copyleft of each license is relaxed to allow distributing
such combinations.[4] "


So, this patch will expand the choice of J2K codecs for all users who use
FFmpeg under the GPLv3 license.

Kind Regards,
Aaron



Cheers,
Aaron
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Support master branch of OpenJPEG and Grok J2K codecs

[Aaron Boxer]

woops, forgot to attach the patch.

On Sun, Apr 3, 2016 at 5:31 PM, Aaron Boxer  wrote:

> Hi Folks,
>
> Here is a small patch to get FFmpeg working with both OpenJPEG master and
> Grok master, for J2K support.  The comment on the commit has all of the
> details; the main change is to remove the OPJ_STATIC flag from configure,
> so that FFmpeg can be configured with a dynamic build of both codecs.
>
> I also want to reiterate that because FFmpeg can be distributed under GPL
> v3, and Grok is licensed under the AGPL, there are no licensing issues
> regarding distributing FFmpeg together with Grok.
>
> Quoting from Wikipedia:
>
> "By contrast, GPLv3 and AGPLv3 each include clauses (in section 13 of each
> license) that together achieve a form of mutual compatibility for the two
> licenses. These clauses explicitly allow the "conveying
> " of a work formed by linking
> code licensed under the one license against code licensed under the other
> license,[3]
> 
> despite the licenses otherwise not allowing relicensing under the terms of
> each other.[4]
> 
> In this way, the copyleft of each license is relaxed to allow distributing
> such combinations.[4] "
> 
>
> So, this patch will expand the choice of J2K codecs for all users who use
> FFmpeg under the GPLv3 license.
>
> Kind Regards,
> Aaron
>
>
>
> Cheers,
> Aaron
>
>
From d12c685578f21b403f6c03505edd84db367306c5 Mon Sep 17 00:00:00 2001
From: Aaron Boxer 
Date: Sun, 27 Mar 2016 00:15:20 -0400
Subject: [PATCH] Support the following jpeg 2000 codecs:

a) latest release of openjpeg (2.1)
b) master branch of openjpeg
c) grok (https://github.com/GrokImageCompression/grok)

The following changes were made:

1. Removed bpp (redundant as this information is already stored in precision)
2. Removed OPJ_STATIC flag in configure: in master branch of openjpeg and in grok, this flag indicates a static build, so codec API functions are marked as hidden. This prevents FFmpeg from using a dynamic build of these codecs.
3. link to libdl. This is needed by grok, as it supports a plugin architecture that allows plugins to be dynamically loaded at runtime.

I have tested these changes with openjpeg 2.1, openjpeg master, and grok master.Test was to make sure ./configure and make showed no errors, and then to decompress a J2K file.  Everything worked for all three configurations, with no errors.
---
 configure   | 2 +-
 libavcodec/libopenjpegdec.c | 2 +-
 libavcodec/libopenjpegenc.c | 3 +--
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index 94a66d8..4e81385 100755
--- a/configure
+++ b/configure
@@ -5561,7 +5561,7 @@ enabled libopencv && { check_header opencv2/core/core_c.h &&
  require opencv opencv2/core/core_c.h cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
require_pkg_config opencv opencv/cxcore.h cvCreateImageHeader; }
 enabled libopenh264   && require_pkg_config openh264 wels/codec_api.h WelsGetCodecVersion
-enabled libopenjpeg   && { check_lib openjpeg-2.1/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC ||
+enabled libopenjpeg   && { check_lib openjpeg-2.1/openjpeg.h opj_version -lopenjp2 -ldl ||
check_lib openjpeg-2.0/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC ||
check_lib openjpeg-1.5/openjpeg.h opj_version -lopenjpeg -DOPJ_STATIC ||
check_lib openjpeg.h opj_version -lopenjpeg -DOPJ_STATIC ||
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 65167e6..f116c8b 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -24,7 +24,7 @@
  * JPEG 2000 decoder using libopenjpeg
  */
 
-#define  OPJ_STATIC
+
 
 #include "libavutil/common.h"
 #include "libavutil/imgutils.h"
diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
index 56c8219..720eda0 100644
--- a/libavcodec/libopenjpegenc.c
+++ b/libavcodec/libopenjpegenc.c
@@ -24,7 +24,7 @@
  * JPEG 2000 encoder using libopenjpeg
  */
 
-#define  OPJ_STATIC
+
 
 #include "libavutil/avassert.h"
 #include "libavutil/common.h"
@@ -276,7 +276,6 @@ static opj_image_t *mj2_create_image(AVCodecContext *avctx, opj_cparameters_t *p
 
 for (i = 0; i < numcomps; i++) {
 cmptparm[i].prec = desc->comp[i].depth;
-cmptparm[i].bpp  = desc->comp[i].depth;
 cmptparm[i].sgnd = 0;
 cmptparm[i].dx = sub_dx[i];
 cmptparm[i].dy = sub_dy[i];
-- 
2.5.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel