I have communicated with the author of source code of libvdecoder.so.
The code has been rewrote completely, has no relationship with FFmpeg,
except some function names. This is a silly mistake, but maybe it's true.
Does anybody know how to prove that?

If the LGPL violations of libvdecoder.so can be cleaned up, how can we use
the shared library on open source sunxi kernel, and even mainline kernel?
I don't what's the low level part in the kernel that libvdecoder.so depends
on,
a thin VPU driver and some special memory management modules? If those
parts can be solved, does the cedar + openmax + gstreamor openmax plugin
workable?

On Tue, Mar 10, 2015 at 11:01 PM, Luc Verhaegen <l...@skynet.be> wrote:

> On Tue, Mar 10, 2015 at 01:38:30PM +0000, Manuel Braga wrote:
> > Hi,
> >
> > That was a joke mail, in response to the joke that allwinner gave us
> > when allwinner added the LGPL license to source code that includes a
> > binary accused of being in noncompliance.
>
> This was not a joke email. Its contents was very serious, and it should
> be interpreted as such. Allwinner needs/needed to know what it had just
> done, and that it has to fullfill its obligations.
>
> The fact that I did so, _after_ the facts had been often and openly
> discussed, and after allwinner had been explained their obligations
> countless times, does make it less than serious.
>
> The contents however is nothing to be laughed about.
>
> > > try to get the support of something like the SFC so that they can
> > > evaluate the merits of pursuing.
> > > And then the SFC would do the talking.
> >
> > I heared (but don't have the details), and this looks to be true. SFC
> > or someone from SFC is aware of this issue. But maybe others can make
> > this more clear.
> >
> > But nobody is here to sue, (why do i have to keep saying this)
> > i think  i can speak for all and say that we want to resolve this in a
> > friendly way, but for that, there most be dialog between parties.
> > Not excuse to ignore the issues.
> >
> > And Simos look at the news, with SFC and vmware, look at the time it
> > took and no result.
>
> People tried talking to VMWare for 7-8 years. We have been trying to
> talk to Allwinner at least since 2012 (i am sure that LKCL would be
> happy to divulge his conversations with allwinner if it comes to legal
> action). Allwinners case is pretty open and shut, especially since they
> actively use both the kernel and uboot, and the symbols in cedar are
> clearly visible. And unlike VMWare Allwinner has its _whole_ business to
> lose.
>
> When there is any legal action, it could be a lot swifter. Perhaps
> Allwinner should act quickly and do so in an all encompassing way. If
> not, it stands to lose quite a lot.
>
> Luc Verhaegen.
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to