|
>>If the Linux community contributes to DC, I guess those contributions My understanding of the "general rule" was that contributions are normally assumed to be made under the "local license", ie GPLv2 for kernel changes in general, but the appropriate lower-level license when made to a specific subsystem with a more permissive license (eg the X11 license aka MIT aka "GPL plus additional rights" license we use for almost all of the graphics subsystem. If DC is not X11 licensed today it should be (but I'm pretty sure it already is).
We need to keep the graphics subsystem permissively licensed in general to allow uptake by other free OS projects such as *BSD, not just closed source.
Either way, driver-level maintainers are going to have to make sure that contributions have clear licensing.
Thanks, John From: dri-devel <dri-devel-bounces@xxxxxxxxxxxxxxxxxxxxx> on behalf of Lukas Wunner <lukas@xxxxxxxxx>
Sent: December 13, 2016 4:40 AM To: Cheng, Tony Cc: Grodzovsky, Andrey; dri-devel; amd-gfx mailing list; Deucher, Alexander Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU On Mon, Dec 12, 2016 at 09:52:08PM -0500, Cheng, Tony wrote:
> With DC the display hardware programming, resource optimization, power > management and interaction with rest of system will be fully validated > across multiple OSs. Do I understand DAL3.jpg correctly that the macOS driver builds on top of DAL Core? I'm asking because the graphics drivers shipping with macOS as well as on Apple's EFI Firmware Volume are closed source. If the Linux community contributes to DC, I guess those contributions can generally be assumed to be GPLv2 licensed. Yet a future version of the macOS driver would incorporate those contributions in the same binary as their closed source OS-specific portion. I don't quite see how that would be legal but maybe I'm missing something. Presumably the situation with the Windows driver is the same. I guess you could maintain a separate branch sans community contributions which would serve as a basis for closed source drivers, but not sure if that is feasible given your resource constraints. Thanks, Lukas _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel |
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
