msdk: license exception for gstmsdkvpputil.h and gstmsdkvpputil.c

According to https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/blob/master/sys/msdk/README, gst-msdk is licensed under BSD-3, however gstmsdkvpputil.h (https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/blob/master/sys/msdk/gstmsdkvpputil.h) and gstmsdkvpputil.c (https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/blob/master/sys/msdk/gstmsdkvpputil.c) include LGPL header. Is it OK to add an exception for gstmsdkvpputil.h and gstmsdkvpputil.c in README? @vjaquez @sree @tpm

changed the description

As I mentioned in the other issue, I think the README should just go away.

Maybe we have to adjust the effective license announced in the plugin description though?

Plugin description or the license field ? I think the question is how to avoid the conflict of gstmsdkvpputils.{h,c} which were inherited from gst-plugins-base (lgpl) -> gstreamer-vaapi(lgpl) -> gstmsdk (bsd).

@sree @tpm Yes, the question is how to avoid the license conflict in gst-msdk.

mentioned in merge request !111 (closed)

I don't really understand what the problem is that you're seeing and what you hope to achieve by adding a 'license exception'.

I am not a lawyer, but I don't think there is any "conflict" here? It's just that because the plugin contains LGPL code the effective license will be LGPL. But people can still copy'n'paste and use the BSD licensed code parts elsewhere under the BSD license if they wanted to. I don't think anything you add to the README file or to the other BSD-licensed source files will change that. The only way to change it is to replace the LGPL licensed code or get it relicensed?

Per my understanding, gst-msdk was licensed under BSD-3, so it should not include LGPL code, however gstmsdkvpputils.{h,c} in gst-msdk were inherited from some LGPL code. which is the conflict I think. Did you mean gst-msdk automatically became a LGPL plugin since gstmsdkvpputils.{h,c} were checked in?

Did you mean gst-msdk automatically became a LGPL plugin since gstmsdkvpputils.{h,c} were checked in?

Something like that (though the source code bits that are BSD stay BSD of course).

If you want this plugin to be BSD-3 licensed you need to remove the LGPL code bits and rewrite them, or get them relicensed from whoever wrote them.

@tpm @vjaquez @sree Currently 'gst-inpect-1.0 msdk' shows the license is bsd, so we should change it to LGPL if we don't want to remove the two files, right? I may submit a MR to change it if you agree.

@tpm @vjaquez @sree Currently 'gst-inpect-1.0 msdk' shows the license is bsd, so we should change it to LGPL if we don't want to remove the two files, right? I may submit a MR to change it if you agree.

looks the right thing to do

and remove the README

mentioned in commit haihao/gst-plugins-bad@067bc87c

mentioned in merge request !246 (merged)

@tpm @vjaquez @sree I submitted !246 (merged) for this issue, could you help to review the MR?

mentioned in commit haihao/gst-plugins-bad@440c91fc

mentioned in commit haihao/gst-plugins-bad@44bdffc6

mentioned in commit haihao/gst-plugins-bad@2e3022c5

closed via commit 2e3022c5

Just for the record the initial aim for gst-msdk code release at Oblong was to release it as LGPL but we were requested from some Intel related people to make it BSD-3.

It's not a problem for us either way. If someone really cares, they can rewrite the LGPL bits of the code and then the effective license would be BSD again.

@adn770 just an extra clarification, this change is about the plugin licence, as there is a mixture of BSD and LGPL, the plugin as a whole has to be shipped under the LGPL, so the meta data is being updated to clarify this. Otherwise has @tpm said, someone could contribute a rewrite. Though, I don't think we have ever refused code in specific plugins because it was LGPLv2, it would be extremely strange. So it is likely that in the long term, unless we write a specific rule for this plugin it will become LGPLv2 due to external contributors.