Wow!! "Search and Replace" is not the same as coming clean from license violations!
Do you really believe that one could do: a) Replace all strings, b) replace all function name and claim they're now good ? People are smarter than that! On Tuesday, March 10, 2015 at 11:32:28 AM UTC-5, Zhao Zhili wrote: > > 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 <li...@skynet.be > <javascript:>> 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...@googlegroups.com <javascript:>. >> 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.
