[alsa-devel] Question about the correct license to use with debugfs in SOF
Hi Greg,
Can I please bother you with you quick question about the right license to use for the debug.c file in the SOF directory?
Currently, it is dual licensed with GPLv2.0 and BSD. But Pierre brought up a concern about this conflicting with all the exports in the file being GPLv2.0. Should this be fixed to change the license to GPLv2.0 only? Appreciate your help in this regard.
Thanks, Ranjani
On Wed, Jan 29, 2020 at 09:04:06AM -0800, Sridharan, Ranjani wrote:
Hi Greg,
Can I please bother you with you quick question about the right license to use for the debug.c file in the SOF directory?
What is "SOF"?
Currently, it is dual licensed with GPLv2.0 and BSD. But Pierre brought up a concern about this conflicting with all the exports in the file being GPLv2.0. Should this be fixed to change the license to GPLv2.0 only? Appreciate your help in this regard.
Why ask a developer a legal question, don't you all have a whole huge legal department who knows all of this type of thing really really well?
Would you ask a programmer a medical question?
That being said, think about trying to justify the existance of a BSD licensed file trying to access gpl-only symbols, why in the world would this even be a question? Why have it dual licensed at all when I was told that Intel was NOT going to do this anymore for any kernel code?
bah,
greg k-h
On Wed, Jan 29, 2020 at 11:00 AM Greg KH gregkh@linuxfoundation.org wrote:
On Wed, Jan 29, 2020 at 09:04:06AM -0800, Sridharan, Ranjani wrote:
Hi Greg,
Can I please bother you with you quick question about the right license
to
use for the debug.c file in the SOF directory?
What is "SOF"?
Its Sound Open Firmware in the sound/soc/sof dir
Currently, it is dual licensed with GPLv2.0 and BSD. But Pierre brought
up
a concern about this conflicting with all the exports in the file being GPLv2.0. Should this be fixed to change the license to GPLv2.0 only? Appreciate your help in this regard.
Why ask a developer a legal question, don't you all have a whole huge legal department who knows all of this type of thing really really well?
Would you ask a programmer a medical question?
That being said, think about trying to justify the existance of a BSD licensed file trying to access gpl-only symbols, why in the world would this even be a question? Why have it dual licensed at all when I was told that Intel was NOT going to do this anymore for any kernel code?
Thanks for your patience and clarification. We discovered the discrepancy while vetting the licenses in the files again. Something we should be a bit more careful about moving forward. Sorry for the trouble!
Ranjani
Currently, it is dual licensed with GPLv2.0 and BSD. But Pierre brought
up
a concern about this conflicting with all the exports in the file being GPLv2.0. Should this be fixed to change the license to GPLv2.0 only? Appreciate your help in this regard.
Why ask a developer a legal question, don't you all have a whole huge legal department who knows all of this type of thing really really well?
Would you ask a programmer a medical question?
That being said, think about trying to justify the existance of a BSD licensed file trying to access gpl-only symbols, why in the world would this even be a question? Why have it dual licensed at all when I was told that Intel was NOT going to do this anymore for any kernel code?
Thanks for your patience and clarification. We discovered the discrepancy while vetting the licenses in the files again. Something we should be a bit more careful about moving forward. Sorry for the trouble!
Indeed it's not our intention to use dual-licensing for debugfs at all.
Please treat this thread as a desire to be transparent with maintainers about a miss rather than an evil scheme to work around GPL.
Ranjani and I discovered the issue only a couple of hours ago while moving code around. I don't have any explanation for this other than a review oversight where we saw the EXPORT_SYMBOL_GPL and not the SPDX line. It's a mistake, not a feature.
I just checked the history and all the changes were made by Intel, except for your change "ASoC: SOF: no need to check return value of debugfs_create functions", and 2 minor other fixes for memory leaks.
We'll immediately change the license to GPLv2 only, move the code in a dedicated module that's GPLv2 only, and scan the rest of the Intel-contributed parts to make sure we don't have this mistake in other places.
Thanks -Pierre
On Wed, Jan 29, 2020 at 01:41:34PM -0600, Pierre-Louis Bossart wrote:
Currently, it is dual licensed with GPLv2.0 and BSD. But Pierre brought
up
a concern about this conflicting with all the exports in the file being GPLv2.0. Should this be fixed to change the license to GPLv2.0 only? Appreciate your help in this regard.
Why ask a developer a legal question, don't you all have a whole huge legal department who knows all of this type of thing really really well?
Would you ask a programmer a medical question?
That being said, think about trying to justify the existance of a BSD licensed file trying to access gpl-only symbols, why in the world would this even be a question? Why have it dual licensed at all when I was told that Intel was NOT going to do this anymore for any kernel code?
Thanks for your patience and clarification. We discovered the discrepancy while vetting the licenses in the files again. Something we should be a bit more careful about moving forward. Sorry for the trouble!
Indeed it's not our intention to use dual-licensing for debugfs at all.
Please treat this thread as a desire to be transparent with maintainers about a miss rather than an evil scheme to work around GPL.
Ranjani and I discovered the issue only a couple of hours ago while moving code around. I don't have any explanation for this other than a review oversight where we saw the EXPORT_SYMBOL_GPL and not the SPDX line. It's a mistake, not a feature.
I just checked the history and all the changes were made by Intel, except for your change "ASoC: SOF: no need to check return value of debugfs_create functions", and 2 minor other fixes for memory leaks.
We'll immediately change the license to GPLv2 only, move the code in a dedicated module that's GPLv2 only, and scan the rest of the Intel-contributed parts to make sure we don't have this mistake in other places.
Don't create a new module, unless your lawyers say you have to do so. That way lies madness...
Why is this code dual-licensed in the first place anyway? It only will work on Linux, right?
Anyway, I thought Intel had stopped doing this, just changing the license on the one file should be sufficient for now. But again, I am not your lawyer, go talk to yours before doing anything.
thanks,
greg k-h
participants (3)
-
Greg KH -
Pierre-Louis Bossart -
Sridharan, Ranjani