Slashdot Mirror

• BMI Declare that all their future music CDs will be copy protected
• While EMI Germany do likewise, they also insult the complainant. (I'm informed it is even harsher than the translation)
• And soon you won't be able to return the CD if it doesn't work (UK)
• And beware of innovations (this article, beat you to it slashdot - nyah nyah!), as they may be slipping DRM in the back door
• Web radio was getting very popular, everyone was getting in on the act. Not any more. Only the big radio stations still broadcast.
• Microsoft joined the party with their "Trusted Computing" initiative, meaning *you* can trust MS software, Which in reality is a DRM thing (MS software can't trust you)
• Oh, and extending copyright. Courts admit that it can't be extended indefinately, but how long is a piece of string?

• Reuters sued for linking to a URL
• They haven't been the first to be sued for deeplinking. Check out This particularly fine example.
• How a single sniper is more dangerous than all the world's hackers combined

• Getting sued for silence
• Thanks to the CBDTPA, nearly everything *must* embed DRM. This includes cockpit voice recorders, digital speed cameras, hearing aids, and big mouth billy bass
• Even phoning a friend can breach copyright, 2 musicians copyright 100,000 phone numbers (dial tones).

• A review of the technologies shows that it is futile to protect CDs, (based on the assumption that new devices will more likely circumvent protection rather than enforce it)
• Richard Stallman (Free Software advocate) jumps in with a cautionary tale
• And a felt tip pen can bypass some protections

Check out this link at the Mailman website. It details who's using it. Names like Apple Computer. My recollection from about a year a go was that the had a 1 million user list. I use Mailman as well for all client list serves. Works great.

"If you care about what you are running on your system, you should already know who contributed what aspects."

Most people don't know, even if they do care. Head over to a LUG meeting. I'd wager the great majority of them care, but only a few properly know the history of the system. Obviously if they're interested, education is something that should be given to them. That's why I tell them about the history of the system, and clarify for confused people (such as yourself) about why it's called GNU/Linux.

"Under this logic, windows graphic and multimedia designers should be calling their machines Adobe/Windows or Macromedia/Windows, etc, etc, etc."

Microsoft does follow the same naming contention very closely:
Windows 95
Windows 98
Windows ME
Windows NT
Windows XP

First is Windows, which encompases the API (libraries) and interface (UI) and most of the userland (the ubiquitous Notepad :)). Second is the kernel (the "friendly name" of it), with flavours following ("Professional," "Server," etc). RMS also answers why it's GNU/Linux instead of GNU Linux because:
"Following the rules of English, in the construction "GNU Linux" the word "GNU" modifies "Linux". This can mean either "GNU's version of Linux" or "Linux, which is a GNU package." Neither of those meanings fits the situation at hand."

The BSDs also follow this naming contention, with Free, Open, or Net prefixing the BSD kernel. GNU/BSD would be a BSD distribution which has a complete GNU userland around a BSD kernel, with the slash to denote that they are logically separated.

As for more credit than credit is due: I have no problem for giving RMS the credit for starting freely available, modifyably software back in the 1980s before anyone else was developing software for the purpose of giving it away. If you don't like it, TS. Unless you build a time machine to beat him to the punch, he deserves the credit.

"If you care about what you are running on your system, you should already know who contributed what aspects."

Most people don't know, even if they do care. Head over to a LUG meeting. I'd wager the great majority of them care, but only a few properly know the history of the system. Obviously if they're interested, education is something that should be given to them. That's why I tell them about the history of the system, and clarify for confused people (such as yourself) about why it's called GNU/Linux.

"Under this logic, windows graphic and multimedia designers should be calling their machines Adobe/Windows or Macromedia/Windows, etc, etc, etc."

Microsoft does follow the same naming contention very closely:
Windows 95
Windows 98
Windows ME
Windows NT
Windows XP

First is Windows, which encompases the API (libraries) and interface (UI) and most of the userland (the ubiquitous Notepad :)). Second is the kernel (the "friendly name" of it), with flavours following ("Professional," "Server," etc). RMS also answers why it's GNU/Linux instead of GNU Linux because:
"Following the rules of English, in the construction "GNU Linux" the word "GNU" modifies "Linux". This can mean either "GNU's version of Linux" or "Linux, which is a GNU package." Neither of those meanings fits the situation at hand."

