> From: allwinner-zh <[email protected]> > Date: 26 June 2015 08:00:21 CEST > To: allwinner-zh/media-codec <[email protected]> > Subject: Re: [media-codec] Unsuitable copyright text in some source code > files (#8) > Reply-To: allwinner-zh/media-codec > <reply+002e3f92e1b2be6b9fa6e059976cde198b80b04e41a5c0e592cf0000000111a4ac7592a169ce0568e...@reply.github.com> > > Thank you very much for your constructive suggestion, it has been fixed. > > — > Reply to this email directly or view it on GitHub. >
Clement > On 25 Jun 2015, at 17:12, Julian Calaby <[email protected]> wrote: > > Hi Simos, > > On Thu, Jun 25, 2015 at 7:56 PM, 'Simos Xenitellis' via linux-sunxi > <[email protected]> wrote: >> Let's dissect. > > Yes, let's dissect. > >>> On Wed, Jun 24, 2015 at 11:56 PM, Andrés Domínguez <[email protected]> >>> wrote: >>> 2015-06-24 21:25 GMT+02:00 Simos Xenitellis <[email protected]>: >>>> >>>> If something needs to get fixed in those repositories >>>> (https://github.com/allwinner-zh/), >>>> point it out constructively. >>> >>> Sorry, I didn't make the infringement statement and I don't know about it, >>> but >>> knowing about allwinner's past behavior and libv it's clear that it has some >>> credibility. >> >> Here you say "it's clear" for a reference to _past behaviour_, while a >> more appropriate >> wording would be "I assume". You *assume* it has some credibility. > > Allwinner's past behaviour is very clear. They release stuff without > checking that it complies with the license they release it under then > appear to ignore it (or at least don't communicate) when the > community, us, rightly complains. > > As for libv, arguably he's just the messenger here, the person who > shouts the loudest about this. The fact that he keeps shouting this > message when things don't change is commendable. > > And you know what, he's right: GPL violations are serious business and > ignoring them is simply not a viable strategy for anyone involved. Luc > has been consistently right on this subject from the very beginning, > that's credibility. > >> You also use the term "past behavior", which is a term that probably >> means a different thing >> to each recipient of these emails. It is not constructive to use such >> terms; in those >> TV shows that depict family problems, you get to see family members picking >> on each other for things that happened in the past, remaining stuck >> perpetually >> for that other thing in the past. > > I outlined the behaviour I, and a lot of other people, perceive from > companies like Allwinner in my previous email. Again, it's very clear. > > Are you saying that we shouldn't argue about serious legal issues > because they happened in the past? Yet you attack Luc for the things > he's done in the past. What exactly are you trying to argue here? > > So maybe you're trying to argue that we should focus less on the past > and more on the future. Focusing less on the past isn't going to > happen. These are, again, serious legal issues, they're not going to > just go away. As for focusing on the future, we've made it very clear > what we want from Allwinner: (L)GPL compliant code to replace the > binary blobs they keep releasing. Very simple. > >>> What I criticized was your non constructive attitude with libv >>> just because you don't like their way to say things, instead of explaining >>> why >>> do you think that you are right and others are wrong. >> >> My point has been that if there are things in the repository that >> should be fixed, >> then point them out and explain them. > > This isn't just about some little changes in a repository. This is > about a systematic company practice of violating the licence > agreements the software their continued existence is built on. > > As far as I know, every single SoC they've produced since the A10 has > had GPL issues. _Every_ one. There's a saying: "Once is happenstance. > Twice is coincidence. The third time it's enemy action." We've seen > this happen for ~9 different products. This is not a coincidence any > more. > >>> And no, saying that >>> header files are easy to fix (it seems that you don't understand that >>> changing >>> license text is not enough, but also fulfilling with the LGPL conditions, >>> like >>> releasing source code) don't matter in this topic. About "Such cases occur >>> frequently with many companies" (I doubt it) is sad if true. >> >> Let's see a recent case. >> It's about the MediaTek kernel for the bq E4.5 phone Ubuntu Edition, >> and the post was written by Carsten Munk, >> http://mer-project.blogspot.gr/2015/03/some-doubts-about-gpl-licensing-and-bq.html >> Phoronix covered it with style, >> https://www.phoronix.com/scan.php?page=news_item&px=BQ-Ubuntu-Phone-Bad-Kernel >> It was about header files and here is the commit that fixed it, >> https://github.com/bq/aquaris-E4.5/commit/34cf494bca625acad06274c3cba10aca148813c0 > > You're missing the forest for the trees: the point is that code with > proprietary licenses shouldn't have been released in the first place. > It might be easy to change, the point was that the change didn't > happen before it left their hands. > > In the case of the BQ Ubuntu phone issue, a company released thousands > of lines of code and got a couple of bits wrong. In our case we're > looking at a source release that touched 29 files. 9 were added with > unusable headers: that's 1/3 of the files they touched and almost 70% > of the code they released. This sort of thing doesn't happen by > accident. This was deliberate. Also, it was almost a week ago, if it's > such a small change, why hasn't it been made? > >> The way I see the whole situation is this: It is true that Allwinner >> did not make effort over the years >> for mainline Linux kernel support. Whatever support is there for the >> A10, A13, A20, etc, >> is the result of the hard work of this community. Working on mainline >> support is initially expensive >> in terms of resources but builds an ecosystem and opens up markets. It >> makes business sense. > > So where are they? As far as I'm aware, we have _no_ upstream > contributions from Allwinner whatsoever. The only things they've > released have been source trees with licence issues or badly written > board support on top of ancient kernels. > >> As a community, we need to figure out what we need from Allwinner. >> Do we need specific SoC information so that we do the mainline effort >> on our own? And among all things that can be asked, >> we prioritize to those that are really needed at the moment. >> Do we need Allwinner to fund some developers so that they work >> full-time on this? We would need to start talking about goals and >> targets. > > It's obvious what is required: > 1. Datasheets > 2. Programming manuals > 3. GPL compliant drivers > 4. (L)GPL compliant userspace stuff > > and maybe > > 5. Some on-going contribution to the community > > They have #1 and #2 but aren't bothering to release them to us. I > believe most of the documentation we have has been obtained through > third parties. #3 is almost happening, but with just about every code > release, there's something in there violating the licence. We're > arguing over their lack of ability on #4 and their employees (with the > possible exception of Kevin, who pops up every so often to announce > something) are absent from the community. This isn't hard, there are > thousands of companies doing it. > > Thanks, > > -- > Julian Calaby > > Email: [email protected] > Profile: http://www.google.com/profiles/julian.calaby/ > > -- > 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
