Hello Greg, Thanks for answering and I will comment below, please continue reading.
On Fri, Jan 21, 2011 at 16:10, Greg KH <[email protected]> wrote: > > Why are you asking legal questions on a developer mailing list? > There is a miss understand here. I do not want legal advice at all. > Please contact a lawyer and work with them on this issue. > No, it is a technical question, for one developer to another. What I originally intended was to hear from developers what can be done instead of use sysFS or if there is another way. The fact is, driver already exist and is in use out the market. I am assuming it is totally legal and that someone cares about this fact. What I just want to do is keep it as it is now. If use sysFS makes it not compile or not compliant with GPL I do not want to go that way, it is not what I am supposed to do. > Note, the GPL does not prohibit releasing patent-covered code at all, > this is done quite often, and the Linux kernel itself has lots of patent > covered code in it, and everything is just fine. > I totally agree with you and am aware BUT I am not patent neither copyright holder. I have no rights to do this. This is not my business. > > All kernel code must be released under the GPL, so there's not really > a "if I use this function or not" type thing going on, sorry. > Here is somehow an answer to my question. If all is GPL so my assumption of driver legality is wrong but I am not (and probably neither you) a lawyer then I wise approach would be not go this way. Let's talk about other paths: This discussion started due the change of a read permission in the /dev/device_name file. Someone here strongly believe that others read permission to any device driver is prohibited by Google CTS policy. Personally I did not see that written neither have this understand from reading the compatibility document. So my question now is: Is it true that anyone reads permission to a device file is prohibited by CTS policy? How does this would lead to a security breach? thanks in advance Regards. Benito. -- unsubscribe: [email protected] website: http://groups.google.com/group/android-kernel