The BSDs also follow this naming contention, with Free, Open, or Net prefixing the BSD kernel. GNU/BSD would be a BSD distribution which has a complete GNU userland around a BSD kernel, with the slash to denote that they are logically separated.

As for more credit than credit is due: I have no problem for giving RMS the credit for starting freely available, modifyably software back in the 1980s before anyone else was developing software for the purpose of giving it away. If you don't like it, TS. Unless you build a time machine to beat him to the punch, he deserves the credit.

• Translators: userspace programs programs to act as a file or a hierarchical directory. Device drivers, filesystems, etc are implemented as translators in Hurd.
• A security structure to allow arbitrary users to install arbitrary translators as needed to the system without compromising security or system integrity.
• Multiple authentication servers, allowing different parts of the system to have completely different security models.
• A very flexible interprocess communication model.
• Many other, more subtle, innovations I don't have time to list.

The FSF is also modifying the GNU General Public License (GPL), though the fundamental principles will remain unchanged, according to Stallman.
"We have looked at, for example, adding a clause that explicitly states that you give a patent license when you redistribute the software," Stallman added.


This will hopefully remove some incompatibilityies between the GPL and other free licenses such as the IBM Public License 1.0 used for Eclipse.

Sorry, but that is just propaganda. The hurd uses a microkernel, not a monolithic kernel - so in saying "the whole kernel" you are actually only talking about a rather small part of the system in comparison to, say, Linux, where the kernel performs a rather large array of tasks. Having to replace "the whole kernel" is not as huge of a task as you make it out to be, that in itself is one of the advantages of a microkernel based design. The main problem that the hurd suffers from is a lack of developers * time.
Nobody gets paid to work on the hurd, AFAIK.

You're totally misinterpretting Mr. Stallman's beliefs about naming.

Probably.

A modular layer deep in the kernel which can be swapped at will is not really relevant to it.

"Swapped at will?" Not to put to fine a point on it, but this is in an article about the Hurd being delayed an indeterminate amount of time due to just such a swap.

You could ask why XFree86 is not in the name of GNU/Linux, and you'll be told it's because only the GNU and Linux parts were designed towards the goal of a free system.

1) I really don't believe those were the only parts developed towards the goal of a free system, so I suspect I must be misinterpreting your point, and 2) I would suspect I would really be told that you can have a perfectly reasonable Gnu/Linux system without XFree86. The GNU/Linux FAQ seems to imply it's really a matter of giving credit for effort, and not a matter of the philospohical goals.

GNU is the only operating environment designed to be free as in freedom from the very start, which is why Mr. Stallman asks that you properly credit the GNU contributors for their many man-centuries of effort.

Doesn't follow. Mach sure seems like it's free (and thus Hurd can use it), and it seems necessary to enabling the Hurd to exist. I still don't see why the efforts of the developers deserve any less credit for their man-years of effort towards making Hurd possible.

I'm not trying to be arbitrary here; I don't know all the issues, and I didn't know about the planned port to a different microkernel, but it seems like the current Hurd owes a lot of credit to the existence of Mach, in a way simliar to the way Linux-based OSes owes a huge amount of credit to the existence of GNU.

Your trolling questions are answered in very nice detail here.

In a nutshell:
The free operating environment he has been trying to create for 20 years is called GNU. This encompases a kernel, userland, system libraries, compilers, etc. It's a whole, big lot of work. They started out with the editors, a C library, and a compiler so they could write the rest, and they went very far. GNU userlands started to supplant the traditional ones on most UNIX machines because GNU applications were full featured and matured quickly (try the BSD userland sometime, you'll start to notice missing options quickly), and because they were open and free.

But their kernel, the Hurd, lagged in development. Linus took the amazing GNU userland and added his Linux kernel. The GNU/Linux system was born, a fusion of the GNU userland and the Linux kernel. Mr. Stallman believes than Linus deserves much credit for bringing a free kernel into the world (remember, it was released when BSD was dealing with much legal ramblings), and that's why it's listed as a part of the name (and not just included in the name "GNU").

