Slashdot Mirror

Just to clarify, I think he/she is thinking of the license for Guile, the GNU extension interpreter/library based on the Scheme language. The FSF added an exception to the GPL in this case, hoping that it would promote the use and development of guile by allowing proprietary software developers to link guile into their apps without requiring the software to be put under a GPL-compatible license. Guile may one day replace Emacs Lisp as the standard extensibility language for GNU Emacs.

Just to clarify, I think he/she is thinking of the license for Guile, the GNU extension interpreter/library based on the Scheme language. The FSF added an exception to the GPL in this case, hoping that it would promote the use and development of guile by allowing proprietary software developers to link guile into their apps without requiring the software to be put under a GPL-compatible license. Guile may one day replace Emacs Lisp as the standard extensibility language for GNU Emacs.

There isn't any ethical or legal problem with this at all. Their products are proprietary add-ons and services, it's hardly different in kind to what RedHat does. When they modify GPL code, they are obliged to GPL the mods. When they write their own code from scratch, they are not. There is no requirement that proprietary programs be GPLd to run under a GPL OS (ever heard of Oracle?)

Bottom line, as long as they comply with the terms of the GPL when it comes to GPL code, they can put whatever license they want on their own. There might be a minor nitpick if their license doesn't make it clear that it only applies to their proprietary programs, not the OS as a whole, I'll grant, but if that is the case it will be easily fixed. There was a similar flap awhile back about Corel's license, and it didn't turn out to be any big deal, I recall.

I wonder when RMS will spout on this... IMO, this is FAR worse than the KDE/QT controversy, and it'd be hypocritical of him to not condemn it.

First off the KDE/QT deal was a totally different issue. KDE was making Free, not proprietary software, yet they were using a library with a license incompatible with the license of their own software. Much more serious problem. Fortunately that one got fixed, though it wasn't easy, and for all the flaming certain immature individuals gave RMS over it, they should be thanking him - if he hadn't raised a stink KDE might still be in a legal limbo, and QT unfree.

RMS is no fan of Caldera, in fact he has expressed what could only be termed contempt for CEO Ransom Love in particular. But I'll be surprised if he loses his objectivity on this issue. If they need to clarify the wording of their license, that's fine, that's not the end of the world, and the FSF has always worked to resolve these little bumps quickly and quietly in the past. The GPL is not, and was explicitly never intended to be, anti-business. It's designed to allow writers of Free Software to share code without fear of their code being proprietarised (the major weakness of the BSD license.)

See this entry in the GPL FAQ. Calderas proprietary products are aggregated, not integrated, and as long as that is so, they can license them under any terms they wish.

This is absolutely, 100% wrong. Just check out this if you don't believe that. For those who don't want to follow the link, the FSF say, in part [emphasis is theirs]:

Actually we encourage people who redistribute free software to charge as much as they wish or can....

Since free software is not a matter of price, a low price isn't more free, or closer to free. So if you are redistributing copies of free software, you might as well charge a substantial fee and make some money. Redistributing free software is a good and legitimate activity; if you do it, you might as well make a profit from it.

Free software is a community project, and everyone who depends on it ought to look for ways to contribute to building the community. For a distributor, the way to do this is to give a part of the profit to the Free Software Foundation or some other free software development project. By funding development, you can advance the world of free software.

Distributing free software is an opportunity to raise funds for development. Don't waste it!

That sure doesn't sound like being opposed to selling the software. Nobody claims that RedHat or Mandrake are evil for selling copies of their software. The objection is to hooking a small bit of proprietary software onto a boatload of Free Software and using that as an excuse to restrict peoples' ability to use the Free Software as they choose.

Actually, IMPO, this is going to wind up hurting Caldera more than anyone. Why would somebody want to pay Caldera per-copy licenses when they could buy one copy from RedHat, Mandrake, Debian, etc. and install it on many computers? It's not as though Caldera's selection of packages, packaging system, or proprietary extensions make their product enough better to justify the additional charge. This is just going to scare away potential customers.

