Slashdot Mirror
Squaring the Open Source/Open Standards Circle
Andy Updegrove writes "Before there was Linux, before there was open source, there was of course (and still is) an operating system called Unix that was robust, stable and widely admired. It was also available under license to anyone that wanted to use it, and partly for that reason many variants grew up and lost interoperability - and the Unix wars began. Those wars helped Microsoft displace Unix with Windows NT, which steadily gained market share until Linux, a Unix clone, in turn began to supplant NT. Unfortunately, one of the very things that makes Linux powerful also makes it vulnerable to the same type of fragmentation that helped to doom Unix - the open source licenses under which Linux distributions are created and made available. Happily, there is a remedy to avoid the end that befell Unix, and that remedy is open standards - specifically, the Linux Standards Base (LSB). The LSB is now an ISO/IEC standard, and was created by the Free Standards Group. In a recent interview, the FSG's Executive Director, Jim Zemlin, and CTO, Ian Murdock, creator of Debian GNU/Linux, tell how the FSG works collaboratively with the open source community to support the continued progress of Linux and other key open source software, and ensure that end users do not suffer the same type of lock in that traps licensees of proprietary software products."
All mainstream package formats have the full installation path hard-coded in the archive. LSB does not address this yet. The other problem of RPM, namely binary compatibility between different library versions, is already solved by compiling with apbuild. This works surprisingly easy, and allows my to provide one single package that can be installed everywhere [1].
[1] I can recommend to compile packages at Slackware because Slackware ships most packages without patches. Compiling an app at SuSE for example, made binaries depend on ABI changes caused by SuSE patches.
The best way to accelerate a windows server is by 9.81 m/s2
Depending on what open source license the standard's implementation is released with, ofcourse.
The most common license, (L)GPL pretty much blocks most other licenses.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
You were probably too busy boosting your ego via anti-Linux trolls to notice
While that might have been true, there was a standards brawl called the "UNIX Wars" right before Windows NT showed up. So clearly some people were frustrated with the state of standardization in the Unix world.
UNIX vendors also basically stopped workstation development (X11, Motif, CDE etc) in the early 90s when NT showed up, giving up the desktop without much of a fight.
Business. Numbers. Money. People. Computer World.
Depending on what open source license the standard's implementation is released with, of course.
The most common license, (L)GPL pretty much blocks most other licenses.
I'm not sure I understand what you mean. I've never seen an open standard (documentation) released under a license designed for code. The free standards group (LSB & other free standards) release their licenses under the GNU free documentation license.
I'm not exactly an IP lawyer, but I don't see any obstacle to writing code to conform to a FDL specifcation under any license you choose.
There are shills on slashdot. Apparently, I'm one of them.
Any Free Software license allows you to use or distribute the software in any way you choose.
I am TheRaven on Soylent News
What's this about "various types of licenses" under which Linux is supposed to be available? Linux is GPL, so forking is possible, but there is no risk of UNIX-style fragmentation because the source is open and copyleft. For somebody to create a "closed Linux" they would have to start from scratch. You can't add closed bits to GPL software and keep them hidden, so any incompatible Linuxes ("fragments") could always be re-connected by users irritated about the differences.
The nonsense about UNIX displaced by NT and NT in turn displaced by Linux already set off my alarm, but the above really is FUD designed to further somebody's personal agenda.
It is not possible for UNIX-style fragmentation to happen to Linux, because of the GPL.
I thought forking and merging (thanks to the license) are strengths of Linux. It's an evolutionary development process where the best or most popular ideas rise to the top. Basic standards arise out of the most widespread/adopted projects.
It's hard for me to see in this chaotic (but necessary) environment how much external control developers are willing to have "imposed" on them by such standards - unless of course from a development/technical standoint it makes sense.
My understanding is that Linux really isn't in the game of competing with anybody (Unix, Windows or otherwise) anyway. it's just about the code, love of things computers and a new way of doing things.
E.
Well, if you'd read the article you'd see it discussed in the second answer:
"2. How does FSG work with the Linux development team and the Linux process?
Actually, the LSB doesn't specify the kernel--it only specifies the user level runtime, such as the core system libraries and compiler toolchain. Ironically, then, the _Linux_ Standard Base isn't Linux specific at all--it would be entirely possible (and probably not altogether hard) for Solaris to be made LSB compliant. The LSB is entirely concerned with the application environment, and the kernel is usually pretty well hidden at the application level."
So they are fully aware themselves.
No. Unlike commercial EULAs (see one that comes with Windows for example) Linux licenses are written in a clear language - what it says is what it intends.
Here is an explanation, just in case:
There are four major licenses: GPL, LGPL, BSD and MIT-X.
From users point of view all are equally good as they allow one to use the program and perform personal modifications.
From distributors point of view GPL and LGPL require that source code be made available so some care needs to be taken to address that.
From developer point of view it is a matter of choice:
Linux has one thing Unix never did - if someone forks it and does something innovative, then ther forks/branches can use it too, thanks to the GPL. The varous 'Unix' flavors didn't allow that.
Just like commercial EULA's, the GPL and other Free Software/Open Source license use technical language which can be unclear to people unfamiliar with either the area of law or to technical language in computing, and many are perhaps more unclear than many commercial EULA's because in their attempt to be unintimidating in size and complexity, they avoid things like sections of clarifying definitions; further, like (perhaps worse than) commercial EULA's, Free Software/Open Source licenses often used strained sentence structures which make it unclear where provisions apply (a good example, IMO, being section 2 of the GPL, where it is ambiguous which restrictions apply to all modifications, and which apply to distribution.)
Well, sure, that's the selling point; the actual terms of the specific agreements may be less clear on the exact degree of freedom granted.
And while this will NEVER happen, I think we need one major development kit, instead of GTK vs QT. When it comes to aesthetics, visual style and usability, I can certainly understand people wanting a choice between Gnome and KDE. But when I design an app, I should build it on one toolkit, and then it should work on both Gnome and KDE, letting Gnome/KDE handle how it looks, etc.
That's nearly how it works now, and the Free Desktop folks are pushing it closer to that ideal all the time. Programmers should be able to use whichever toolkit they prefer, trusting that the window manager will handling themeing, look and feel, drag and drop, etc. all seamlessly regardless of which desktop the app uses. That's a much better outcome than having a single kit, since it allows developers to use whatever sort of development toolset they're most comfortable with. Personally, I like C++, and KDE/Qt provides much nicer tools for the way I like to work than GTK+ does. Others hate C++ and prefer GTK. Others use other languages and evaluate the bindings between the toolkits and their preferred language and pick what works best for them. That's all good.
If I use KDE but want a few GTK apps like Firefox or GAIM, I have to install half of Gnome.
Why do you care, really? Disk space and RAM are so cheap these days that there's little reason to care there, and any decent distro handles all of the dependencies automagically for you, so it's not like you actually have to track the dependency chain yourself.
Who cares if you need some GNOME libs or KDE libs in order to support the mixture of apps you want?
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I find using apt-get with a decent GUI front-end to be easier than using windows binary installers (especially when it comes to resolving dependencies and, particularly, conflicting dependencies).
Of course "If Linux wants to be taken seriously..." arguments are hard to take seriously themselves -- Linux is taken seriously now. Its not competing for the unsophisiticated home user -- because a lot of things are missing simple "just works" functionality. But Joe User doesn't care if that's an abstraction built on top of apt-get or some other process that might involve building a package when it is download or whether its a simple binary installer. As long as there is a "click it and I get it" mechanism, whose security features are understandable and straightforward, that will serve the need.