As to why it's not including other names, you could ask why XFree86 is not in the name of GNU/Linux, and you'll be told it's because only the GNU and Linux parts were designed towards the goal of a free system. XFree86 is just a reference implementation of X11R6 which runs on x86 (and other) hardware.

I would like to see a GNU/BSD system myself, because the Linux kernel can be buggy, and verification that the bug is in the kernel is a lot less hard if I use one system which can boot a few different kernels.

GNU/Hurd. 19 years in the making, and worth every minute of it.

That's not entirely fair. A lot of Linux-based OSes contain very healthy doses of GNU software and are compiled with GCC, one of the first major contributions of GNU.

The kernel was one of the last things they tackled, but along came Linus Torvalds and now many OS kernel developers would rather work on Linux than the Hurd.

Bang on the money.

If I might add to what you've pointed out, RMS has explained that the motivation for continuing development of the Hurd is that it has the potential to be something much more powerful.

Which leads to what really bothers me about the Slashdot crowd's reaction to the Hurd. Lot's of people I know criticize Free/Open Source Software just rips stuff off, and doesn't innovate. Well, the Hurd is one of the most innovative Free Software projects around. These guys were talking about buiding a multi-server OS back at the beginning of the 90s.

Come on, once the Hurd is finished, GNU/Hurd will be years ahead of GNU/Linux, Windows NT, or Mac OSX. The only other OS I know of that's as theoretically-advanced as GNU/Hurd is QNX another multi-server.

This is cool stuff. Unfortunately, it seems that most people just want to complain, "Oh, does it have the drivers for XXXXX? No. Then it's useless." Grow up - the value of an operating system isn't defined by what hardware it runs on. That's much easier to change than the fundamental architecture of the system.

http://www.gnu.org/software/hurd/hurd.html

GNU HURD is a slimmer re-write of the UNIX kernel that is completely OOP.

Here's a cut and paste from the homepage:

The Hurd is not the most advanced kernel known to the planet (yet), but it does have a number of enticing features:

it's free software
Anybody can use, modify, and redistribute it under the terms of the GNU General Public License (GPL).
it's compatible
The Hurd provides a familiar programming and user environment. For all intents and purposes, the Hurd is a modern Unix-like kernel. The Hurd uses the GNU C Library, whose development closely tracks standards such as ANSI/ISO, BSD, POSIX, Single Unix, SVID, and X/Open.
it's built to survive
Unlike other popular kernel software, the Hurd has an object-oriented structure that allows it to evolve without compromising its design. This structure will help the Hurd undergo major redesign and modifications without having to be entirely rewritten.
it's scalable
The Hurd implementation is aggressively multithreaded so that it runs efficiently on both single processors and symmetric multiprocessors. The Hurd interfaces are designed to allow transparent network clusters (collectives), although this feature has not yet been implemented.
it's extensible
The Hurd is an attractive platform for learning how to become a kernel hacker or for implementing new ideas in kernel technology. Every part of the system is designed to be modified and extended.
it's stable
It is possible to develop and test new Hurd kernel components without rebooting the machine (not even accidentally). Running your own kernel components doesn't interfere with other users, and so no special system privileges are required. The mechanism for kernel extensions is secure by design: it is impossible to impose your changes upon other users unless they authorize them or you are the system administrator.
it exists
The Hurd is real software that works Right Now. It is not a research project or a proposal. You don't have to wait at all before you can start using and developing it.

GNU/Hurd. 19 years in the making, and worth every minute of it.

Finally the world will have a politically correct OS that works just like other Unices have for decades.

As Eben Moglen has said, the GPL has been enforced dozens of times. Potential violators have always backed down and settled before going to court, but that in itself is enforcement.

The fact that no corporate lawyer has yet dared to challenge the FSF in court should tell you something. In many cases, the FSF obtains settlements that require senior managers to report to the FSF regularly on their use of GPL software and their efforts to comply with licenses.

While my snappy answers to stupid questions usually end here, I feel I should elaborate, lest I be called a troll or worse a (gasp) Linux user.

I feel I have sufficent knowledge to answer this question in the affirmative based on my following experiences:

• Developing software using carbon on an iBook (450 MHz G3, 128MB RAM). I usually set up my Linux box to run Mozilla for browsing documentation and playing OGGs, since running Project Builder under Mac OS X seems to eat up ALL the RAM (and iTunes won't play my OGGs anyway). Did I mention it takes forever to boot up? Did I mention it also takes at least five minutes to login before I can even start using it?
• Developing Tcl/Tk applications on a DUAL G4 (not sure what processor speed or amount of RAM, but it was at least DUAL 450s with at least 512 MB of RAM). You'd think running Mac OS X, a multi-tasking, multithreading operating system, on a dual processor machine would be fast, right? Wrong. This was also butt ass slow. Everything from loading a simple browser to opening a terminal, while not taking minutes, felt like it.

GNU's Not Unix!
(GNU's Not MySQL Either)

Underneath is an altered picture of a GNU humping a dolphin.

TeXmacs!=Emacs. In TeXmacs, WYSIWYG. I just thought I'd mention that, although I must admit my original post was a bit stupid (i.e. 8-year-olds don't yet need the features of LaTeX). Thus, in an attempt to vindicate myself, I'll mention the DebianEdu and Debian Jr. projects. Even if the original poster didn't intend to use Debian, these projects could provide ideas of what to include.

Might as well start while you're young. Use emacs(and gcc while you're at it). Might as well go open source also.

Might as well start while you're young. Use emacs(and gcc while you're at it). Might as well go open source also.

If you haven't already, read Right to Read It's by RMS, it is an almost eerie prediction that seems to be coming more and more true each day. This summarizes what most of us are seeing happen slowly.

Try the solution that has been successful for most of the GNU projects. Take a careful look at GNU's automake and autoconf packages. You'll find them at the Program Build Automation section of the GNU software directory. In addition to the reference manuals from GNU, you'll want to read through the book Autoconf, Automake, and Libtool
which is the only book I've found on the subject.

I've just started using these tools in the last couple of months, replacing a complex and brittle hand-coded multi-platform makefile system. To be perfectly honest, there isn't enough tutorial information for setting up a new project. But once you figure out the magic incantations that your software needs, autoconf seems to do a nice job of detecting incompatibilities and passing them through the make system to your code. Automake generates the thousand-line makefiles replete with targets for all, clean, install, etc. All I have to do is list the source code files for a given module or library. These tools will do the rest.

That isn't to say that my code became instantly portable. After we got a small application working on HP-UX, we just configure/make'd on Windows. Everything compiled under mingw, but the Windows crtl has different ideas about little posixy things like user names. So we had to add some portability code based on the checks that configure performs for us.

Overall, I'm looking forward to not messing around with makefile systems much any more, and concentrating on the more interesting bits of software development.

As a matter of fact, the lawyer is quite right about the matter of writting a non gpl-conformant module to the kernel. You may consult a lawyer, or you may read the GPL FAQ.
The apropriate solution would be one that made all the software that use the kernel APIs open sourced and GPL conformant - and, ona separte software layer, make the proprietary calls to your device, without touching the kernel API, but using an API on your own GPLed layer, which license contains exceptions of the GPL to allow the use of the proprietary part of the software.
Actually, there is this whole session on the GPL FAQ dealing with these issues.

As a matter of fact, the lawyer is quite right about the matter of writting a non gpl-conformant module to the kernel. You may consult a lawyer, or you may read the GPL FAQ.
The apropriate solution would be one that made all the software that use the kernel APIs open sourced and GPL conformant - and, ona separte software layer, make the proprietary calls to your device, without touching the kernel API, but using an API on your own GPLed layer, which license contains exceptions of the GPL to allow the use of the proprietary part of the software.
Actually, there is this whole session on the GPL FAQ dealing with these issues.

You will probably need some toolkits. Basic things like multi-threading are generally non-portable.

For a GUI, FOX or wxWindows may help. For threads, you may want to consider JThreads/C++, especially if you intend to add a Java front-end to a client-server style system. Alternatively, there are packages like pth or various MPI products to fit the bill. The MPI products have slightly higher overhead/configuration, but open the door to Beowulf applications.

Since you have a functional Makefile system, I would recommend keeping it unless you get some big bang (e.g. current system is very badly written) by ditching it. You can help by using GNU's make instead of the platform's native make. This will remove the portability issues from Makefiles and adds "if then else" constructs to better handle portability. Remember that a Makefile is a set of AI inference rules and not a procedural language (though many try to use it as such).

You will probably need some toolkits. Basic things like multi-threading are generally non-portable.

For a GUI, FOX or wxWindows may help. For threads, you may want to consider JThreads/C++, especially if you intend to add a Java front-end to a client-server style system. Alternatively, there are packages like pth or various MPI products to fit the bill. The MPI products have slightly higher overhead/configuration, but open the door to Beowulf applications.

Since you have a functional Makefile system, I would recommend keeping it unless you get some big bang (e.g. current system is very badly written) by ditching it. You can help by using GNU's make instead of the platform's native make. This will remove the portability issues from Makefiles and adds "if then else" constructs to better handle portability. Remember that a Makefile is a set of AI inference rules and not a procedural language (though many try to use it as such).

using autoconf might help you out

Please see the GNU FAQ on this point, which I quote:

If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in.

It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, so plug-ins must be treated as extensions to the main program. This means they must be released under the GPL or a GPL-compatible free software license.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case.

Drivers are not a borderline case. They do much more linking and data structure sharing than just invoking main with options. Their program, the kernel, "dynamically links plug-ins [drivers], and they make function calls to each other and share data structures".

There is a way to allow proprietary modules, but it requires a special license clause for the platform; see again the FAQ.

The inability to create proprietary plugins to extend a free platform is an important and possibly deliberate problem with the GPL. It makes it more difficult to build proprietary software by imposing an arbitrary restriction on its relationship to GPL software.

Please see the GNU FAQ on this point, which I quote:

If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in.

It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, so plug-ins must be treated as extensions to the main program. This means they must be released under the GPL or a GPL-compatible free software license.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case.

Drivers are not a borderline case. They do much more linking and data structure sharing than just invoking main with options. Their program, the kernel, "dynamically links plug-ins [drivers], and they make function calls to each other and share data structures".

There is a way to allow proprietary modules, but it requires a special license clause for the platform; see again the FAQ.

The inability to create proprietary plugins to extend a free platform is an important and possibly deliberate problem with the GPL. It makes it more difficult to build proprietary software by imposing an arbitrary restriction on its relationship to GPL software.

gcc is cross-platform, can cross-compile to different platforms, and for those who feel the need to use Windows, gcc has been ported, to the ever-popular development suite called DJGPP.

GCC
DJGPP

First, IANAL.

Second, take a look at http://www.gcom.com/home/support/whitepapers/linux -gnu-license.html which contains a post from Linus where he explains that the Kernel Module Interface is actually LGPL.

Next, see http://www.gnu.org/licenses/lgpl.html Read section 5. In particular, the paragraph :

"If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)"

This leads one to believe that Binary-Only Device Drivers are A-OK.

Nvida and other graphics board developers aren't the only ones providing binary only drivers.... Adaptec only provides binaries for their RAID controller drivers - no sources at all. Not even
an "intermediate buffer layer"

The spirit of the LGPL licence seems to be "If you can upgrade the LGPL code without having to recompile the Proprietary stuff, and continue to have everything work, that's ok."

> Simply using library functions of GPL'd software doesn't mean you have to release your source code.
> It does mean, however, that you should credit somebody else's work for giving you the
> functionality that you didn't write yourself.

This is not insightful, this is wrong.
See GPL-FAQ:

"You have a GPL'ed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program?"
Yes.
There seem to be some exceptions for the kernel though, see other postings.

drive the device without revealing intellectual property

Instead of saying "intellectual property", say "copyrights", "patents", or "trade secrets", which are almost completely unrelated to one another in the U.S. federal and state legal codes. Under which part of the law do you claim your company is trying to protect its monopoly?

Is your company trying to make money selling drivers? Don't. Here's why not:

Later Xerox gave the AI Lab a newer, faster printer, one of the first laser printers. It was driven by proprietary software that ran in a separate dedicated computer, so we couldn't add any of our favorite features. We could arrange to send a notification when a print job was sent to the dedicated computer, but not when the job was actually printed (and the delay was usually considerable). There was no way to find out when the job was actually printed; you could only guess. And no one was informed when there was a paper jam, so the printer often went for an hour without being fixed.

