Hacker News Reader

Comment by moonchrome | Hacker News Reader

>BSD licenced software surges. News at 11.

Actually if you listened to the GPL fanatics that are all over some tech forums (note: I'm not implying that all people using GPL are fanatics, just that there is a subset that's fanatical about it, ironically they are usually technically ignorant) this shouldn't happen - instead everyone should just "steal" BSD software and not contribute (let alone create) stuff back.

View on HN

This does happen, though. How much of Apple's kernel code has made it back into other BSD kernels?

That's not a fair comparison. Apple's kernel is Mach/XNU, which is a completely different architecture than the 4.4BSD derived kernels used by Free-, Net-, Open-, etc. BSD. That said, the API for kauth has been implemented (albeit not via open code from apple) on NetBSD. https://developer.apple.com/library/mac/#technotes/tn2127/_i... http://netbsd.gw.com/cgi-bin/man-cgi?kauth++NetBSD-current

Apple guides development for WebKit and releases code for mDNSResponder (Avahi is admittedly used more in OSS operating systems, although NetBSD-current notably uses mDNSResponder), Darwin Streaming Server (the backend to their proprietary QuickTime Streaming Server, and ALAC.

They don't release everything as open source, but they certainly don't disregard its importance.

Webkit is mostly LGPL. This is a bad example, because the codebase is derived from KDE.

mDNSResponder is Apache. This was released to drive industry acceptance of Bonjour/Zeroconf.

Darwin Streaming Server is APSL (the Darwin license) and patent encumbered. IIRC, there was talk of it being open sourced to drive H264 acceptance.

Darwin mostly does count as sharing code for the sake of being open, and to their credit Apple does keep updating it, but I struggle to think of other Apple releases for which this appears to be the most important consideration.

I'm not saying it doesn't happen. I'm saying there are reasons for contributing to opensource and opensourcing your projects, other than being forced by the license. Sometimes it doesn't make sense and in those cases GPL forces the company to reinvent the wheel which is counter productive. And there are business models that could rely on GPL to make them viable (offer custom licensing for a fee for eg.) Point is GPL isn't the ultimate license of opensource, and BSD is a viable license, which you won't hear from GPL fanboys.

>'Sometimes it doesn't make sense and in those cases GPL forces the company to reinvent the wheel which is counter productive.'

Same goes for a company taking BSD/MIT licenced open source code, enhancing it and not releasing those enhancements back. In order to have those enhancements reinventing/duplication of effort is needed here aswell.

Also by dual-licencing your open source code you can provide it under GPL for FOSS projects while also offering a proprietary licence for companies for a fee. x264 makes good money this way.

The number of BSD code sucked by proprietary code and never returned; causes a great number of rewrites; you won't hear much of them; well because of the closed nature of proprietary forks. That way BSD licenses are unfortunately not good for the open source ecosystem, but I accept they are good for proprietary projects or patent-users, commercial users.

But the point is that the proprietary code will be proprietary code even if you GPL you just make the company that would use BSD licensed code rewrite it (or steal it since there's no practical way of enforcing it - and unethical company gets rewarded). There is no way to force a company to contribute if it won't/can't. And GPL is all or nothing deal, BSD allows you to upstream selective patches but keep some parts you can't/won't release.

> And there are business models that could rely on GPL to make them viable (offer custom licensing for a fee for eg.)

This seems to be the most common GPL-based business model; particularly popular with Oracle, whose newest open-source/commercial license product (confusingly called Oracle NoSQL; it's more or less an autosharding network available BDB JE) is actually AGPL.

We don't take much Apple code into the FreeBSD kernel, because it simply isn't a good technical fit. Userland code, on the other hand, we take plenty of -- and at the last FreeBSD devsummit I attended, the people Apple sent were begging us to take more and the holdup was FreeBSD developers (myself included) not being sure that we really liked the solutions OS X had developed.

Apple's kernel code is largely _available_, even in other BSDs do not necessarily want to take it. In practice, it's very common for companies who use permissive licensed software to contribute back to it.

Reply on news.ycombinator.com