Hello Everyone, I'm really glad this has been forwarded to *BSD mailing lists, thanks for this Simon and Daniel. As i'm not an active contributor yet nor someone known my voice would probably have very little consideration but i'll speak anyway :)
Someone from FreeBSD already answered and i'll second him in his will of potential dual licensing as i'm interested in hacking DRM on OpenBSD (other peoples than me already does). Dual licensing MIT/GPL would help graphics improvements in all free OS'es around while avoiding any kind of conflicts so if the original authors of the GPL'ed only files might agree about dual licensing it would be very great. Rewriting things would be a non necessary last resort for everyone. And authors might have their name and consideration in others systems :) thank you for reading, Jerome KASPER Le 14/11/2019 à 10:12, Simon Ser a écrit :
Hi OpenBSD and NetBSD folks, Here [1] is an e-mail from Daniel Vetter that probably affect you. It's about the DRM subsystem license. It would be nice if you could reply to the original post with your thoughts. Thanks, Simon Ser [1]: https://lists.freedesktop.org/archives/dri-devel/2019-November/243789.html On Tuesday, November 12, 2019 4:03 PM, Daniel Vetter <[email protected]> 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 [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