The system programmers at the AI Lab were capable of fixing such problems, probably as capable as the original authors of the program. Xerox was uninterested in fixing them, and chose to prevent us, so we were forced to accept the problems. They were never fixed.

"Nobody wants to force you to give away some original work..."

Not true, that is the entire purpose of the GPL.
If you profit from the use of GPL code, you are
forced to donate your source code. This is being
[en]forced every day by FSF legal counsel. See

Enforcing the GNU GPL

The recent battle between Progress Software and
MySQL is a case in point.

My company uses Linux in some of our embedded products. Before doing so, and before we had fulltime counsel, we hired a lawyer to go over the GPL and tell us if it was going to present a problem. This lawyer seemed to think that anything compiled with GCC would fall under the GPL, which is incorrect. There are specific exceptions that allow it to be used to produce non-free software.

I'm not saying he should ignore the lawyer, but that his lawyer could quite possibly be wrong. The GPL is 'viral' in a sense, but not in as devious a way as Microsoft FUD would indicate, and at least they are up front about being a bunch of commies =)

See http://www.gnu.org/licenses/gpl-faq.html for more info.

Ed is the standard, and this is the standard ed comment.

from http://www.gnu.org/fun/jokes/ed.msg.html
i found the original alt.religion.emacs post here: groups.google.com

... nevermind, there is no way this post is making it past the lameness filter. too bad, read the link.

This post and these questions are made assuming Microsoft is the antithesis of Open Source. If Microsoft has a good day, open source has a bad day. If Microsoft loses, Open Source wins. In this light, any question about Microsoft can be seen as relating to Open Source Software.

From no point of view does the judge's decision make sense. Microsoft is as large a company as there ever has been, and they've gotten that way by screwing people (Microsoft tax on OEM machines), other companies (Microsoft Java VM, etc) , and the government (billions wasted on NT) at every turn. As large as they are, one could speculate that turning this case against Microsoft would devastate the economy (if one were a fool, of course). Is it possible that the ruling was made in favour of Microsoft in order to not dent the economy? Whether or not this was done, nobody with any sense expects Microsoft's tactics to change, so when this court case comes around again next time, how difficult will it be to make a case, considering that Microsoft doesn't have to turn over documents they judge to hold IP, coupled with the precedence this case sets?

With Microsoft's won-loss record in the courts, what would occur if they tried to step on the GPL (a prevalent license of Open Source Software)? If they defeated the viral parts of the GPL, would the entire license be void, or would just the viral parts be NULL? Finally, as a not-a-lawyer, I can't tell who the "we" in the preamble of the GPL means. When I read it, it sounds like the "we" refers to the Free Software Foundation. If just a portion of the GPL were defeated, would the FSF own the copyright to all the software ever GPL'd, but not have to play by it's viral rules anymore?

This post and these questions are made assuming Microsoft is the antithesis of Open Source. If Microsoft has a good day, open source has a bad day. If Microsoft loses, Open Source wins. In this light, any question about Microsoft can be seen as relating to Open Source Software.

From no point of view does the judge's decision make sense. Microsoft is as large a company as there ever has been, and they've gotten that way by screwing people (Microsoft tax on OEM machines), other companies (Microsoft Java VM, etc) , and the government (billions wasted on NT) at every turn. As large as they are, one could speculate that turning this case against Microsoft would devastate the economy (if one were a fool, of course). Is it possible that the ruling was made in favour of Microsoft in order to not dent the economy? Whether or not this was done, nobody with any sense expects Microsoft's tactics to change, so when this court case comes around again next time, how difficult will it be to make a case, considering that Microsoft doesn't have to turn over documents they judge to hold IP, coupled with the precedence this case sets?

With Microsoft's won-loss record in the courts, what would occur if they tried to step on the GPL (a prevalent license of Open Source Software)? If they defeated the viral parts of the GPL, would the entire license be void, or would just the viral parts be NULL? Finally, as a not-a-lawyer, I can't tell who the "we" in the preamble of the GPL means. When I read it, it sounds like the "we" refers to the Free Software Foundation. If just a portion of the GPL were defeated, would the FSF own the copyright to all the software ever GPL'd, but not have to play by it's viral rules anymore?