Quite a difference between improving something and totally rewriting it, even if in the end no original code remains.

Like LAME? Like GNU itself? The GNU system is a piecewise reimplementation of the UNIX® system. Until the free Linux kernel came around, the GNU system (gcc, Emacs, bash, etc.) ran on top of proprietary UNIX systems (and free BSD systems). Even Richard Stallman supports using proprietary software and semi-free software "temporarily for the specific purpose of writing a free replacement for that very program."

Heck, RMS used to charge for emacs!

Used to? He still does.

The code is already out there and licensed such that all can use it and extend it. That *cannot* be undone.

Except by deprecating the hardware on which the software runs (think VHS => DVD or NTSC => HDTV) or by embracing and extending the protocols that the software speaks. It would have been better titled "When not to use LGPL" rather than "Why not to use LGPL".

RMS's essay advocates using viral GPL only for libraries that have no proprietary equivalent. A more permissive license (e.g. Lesser GPL or even the New BSD license) is indicated in highly competitive fields (e.g. C libraries; graphics infrastructure; audio compression).

The first Emacs was developed in 1976 for the ITS platform by Richard Stallman, six years before Turbo Pascal. See the Emacs FAQ for yourself. Before you flame me, you might want to check your facts.

As far as development tools are concerned don't get me started with the monstrosity that Windows development has become. Between the Hungarian notation, the mixing of 16 & 32 bit code, the badly designed APIs, the not-quite-protected memory model and the maze of not-quite-compatible versions of the same DLLs, programming on Windows platforms is a nightmare. Comparatively speaking, Linux programming is much easier. Look how far KDE has come in just two years. They might put all the astroturfers posting on Slashdot out of a job at this pace.

And why shouldn't it be? Microsoft isn't preventing anybody from writing software, they're just saying "if you don't agree with me, you can't use my stuff to do it".

So don't use their crappy stuff.

The coding world gets along quite happily without it.

-

If you refer to the GPL license at http://www.gnu.org/copyleft/gpl.html, you'll note the following:

2b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

IANAL but this implies that if I download the Microsoft SDK, develop some code against it, then release it under the GPL, or incorporate any GPL code, the GPL applies to the entire program, not just the modifications of the original GPL program. It is perfectly within the rights of Microsoft to prevent another license from superceding their own, or to allow users to be confused. This problem is exactly why LGPL was developed. For a program to be GPL, ALL OF THE SOURCE REQUIRED TO MAKE THE PROGRAM MUST BE GPL. You can't develop GPL code that works against non-GPL code, and distribute them together.

If you refer to the GPL license at http://www.gnu.org/copyleft/gpl.html, you'll note the following:

2b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

IANAL but this implies that if I download the Microsoft SDK, develop some code against it, then release it under the GPL, or incorporate any GPL code, the GPL applies to the entire program, not just the modifications of the original GPL program. It is perfectly within the rights of Microsoft to prevent another license from superceding their own, or to allow users to be confused. This problem is exactly why LGPL was developed. For a program to be GPL, ALL OF THE SOURCE REQUIRED TO MAKE THE PROGRAM MUST BE GPL. You can't develop GPL code that works against non-GPL code, and distribute them together.

RMS can only name what he wrote; the fact of the matter may be that he (and many other volunteers at the FSF) wrote a large piece of a free operating system, which they are still working on, and have named "GNU".

