Caution: EXT Email
On Tue, Dec 20, 2022 at 07:39:52PM +0530, Manjunatha Venkatesh wrote:
On 11/30/2022 12:57 PM, Greg KH wrote:And I need a tangable _reason_ why a dual license is needed here.
Caution: EXT EmailSorry for the delayed response,further we will make sure address the review
On Wed, Nov 30, 2022 at 09:10:08AM +0530, Manjunatha Venkatesh wrote:
On 9/14/2022 8:23 PM, Greg KH wrote:Note, originally you all were "rushed" to get this accepted, and now
this took 2 1/2 months to respond back to a code review? Something is
wrong here, when responding so late, almost all context is lost :(
comments ASAP.
As part of Version6 patch submission signed-off by NXP corporate lawyerWe need a signed-off-by on the patch itself.Caution: EXT EmailDual-license is signed-off by NXP corporate lawyer.
On Wed, Sep 14, 2022 at 07:59:44PM +0530, Manjunatha Venkatesh wrote:
+++ b/drivers/misc/nxp-sr1xx.cPlease no. If you really want to dual-license your Linux kernel code,
@@ -0,0 +1,794 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
that's fine, but I will insist that you get a signed-off-by from your
corporate lawyer so that I know that they agree with this and are
willing to handle all of the complex issues that this entails as it will
require work on their side over time.
If that's not worth bothering your lawyers over, please just stick with
GPL as the only license.
updated
Our corporate lawyer suggested to use this dual license for NXP UWB product.Though, we would like to understand what complex issues which requireI am not a lawyer and can not advise you of this, please work with yours
work over the time?
to set into place the requirements you will have to keep this working
properly. Note, it is not trivial, and will require work on your end.
I will push back again, and ask "Why?" Why do you want this dual
licensed? What is driving that requirement and what will having it
licensed like this enable you to do that having it just under GPL-2.0
will not?
Remember, dual licensing takes from the community and does not give
back, so justifications for why this is required is essencial if you
wish for people to at the very least, review your code...
And the code there shows that you did not write the kernel sideNXP UWB user space code available at below shared path.You all have ways of posting code publicly :)We will move ioctl command definitions into user space header file as part+#define SR1XX_SET_PWR _IOW(SR1XX_MAGIC, 0x01, long)You can't stick ioctl command definitions in a .c file that userspace
+#define SR1XX_SET_FWD _IOW(SR1XX_MAGIC, 0x02, long)
never sees. How are your userspace tools supposed to know what the
ioctl is and how it is defined?
of our next patch submission.
How was this ever tested and where is your userspace code that interactsWe will share the corresponding user space code soon,meanwhile can you
with this code?
please suggest how to share this user space code?
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNXP%2Fuwb-driver-testapp&data=05%7C01%7Cmanjunatha.venkatesh%40nxp.com%7C999fcbfc998c42d4ae5708dae296be78%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638071434311303825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1Z4h8OUd%2BM%2Fy5dnVoiBioS1%2FbR4Rqul8tW7OB%2FPCRqI%3D&reserved=0
correctly :(
Please fix it all up for your next submission.
thanks,
greg k-h