tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Fw: drm core/helpers and MIT license

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,

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.


Simon Ser


On Tuesday, November 12, 2019 4:03 PM, Daniel Vetter <> 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:
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:
drivers/gpu/drm/drm_gem_vram_helper.c:// SPDX-License-Identifier:
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:
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:
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 -

dri-devel mailing list

Home | Main Index | Thread Index | Old Index