Due to licensing issues, the network drivers are imported from BSD environments rather than Linux. The MIT license that Haiku uses is not compatible with GPL but is compatible with BSD.
My point really wasn’t that there should be porting of Linux drivers to Haiku as such, only that Linux is mainstream and supports quite a lot of hardware even though it might not be in regular use by many people.
Heck, Windows XP supports an awful lot of hardware that Haiku probably does not. Again, porting drivers is not really the point. It’s more that Haiku works/is useful on a fairly small subset of hardware.
Aside from the desire (personal and that of others) to be able to use Haiku on/with other hardware, there is the reality that these limitations necessarily reduce the pool of people who will actually use it for any real length of time.
MIT and GPL are compatible. We just strongly prefer to avoid copyleft code. We have a bunch of LGPL code in
libroot at least, and some GPL in kernel-space too (the NTFS driver, which is dynamically linked.)
Oh! Ok! I get it now.
Licensing issues can be avoided by packaging GPL drivers separately from base Haiku system.
That should be moved to HaikuPorts like OSS driver.
How do you access the external network drivers from a package manager that downloads its packages using a network driver? Catch 22?
OSS isn’t GPL’ed, anyway, I don’t think. Also we have other GPL components here and there. If someone really wants no-GPL, they can build their own system.
Which licensing issues are you referring to? Why would we fix a problem that doesn’t exist?
Here is how it works:
- Each file in Haiku has a copyright header mentionning what license it is distributed under
- Since the distribution includes some GPL code, this means redistributing the complete Haiku image has to comply with GPL. For this reason, we include all the sourcecode in our release DVDs (and, since we are not doing physical DVDs at the moment, we could even stop doing that)
- If you want to make a “GPL free” version of HaIku so you can redistribute it without sources, you can easily find the code that is under GPL license and remove it. And probably replace it with something else, because it will make Haiku quite a bit less useful. The GPL “virality” does not apply if you extract a subset of the system that does not include any GPL bits
- We have a “disable GPL addons” option to ./configure to assist in building such a Haiku image, although it does not currently affect the set of included hpkg files
I expect that core Haiku should be able to be distributed with private modifications without source code. To allow this, it would be good to move all GPL code to HaikuPorts and make it possible to get operational system without that packages installed.
I suppose that glibc code is fine because it use LGPL?
The GCC runtimes have a linkage exception to the full GPL.
I don’t see how it matters that the code is in haikuports or in Haiku git repository. What matters is what you distribute, so if the filesystem image contains GPL code, it should follow the GPL. It does not matter at all how the sources are organized and if they are in a single repository or multiple ones.
What matters is what is in the filesystem image at the end. And for this, we would have to change the --enable-gpl-addons configure option to work better and remove more things. As far as I know, there is no one who is really interested in doing that and so that work is not done.
Add an extra small FAT partition to the install image, after dd-ing the image this partition can be mounted on any other operating system and the user can place the hpkg there.