Re: [PATCH v2 00/15] drm: Add a driver for FW-based Mali GPUs

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

 



On Thu, Aug 10, 2023 at 10:44 AM Boris Brezillon
<boris.brezillon@xxxxxxxxxxxxx> wrote:
>
> Hello Rob,
>
> On Wed, 9 Aug 2023 14:22:59 -0600
> Rob Herring <robh@xxxxxxxxxx> wrote:
>
> > On Wed, Aug 9, 2023 at 10:53 AM Boris Brezillon
> > <boris.brezillon@xxxxxxxxxxxxx> wrote:
> > >
> > > I tried to Cc anyone that was involved in any development of the code
> > > I picked from panfrost, so they can acknowledge the GPL2 -> MIT+GPL2
> > > change. If I missed someone, please let me know.
> >
> > Panfrost was largely based on etnaviv, vc4, v3d, and msm. Those are
> > all GPL2 (or 2+) only.
>
> Uh, I must have missed some copyright headers then. Note that not all
> panfrost files were taken as a base for panthor:
>
> - Makefile/Kconfig. I honestly hope there's nothing copyright-able in
>   there, given there's no other way to define your driver and
>   compilation rules.
> - panthor_device.{c,h} copied from panfrost_device.{c,h} with quite a
>   few modifications in the process. This one has your copyright, and
>   Marty's one.
> - a tiny part of panthor_drv.c was copied from panfrost_drv.c, but let's
>   be honest, the part that was copied (ioctl wrappers, mostly), can't
>   really be done differently. This one has your copyright, Marty's one,
>   and Collabora's one.
> - panthor_regs.h copied from panfrost_regs.h. This one has your
>   copyright, Marty's one and Arm's one (definitions extracted from
>   kbase). But again, I'm not even sure register definitions are
>   copyright-able, given there's no other way to define them. If that
>   makes a difference, I changed the prefix, and dropped definition that
>   do not exist on CSF HW.
> - panthor_gpu.{c,h} copied from panfrost_gpu.{c,h}. These files have
>   your copyright, Marty's one, and Collabora's one.
> - panthor_{gem,mmu}.{c,h} copied from panfrost_{gem,mmu}.{c,h}. Those
>   ones have your copyright only.
> - panthor_devfreq.{c,h} copied from panfrost_devfreq.{c,h}. Collabora's
>   copyright only.
> - panthor_{heap,fw,sched}.{c,h}. Those are brand new files, that were
>   written from scratch.
>
> I also git-blamed the lines I copies to Cc any contributors to the
> above files. I might have omitted someone, but I did my best to
> try and spot people that have a word in this decision.
>
> > How is relicensing that code okay?
>
> Sorry, the copyright headers of the files I copied didn't mention that
> :-/. If that's an omission, it would be good to have the headers updated
> to reflect the actual chain of copyrights.

Yes, we probably should make it more explicit though at this point it
would be fairly vague in terms of the exact sources. IMO, it should be
assumed by default any driver is derived work. No one writes a new
driver from scratch (unless they are really actively trying to avoid
being derivative work). Then the question is what driver(s) were the
source. I think it is safe to say no one copies the big 3 (Intel, AMD,
NVIDIA) nor para-virt drivers as those are the MIT licensed ones. The
ones left are pretty much *all* GPL.

> > Also,
> > panfrost depends on drm_gem_shmem_helper.c (at least) which is GPL2.
> > Does that get re-implemented in a MIT licensed environment?
>
> Not only drm_gem_shmem, but drm_gpuva_mgr and drm_sched too. And yes,
> any helper function/lib that's not GPL+MIT will have to be
> re-implemented or replaced by something else.
>
> >
> > Maybe some drivers are enough of a silo to get away with MIT
> > licensing, but I wouldn't be comfortable claiming it.
>
> Well, yes, re-using the code as-is is almost impossible, unless
> someone rewrites the various GPL components we depend on. But if
> someone wants to pick, say, the scheduling logic, and replace drm_sched
> by something else, they can. Not saying it's worth it, just saying it's
> possible.

Sure, it is possible. Seems like reimplementing all that would be more
work than the driver. Maybe the BSDs already have?

Rob




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux