> > rest is required to be GPL anyway in principle so can be adjusted. > > I thought binary modules were OK, hence the whole GPL vs non-GPL symbol > versioning system? you think wrong most likely. It kinda depends on which lawyer you talk to, and on in which country that lawyer is. But there is no explicit permission to do non-GPL kernel modules. At least not from most authors of the kernel, and certainly not for the parts of which I own the copyright. It all is a bit of a gray area (eg the "which lawyer" part), the _GPL exports are a start to make it clear that certain parts sure are NOT part of the gray area. > > At least that's the intention. Some people think they can get away with > > not being GPL while still using and depending on deep kernel internals; > > well... to be honest the pain is on them though. > > Actually the pain is on the users. You just don't see it. people who choose to use binary modules suffer, I am fully aware of that. I rather not have them suffer that. But in a way they choose that pain when they choose to start using binary modules. But look at it with a slightly longer pervue; about half the bugs reported against the kernel are in the drivers. The fact that the driver sources are available gives us a shot at fixing those, just as the availability of the core source allows us to fix bugs there. If the drivers weren't part of that, their quality would lag WAY behind. (And to be honest, you do see that in several binary drivers: bad quality. Nvidia seems to be improving somewhat there but they didn't always have that; others are still struggling). > > As for your comparison to X, glibc, gtk etc, those EXTERNAL interfaces > > remain stable, just like the kernel external interface is. > > The X server has provided a stable driver interface for a very long time > now. GTK provides a stable interface for theming engines, glibc for DNS > resolver plugins and so on. Clearly the kernel *does* provide an interface btw the glibc NSS abi is changing all the time ... X is about to change their driver interfaces because they suffered too much bitrot. > > But those > > projects do change the internal interfaces a lot.. just they don't allow > > anyone to see it, unlike the kernel where modules do get to see it. > > As already pointed out, these projects actually make it clear which > interfaces are internal and which aren't. Whether you like it or not, > parts of the module interface aren't internal, they are being used by > external developers sometimes because they have no choice. they do have a choice. they can do things on the other side of the designed stable interface. For example, NVidia could do this. Their IP is in code that easily can be on the userspace side (the open source DRM modules prove this, they do it that way). They need a very thin layer in the kernel for support in that scenario, which is so thin that it doesn't contain IP. But they *choose* to not do that. That's their choice. With that, they choose the pain and problems that come with that approach. They not only chose for themselves but also for all their customers who want to use their 3D engine.
Attachment:
signature.asc
Description: This is a digitally signed message part
