On Mon, 22 Jun 2015 12:07:24 -0400 "[email protected]" <[email protected]> wrote: > On Mon, Jun 22, 2015 at 11:54 AM, Rodrigo Pereira > <[email protected]> wrote: > > I don't understand any advantages of put a device driver code in > > secret. Someone can explain the advantage of a secret device > > driver? Maybe is about money. They want to license the code to some > > company and charge money for that. In case I want to buy the source > > code, how much this will cost? > > There are many reasons for keeping device drivers code secret...
I am answering, not to oppose this points, but because i believe that this answer should be complemented in the context of allwinner's video engine. That has been in the focus of this discussions. So here goes. > 1) You believe you have an innovative hardware implementation and are > protecting it via trade secret. Releasing the driver source code will > provide register definitions and an understanding of how the hardware > works. Competitors will see this and copy your hardware. Register definitions, which in large part have been already Reverse Engineered by the people involved in the Cedrus effort, that had started 2 years ago and which results can be seen in the wiki for everyone that wants to see. http://linux-sunxi.org/VE_Register_guide What little is still missing is only a question of priorities and needs, because as everyone can see, this information was and is more than enough for the creation of a working vdpau implementation. http://linux-sunxi.org/Cedrus https://github.com/linux-sunxi/libvdpau-sunxi There is nothing to hide. > > 2) Your hardware implementation is violating patents or you are afraid > that people will sue you for patent infringement even when you aren't. > Closed source makes it much hard for trolls to launch a patent suit. This patent trolls will not be very successful if they can be stopped by close source software, or are the patent trolls too greed to paid someone to look for targets. This video engine was already successful reverse engineered, where it was found that this video engine hardware is of fixed-function-kind. Meaning that everything (the codec) are done by the hardware in the silicon die. The software driver task in only one of feeding the hardware. All the secrets or patenta are in the hardware, and not in the software. > 3) You have licensed third party code for use in your device driver > and you don't have the ability to open source. The third party that > wrote this code wants to sell it multiple times so they refuse to open > source. Common example -- lighting or physic engines in GPU drivers. Then here, the solution is to rewrite what can not be open-sourced, and as this video engine is very simples, this is not difficult task. As can be seen, by the current cedarx driver, which is a rewrite. > > 4) You are afraid competitors with similar hardware will take the > source you have worked hard to write, modify a few lines, and have a > free driver for their hardware. Free, like taking the linux kernel source and the android kernel source, and modify to add support for the some particular socs. Or by taking some LGPL license source code and include in a video engine driver. > > 5) Your hardware is really messed up and almost broken. These warts > are embarrassing and you hide the work arounds in closed source. Actually, this video engine is not bad. It has some (hardware) limitations, but this has been improving in newer versions, and up to now, i only found one undefined (maybe better to say unexpected because should not happen in normal use) This to say, that this video engine hardware is very well behaved, whatever can be writing to registers or whatever state the hardware get into, can always be recovered from. > 6) You licensed the IP for the hardware. As part of the IP licensing > agreement you are required to keep the register definitions closed. Register definitions that are already here, http://linux-sunxi.org/VE_Register_guide which everyone can see, that there isn't anything to hide. > 7) Your secret driver code is violating someone's copyright. Like the copyright of open source software developers that published source code under a (L)GPL license. > > and so on..... > > > > > > > Em segunda-feira, 22 de junho de 2015 09:19:54 UTC-3, Luc Verhaegen > > escreveu: > >> > >> Hi, > >> > >> It's been a month since Allwinners big "open source" release, > >> where they tried to shut up the big (and very justified) GPL > >> violations noise by releasing some code which moves decoder codecs > >> into modules, and by releasing some codecs as open source as well. > >> As i predicted then, Allwinner now has taken the next step: > >> > >> They produced a binary for the decoder, which is loaded in: > >> > >> https://github.com/allwinner-zh/media-codec/blob/72f2b8537/sunxi-cedarx/SOURCE/vencoder/venc_device.c > >> > >> Note the "Proprietary" license notice on top of this and other new > >> files. > >> > >> Even if we ignore the past, all of this is built together with > >> LGPLed code, and the binary is being dlopened into this LGPLed > >> code. Quite illegally so. > >> > >> This is further deliberate avoidance of responsibility by > >> Allwinner. One can only assume that Allwinner is incorrigible at > >> this point. They have been told time and time again what is wrong > >> and they have time and time again been given possible ways out, in > >> great detail. All we get though, is microsteps to take off the > >> heat, followed by further deliberate breaking/bending of the rules. > >> > >> This also sheds a further shadow on the C.H.I.P. project. Clearly > >> the Next Thing Co. guys were very gullible when they went into > >> business with Allwinner (and believed the statements made by > >> allwinner). Later during the run of the kickstarter campaign, > >> after all the noise had been made on the internet about GPL > >> Violations, Next Thing Co. loudly claimed that they are working > >> the Free Electrons and that all promises of open sourceness and > >> such would be kept (all?). While this move in itself was very > >> laudable, it did underline the fact that Next Thing Co. had not > >> done its homework beforehand. Now Allwinner does this, which > >> clearly goes in against everything the Next Thing Co. people have > >> promised us so far... > >> > >> Allwinner has some explaining to do (as does Next Thing Co, to a > >> lesser extent). > >> > >> 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 [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.
