Re: drm core/helpers and MIT license
On Fri, Nov 15, 2019 at 1:34 PM Ville Syrjälä wrote: > > On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote: > > Hi Daniel, > > > > I don't think we can make any complaints about GPL being more widely > > used in the DRM code. It's nice to have the code at all, the MIT license > > is a bonus. Thanks for writing it and bearing with us. > > > > Would rewrites done purely for licensing reasons be accepted upstream? > > Rewrite should be the last resort. I think a lot of the GPL only stuff > is quite recent so there's a good chance the author(s) are still around > to discuss relicensing. The trouble is this stuff is mostly coming from refactorings of gpl-only drivers, and quick chat with Dave looks like some of that code comes from gpl-only fbdev drivers. Doing the relicensing properly will be some work I think. -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
Re: drm core/helpers and MIT license
Den 16.11.2019 12.57, skrev Emmanuel Vadot: > On Fri, 15 Nov 2019 15:33:46 +0100 > Noralf Trønnes wrote: > >> >> >> Den 15.11.2019 13.34, skrev Ville Syrjälä: >>> On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote: Hi Daniel, I don't think we can make any complaints about GPL being more widely used in the DRM code. It's nice to have the code at all, the MIT license is a bonus. Thanks for writing it and bearing with us. Would rewrites done purely for licensing reasons be accepted upstream? >>> >>> Rewrite should be the last resort. I think a lot of the GPL only stuff >>> is quite recent so there's a good chance the author(s) are still around >>> to discuss relicensing. >>> >> >> If someone sends patches to MIT license the work I've done, I'll be >> happy to ack it. It's only recently that I've been aware of the fact >> that MIT licensed was a thing in the kernel. I was under the impression >> that all new code should be GPL and MIT were for code imported from >> elsewhere. I would love to see my work being used on the BSD's. > > And I would love to be able to use your work on FreeBSD :) > I don't really know the rules but shouldn't you send a patch to > relicence ? I don't know the rules either, but I don't think I have to be the author of the relicensing patch, I just have to put my stamp on it. Myself I haven't got the time to do the work, it's not just putting out a patch, everyone having made changes to the affected files would also have to be ok with the new license. Noralf. > Right now for me drm_client (and others) being GPL is a problem for my > update of DRM in FreeBSD so I'm not using it (which is bad and will > probably cause problems). > >> Noralf. >> ___ >> 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
Re: drm core/helpers and MIT license
Hi Daniel, On Tue, 12 Nov 2019 16:03:33 +0100 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: > 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)
Re: drm core/helpers and MIT license
On Fri, 15 Nov 2019 15:33:46 +0100 Noralf Trønnes wrote: > > > Den 15.11.2019 13.34, skrev Ville Syrjälä: > > On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote: > >> Hi Daniel, > >> > >> I don't think we can make any complaints about GPL being more widely > >> used in the DRM code. It's nice to have the code at all, the MIT license > >> is a bonus. Thanks for writing it and bearing with us. > >> > >> Would rewrites done purely for licensing reasons be accepted upstream? > > > > Rewrite should be the last resort. I think a lot of the GPL only stuff > > is quite recent so there's a good chance the author(s) are still around > > to discuss relicensing. > > > > If someone sends patches to MIT license the work I've done, I'll be > happy to ack it. It's only recently that I've been aware of the fact > that MIT licensed was a thing in the kernel. I was under the impression > that all new code should be GPL and MIT were for code imported from > elsewhere. I would love to see my work being used on the BSD's. And I would love to be able to use your work on FreeBSD :) I don't really know the rules but shouldn't you send a patch to relicence ? Right now for me drm_client (and others) being GPL is a problem for my update of DRM in FreeBSD so I'm not using it (which is bad and will probably cause problems). > Noralf. > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Emmanuel Vadot ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm core/helpers and MIT license
On Tue, Nov 12, 2019 at 10:03 AM 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: > 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm core/helpers and MIT license
Den 15.11.2019 13.34, skrev Ville Syrjälä: > On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote: >> Hi Daniel, >> >> I don't think we can make any complaints about GPL being more widely >> used in the DRM code. It's nice to have the code at all, the MIT license >> is a bonus. Thanks for writing it and bearing with us. >> >> Would rewrites done purely for licensing reasons be accepted upstream? > > Rewrite should be the last resort. I think a lot of the GPL only stuff > is quite recent so there's a good chance the author(s) are still around > to discuss relicensing. > If someone sends patches to MIT license the work I've done, I'll be happy to ack it. It's only recently that I've been aware of the fact that MIT licensed was a thing in the kernel. I was under the impression that all new code should be GPL and MIT were for code imported from elsewhere. I would love to see my work being used on the BSD's. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm core/helpers and MIT license
On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote: > Hi Daniel, > > I don't think we can make any complaints about GPL being more widely > used in the DRM code. It's nice to have the code at all, the MIT license > is a bonus. Thanks for writing it and bearing with us. > > Would rewrites done purely for licensing reasons be accepted upstream? Rewrite should be the last resort. I think a lot of the GPL only stuff is quite recent so there's a good chance the author(s) are still around to discuss relicensing. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm core/helpers and MIT license
On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote: > Hi Daniel, > > I don't think we can make any complaints about GPL being more widely > used in the DRM code. It's nice to have the code at all, the MIT license > is a bonus. Thanks for writing it and bearing with us. > > Would rewrites done purely for licensing reasons be accepted upstream? Figuring that out is why I started this thread. Thus far the consensus seems to be a deafening *shrug*, so no idea. Personally I'm happy to take any patches with a clear net benefit in terms of contributions/hw support/maintenability for linux gpu support. Everything else probably needs a much wider support in the community. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm core/helpers and MIT license
Hi Daniel, I don't think we can make any complaints about GPL being more widely used in the DRM code. It's nice to have the code at all, the MIT license is a bonus. Thanks for writing it and bearing with us. Would rewrites done purely for licensing reasons be accepted upstream? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm core/helpers and MIT license
Adding zeis...@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 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
drm core/helpers and MIT license
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
