| |||||||||||||
Odd choice of licencesOdd choice of licencesPosted Jul 5, 2010 15:58 UTC (Mon) by vonbrand (subscriber, #4458)In reply to: Odd choice of licences by epa Parent article: A line in the sand for graphics drivers
The userspace pieces have to interact with assorted userspace programs, some of which are closed source, thus LGPL at most, preferrably MIT as that is the default license for X.org. GPLv3 is out, as the kernel won't go GPLv3 in our lifetimes (and the need to exchange pieces with the userspace part is a real possibility); thus GPLv2+ is also out.
(Log in to post comments)
Odd choice of licences Posted Jul 5, 2010 16:16 UTC (Mon) by mjr (guest, #6979) [Link]
Otherwise yeah, but I'd like to nitpick that GPL3 being out doesn't mean that GPL2+ is out; it merely means that the license would be compatible with GPL3(+) code in addition to (kernel) GPL2 code, thus potentially enabling the use of the code in more places.
Odd choice of licences Posted Jul 5, 2010 16:46 UTC (Mon) by epa (subscriber, #39769) [Link]
Surely if MIT licence is okay, then 'GPL v2, or later, at your option' is also okay? If not, why not?
Odd choice of licences Posted Jul 5, 2010 17:16 UTC (Mon) by bronson (subscriber, #4806) [Link]
Not if you want any chance of upstreaming the code into X11 or or any of the other graphics-related projects. They're probably thinking longer term.
Odd choice of licences Posted Jul 5, 2010 22:54 UTC (Mon) by airlied (subscriber, #9104) [Link]
The code ends up linked into any 3D application, being GPL would be rather limiting on users of the code via the defined GL APIs. Hence MIT or LGPL.
Odd choice of licences Posted Jul 5, 2010 23:52 UTC (Mon) by elanthis (guest, #6227) [Link]
Because the GPL in any version is far more restrictive than MIT and infects applications written on top of it. You'd basically be saying that the entire GL/Mesa/Gallium stack using the driver would have to be considered as GPL, and thus any apps written to those interfaces (which would load the GPL driver into the apps' address space and link it into the program as a whole) must also be GPL. Which in turn really sucks for anyone who uses their devices for actual work or play in the real world where much interesting software is still non-Free with no Free alternatives. Especially in gaming, which is a highly important use of computers and mobile devices for most people (something the Free Software community always seems to underestimate and ignore). Looking purely at a Free Software world, I don't think graphics hardware would even be as advanced as it is today, as the proprietary gaming market is really what pushed a lot of the innovation and advancement in hardware, like shaders and the general massive speed increase. Most high end professional rendering is still done on the CPU using a drastically different rendering model than OpenGL/DX, and the CAD market isn't really a huge user of much beyond basic polygon rendering. Games are what pushed graphics hardware to where it is, and every single moderately advanced gaming graphics engine is still developed in a speedy, schedule-oriented, high-risk fashion that the bazaar development model just isn't good for (you really need a tightly focused team of highly skilled individuals to push out a quality game from start to finish, not a constantly changing army of somewhat skilled hobbyists contributing bits and pieces of itch-scratching functionality over many years of development; I'm considering writing an article on why this is and what the potential solutions are for the Free Software world, potentially for LWN.)
Odd choice of licences Posted Jul 8, 2010 19:28 UTC (Thu) by robert_s (subscriber, #42402) [Link]
"I'm considering writing an article on why this is and what the potential solutions are for the Free Software world, potentially for LWN."
Be warned if it's for LWN your ideas will have to be quite well thought out and cogent.
Talking about an "infectious GPL" isn't a good start.
Odd choice of licences Posted Jul 9, 2010 16:35 UTC (Fri) by mpr22 (subscriber, #60784) [Link] Actually, when the GPL is applied to a library, rather than a program, I'm entirely sympathetic to the viewpoint that describes it as "infectious".
Odd choice of licences Posted Jul 9, 2010 17:24 UTC (Fri) by njs (guest, #40338) [Link]
The problem with the 'infection' metaphor is that infections are things that spread on their own, against the person being infected's will.
When a library is under the GPL, that's not an infection, it's a price -- you can use the library if you pay it back by freeing your own software in return, or you can not use the library and not pay that price. Totally up to you.
Ironically, some of the people who hate the idea of this kind of quid-pro-quo rant about how it's 'communist'. (And, to drive the point home, also hate the first-sale doctrine, traditional contract law as applied to EULAs, etc.) Really it's 'capitalism' they seem to object to.
Odd choice of licences Posted Jul 12, 2010 9:03 UTC (Mon) by mpr22 (subscriber, #60784) [Link] Which is fine until the price becomes "you can't write 3D games on Linux without first reimplementing the graphics driver's userspace library and everything that links against it".
Odd choice of licences Posted Jul 12, 2010 14:10 UTC (Mon) by njs (guest, #40338) [Link]
Yes, that's generally agreed to be too high a price to impose (or, for the more free-software minded, it's agreed that the costs in terms of network effects of locking proprietary software out of the platform entirely are worse than the costs of that software existing). That's why everyone agrees that graphics drivers should be under something like the MIT license.
But that still has nothing to do with "infections".
Odd choice of licences Posted Jul 12, 2010 15:40 UTC (Mon) by bronson (subscriber, #4806) [Link]
Nothing to do with infections? If a developer wants to use a GPLed library in a proprietary project, his choices are:
- Clean-room rewrite the library. Huge waste of time. - Relicense the entire proprietary project under a GPL-compatible license.
I'm sympathetic to how it could appear like the license is trying to spread on its own. Obviously "infection" is not 100% accurate (what metaphor is?), but I haven't seen a better way to oversimplify this fairly unique aspect of the GPL. I'm afraid "infect" will be used until someone can think of a more appropriate term.
Odd choice of licences Posted Jul 12, 2010 15:44 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
A simpler and less loaded term is "reciprocal" license as opposed to "permissive" license.
Odd choice of licences Posted Jul 12, 2010 16:11 UTC (Mon) by nye (guest, #51576) [Link]
With a proprietary license, there isn't even the second option, just the first. And yet nobody describes them as 'infectious'. This makes it sound like the addition of that extra choice is a *bad* thing.
Odd choice of licences Posted Jul 14, 2010 10:55 UTC (Wed) by mtorni (subscriber, #3618) [Link]
Regards using a GPLed library in a proprietary project, you suggested the choices are:
#1 Clean-room rewrite the library. Huge waste of time. #2 Relicense the entire proprietary project under a GPL-compatible license.
I'd like to add two more options to permit a fair comparison:
#3 Relicense (buy) the free library under a license permitting use
Now the fair comparison goes:
With a GPL'd library you have one more choice in this setting.
The comparison becomes more interesting once you consider the options when using libraries in free software or BSD/MIT-licensed software.
It also happens frequently that most benefit would be had by not writing propriertary software at all to tap the most amount of existing free software and interested developers.
Odd choice of licences Posted Jul 8, 2010 20:29 UTC (Thu) by vonbrand (subscriber, #4458) [Link] Please do write your ideas up!
|
|||||||||||||