|
Authored by: Anonymous on Monday, October 15 2012 @ 04:51 AM EDT |
I think it's a byproduct of actually having your personal contribution open to
inspection. Individuals are personally visible when working on open source, so
they keep it 100% clean, whereas in closed-source development you don't need to
worry so much, as it's unlikely to ever be spotted outside the company.
Kinda turns around the comment about proprietary software having "someone's
ass on the line if it doesn't work".[ Reply to This | Parent | # ]
|
|
Authored by: jesse on Monday, October 15 2012 @ 08:11 AM EDT |
As it clearly and unambiguously identifies an "interface" that is not
a normal interface.
The big upside of using it, and going along with the GPL is that people that
change the interface, are also usually responsible for providing updates for the
uses of that interface.
A binary blob cannot be updated...[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Friday, October 19 2012 @ 03:18 PM EDT |
Essentially Nvidia is asking the relevant GPL copyright
holders for permission to use their code outside the GPL, by
clearly asking them to change the marker that indicates if
such permission is granted or not.
The problem here is that there is some doubt as to which of
the many kernel contributors have the right to block such
permission. It is crystal clear that all those will need to
agree for the change to be legal, but it is not clear how
far away from this new DMA API code can be and still legally
claim a copyright interest in requiring that API to impose
GPL licensing on all is callers.
This is interesting because the API sounds like it is
essentially a general communication interface which many
kernel drivers and components can use to exchange bulk data
at ultra high speed (faster than the CPU bus speed). This
brings up a lot of "arms length" questions.
Imagine as an extreme hypothetical that the DMA sharing code
was fully under a 2-clause BSD or 1-clause MIT permissive
license and was the first part of a brand new kernel, to
which others then contributed drivers etc. under various
licenses. Could those who contribute GPL drivers demand
that those who contribute proprietary drivers not call the
BSD interface because they thereby indirectly access the GPL
code?
Now this is not the actual situation. The actual situation
is that the Linux kernel is GPL code with two exceptions:
1. User mode code may call the exposed (syscall, /proc, /sys
etc.) interfaces with impunity and use the related exported
kernel headers describing those interfaces (Linus
clarification note attached to the kernel copy of the GPL2
license text).
2. GPL-incompatible kernel mode code may call the interfaces
marked as "export no GPL requirement" by their GPL copyright
holders.
So Nvidia said "Please let us use it, we have an idea for
how to do good things for the world with it". And some of
the relevant people said NO. So Nvidia cannot call the
interface unless they open source the relevant drivers.
So this will either be win-win (Nvidia open sources more
drivers, Linux runs faster on Nvidia hardware, Nvidia sells
more chips) or loose-loose (Nvidia refuses to provide the
facility in their closed source drivers and Linux runs
slower on Nvidia hardware, AMD sells more chips). Only time
will tell.
[ Reply to This | Parent | # ]
|
|
|
|
|