Intel Builds On Top of Android, But Hedges On Open-Sourcing Improvements 156
Barence writes with this news as carried by PC Pro: "Intel claims it is making significant improvements to the multicore performance of Android — but isn't sure if it's willing to share them with the open-source community. Speaking to journalists in London, Intel's mobile chief Mike Bell said that Intel's engineers were making significant improvements to Android's scheduler to improve its multicore performance. 'Android doesn't make as effective use of multicore as it could,' he said. However, when pressed by PC Pro on whether those improvements would be shared with the open-source community and Intel's competitors, Bell remained non-committal. 'Where we are required to give back to open source, we do,' said Bell. 'In cases where it's not required to be open source, I'm going to think about it. I don't like doing R&D for competitors if they're not going to contribute themselves,' said Bell, before adding that 'in general, our philosophy is to give things back.'"
He's talking about software that isn't shipping (Score:4, Informative)
Re:Altruism vs profit. (Score:5, Informative)
Android is not GPL, it's Apache:
http://source.android.com/source/licenses.html [android.com]
The linux Kernel is a different matter but this is an Android code change, not a Linux one. Intel doesn't have to release anything, ever.
Re:Altruism vs profit. (Score:4, Informative)
Re:Altruism vs profit. (Score:5, Informative)
Well, if you're working on a huge multi-million dollar project you probably don't have much incentive to use GPL components, do you? The price is too high. Either do the work yourself or go buy a license to something proprietary. Or as you point out, use something with a more permissive open source license.
Different licenses have different goals. If you're looking to make money you use a proprietary license and sell usage rights. If you're looking to create a standard of some sort (platform, file format, whatever) then BSD, MIT, or full-on public domain is the way to go, because your goal is to get the software in as widespread use as possible and any restrictions will hinder that. If you're looking to build a free library of useful code, something like the LGPL may be better because your goal is to maximize the development speed of the library, letting folks improve on it but keep those improvements to themselves is counterproductive.
The GPL was intentionally designed to create an expanding ecosystem of Free software. Not a toolset, not a standard, an ecosystem. To create software at all comparable to the well-funded proprietary alternatives you need some sort of edge. The GPL edge is take anything you want, from any project you want (from within the ecosystem of course), use it however you want, but your project MUST remain a part of the ecosystem. It's done a great job too - the ecosystem is thriving and there is a truly staggering amount of code out there that plenty of projects would love to use but can't because they aren't willing to join the ecosystem. That's fine.
The GPL is an openly idealistic license, and that's not always be the most effective stance to take for all purposes, but if you use any open-source software or libraries at all it's rather hypocritical to call out the idealists for being extremists. Everything exists on a spectrum, if the GPL vanished tomorrow the the LGPL would be the "extremists", keep knocking out the "extremists" and pretty soon the public-domain projects that simply make a non-binding request for acknowledgment will be the "extremists". Having idealists as the extremists, much less idealists that have proven that it is still possible to turn a decent profit, gives a good reference point for everyone else. Personally I suspect we'd have a much poorer ecosystem of non-GPL open source software if the GPL folks weren't around to prove that even a hard-line stance is viable.