Red Hat, Inc., gets to name their product, also. So does Caldera, and SUSE, and Mandrake, and Slackware, and Debian, and TurboLinux, and even LinuxOne as lame as they may be, among many many others, and not one of them has to provide a single acknowledgment in their advertising (which includes the name!) to Linus, RMS, or any other person or entity who wrote most of the code. This is a key freedom, according to the FSF (http://www.gnu.org/philosophy/bsd.html)

I believe that freedom is in fact the largest and most important advantage that the group of operating systems we are talking about has over the proprietary alternatives. Personally, I like the fact that my data is not being held hostage by a potentially hostile corporation, and that I will always be able to control my own destiny when using a Free system. Many of the people I support had no end of problems when one of their favorite software packages had no Y2K updates, because the publisher had gone out of business in 1998; other people I know are stuck because their favorite game was produced by a company which went out of business a while ago and never fixed the memory leaks before they collapsed. These are not problems when the software is Free.

However, it is rather disingenuous to insist that Freedom must include the freedom to fork the project and then insist that the old name must be kept as part of the new name, as is the case in insisting that it be called "GNU/Linux". That's just lame; the project was forked multiple times (once for each different distribution out there), as the people who created each of those forks has a perfect right to do, according to the freedom guaranteed to each of them, and they are not required to even give any credit in their advertising.

Now it may be a fact that completely ripping off someone else's project without any attribution and without providing any added value is in very bad taste and probably means that the individual or group in question is just a free-loader, but it also happens to be completely legal according to most Free software licenses.

If the FSF ever "fixes" this problem, they also ought to simultaneously issue the world's largest apology to the BSD project for the implied insult which has been up on the GNU webpage for years. Otherwise, the noise in "Linux" vs. "GNU/Linux" just sounds like petty jealousy.

1. Free as in no charge - This is how IE was distributed. This isn't the kind of free software the FSF talking about.
2. Free as in freedom - This is what the FSF means. It's not just about price, it's about what you can do with it. With M$, you can't do anything except use it on one computer (per license). With free software, you can do what you like - meddle with the source, recompile, distribute, sell it on, whatever!

1. Free as in no charge - This is how IE was distributed. This isn't the kind of free software the FSF talking about.
2. Free as in freedom - This is what the FSF means. It's not just about price, it's about what you can do with it. With M$, you can't do anything except use it on one computer (per license). With free software, you can do what you like - meddle with the source, recompile, distribute, sell it on, whatever!

Microsoft does not support eth concept of Open Source and that it is Open Source, not Free Software, that Microsoft is actively attempting to discredit.

Tom Swiss | the infamous tms | http://www.infamous.net/

Depends on your definition of "operating system." GNU has created plenty Utilities, Applications, and Compilers. In addition, GNU has created a kernel, the HURD. One of the most significant contributions GNU has made is their C Library and their linker.

I would argue that GNU's goal is exactly that: to create an operating system that is free software.

Don't take my word for it, read The GNU Project for a complete description of the project.

Depends on your definition of "operating system." GNU has created plenty Utilities, Applications, and Compilers. In addition, GNU has created a kernel, the HURD. One of the most significant contributions GNU has made is their C Library and their linker.

I would argue that GNU's goal is exactly that: to create an operating system that is free software.

Don't take my word for it, read The GNU Project for a complete description of the project.

Depends on your definition of "operating system." GNU has created plenty Utilities, Applications, and Compilers. In addition, GNU has created a kernel, the HURD. One of the most significant contributions GNU has made is their C Library and their linker.

I would argue that GNU's goal is exactly that: to create an operating system that is free software.

Don't take my word for it, read The GNU Project for a complete description of the project.

Depends on your definition of "operating system." GNU has created plenty Utilities, Applications, and Compilers. In addition, GNU has created a kernel, the HURD. One of the most significant contributions GNU has made is their C Library and their linker.

I would argue that GNU's goal is exactly that: to create an operating system that is free software.

Don't take my word for it, read The GNU Project for a complete description of the project.

I think it was during the 90s that Locus was bought by Platinum. A few years later, Computer Associates bought Platinum, but the SSI technology was sold to Tandem. It was around this time that the port began to UnixWare 2.1.

After Compaq bought Tandem, the SSI code was brought up to UnixWare 7.1 and released as NonStop Clusters for Unixware 7.1.0 in late '99. SCO sold it under their name and Compaq hoped to make money from increased sales of servers. Compaq retained ownership of the NSC code, of course.

It was around this time that I joined the development team. We went through a few more iterations on UnixWare, merging with the UW 7.1.1 code base, adding support for TCP/IP interconnects as an alternative to ServerNet, and fixing bugs.

Early in the year 2000, Bruce (my boss) decided that we should port NSC to Linux. Later that year, he and some other managers decided that we should also open-source the technology.

Now here we are halfway through 2001. We've cleaned up alot of the code (more important for open-source than proprietary), adapted much of it to the implementation of Linux, and just released a major piece (Cluster Infrastructure). Hopefully, an initial release of the full SSI code will be ready soon.

BTW, the article says that we're releasing the SSI code under Yet Another Open-Source Licence. There was some miscommunication here. We're releasing it under the plain vanilla GPL version 2.

Brian Watson
Linux Kernel Developer
SSI Clustering Laboratory
Compaq Computer

don't forget export EDITOR=vi before the crontab -e or else on most *NIX systems you would end up launching ed.

If grandma has problems with vi, you'd hate to see ed! :)

The old *BSD license had such a thing, known as an advertising clause. This is fine when a project uses source code from just your project, but can be problematic if/when many projects with such a license are incorporated into a new work. RMS discusses this very subject here.

Well, your fingers weave quick minarets; Speak in secret alphabets;

And this guy got into Harvard?

This is Java 1.0 at its worst -- this is not some magic box (yet) that takes your Java 1.3 app and makes it native.

Here are some quotes from the gcj FAQ, just for context.

> What Java API's are supported? How complete is the support?
>
> Matt Welsh writes:
> Just look in the 'libjava' directory of libgcj
and see what classes are there.
> Most GUI stuff isn't there yet, that's true, but many of the other classes are easy to add if they don't yet exist.
...
> Considering that AWT support isnt here yet there is no chance of getting Swing running.
> Once we have AWT support the Swing 1.1.1 may be useable and even redistributable,
> but JFC will be another issue...

This quote means that we're talking Java 1.0. Don't bother asking about Java3D yet! :^D
> GCJ supports all Java language constructs as per the Java language
> Specification v1.0. Recent GCJ snapshots have added support for
> most JDK1.1 language features, including inner classes.

(bold mine, natch)
Looks like "faceless" apps should compile, but don't expect much else.

So check out... gcj FAQ
the gcj site
... before getting too excited! ;^)

For more info on AWT and gcj, check out the peerlib work. Not much has happened in a while from the looks of it.

So gcj might be integrated with gcc, but as any two-bit Java programmer like myself can tell you, this ain't my Java. This is several generations behind any other platform. You'd be writing code for the absolute lowest denominator, using deprecated methods in today's Java world. You'd nearly be teaching yourself COBOL, if I can put an exaggerated spin on it. No GUI, no XML API, no Collections, no...

Ruffin Bailey

This is Java 1.0 at its worst -- this is not some magic box (yet) that takes your Java 1.3 app and makes it native.

Here are some quotes from the gcj FAQ, just for context.

> What Java API's are supported? How complete is the support?
>
> Matt Welsh writes:
> Just look in the 'libjava' directory of libgcj
and see what classes are there.
> Most GUI stuff isn't there yet, that's true, but many of the other classes are easy to add if they don't yet exist.
...
> Considering that AWT support isnt here yet there is no chance of getting Swing running.
> Once we have AWT support the Swing 1.1.1 may be useable and even redistributable,
> but JFC will be another issue...

This quote means that we're talking Java 1.0. Don't bother asking about Java3D yet! :^D
> GCJ supports all Java language constructs as per the Java language
> Specification v1.0. Recent GCJ snapshots have added support for
> most JDK1.1 language features, including inner classes.

(bold mine, natch)
Looks like "faceless" apps should compile, but don't expect much else.

So check out... gcj FAQ
the gcj site
... before getting too excited! ;^)

For more info on AWT and gcj, check out the peerlib work. Not much has happened in a while from the looks of it.

So gcj might be integrated with gcc, but as any two-bit Java programmer like myself can tell you, this ain't my Java. This is several generations behind any other platform. You'd be writing code for the absolute lowest denominator, using deprecated methods in today's Java world. You'd nearly be teaching yourself COBOL, if I can put an exaggerated spin on it. No GUI, no XML API, no Collections, no...

Ruffin Bailey

As a student, I don't see any reason there should be any restrictions on how you deal with the copyright. The creation is yours and you can do what you want with it. I'm pretty sure the policy you've pointed to is intended for faculty and staff.

Even as a grad student, I had to sign a nonexclusive license to the Queen (in Canada, as represented by the National Librarian). The copyright remains in my name and if I want to OPL/GPL it, I can.

Staff and faculty have a more complicated arrangement because their research is technically a "work product" (further complicated by the fact that it's usually funded by the University, a granting agency or two and some private donors). If you ain't getting paid, I wouldn't worry about it.

Greg

There is a GPL'd Hello World...

We did consider the name GJC (back in '96 when the project was started), but for some reason I don't remember (I think it was trademark-related) we decided on GCJ.

I'm very glad to see GCJ in a mainstream GCC release, and hope it will finally get the attention I think it deserves.

GJC is indeed cool, and it had the name before GCJ. Watch those acronyms. :)

BTW, gcj and gjc work together. :)

Sorry for the high geek quotient in the previous message, I think the five cups of coffee injested since the news of GJC have kind of warped my perception of, well, anything. In my zeal, I forgot to paste a link to this HELL LEET COOL BITCHIN SWEET ASS new GNU tool...http://gcc.gnu.org/java/.

GNU & JAVA: The Network is the OS.

see Options Controlling C++ dialect in the manual.

[...] the big question is "how much stuff is this going to break?

Not much, hopefully.

The only major thing that can affect the binary packages is the new C++ ABI. But for plain C programs, there should be no big difference. Most of the Linux programs and libraries are written in C and should not be affected significantly. This could be a problem for Qt and KDE packages, though.

See also the list of caveats on the GCC web site.

For those of you who prefer a non-hacker announcement of the release, a press release is available.

You're confused about how symbol versioning works (as are a lot of people complaining about this, it seems). glibc has it arranged so that it can change its API without it breaking things.

You change the major version number of a library (or, more accurately, its SONAME) when you make changes that break programs properly linked against older versions of the library. But when you install a new version of libc6, programs linked against the old version continue to work! So they have backward compatibility, and don't have to change their soname. Sure, if you link a program against the newer libc6, people will need a comparable version of that library to run it, but they can upgrade the library and not break everything else on their system. This was not the case between libc5 and libc6, which was why the soname had to change.

(Oh yeah, and before everyone jumps in with libc6-2.0 to libc6-2.1, sure, that caused a few problems, but only because a minority of people linked against libc6-2.0 in weird undocumented ways. In 2.1, the glibc people closed that so that this problem couldn't happen in future.)

If you still don't understand library versioning, and care enough to want to find out, the libtool documentation has some notes on how it works. If you don't believe me about libc6, try objdump -p /lib/libc.so.6 and look for the "Version definitions" section. That lists all the interfaces it supports.

Forgetting about GNU/* for a moment, Solaris is still on major version 1 of its libc: it has (or at least claims to have) never broken backward compatibility.

[IANAL, but of course you wouldn't go to Slashdot for legal advice anyway.]

There are two questions to ask yourself:

1. Would a court think that the proprietary code was a derived work based on the GPLed code?
2. Would the copyright holder think it was a derived work and sue (painful whether or not they win).

To answer question 2, ask the copyright holder. Answering question 1 is trickier. I would hope that they would base a decision on the extent that unique features of the GPLed code are essential to the functionality of the proprietary code, and not base the decision on the technicality of how/when the linking happens. But who knows?

This is why Kawa and BRL have an alternate license: no restrictions if used unchanged. This removes ambiguity about question 1, but might enable GPL circumvention via subclassing. I think exactly how to copyleft Java classes is still an open question.

I pointed out some of them on the bug-glibc mailing list:

• if glibc (or really any shared library, bug glibc is fundemaental for all apps) is updated (even from, say, 2.1.1 to 2.1.2), the n all applications (including things like X-windows) on the system need to be recompiled for guaranteed correct behaviour.
• If a user has glibc 2.2.2, downloads an application which was compiled with glibc 2.2.1, but uses some shared already on the user's computer compiled under glibc 2.2.2, correct behaviour is not guaranteed.

The current situation is not acceptable.

You can use Kawa to compile Scheme to JVM bytecodes. It's easy to make use of Java objects as well.

Using libraries to add functionality to applications is essential. There can be little doubt here. It is easier, more robust, and better practice to use the standard implementation library for a piece of functionality than to attempt to re-write that functionality for yourself. However there are some important basic principles that must be understood when writing application to use, and more particularly developing shared libs.

In development of any code project, there will be times when the codes design is undergoing rapid change. In the case of a library this means that the API will be constantly changing. In a closed source environment this does not cause too many problems because noone ever sees this code. In a cooperative Free Software project, the source to a library is always available, so there is a temptation for the application developer to use a development version of a library to get a certain feature. This is the beginning of the road to hell. It is essential that applications never have stable releases that depend on development libraries. I remember some years ago when gtk+ 1.1 was being developed towards 1.2, and many application developers were chasing the development branch because they wanted the features it had. The result was chaos. It became nearly impossible to install many combinations of gtk+ applications because they all required different versions.

On the library development side there is a need for a great deal of responsibility. Library developers need to learn about, and really understand library interface versioning. The interface version of a library is completely different from the release version number, and it is used by the runtime linker to ensure that it is safe to link a binary to library at runtime. With properlly managed interface versions it is quite possible to have many different incompatable versions of a library installed and available for runtime linking. GNU libtool has some excellent support for library interface versioning, and the libtool documentation contains some excellent documentation on how to correctly assign interface version numbers to a release.

Large numbers of libraries can be managed effectively, and cleanly as long as these principles are understood by both library and application developers, and good practice is followed.

Using libraries to add functionality to applications is essential. There can be little doubt here. It is easier, more robust, and better practice to use the standard implementation library for a piece of functionality than to attempt to re-write that functionality for yourself. However there are some important basic principles that must be understood when writing application to use, and more particularly developing shared libs.

In development of any code project, there will be times when the codes design is undergoing rapid change. In the case of a library this means that the API will be constantly changing. In a closed source environment this does not cause too many problems because noone ever sees this code. In a cooperative Free Software project, the source to a library is always available, so there is a temptation for the application developer to use a development version of a library to get a certain feature. This is the beginning of the road to hell. It is essential that applications never have stable releases that depend on development libraries. I remember some years ago when gtk+ 1.1 was being developed towards 1.2, and many application developers were chasing the development branch because they wanted the features it had. The result was chaos. It became nearly impossible to install many combinations of gtk+ applications because they all required different versions.

On the library development side there is a need for a great deal of responsibility. Library developers need to learn about, and really understand library interface versioning. The interface version of a library is completely different from the release version number, and it is used by the runtime linker to ensure that it is safe to link a binary to library at runtime. With properlly managed interface versions it is quite possible to have many different incompatable versions of a library installed and available for runtime linking. GNU libtool has some excellent support for library interface versioning, and the libtool documentation contains some excellent documentation on how to correctly assign interface version numbers to a release.

Large numbers of libraries can be managed effectively, and cleanly as long as these principles are understood by both library and application developers, and good practice is followed.

Unless Jython changes its licence also, it is not yet GPL compatible - point 8 stipulates that the agreement is to be governed by, and interpreted in the state of Virginia, the very issue which stopped the CPython CNRI licence from being compatible.

Since class files are run together in one memory space, an incompatible code licence is an issue.

So distributing JPython is incompatible with other GPL Java code. But remember that if none of the other code is GPL, then this is not an issue. And if you are writing the other Java code, you can release your code under a licence compatible with both the old CNRI and GPL licences.

Oh and to clarify: just distributing GPL with non-GPL code isn't a problem. It's the 'running in the same memory space' issue which is. So if some of your Java code is run completely separately from the others, say client and server software, the two components can have incompatible licences.

Check out http://www.gnu.org/software/libc/FAQ.html#s-1.17, and try objdump -T sometime.

The License of Python 1.6b1 and later versions:
This is a free software license but is incompatible with the GNU GPL. The primary incompatibility is that this Python license is governed by the laws of the "State" of Virginia in the USA, and the GPL does not permit this.

Disclaimer: I am by no means a GPL fanatic. But nonetheless I think I can help to answer your question.

The biggest component of the GPL that RMS and the fans of GPL like is the same thing that made Microsoft incorrectly call it a "cancer". The GPL basically says that if you take the source code to a GPL program, make changes, and then distribute the binary, you are obligated to release the source to whomever you released the binary. In addition, you must release your new source under the GPL license, which gives the new users of the source the ability to distribute the code for free, even if you do not. This does NOT mean you can't sell it, or that you have to give away your program free at all. It just means that the first person you sell code to has the ability to give it away.

People misunderstand the GPL because they see companies like Red Hat and Mandrake giving away almost all of their products off of FTP sites. They could, if they chose, only sell their CDs. The CDs, though, must have the source code for every GPL program on them. If they don't, they need to make that source code publicly available (like on a web site). If someone were to buy these CDs though, they have every right to take the GPL programs off the CD and redistribute them, for whatever price they want.

Some of the other licenses you mentioned do not require that the source code be released when code is used in another program (called a "derivative" work). This appeals more to closed-source companies that want to take advantage of open-source products without releasing their source code. I'm not as familiar with the specifics of each license, but I'm fairly sure that the ability to keep source closed applies to BSD, Apache, and Artistic licenses.

One more note about the GPL. One can distribute closed source programs that use GPL code, but the code must be seperated. A good example of this might be a program like the GIMP (image editor) with proprietary plugins. You can ship both together, since the GIMP is self-contained, and your plugins can still be closed-source.

In addition to the GPL, the LGPL (Lesser General Public License) exists but is not recommended by RMS and the gang. It's used primarily for libraries and allows closed-source products to fully contain the LGPL code. Library designers use this because they want their programming code to be used with commercial products. An example of this is wxWindows, a cross-platform C++ GUI library.

So basically the main reason that some people like GPL programs is that it does somewhat "promote" open-source, by requiring programs that use it to remain open-source for everyone. It's among the most restrictive and wordy licenses, you are correct, but I'm not familiar with any open-source license being completely challenged in court.

Hope this helps.

--

We do not care what censorship laws are passed and things like DeCSS are NOT illegal over here.

Not if you get sued in the US and the Hague Convention forces your UK courts to enforce the US DMCA.

They apologise for "giving SPAM a bad name,", which is hardly Unisys' fault, but forget about the only reason anyone knows Unisys' name these days - the .GIF patent.

I smell PR Bunnies at work - although time was when WiReD would have called them on something like that.

However, these languages are very difficult to learn and this can get in the way of learning other facets of programming and computer science. This learning curve impacts the learning of the general problem solving skills needed to work outside the limited world of discrete finite machines, such as in networking or inter-personal spaces. Java solves some of the problem in the OU cirricula by providing a "lite" language. It is a language that does impressive things very easily and that gaurds the programmer against some nasty complexities like platform/compile/library incompatabilities. These are also the reasons it is popular in industry. Languages such as Fortran and Cobol hold on in our Science and Business colleges because of legacy code and the personal perceptions of the faculty. Unfortunately you can improperly teach the problem solving ciritcal to progammin in any language, just as you can properly teach without a language. Classes that focus on getting design and thought about a problem started at least during if not before a project would be much more helpful. Systems such as OO pattern and tools like UML provide much help to the Software Engineer and Computer Scientist alike.

I've worked in the *real world* Perl, C, C++, Z80 assembler (in embedded and non-embedded environments) and Java. Each has a different goal and a different way of getting their. However, irregardless of the path taken, they achieve those golas to a limited degree. Oak, the language that became Java, was designed to be a simple extension of real OOP with a C syntax. Like other embedded languages, most of which are either assemblers or functional strangely enough, it has grown to include methods of getting at the machine and conecpts such as closures. If it adopted lamda calculus syntax extensions, you could use it to teach mathematical therom proving.

However you choose to view the language, as toy, irritant, the next wave, the last wave, et cetera, it is in our CompSci cirricula and it can be taught and taught well. When I went on to my second year of classes I was exposed to C++ for Data Structures and Java for a Programming Abstractions course. Data Structures became a waste of a class trying while to work with a professor who was new to the lanugage. The Programming Abstractions professor knew what was up with Java and so taught us a lot about OO design before delving into the language. I didn't get a lot of help from my time learning Haskel, wich in turn had severly limited my time working with C before moving onto C++.

For what it's worth, learning RCS, and later CVS and UML, helped with my programming more than any of the languages I in which I learned or worked. In the end, these languages proved that they are just tools. Like all tools - Craftsman, DeWALT, GNU liscenses, Sun.Java.*, there will be proponents and detractors and teachers and charlitans. You mileage may vary.

Here's to 5 years of CompSci and counting (with 1 year to go.)

Chris DiBona twice slams Java for being non-free, and in some ways it is. However, it is worth pointing out that there are Free and useful implementations of Java. GCC 3.0 will be out in a few days and it will be the first official GCC release with full Java support. GCJ has made tremendous strides the last half year in terms of sbility, completeness, and features. (As the original and still active author of GCJ I admit to some bias.) The most "visible" limitation is that functional GUI libraries, but then your typical introductory CS class doesn't have much need for GUI programming. I myself am using GCJ to compile Scheme to native code, and using it to write Apache modules (still very experimental).

Chris DiBona twice slams Java for being non-free, and in some ways it is. However, it is worth pointing out that there are Free and useful implementations of Java. GCC 3.0 will be out in a few days and it will be the first official GCC release with full Java support. GCJ has made tremendous strides the last half year in terms of sbility, completeness, and features. (As the original and still active author of GCJ I admit to some bias.) The most "visible" limitation is that functional GUI libraries, but then your typical introductory CS class doesn't have much need for GUI programming. I myself am using GCJ to compile Scheme to native code, and using it to write Apache modules (still very experimental).

Protests are fine and all, but more often than not, heads get hot and trouble breaks out. The news covers this trouble with stories not about people standing up for freedom getting smacked down by the man, but rather stories about trouble-makers making life difficult for honest working people and disturbing the public peace.

Now, I would say a good chunk of the American "Joe Sixpack" population gets their news specifically from these outlets and that is how they are "educated" about the current events of the world.

So, here is my modest proposal. Write to your local new outlets (especially to the individual reporters if you can) and point them to a source of information on this proposed treaty. Point them to RMS's commentary on it. Point them to some of the more insightful comments here on Slashdot as well as round the net. Explain to them politely your concern over this, and especially over how scandalous it seems, because the news outlets love a scandal.

Find people like-minded people and get them to do the same. Make enough of this sort of noise, and someone will notice.

You never know. Some up-and-coming journalist trying to make a name for himself might just make a front page story about how outrageous this situation is. And THAT is how you will reach and educate the minds of "Joe Sixpack". And when all of the "Joe Sixpack"s of the US make a noise about it, perhaps then the US government "officials" who are probably planning on trying for re-election will actually listen to the wishes of the people over the rich corporations.

Education is the key, and it seems to me that the system to spread the word is there. Why don't we try to use it?

Just my humble opinion. :)