* drm core/helpers and MIT license
@ 2019-11-12 15:03 Daniel Vetter
2019-11-12 15:03 ` Daniel Vetter
` (3 more replies)
0 siblings, 4 replies; 8+ messages in thread
From: Daniel Vetter @ 2019-11-12 15:03 UTC (permalink / raw)
To: dri-devel, intel-gfx, amd-gfx list, VMware Graphics,
Alex Deucher, Joonas Lahtinen, Rodrigo Vivi, Nikula, Jani,
Thomas Hellstrom, Christian König
Hi all,
Dave and me chatted about this last week on irc. Essentially we have:
$ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/*c'
drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_damage_helper.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
drivers/gpu/drm/drm_dp_cec.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_edid_load.c:// SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_fb_cma_helper.c:// SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_format_helper.c:/* SPDX-License-Identifier: GPL-2.0 */
drivers/gpu/drm/drm_gem_cma_helper.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_gem_framebuffer_helper.c://
SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_gem_shmem_helper.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_gem_ttm_helper.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_gem_vram_helper.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_hdcp.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_lease.c:// SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_mipi_dbi.c:// SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_of.c:// SPDX-License-Identifier: GPL-2.0-only
drivers/gpu/drm/drm_simple_kms_helper.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_sysfs.c:// SPDX-License-Identifier: GPL-2.0-only
drivers/gpu/drm/drm_vma_manager.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
drivers/gpu/drm/drm_vram_helper_common.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_writeback.c:// SPDX-License-Identifier: GPL-2.0
One is GPL+MIT, so ok, and one is a default GPL-only header from
Greg's infamous patch (so could probably be changed to MIT license
header). I only looked at .c sources, since headers are worse wrt
having questionable default headers. So about 18 files with clear GPL
licenses thus far in drm core/helpers.
Looking at where that code came from, it is mostly from GPL-only
drivers (we have a lot of those nowadays), so seems legit non-MIT
licensed. Question is now what do we do:
- Nothing, which means GPL will slowly encroach on drm core/helpers,
which is roughly the same as ...
- Throw in the towel on MIT drm core officially. Same as above, except
lets just make it official.
- Try to counter this, which means at least a) relicensing a bunch of
stuff b) rewriting a bunch of stuff c) making sure that's ok with
everyone, there's a lot of GPL-by-default for the kernel (that's how
we got most of the above code through merged drivers I think). I
suspect that whomever cares will need to put in the work to make this
happen (since it will need a pile of active resistance at least).
Cc maintainers/driver teams who might care most about this.
Also if people could cc *bsd, they probably care and I don't know best
contacts for graphics stuff (or anything else really at all).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* drm core/helpers and MIT license
2019-11-12 15:03 drm core/helpers and MIT license Daniel Vetter
@ 2019-11-12 15:03 ` Daniel Vetter
2019-11-14 8:43 ` Simon Ser
` (2 subsequent siblings)
3 siblings, 0 replies; 8+ messages in thread
From: Daniel Vetter @ 2019-11-12 15:03 UTC (permalink / raw)
To: dri-devel, intel-gfx, amd-gfx list, VMware Graphics,
Alex Deucher, Joonas Lahtinen, Rodrigo Vivi, Nikula, Jani,
Thomas Hellstrom, Christian König
Hi all,
Dave and me chatted about this last week on irc. Essentially we have:
$ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/*c'
drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_damage_helper.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
drivers/gpu/drm/drm_dp_cec.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_edid_load.c:// SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_fb_cma_helper.c:// SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_format_helper.c:/* SPDX-License-Identifier: GPL-2.0 */
drivers/gpu/drm/drm_gem_cma_helper.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_gem_framebuffer_helper.c://
SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_gem_shmem_helper.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_gem_ttm_helper.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_gem_vram_helper.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_hdcp.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_lease.c:// SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_mipi_dbi.c:// SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_of.c:// SPDX-License-Identifier: GPL-2.0-only
drivers/gpu/drm/drm_simple_kms_helper.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_sysfs.c:// SPDX-License-Identifier: GPL-2.0-only
drivers/gpu/drm/drm_vma_manager.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
drivers/gpu/drm/drm_vram_helper_common.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_writeback.c:// SPDX-License-Identifier: GPL-2.0
One is GPL+MIT, so ok, and one is a default GPL-only header from
Greg's infamous patch (so could probably be changed to MIT license
header). I only looked at .c sources, since headers are worse wrt
having questionable default headers. So about 18 files with clear GPL
licenses thus far in drm core/helpers.
Looking at where that code came from, it is mostly from GPL-only
drivers (we have a lot of those nowadays), so seems legit non-MIT
licensed. Question is now what do we do:
- Nothing, which means GPL will slowly encroach on drm core/helpers,
which is roughly the same as ...
- Throw in the towel on MIT drm core officially. Same as above, except
lets just make it official.
- Try to counter this, which means at least a) relicensing a bunch of
stuff b) rewriting a bunch of stuff c) making sure that's ok with
everyone, there's a lot of GPL-by-default for the kernel (that's how
we got most of the above code through merged drivers I think). I
suspect that whomever cares will need to put in the work to make this
happen (since it will need a pile of active resistance at least).
Cc maintainers/driver teams who might care most about this.
Also if people could cc *bsd, they probably care and I don't know best
contacts for graphics stuff (or anything else really at all).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: drm core/helpers and MIT license
2019-11-12 15:03 drm core/helpers and MIT license Daniel Vetter
2019-11-12 15:03 ` Daniel Vetter
@ 2019-11-14 8:43 ` Simon Ser
2019-11-14 8:43 ` Simon Ser
[not found] ` <CAKMK7uH-8+tbKsAoiChsxELEc_77RVVxP2wapHWhqB+0Viifog-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-16 12:12 ` Emmanuel Vadot
3 siblings, 1 reply; 8+ messages in thread
From: Simon Ser @ 2019-11-14 8:43 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Hellstrom, intel-gfx, amd-gfx list, zeising,
VMware Graphics, dri-devel, Rodrigo Vivi, Christian König
Adding zeising@FreeBSD.org for FreeBSD. I'll try to see if I can ping
some NetBSD/OpenBSD folks too.
On Tuesday, November 12, 2019 4:03 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Hi all,
>
> Dave and me chatted about this last week on irc. Essentially we have:
>
> $ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/c'
> drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_damage_helper.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
> drivers/gpu/drm/drm_dp_cec.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_edid_load.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_fb_cma_helper.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_format_helper.c:/ SPDX-License-Identifier: GPL-2.0 */drivers/gpu/drm/drm_gem_cma_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_framebuffer_helper.c://
> SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_shmem_helper.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_gem_ttm_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_vram_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_hdcp.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_lease.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_mipi_dbi.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_of.c:// SPDX-License-Identifier: GPL-2.0-only
> drivers/gpu/drm/drm_simple_kms_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_sysfs.c:// SPDX-License-Identifier: GPL-2.0-only
> drivers/gpu/drm/drm_vma_manager.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
> drivers/gpu/drm/drm_vram_helper_common.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_writeback.c:// SPDX-License-Identifier: GPL-2.0
>
> One is GPL+MIT, so ok, and one is a default GPL-only header from
> Greg's infamous patch (so could probably be changed to MIT license
> header). I only looked at .c sources, since headers are worse wrt
> having questionable default headers. So about 18 files with clear GPL
> licenses thus far in drm core/helpers.
>
> Looking at where that code came from, it is mostly from GPL-only
> drivers (we have a lot of those nowadays), so seems legit non-MIT
> licensed. Question is now what do we do:
>
> - Nothing, which means GPL will slowly encroach on drm core/helpers,
> which is roughly the same as ...
>
> - Throw in the towel on MIT drm core officially. Same as above, except
> lets just make it official.
>
> - Try to counter this, which means at least a) relicensing a bunch of
> stuff b) rewriting a bunch of stuff c) making sure that's ok with
> everyone, there's a lot of GPL-by-default for the kernel (that's how
> we got most of the above code through merged drivers I think). I
> suspect that whomever cares will need to put in the work to make this
> happen (since it will need a pile of active resistance at least).
>
> Cc maintainers/driver teams who might care most about this.
>
> Also if people could cc *bsd, they probably care and I don't know best
> contacts for graphics stuff (or anything else really at all).
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
>
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: drm core/helpers and MIT license
2019-11-14 8:43 ` Simon Ser
@ 2019-11-14 8:43 ` Simon Ser
0 siblings, 0 replies; 8+ messages in thread
From: Simon Ser @ 2019-11-14 8:43 UTC (permalink / raw)
To: Daniel Vetter
Cc: Nikula, Jani, Thomas Hellstrom, intel-gfx, Joonas Lahtinen,
amd-gfx list, zeising, VMware Graphics, dri-devel, Rodrigo Vivi,
Alex Deucher, Christian König
Adding zeising@FreeBSD.org for FreeBSD. I'll try to see if I can ping
some NetBSD/OpenBSD folks too.
On Tuesday, November 12, 2019 4:03 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Hi all,
>
> Dave and me chatted about this last week on irc. Essentially we have:
>
> $ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/c'
> drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_damage_helper.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
> drivers/gpu/drm/drm_dp_cec.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_edid_load.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_fb_cma_helper.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_format_helper.c:/ SPDX-License-Identifier: GPL-2.0 */drivers/gpu/drm/drm_gem_cma_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_framebuffer_helper.c://
> SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_shmem_helper.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_gem_ttm_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_vram_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_hdcp.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_lease.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_mipi_dbi.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_of.c:// SPDX-License-Identifier: GPL-2.0-only
> drivers/gpu/drm/drm_simple_kms_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_sysfs.c:// SPDX-License-Identifier: GPL-2.0-only
> drivers/gpu/drm/drm_vma_manager.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
> drivers/gpu/drm/drm_vram_helper_common.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_writeback.c:// SPDX-License-Identifier: GPL-2.0
>
> One is GPL+MIT, so ok, and one is a default GPL-only header from
> Greg's infamous patch (so could probably be changed to MIT license
> header). I only looked at .c sources, since headers are worse wrt
> having questionable default headers. So about 18 files with clear GPL
> licenses thus far in drm core/helpers.
>
> Looking at where that code came from, it is mostly from GPL-only
> drivers (we have a lot of those nowadays), so seems legit non-MIT
> licensed. Question is now what do we do:
>
> - Nothing, which means GPL will slowly encroach on drm core/helpers,
> which is roughly the same as ...
>
> - Throw in the towel on MIT drm core officially. Same as above, except
> lets just make it official.
>
> - Try to counter this, which means at least a) relicensing a bunch of
> stuff b) rewriting a bunch of stuff c) making sure that's ok with
> everyone, there's a lot of GPL-by-default for the kernel (that's how
> we got most of the above code through merged drivers I think). I
> suspect that whomever cares will need to put in the work to make this
> happen (since it will need a pile of active resistance at least).
>
> Cc maintainers/driver teams who might care most about this.
>
> Also if people could cc *bsd, they probably care and I don't know best
> contacts for graphics stuff (or anything else really at all).
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
>
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: drm core/helpers and MIT license
[not found] ` <CAKMK7uH-8+tbKsAoiChsxELEc_77RVVxP2wapHWhqB+0Viifog-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2019-11-15 15:38 ` Alex Deucher
2019-11-15 15:38 ` Alex Deucher
0 siblings, 1 reply; 8+ messages in thread
From: Alex Deucher @ 2019-11-15 15:38 UTC (permalink / raw)
To: Daniel Vetter
Cc: Nikula, Jani, Thomas Hellstrom, intel-gfx, Joonas Lahtinen,
amd-gfx list, VMware Graphics, dri-devel, Rodrigo Vivi,
Christian König
On Tue, Nov 12, 2019 at 10:03 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> Hi all,
>
> Dave and me chatted about this last week on irc. Essentially we have:
>
> $ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/*c'
> drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_damage_helper.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
> drivers/gpu/drm/drm_dp_cec.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_edid_load.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_fb_cma_helper.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_format_helper.c:/* SPDX-License-Identifier: GPL-2.0 */
> drivers/gpu/drm/drm_gem_cma_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_framebuffer_helper.c://
> SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_shmem_helper.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_gem_ttm_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_vram_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_hdcp.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_lease.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_mipi_dbi.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_of.c:// SPDX-License-Identifier: GPL-2.0-only
> drivers/gpu/drm/drm_simple_kms_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_sysfs.c:// SPDX-License-Identifier: GPL-2.0-only
> drivers/gpu/drm/drm_vma_manager.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
> drivers/gpu/drm/drm_vram_helper_common.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_writeback.c:// SPDX-License-Identifier: GPL-2.0
>
> One is GPL+MIT, so ok, and one is a default GPL-only header from
> Greg's infamous patch (so could probably be changed to MIT license
> header). I only looked at .c sources, since headers are worse wrt
> having questionable default headers. So about 18 files with clear GPL
> licenses thus far in drm core/helpers.
>
> Looking at where that code came from, it is mostly from GPL-only
> drivers (we have a lot of those nowadays), so seems legit non-MIT
> licensed. Question is now what do we do:
>
> - Nothing, which means GPL will slowly encroach on drm core/helpers,
> which is roughly the same as ...
>
> - Throw in the towel on MIT drm core officially. Same as above, except
> lets just make it official.
>
> - Try to counter this, which means at least a) relicensing a bunch of
> stuff b) rewriting a bunch of stuff c) making sure that's ok with
> everyone, there's a lot of GPL-by-default for the kernel (that's how
> we got most of the above code through merged drivers I think). I
> suspect that whomever cares will need to put in the work to make this
> happen (since it will need a pile of active resistance at least).
>
I'd like to try and keep as much MIT as possible. I'd be willing to
help with the re-licensing effort.
Alex
> Cc maintainers/driver teams who might care most about this.
>
> Also if people could cc *bsd, they probably care and I don't know best
> contacts for graphics stuff (or anything else really at all).
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: drm core/helpers and MIT license
2019-11-15 15:38 ` Alex Deucher
@ 2019-11-15 15:38 ` Alex Deucher
0 siblings, 0 replies; 8+ messages in thread
From: Alex Deucher @ 2019-11-15 15:38 UTC (permalink / raw)
To: Daniel Vetter
Cc: Nikula, Jani, Thomas Hellstrom, intel-gfx, Joonas Lahtinen,
amd-gfx list, VMware Graphics, dri-devel, Rodrigo Vivi,
Christian König
On Tue, Nov 12, 2019 at 10:03 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> Hi all,
>
> Dave and me chatted about this last week on irc. Essentially we have:
>
> $ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/*c'
> drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_damage_helper.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
> drivers/gpu/drm/drm_dp_cec.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_edid_load.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_fb_cma_helper.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_format_helper.c:/* SPDX-License-Identifier: GPL-2.0 */
> drivers/gpu/drm/drm_gem_cma_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_framebuffer_helper.c://
> SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_shmem_helper.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_gem_ttm_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_vram_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_hdcp.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_lease.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_mipi_dbi.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_of.c:// SPDX-License-Identifier: GPL-2.0-only
> drivers/gpu/drm/drm_simple_kms_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_sysfs.c:// SPDX-License-Identifier: GPL-2.0-only
> drivers/gpu/drm/drm_vma_manager.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
> drivers/gpu/drm/drm_vram_helper_common.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_writeback.c:// SPDX-License-Identifier: GPL-2.0
>
> One is GPL+MIT, so ok, and one is a default GPL-only header from
> Greg's infamous patch (so could probably be changed to MIT license
> header). I only looked at .c sources, since headers are worse wrt
> having questionable default headers. So about 18 files with clear GPL
> licenses thus far in drm core/helpers.
>
> Looking at where that code came from, it is mostly from GPL-only
> drivers (we have a lot of those nowadays), so seems legit non-MIT
> licensed. Question is now what do we do:
>
> - Nothing, which means GPL will slowly encroach on drm core/helpers,
> which is roughly the same as ...
>
> - Throw in the towel on MIT drm core officially. Same as above, except
> lets just make it official.
>
> - Try to counter this, which means at least a) relicensing a bunch of
> stuff b) rewriting a bunch of stuff c) making sure that's ok with
> everyone, there's a lot of GPL-by-default for the kernel (that's how
> we got most of the above code through merged drivers I think). I
> suspect that whomever cares will need to put in the work to make this
> happen (since it will need a pile of active resistance at least).
>
I'd like to try and keep as much MIT as possible. I'd be willing to
help with the re-licensing effort.
Alex
> Cc maintainers/driver teams who might care most about this.
>
> Also if people could cc *bsd, they probably care and I don't know best
> contacts for graphics stuff (or anything else really at all).
>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: drm core/helpers and MIT license
2019-11-12 15:03 drm core/helpers and MIT license Daniel Vetter
` (2 preceding siblings ...)
[not found] ` <CAKMK7uH-8+tbKsAoiChsxELEc_77RVVxP2wapHWhqB+0Viifog-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2019-11-16 12:12 ` Emmanuel Vadot
2019-11-16 12:12 ` Emmanuel Vadot
3 siblings, 1 reply; 8+ messages in thread
From: Emmanuel Vadot @ 2019-11-16 12:12 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Hellstrom, intel-gfx, amd-gfx list, VMware Graphics,
dri-devel, Rodrigo Vivi, Christian König
Hi Daniel,
On Tue, 12 Nov 2019 16:03:33 +0100
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Hi all,
>
> Dave and me chatted about this last week on irc. Essentially we have:
>
> $ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/*c'
> drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_damage_helper.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
> drivers/gpu/drm/drm_dp_cec.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_edid_load.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_fb_cma_helper.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_format_helper.c:/* SPDX-License-Identifier: GPL-2.0 */
> drivers/gpu/drm/drm_gem_cma_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_framebuffer_helper.c://
> SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_shmem_helper.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_gem_ttm_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_vram_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_hdcp.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_lease.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_mipi_dbi.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_of.c:// SPDX-License-Identifier: GPL-2.0-only
> drivers/gpu/drm/drm_simple_kms_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_sysfs.c:// SPDX-License-Identifier: GPL-2.0-only
> drivers/gpu/drm/drm_vma_manager.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
> drivers/gpu/drm/drm_vram_helper_common.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_writeback.c:// SPDX-License-Identifier: GPL-2.0
>
> One is GPL+MIT, so ok, and one is a default GPL-only header from
> Greg's infamous patch (so could probably be changed to MIT license
> header). I only looked at .c sources, since headers are worse wrt
> having questionable default headers. So about 18 files with clear GPL
> licenses thus far in drm core/helpers.
>
> Looking at where that code came from, it is mostly from GPL-only
> drivers (we have a lot of those nowadays), so seems legit non-MIT
> licensed. Question is now what do we do:
>
> - Nothing, which means GPL will slowly encroach on drm core/helpers,
> which is roughly the same as ...
>
> - Throw in the towel on MIT drm core officially. Same as above, except
> lets just make it official.
>
> - Try to counter this, which means at least a) relicensing a bunch of
> stuff b) rewriting a bunch of stuff c) making sure that's ok with
> everyone, there's a lot of GPL-by-default for the kernel (that's how
> we got most of the above code through merged drivers I think). I
> suspect that whomever cares will need to put in the work to make this
> happen (since it will need a pile of active resistance at least).
>
> Cc maintainers/driver teams who might care most about this.
>
> Also if people could cc *bsd, they probably care and I don't know best
> contacts for graphics stuff (or anything else really at all).
>
> Cheers, Daniel
First of all thanks for sending this mail.
I'm of course not speaking for the whole FreeBSD project but being
one of the persons that is currently trying to finish a clean update of
DRM for it to finally have DRM drivers for arm/arm64 here is my view :
I would love to have all the helper MIT or dual licence so I don't
need to comment part of DRM code (which is ok on some part but wrong on
most) or re-implement them. There is already too much code that really
need a rewrite for FreeBSD (dma-bufs, syncobjs and a lot of others linux
kernel subsystems) that adding drm helpers to the list makes it really
hard for me.
From the list you've send here are the most problematic files for me,
for now I've simply not import them and hack around the code that calls
functions from them :
drivers/gpu/drm/drm_client.c It's now really tied into the drm
subsystem so it's hard to ignore it, for now not merging the latest
patches from 5.4 makes it ok-ish to ignore it.
drivers/gpu/drm/drm_lease.c I can hack around it but I would prefer to
include it and stop my hacks.
drivers/gpu/drm/drm_format_helper.c a lot of helpers are here and
needed, for now I'm using the old functions that were MIT licenced but
it's kinda wrong to do it this way.
For the gem_cma/gem_framebuffer/gem_etc ... we have our own
implementation when we need one, those file are too close to the vm
subsystem to be portable anyway so I don't really care if they stay
GPLed.
For the rest of the files either I don't want them (_sysfs and _of for
example) because it don't make sense for us to have them (sysfs) or the
subsystem is too different between FreeBSD-Linux (of) or I the current
drivers that we have don't need them for now (writeback, hdcp etc ...)
To finish this mail, I'd like to say that I would love to contribute
to DRM and some drivers (lima/panfrost mostly) but for now I need to
keep in sync with Linux and finish my work so I can commit it into the
FreeBSD kernel. Knowing that future updates will be easier for me
because of a licence issue would be great to know otherwise I think
that all the available time that I have for DRM on FreeBSD will be 100%
rewritting compatibility layers.
Cheers,
--
Emmanuel Vadot <manu@bidouilliste.com>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: drm core/helpers and MIT license
2019-11-16 12:12 ` Emmanuel Vadot
@ 2019-11-16 12:12 ` Emmanuel Vadot
0 siblings, 0 replies; 8+ messages in thread
From: Emmanuel Vadot @ 2019-11-16 12:12 UTC (permalink / raw)
To: Daniel Vetter
Cc: Nikula, Jani, Thomas Hellstrom, intel-gfx, Joonas Lahtinen,
amd-gfx list, VMware Graphics, dri-devel, Rodrigo Vivi,
Alex Deucher, Christian König
Hi Daniel,
On Tue, 12 Nov 2019 16:03:33 +0100
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Hi all,
>
> Dave and me chatted about this last week on irc. Essentially we have:
>
> $ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/*c'
> drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_damage_helper.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
> drivers/gpu/drm/drm_dp_cec.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_edid_load.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_fb_cma_helper.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_format_helper.c:/* SPDX-License-Identifier: GPL-2.0 */
> drivers/gpu/drm/drm_gem_cma_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_framebuffer_helper.c://
> SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_shmem_helper.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_gem_ttm_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_gem_vram_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_hdcp.c:// SPDX-License-Identifier: GPL-2.0
> drivers/gpu/drm/drm_lease.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_mipi_dbi.c:// SPDX-License-Identifier: GPL-2.0-or-later
> drivers/gpu/drm/drm_of.c:// SPDX-License-Identifier: GPL-2.0-only
> drivers/gpu/drm/drm_simple_kms_helper.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_sysfs.c:// SPDX-License-Identifier: GPL-2.0-only
> drivers/gpu/drm/drm_vma_manager.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
> drivers/gpu/drm/drm_vram_helper_common.c:// SPDX-License-Identifier:
> GPL-2.0-or-later
> drivers/gpu/drm/drm_writeback.c:// SPDX-License-Identifier: GPL-2.0
>
> One is GPL+MIT, so ok, and one is a default GPL-only header from
> Greg's infamous patch (so could probably be changed to MIT license
> header). I only looked at .c sources, since headers are worse wrt
> having questionable default headers. So about 18 files with clear GPL
> licenses thus far in drm core/helpers.
>
> Looking at where that code came from, it is mostly from GPL-only
> drivers (we have a lot of those nowadays), so seems legit non-MIT
> licensed. Question is now what do we do:
>
> - Nothing, which means GPL will slowly encroach on drm core/helpers,
> which is roughly the same as ...
>
> - Throw in the towel on MIT drm core officially. Same as above, except
> lets just make it official.
>
> - Try to counter this, which means at least a) relicensing a bunch of
> stuff b) rewriting a bunch of stuff c) making sure that's ok with
> everyone, there's a lot of GPL-by-default for the kernel (that's how
> we got most of the above code through merged drivers I think). I
> suspect that whomever cares will need to put in the work to make this
> happen (since it will need a pile of active resistance at least).
>
> Cc maintainers/driver teams who might care most about this.
>
> Also if people could cc *bsd, they probably care and I don't know best
> contacts for graphics stuff (or anything else really at all).
>
> Cheers, Daniel
First of all thanks for sending this mail.
I'm of course not speaking for the whole FreeBSD project but being
one of the persons that is currently trying to finish a clean update of
DRM for it to finally have DRM drivers for arm/arm64 here is my view :
I would love to have all the helper MIT or dual licence so I don't
need to comment part of DRM code (which is ok on some part but wrong on
most) or re-implement them. There is already too much code that really
need a rewrite for FreeBSD (dma-bufs, syncobjs and a lot of others linux
kernel subsystems) that adding drm helpers to the list makes it really
hard for me.
From the list you've send here are the most problematic files for me,
for now I've simply not import them and hack around the code that calls
functions from them :
drivers/gpu/drm/drm_client.c It's now really tied into the drm
subsystem so it's hard to ignore it, for now not merging the latest
patches from 5.4 makes it ok-ish to ignore it.
drivers/gpu/drm/drm_lease.c I can hack around it but I would prefer to
include it and stop my hacks.
drivers/gpu/drm/drm_format_helper.c a lot of helpers are here and
needed, for now I'm using the old functions that were MIT licenced but
it's kinda wrong to do it this way.
For the gem_cma/gem_framebuffer/gem_etc ... we have our own
implementation when we need one, those file are too close to the vm
subsystem to be portable anyway so I don't really care if they stay
GPLed.
For the rest of the files either I don't want them (_sysfs and _of for
example) because it don't make sense for us to have them (sysfs) or the
subsystem is too different between FreeBSD-Linux (of) or I the current
drivers that we have don't need them for now (writeback, hdcp etc ...)
To finish this mail, I'd like to say that I would love to contribute
to DRM and some drivers (lima/panfrost mostly) but for now I need to
keep in sync with Linux and finish my work so I can commit it into the
FreeBSD kernel. Knowing that future updates will be easier for me
because of a licence issue would be great to know otherwise I think
that all the available time that I have for DRM on FreeBSD will be 100%
rewritting compatibility layers.
Cheers,
--
Emmanuel Vadot <manu@bidouilliste.com>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-11-16 12:19 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-12 15:03 drm core/helpers and MIT license Daniel Vetter
2019-11-12 15:03 ` Daniel Vetter
2019-11-14 8:43 ` Simon Ser
2019-11-14 8:43 ` Simon Ser
[not found] ` <CAKMK7uH-8+tbKsAoiChsxELEc_77RVVxP2wapHWhqB+0Viifog-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-11-15 15:38 ` Alex Deucher
2019-11-15 15:38 ` Alex Deucher
2019-11-16 12:12 ` Emmanuel Vadot
2019-11-16 12:12 ` Emmanuel Vadot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).