I don't believe you need Jakarta in the tool chain. Definitely not Apache. Just Xerces, Xalan and FOP.
I'm using DocBook/XML with the Jade tool chain. But as soon as Xalan lets me resolve public identifiers locally, I'll switch to it. Until then, some of us are behind firewalls, have slow connections, etc.
Linux may be the most "prominent" example of Open Source, but the three pieces of Open Source work that are actually the most used are not listed either. Perl, Apache and XFree86.
The OSD is not meant to be a definitive archive. It's mission is to provide a resource for users. I think it has a done a good job in this regard.
So? Gcc is used to build OpenBSD. Should we now call that GNU/OpenBSD? It is also used to build the OS that we use at work for embedded systems. Should we call it GNU/LynxOS? Or what about GNU/Macintosh OS X?
You do not name a system after the tool chain. That is so silly that even RMS dismisses it. Next thing you know you'll want me to name my doghouse "Stanley" after the brand of hammer I used.
Talks like a duck, quacks like a duck, it is a duck.
The GNU System has not yet been shipped. It is incomplete. So far, I have not heard it talk or quack, so I have no reference with which to compare it to Slackware's talk and quack. Which, by the way is extremely similar to the talk and quack of Solaris, IRIX, BSD and every other Unix and Unix-like system.
My company creates very large and very expensive embedded devices. We recently shipped two new products.
The first product (call it Alpha) was designed and created by us, but manufactured by Fujistu. Should this product be called "Alpha" or "Fujistu/Alpha"?
The second product (call it Beta) was designed, created and assembled by us. But every board was built by Solectron. Should this product be called "Beta", or "Solectron/Beta"? Or should it be called "Xylinx/Solectron/Beta"?
If I build a new house from parts purchased as Lowe's, I do not call my new home "Lowe's Manor". Likewise, if Patrick Volkerding created an operating system where the parts came from GNU, he does not have to call the finished product "GNU/Linux". Indeed, only a fraction of the parts he used came from GNU anyway.
To quote Linus, "Your midwife doesn't select the name of your babies."
Thank you for setting the persective straight. Adobe is pretty sleazy, but they have nothing on the US government when it comes to corruption. If the government did not have the legislative process up for sale, no one could buy it.
Yellow Dog Linux (it's official name) is most certainly not The GNU System. It can't be, as a completed GNU System has not yet been shipped.
Most certainly it is not The GNU System with merely a different kernel. Go buy the Deluxe GNU distribution, pop in the linux kernel, and it won't work. (To be fair, it won't work with Hurd either). Take any given Linux distro and merely replace the kernel with Hurd and it won't work.
Merriam Webster's dictionary defines "operating system" as "software that controls the operation of a computer and directs the processing of programs". That sounds like a kernel to me. But I'll be generous and allow a certain amount of infrastructure as well. But it still doesn't cover bash (you can use a dozen other shells instead), glibc, emacs or gcc. It would cover ld, init and the file system, none of which on my system come from GNU.
I've looked all over my Slackware box, CD and installed documentation. I've even perused the Slackware web page. I cannot find any reference whatsoever to something called "Slackware GNU/Linux". Patrick Volkerding created Slackware, and he is the one that gets to name it.
The new version will have a dual licensing model similar to TrollTech's Qt (GPL/QPL/commercial), thus allowing non-GPL applications (either commercial or under an OSI approved license) to use korelib.
This is a good thing to hear. Often times the community forgets that there are other licenses than the GPL. I have some BSD licensed apps that I would dearly love to port to Qt-Embedded, but I cannot do it without purchasing the commercial version.
Qt is under a dual QPL/GPL license. This makes it usuable by any application under any open source license. It would be nice if it were under licensing that granted more freedom, but at least it has a nice symmetry (closed for closed, open for open).
The LGPL has a few niggly problems of its own, which smacked me right in the face the first time I tried to use an LGPL library for a commerical app on an embedded COFF system. Besides which, the LGPL has more ifs, elses, exeptions and caveats than most volumes of the Federal Register. We really need an LGPL like license that understandable by laymen.
If you find a pamphlet in the street, take it home, and copy it in the privacy of your own home for your personal enjoyment, then you are breaking the law, because you don't have the copyright.
I checked (US) copyright law again. I will apologize for exaggeration. I was in error. However, the law does allow for copying for archival purposes. The law seems to suggest that only one such copy can be made, though there are a few references in the plural.
The reverse works as well. You spend $50K for support, find out you don't need it because all the defaults are correct, it's easy to use, easy to administer, and does everything you need. Next year you screw the support, and just download it.
Yes. Plain vanilla copyright. Just insert the words "Copyright (c) 2001, J. Random Hacker".
Then give them the source code. Copyright law will allow them to fold, spindle, mutilate and otherwise experiment with the source code. They can reverse engineer it, make archival copies, modify for their own personal use, yada, yada, yada. But they will not have the rights to redistribute it.
IMHO, all proprietary software should be plain vanilla copyright, and all free software should likewise be plain vanilla copyright with the addition of a permission statement.
Why is corelib released under the GPL? Why not the LGPL or other license more appropriate to shared libraries? Will there be an option to purchase it under a proprietary license for those wishing the freedom to develop with it? Since quite a few KDE core applications are under non_GPL free software licenses (KWin, Kicker, etc), will they be barred from using KoreLib?
Of course. I am not disputing that GIMP is not necessary. I just find it strange that GNU considers GIMP and other end user applications to be a part of the operating system. As equally strange as Microsoft claiming IE is part of the OS.
It's like the window managers that come with Red Hat.
Slightly more relevant, though still a bad analogy, would be package management. RPM is an integral part of Redhat. The DEB format is an alternate format that has a few advantages over RPM. Yet you cannot totally remove RPM from you Redhat system and replace it with DEB! You would then be unable to install any Redhat packages. Even if you used alien or other similar tool, you still need RPM around.
Or maybe even more germane: GNOME. Many of the Redhat utilities use the GNOME libraries. You must have parts of GNOME installed even if you use the KDE desktop, or you have to forego the use of those Redhat utilities. If I use Netscape on Windows I still have to have Exploder installed. If I use KDE on Redhat I still have to have GNOME installed.
Otherwise every application could be considered part of the OS.
Microsoft isn't the only organization that believes that. GNU is an operating system. GIMP is a part of GNU. Thus GIMP is a part of an operating system. Wow!
Although shared/dynamic linking doesn't change the binary on the HDD, It does alter it in RAM, making it impossible to tell apart where the your program ends and the library starts, thus modifying you program.
The alteration of RAM is performed by the end user in the privacy of his or her own home. The GPL does not apply, and specifically says so ("The act of running the Program is not restricted"). I, myself, have not distributed, modified or publicly copied any GPL covered software.
And please look up the definition of "modify". Being unable to distinguish the boundaries of the library in RAM does not constitute modification.
If I do not accept/assent to the GPL, then I am not allowed to distribute or modify the program. Copyright law still allows me to use the program for any purpose, to copy the program for my own personal use, to reverse engineer the program, and to publish benchmarks and reviews on the program. (fair use is a slightly different matter).
When I create a binary that is intended to dynamically link to a GPL library, and distribute that binary, I am not distributing or modifying the GPL library. No part of the GPL source is included in my application, either verbatim or translated by a compiler. (a few exceptions exist, which I noted previously)
I've already teared aprt your arument in another psot
Wow! I didn't now that I had an arument that had an aprt teared in by a psot!
But I am *not* purchasing Linux! I am downloading it for free with no payments to anyone. My monetary vote in the free market election is "none of the above".
GPL is designed to prohibit the use of GPLed software in close-source non-free (in GPL's sense of the world 'free') programs
If GPLd software were indeed contained *within* the closed-source software, then the GPL applies. But in the case of dynamic and runtime linkage, this is not the case. The library is not a part of the application, nor contained within it. They may reside in the same process space, but it is the end user who causes that to happen, and the GPL allows complete and total permission to run the program for any purpose.
Wrong. Usage of GPL'd works is completely unrestricted. It only restricts copying, distributing and modifying the work. To quote from the GPL: "Activities other than copying, distribution and modification are not covered by this License."
The license says "if it is linked in thus-and-such a way, you must do these things."
To quote the GPL again: "a "work based on the Program" means either the Program or any derivative work under copyright law."
The GPL is operating under copyright law. It cannot change copyright law, and copyright law is completely silent on the topic of linking. The GPL does not apply to linkage unless it can be demonstrated that the linking process copies, distributes or modifies the Program. It does none of these. (actually a copy is created during program execution by the end user, but the copyright law and the GPL already allow that).
This is no different than a MS license saying "you may not publish benchmarks of this software without consent."
The GPL does not take away any rights already granted by copyright law, and clarifies this point in section 5. The Microsoft EULA, on the other hand, takes away rights that the law has already given to the user. You already have the legal right (in the US) to publish benchmarks about Microsoft products. If you agree and assent to the MS EULA contract, however, you have agreed to waive that right.
Slashdot Mirror
We used to connect to the university lab with 300 baud modems. 4.1BSD UNIX was quite usable with it. It was even sufficient for rogue.
I don't believe you need Jakarta in the tool chain. Definitely not Apache. Just Xerces, Xalan and FOP.
I'm using DocBook/XML with the Jade tool chain. But as soon as Xalan lets me resolve public identifiers locally, I'll switch to it. Until then, some of us are behind firewalls, have slow connections, etc.
Linux may be the most "prominent" example of Open Source, but the three pieces of Open Source work that are actually the most used are not listed either. Perl, Apache and XFree86.
The OSD is not meant to be a definitive archive. It's mission is to provide a resource for users. I think it has a done a good job in this regard.
However, RMS created gcc.
So? Gcc is used to build OpenBSD. Should we now call that GNU/OpenBSD? It is also used to build the OS that we use at work for embedded systems. Should we call it GNU/LynxOS? Or what about GNU/Macintosh OS X?
You do not name a system after the tool chain. That is so silly that even RMS dismisses it. Next thing you know you'll want me to name my doghouse "Stanley" after the brand of hammer I used.
Talks like a duck, quacks like a duck, it is a duck.
The GNU System has not yet been shipped. It is incomplete. So far, I have not heard it talk or quack, so I have no reference with which to compare it to Slackware's talk and quack. Which, by the way is extremely similar to the talk and quack of Solaris, IRIX, BSD and every other Unix and Unix-like system.
My company creates very large and very expensive embedded devices. We recently shipped two new products.
The first product (call it Alpha) was designed and created by us, but manufactured by Fujistu. Should this product be called "Alpha" or "Fujistu/Alpha"?
The second product (call it Beta) was designed, created and assembled by us. But every board was built by Solectron. Should this product be called "Beta", or "Solectron/Beta"? Or should it be called "Xylinx/Solectron/Beta"?
If I build a new house from parts purchased as Lowe's, I do not call my new home "Lowe's Manor". Likewise, if Patrick Volkerding created an operating system where the parts came from GNU, he does not have to call the finished product "GNU/Linux". Indeed, only a fraction of the parts he used came from GNU anyway.
To quote Linus, "Your midwife doesn't select the name of your babies."
Thank you for setting the persective straight. Adobe is pretty sleazy, but they have nothing on the US government when it comes to corruption. If the government did not have the legislative process up for sale, no one could buy it.
Yellow Dog Linux (it's official name) is most certainly not The GNU System. It can't be, as a completed GNU System has not yet been shipped.
Most certainly it is not The GNU System with merely a different kernel. Go buy the Deluxe GNU distribution, pop in the linux kernel, and it won't work. (To be fair, it won't work with Hurd either). Take any given Linux distro and merely replace the kernel with Hurd and it won't work.
Merriam Webster's dictionary defines "operating system" as "software that controls the operation of a computer and directs the processing of programs". That sounds like a kernel to me. But I'll be generous and allow a certain amount of infrastructure as well. But it still doesn't cover bash (you can use a dozen other shells instead), glibc, emacs or gcc. It would cover ld, init and the file system, none of which on my system come from GNU.
I've looked all over my Slackware box, CD and installed documentation. I've even perused the Slackware web page. I cannot find any reference whatsoever to something called "Slackware GNU/Linux". Patrick Volkerding created Slackware, and he is the one that gets to name it.
FreeBSD's boot loader will load anything with no messy configuration scripts. Just install and boot. Too easy.
The title says "GNU/Linux". The text of the announcement says "Yellow Dog Linux". Which is it? Debian or YDL?
The new version will have a dual licensing model similar to TrollTech's Qt (GPL/QPL/commercial), thus allowing non-GPL applications (either commercial or under an OSI approved license) to use korelib.
This is a good thing to hear. Often times the community forgets that there are other licenses than the GPL. I have some BSD licensed apps that I would dearly love to port to Qt-Embedded, but I cannot do it without purchasing the commercial version.
Qt is under a dual QPL/GPL license. This makes it usuable by any application under any open source license. It would be nice if it were under licensing that granted more freedom, but at least it has a nice symmetry (closed for closed, open for open).
The LGPL has a few niggly problems of its own, which smacked me right in the face the first time I tried to use an LGPL library for a commerical app on an embedded COFF system. Besides which, the LGPL has more ifs, elses, exeptions and caveats than most volumes of the Federal Register. We really need an LGPL like license that understandable by laymen.
If you find a pamphlet in the street, take it home, and copy it in the privacy of your own home for your personal enjoyment, then you are breaking the law, because you don't have the copyright.
I checked (US) copyright law again. I will apologize for exaggeration. I was in error. However, the law does allow for copying for archival purposes. The law seems to suggest that only one such copy can be made, though there are a few references in the plural.
The reverse works as well. You spend $50K for support, find out you don't need it because all the defaults are correct, it's easy to use, easy to administer, and does everything you need. Next year you screw the support, and just download it.
The service and support model is a huge incentive to ship shoddy shit.
Yes. Plain vanilla copyright. Just insert the words "Copyright (c) 2001, J. Random Hacker".
Then give them the source code. Copyright law will allow them to fold, spindle, mutilate and otherwise experiment with the source code. They can reverse engineer it, make archival copies, modify for their own personal use, yada, yada, yada. But they will not have the rights to redistribute it.
IMHO, all proprietary software should be plain vanilla copyright, and all free software should likewise be plain vanilla copyright with the addition of a permission statement.
Why is corelib released under the GPL? Why not the LGPL or other license more appropriate to shared libraries? Will there be an option to purchase it under a proprietary license for those wishing the freedom to develop with it? Since quite a few KDE core applications are under non_GPL free software licenses (KWin, Kicker, etc), will they be barred from using KoreLib?
Of course. I am not disputing that GIMP is not necessary. I just find it strange that GNU considers GIMP and other end user applications to be a part of the operating system. As equally strange as Microsoft claiming IE is part of the OS.
It's like the window managers that come with Red Hat.
Slightly more relevant, though still a bad analogy, would be package management. RPM is an integral part of Redhat. The DEB format is an alternate format that has a few advantages over RPM. Yet you cannot totally remove RPM from you Redhat system and replace it with DEB! You would then be unable to install any Redhat packages. Even if you used alien or other similar tool, you still need RPM around.
Or maybe even more germane: GNOME. Many of the Redhat utilities use the GNOME libraries. You must have parts of GNOME installed even if you use the KDE desktop, or you have to forego the use of those Redhat utilities. If I use Netscape on Windows I still have to have Exploder installed. If I use KDE on Redhat I still have to have GNOME installed.
Otherwise every application could be considered part of the OS.
Microsoft isn't the only organization that believes that. GNU is an operating system. GIMP is a part of GNU. Thus GIMP is a part of an operating system. Wow!
Although shared/dynamic linking doesn't change the binary on the HDD, It does alter it in RAM, making it impossible to tell apart where the your program ends and the library starts, thus modifying you program.
The alteration of RAM is performed by the end user in the privacy of his or her own home. The GPL does not apply, and specifically says so ("The act of running the Program is not restricted"). I, myself, have not distributed, modified or publicly copied any GPL covered software.
And please look up the definition of "modify". Being unable to distinguish the boundaries of the library in RAM does not constitute modification.
If I do not accept/assent to the GPL, then I am not allowed to distribute or modify the program. Copyright law still allows me to use the program for any purpose, to copy the program for my own personal use, to reverse engineer the program, and to publish benchmarks and reviews on the program. (fair use is a slightly different matter).
When I create a binary that is intended to dynamically link to a GPL library, and distribute that binary, I am not distributing or modifying the GPL library. No part of the GPL source is included in my application, either verbatim or translated by a compiler. (a few exceptions exist, which I noted previously)
I've already teared aprt your arument in another psot
Wow! I didn't now that I had an arument that had an aprt teared in by a psot!
But I am *not* purchasing Linux! I am downloading it for free with no payments to anyone. My monetary vote in the free market election is "none of the above".
GPL is designed to prohibit the use of GPLed software in close-source non-free (in GPL's sense of the world 'free') programs
If GPLd software were indeed contained *within* the closed-source software, then the GPL applies. But in the case of dynamic and runtime linkage, this is not the case. The library is not a part of the application, nor contained within it. They may reside in the same process space, but it is the end user who causes that to happen, and the GPL allows complete and total permission to run the program for any purpose.
Dependency is not derivation.
All that matters is that they use GPL'ed works.
Wrong. Usage of GPL'd works is completely unrestricted. It only restricts copying, distributing and modifying the work. To quote from the GPL: "Activities other than copying, distribution and modification are not covered by this License."
The license says "if it is linked in thus-and-such a way, you must do these things."
To quote the GPL again: "a "work based on the Program" means either the Program or any derivative work under copyright law."
The GPL is operating under copyright law. It cannot change copyright law, and copyright law is completely silent on the topic of linking. The GPL does not apply to linkage unless it can be demonstrated that the linking process copies, distributes or modifies the Program. It does none of these. (actually a copy is created during program execution by the end user, but the copyright law and the GPL already allow that).
This is no different than a MS license saying "you may not publish benchmarks of this software without consent."
The GPL does not take away any rights already granted by copyright law, and clarifies this point in section 5. The Microsoft EULA, on the other hand, takes away rights that the law has already given to the user. You already have the legal right (in the US) to publish benchmarks about Microsoft products. If you agree and assent to the MS EULA contract, however, you have agreed to waive that right.