I'd like to nominate this as the longest license.
I wouldn't even call it a license, it's political gibberish.

From the site: It is open-source (under the well know GPL) and available for non-commercial use. If you need a commercial license please email...

Ok, so someone enlighten me: Can a GPL'd program be released for non-commercial use with a separate license for commercial use, or does the GPL pretty much cover all use of the code? I checked the GPL FAQ, and the only case that comes close says that the license under which you received the code is the license that controls how you use the code. But that doesn't really cover the case where "This code is GPL for non-commercial use." Does the GPL permit that?

From the site: It is open-source (under the well know GPL) and available for non-commercial use. If you need a commercial license please email...

Ok, so someone enlighten me: Can a GPL'd program be released for non-commercial use with a separate license for commercial use, or does the GPL pretty much cover all use of the code? I checked the GPL FAQ, and the only case that comes close says that the license under which you received the code is the license that controls how you use the code. But that doesn't really cover the case where "This code is GPL for non-commercial use." Does the GPL permit that?

Have you heard the Fenster's version of the Free Software Song

I don't know if it's because RMS's version is so unpolished, but this song isn't bad. :)

That's a myth. The GPL doesn't stop people from profiting from your work. Read about it.

You mean like the GNU Hello, World! software?

--Jon

There may be no Linux song, but there's definitely a Free Software Song, lovingly performed by RMS.

When GPL'ed code is compatible with BSD licenced code, then I'll start giving a damn about what YOU think.

According to the GNU license list, code under the new BSD license can be used in a program licensed under the GNU GPL. Thus, the licenses are compatible.

To clear up any misconceptions that the sarcastic parent comment might have created:

GPL gets around this by asking that you give them the copyright and give them all the credit leaving you with none.

Actually, every author of a GPL program gets credit. The GNU GPL, section 2, requires that "You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change." Thus, the credit stays where it belongs, in the source code, documentation, and (for interactive programs) the about box, rather than in possibly unrelated advertising.

From the article:

3. All advertising materials mentioning features or use of this software must display the following acknowledgement:

This product includes software developed by Hubert Feyrer .

This form of the BSD license has a minor problem.

Emacs is released under the GPL. (...) The restrictions placed on developers by the GPL make it impossible for a commercial concern to use either of these programs, or components of them, as part of an IDE.

Actually, it has been done -- Energize, a C++ IDE made by Lucid Inc (it came out something around 1991-1992), used GNU Emacs as an editor (then forked* GNU Emacs to Lucid Emacs, which finally became XEmacs).

(*It was, as far as I know, the most controversial as well as the most significant fork in the free software community. See The Lemacs/FSFmacs Schism by Jamie Zawinski and A History of Emacs from the XEmacs Internals Manual for some informations about Lucid Energize (and for lots of GNU Emacs vs. Lucid/XEmacs flame wars). There's also a short explaination on GNU Emacs FAQ, question 8.6.)

So, the point is that Emacs can be used and has been used as a text editor in proprietary IDE, while still being released under the GPL. It was even being sold for well over $4000 per seat, back then.

That said, I totally agree with GusherJizmac's point: "The point is, why don't they use those editors as their basis for their integrated editor? Why re-invent the wheel so many times?" I, for one, won't touch any IDE with a text editor using which I'm much less productive than using Emacs, which is an ideal "IDE" for me -- but then again, I'm not a big fan of traditional IDEs, so what do I know (also, I don't use any proprietary software, so even if Komodo was in my opinion better than Emacs (or if it included Emacs for that matter), I still wouldn't use it, anyway -- I say it just to make things clear: Komodo may be great for a proprietary IDE).

OK, back to the topic -- Emacs can be legally used in proprietary IDEs and I suppose ActiveState could successfully use Emacs as an editor in Komodo and still be able to sell it. They didn't do that probably because they thought their customers would prefer ActiveState's editor over Emacs -- which I believe is true -- not because it's legally impossible with the GPL.

These are all configure/make problems. Make install are the worst, since if you EVER get rid of the source directory, you can't make uninstall. And many apps do not support make uninstall. Linux file/library management is in every respect sloppier than Windows.

One word: stow

stow enables you to manage all your installed programs using a very simple symlinking scheme. I urge you to check it out.