Slashdot Mirror

This isn't the artcile I originally read. I can't find it. But it is similer. http://www.gnu.org/philosophy/motivation.html

In almost any kind of software other than games, the stock response to "If only" is "Patches are welcome." But for some reason, games as a whole tend to be more resistant to free software principles than other kinds of software. I've written a couple reasons why that might be.

Modern C++ compilers put the unwinding logic in other pages. The C++ one can be faster if errors are rare, but slower if errors are common.

I've looked at this myself. It is very nice that in C++ the "default" way of approaching error handling with RAII plays nicely with the compiler's static branch prediction logic. However, it's not a sufficient argument for truly high-performance code. Either your compiler provides conventions on static branch prediction or it provides intrinsics such as __builtin_expect that give you control. Both of these will give you the same benefits as the C++ RAII style, and (in my experience) neither approach gums up the logic enough to hurt readability.

It is extremely well documented what every function in there is supposed to do, and most of the functions are actually written in C. Though I suggest you avoid printf. You'll learn things about C that you really can't learn any other way.

Some of the other standard unix utilities are also pretty good. I seem to recall that reading the source to awk and vi were very enlightening.

"Free Software" protects your four freedoms (as defined by the FSF). Open source does allow you to see the source, but also permits the use of more restrictive licenses.

In the Open Source Definition, criteria 5 and 6 protect freedom 0 under the Free Software Definition, criterion 2 protects freedom 1, criterion 1 protects freedom 2, and criteria 3, 7, and 8 protect freedom 3.

GNU is way, way more that just a host for X11. In fact I wouldn't be surprised to discover that most GNU installs did not even have X11 installed (there's a lot of severs on the planet).

If GNU is primarily a server operating system, then what's the corresponding desktop operating system called?

what constitutes "a GNU system", if "a GNU system" includes critical non-GNU projects?

That's a good question. I wish I could find a precise answer on GNU.org as to what is and is not a "GNU operating system", but I guess this is the closest thing.

Emacs lisp now has optional lexical scoping, similar semantics to common lisp.

http://lists.gnu.org/archive/html/emacs-devel/2011-04/msg00043.html

Before anyone jumps on the band wagon and says that we all have perfectly usable user space desktop apps for 28 years in the UNIX world, let me say that it is actually very important that now even Microsoft starts to understand that modularity is the way to go while designing complex systems. Moving various operating system components to the user space is just a logical conclusion of the research done during the last four decades. Look at the direction of modern OSii development, from MINIX to GNU. Started by GNOSIS, KeyKOS, EROS and Coyotos this trend seems to suggest that it is much more natural and reliable to design a secure capability-based system when all of the services are separated from each other. Now when even Microsoft is going in that direction - and it is not a trivial change for them, trust me - we can expect Apple and other OS vendors to follow which is a Good Thing. After all, even if people like you and me are using secure operating systems we still don't want to get spammed and dossed by all of the legacy machines out there. It turns out that the rumors that Microsoft is starting to take the latest research in operating systems seriously turned out to be true. This is good news for everyone.

They are becoming more and more alike. It seems the GNU guys were right all along. Microsoft Church

The GNU Hacker's Meeting page has "GNU Operating System" at the top. The GNU Operating System was intended to be "a complete Unix-compatible software system", with "all improvements that are convenient, based on our experience with other operating systems".

However, that's not what happened:

At the beginning of the GNU Project, I imagined that we would develop the whole GNU system, then release it as a whole. That is not how it happened.

Since each component of the GNU system was implemented on a Unix system, each component could run on Unix systems long before a complete GNU system existed. Some of these programs became popular, and users began extending them and porting them—to the various incompatible versions of Unix, and sometimes to other systems as well.

The process made these programs much more powerful, and attracted both funds and contributors to the GNU Project. But it probably also delayed completion of a minimal working system by several years, as GNU developers' time was put into maintaining these ports and adding features to the existing components, rather than moving on to write one missing component after another.

so one could argue that the real result of the GNU project is not the intended complete operating system but, instead, a collection of pieces of free software that have been adopted by a number of operating systems, including Linux distributions, the *BSDs, Mac OS X, and perhaps other commercial UNIXes.

Those operating systems are, however, not built with a 100% GNU userland. So, at best, Guile might, at some point, be the extension language for all pieces of software from the GNU project, and perhaps even for many pieces of free software not from the GNU project (most of it is licensed under the LGPL, so even non-free software written for environments that provide Guile could use it as an extension language, as long as they avoid GPLed parts such as the readline module), but I wouldn't hold my breath waiting for an operating system where it's the extension language.

Perhaps when Andy Wingo argued that Guile should be the extension language for GNU, he meant "for all pieces of software from the GNU project", but I wouldn't hold my breath waiting for it to be the extension language for an entire operating system - relative technical merits of various languages nonwithstanding, the world will probably have to live with the languages that Wingo asserts "are at the height of [their adoption curves] and beginning [their] descent" or that "will fall out of favor" for quite a while. Perhaps he's right, and Python's fading away and JavaScript will become a legacy language; if so, whether what replaces them is some flavor of LISP is something to be determined by waiting and watching. After all, Worse is Better.

The GNU Hacker's Meeting page has "GNU Operating System" at the top. The GNU Operating System was intended to be "a complete Unix-compatible software system", with "all improvements that are convenient, based on our experience with other operating systems".

However, that's not what happened:

At the beginning of the GNU Project, I imagined that we would develop the whole GNU system, then release it as a whole. That is not how it happened.

Since each component of the GNU system was implemented on a Unix system, each component could run on Unix systems long before a complete GNU system existed. Some of these programs became popular, and users began extending them and porting them—to the various incompatible versions of Unix, and sometimes to other systems as well.

The process made these programs much more powerful, and attracted both funds and contributors to the GNU Project. But it probably also delayed completion of a minimal working system by several years, as GNU developers' time was put into maintaining these ports and adding features to the existing components, rather than moving on to write one missing component after another.

so one could argue that the real result of the GNU project is not the intended complete operating system but, instead, a collection of pieces of free software that have been adopted by a number of operating systems, including Linux distributions, the *BSDs, Mac OS X, and perhaps other commercial UNIXes.

Those operating systems are, however, not built with a 100% GNU userland. So, at best, Guile might, at some point, be the extension language for all pieces of software from the GNU project, and perhaps even for many pieces of free software not from the GNU project (most of it is licensed under the LGPL, so even non-free software written for environments that provide Guile could use it as an extension language, as long as they avoid GPLed parts such as the readline module), but I wouldn't hold my breath waiting for an operating system where it's the extension language.

Perhaps when Andy Wingo argued that Guile should be the extension language for GNU, he meant "for all pieces of software from the GNU project", but I wouldn't hold my breath waiting for it to be the extension language for an entire operating system - relative technical merits of various languages nonwithstanding, the world will probably have to live with the languages that Wingo asserts "are at the height of [their adoption curves] and beginning [their] descent" or that "will fall out of favor" for quite a while. Perhaps he's right, and Python's fading away and JavaScript will become a legacy language; if so, whether what replaces them is some flavor of LISP is something to be determined by waiting and watching. After all, Worse is Better.

The GNU Hacker's Meeting page has "GNU Operating System" at the top. The GNU Operating System was intended to be "a complete Unix-compatible software system", with "all improvements that are convenient, based on our experience with other operating systems".

However, that's not what happened:

At the beginning of the GNU Project, I imagined that we would develop the whole GNU system, then release it as a whole. That is not how it happened.

Since each component of the GNU system was implemented on a Unix system, each component could run on Unix systems long before a complete GNU system existed. Some of these programs became popular, and users began extending them and porting them—to the various incompatible versions of Unix, and sometimes to other systems as well.

The process made these programs much more powerful, and attracted both funds and contributors to the GNU Project. But it probably also delayed completion of a minimal working system by several years, as GNU developers' time was put into maintaining these ports and adding features to the existing components, rather than moving on to write one missing component after another.

so one could argue that the real result of the GNU project is not the intended complete operating system but, instead, a collection of pieces of free software that have been adopted by a number of operating systems, including Linux distributions, the *BSDs, Mac OS X, and perhaps other commercial UNIXes.

Those operating systems are, however, not built with a 100% GNU userland. So, at best, Guile might, at some point, be the extension language for all pieces of software from the GNU project, and perhaps even for many pieces of free software not from the GNU project (most of it is licensed under the LGPL, so even non-free software written for environments that provide Guile could use it as an extension language, as long as they avoid GPLed parts such as the readline module), but I wouldn't hold my breath waiting for an operating system where it's the extension language.

Perhaps when Andy Wingo argued that Guile should be the extension language for GNU, he meant "for all pieces of software from the GNU project", but I wouldn't hold my breath waiting for it to be the extension language for an entire operating system - relative technical merits of various languages nonwithstanding, the world will probably have to live with the languages that Wingo asserts "are at the height of [their adoption curves] and beginning [their] descent" or that "will fall out of favor" for quite a while. Perhaps he's right, and Python's fading away and JavaScript will become a legacy language; if so, whether what replaces them is some flavor of LISP is something to be determined by waiting and watching. After all, Worse is Better.

The GNU Hacker's Meeting page has "GNU Operating System" at the top. The GNU Operating System was intended to be "a complete Unix-compatible software system", with "all improvements that are convenient, based on our experience with other operating systems".

However, that's not what happened:

At the beginning of the GNU Project, I imagined that we would develop the whole GNU system, then release it as a whole. That is not how it happened.

Since each component of the GNU system was implemented on a Unix system, each component could run on Unix systems long before a complete GNU system existed. Some of these programs became popular, and users began extending them and porting them—to the various incompatible versions of Unix, and sometimes to other systems as well.

The process made these programs much more powerful, and attracted both funds and contributors to the GNU Project. But it probably also delayed completion of a minimal working system by several years, as GNU developers' time was put into maintaining these ports and adding features to the existing components, rather than moving on to write one missing component after another.

so one could argue that the real result of the GNU project is not the intended complete operating system but, instead, a collection of pieces of free software that have been adopted by a number of operating systems, including Linux distributions, the *BSDs, Mac OS X, and perhaps other commercial UNIXes.

Those operating systems are, however, not built with a 100% GNU userland. So, at best, Guile might, at some point, be the extension language for all pieces of software from the GNU project, and perhaps even for many pieces of free software not from the GNU project (most of it is licensed under the LGPL, so even non-free software written for environments that provide Guile could use it as an extension language, as long as they avoid GPLed parts such as the readline module), but I wouldn't hold my breath waiting for an operating system where it's the extension language.

Perhaps when Andy Wingo argued that Guile should be the extension language for GNU, he meant "for all pieces of software from the GNU project", but I wouldn't hold my breath waiting for it to be the extension language for an entire operating system - relative technical merits of various languages nonwithstanding, the world will probably have to live with the languages that Wingo asserts "are at the height of [their adoption curves] and beginning [their] descent" or that "will fall out of favor" for quite a while. Perhaps he's right, and Python's fading away and JavaScript will become a legacy language; if so, whether what replaces them is some flavor of LISP is something to be determined by waiting and watching. After all, Worse is Better.

The GNU Hacker's Meeting page has "GNU Operating System" at the top. The GNU Operating System was intended to be "a complete Unix-compatible software system", with "all improvements that are convenient, based on our experience with other operating systems".

However, that's not what happened:

At the beginning of the GNU Project, I imagined that we would develop the whole GNU system, then release it as a whole. That is not how it happened.

Since each component of the GNU system was implemented on a Unix system, each component could run on Unix systems long before a complete GNU system existed. Some of these programs became popular, and users began extending them and porting them—to the various incompatible versions of Unix, and sometimes to other systems as well.

The process made these programs much more powerful, and attracted both funds and contributors to the GNU Project. But it probably also delayed completion of a minimal working system by several years, as GNU developers' time was put into maintaining these ports and adding features to the existing components, rather than moving on to write one missing component after another.

so one could argue that the real result of the GNU project is not the intended complete operating system but, instead, a collection of pieces of free software that have been adopted by a number of operating systems, including Linux distributions, the *BSDs, Mac OS X, and perhaps other commercial UNIXes.

Those operating systems are, however, not built with a 100% GNU userland. So, at best, Guile might, at some point, be the extension language for all pieces of software from the GNU project, and perhaps even for many pieces of free software not from the GNU project (most of it is licensed under the LGPL, so even non-free software written for environments that provide Guile could use it as an extension language, as long as they avoid GPLed parts such as the readline module), but I wouldn't hold my breath waiting for an operating system where it's the extension language.

Perhaps when Andy Wingo argued that Guile should be the extension language for GNU, he meant "for all pieces of software from the GNU project", but I wouldn't hold my breath waiting for it to be the extension language for an entire operating system - relative technical merits of various languages nonwithstanding, the world will probably have to live with the languages that Wingo asserts "are at the height of [their adoption curves] and beginning [their] descent" or that "will fall out of favor" for quite a while. Perhaps he's right, and Python's fading away and JavaScript will become a legacy language; if so, whether what replaces them is some flavor of LISP is something to be determined by waiting and watching. After all, Worse is Better.

Here is an idea instead of adding Lua support, I don't know, USE LUA... Wow what a concept!

Julien Danjou (of awesome fame, a high profile Lua using application), explains it fairly well. Basically, the Lua API is a huge pain to use and contorts the program around it making anything but the most trivial uses nearly impossible.

Lua and a language and basic extension library, however, is eminently usable by non-programmers. This makes it a fairly small task to implement the user facing parts of Lua. This was actually mostly done during GSoC 2010, but like most GSoC projects the student kind of trailed off once he passed the final evaluation and hasn't made too much effort at merging it into master. There was, however, chatter on the Guile IRC channel today about finally getting around to doing that (there is finite maintainer time and everyone has a day job and whatnot).

Despite some harsh words about Tcl, Tcl is alive and well in certain GNU projects, including one of the more prominent GNU projects - GCC, the GNU Compiler Collection. GCC's test suite is run with the DejaGnu testing framework, which written in Tcl. So the next time you use gcc to compile code, be assured that Tcl has helped to make your executable run as you coded it.

http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/README?view=co

http://www.gnu.org/s/dejagnu/

Despite some harsh words about Tcl, Tcl is alive and well in certain GNU projects, including one of the more prominent GNU projects - GCC, the GNU Compiler Collection. GCC's test suite is run with the DejaGnu testing framework, which written in Tcl. So the next time you use gcc to compile code, be assured that Tcl has helped to make your executable run as you coded it.

http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/README?view=co

http://www.gnu.org/s/dejagnu/

Here's the first thing I found when looking for Guile with ECMAScript: http://www.gnu.org/software/guile/manual/html_node/ECMAScript.html
In summary: Don't use ECMAScript for Guile under any circumstances, btw bitch bitch bitch bitch we are not a project worth paying attention to.

It became annoying, however, because Scheme lacks convenient ways of creating local variable declarations without nesting the whole thing into a let form.

Most languages lack convenient ways to create local variable declarations without nesting the whole thing in a code block. In fact, JavaScript lacks a convenient way to create local variable declarations without using an anonymous function.

Another issue was the complete lack of a useful standard library. No hash maps, no sorting function. Even the most basic string functions were lacking. If I'm not mistaken, the Scheme spec doesn't even specify a way to get the numerical code for a character...

Well, we're talking about Guile here, which has sort functions and regexp string manipulation.

And then the performance of the code I'd written (pretty straightforwardly) was abysmal.

Well, it's true that Guile has horrible performance, even compared to other Scheme implementations'; but then, JavaScript had pretty horrible performance until Google and Mozilla started putting serious effort into speeding it up.

It became annoying, however, because Scheme lacks convenient ways of creating local variable declarations without nesting the whole thing into a let form.

Most languages lack convenient ways to create local variable declarations without nesting the whole thing in a code block. In fact, JavaScript lacks a convenient way to create local variable declarations without using an anonymous function.

Another issue was the complete lack of a useful standard library. No hash maps, no sorting function. Even the most basic string functions were lacking. If I'm not mistaken, the Scheme spec doesn't even specify a way to get the numerical code for a character...

Well, we're talking about Guile here, which has sort functions and regexp string manipulation.

And then the performance of the code I'd written (pretty straightforwardly) was abysmal.

Well, it's true that Guile has horrible performance, even compared to other Scheme implementations'; but then, JavaScript had pretty horrible performance until Google and Mozilla started putting serious effort into speeding it up.

why they don't just say "[...] Emacs Lisp is the GNU extension language."

Emacs Lisp the language is quite full of crazy legacy baggage. Emacs Lisp or more precisely the Emacs virtual machine it runs on was never particularly designed to be easily linked into larger applications, unlike Guile/Lua/TCL/etc.

Ripping out the Emacs bytecode virtual machine core from Emacs and replacing it with the Guile core is still a long term plan for Emacs AFAIK. But it is not exactly something you can do between tea breaks. That doesn't mean emacs lisp being replaced by scheme in emacs at the same time, there are millions of lines of emacs lisp code in the wild, it's more about developing an emacs lisp "personality" for Guile - work that is being done - then integrating the guile vm into emacs instead of the existing vm.

Guile specification.

Guile isn't a specification.

http://www.gnu.org/s/guile/ ... Guile is an efficient virtual machine that executes a portable instruction set generated by its optimizing compiler, and integrates very easily with C and C++ application code. In addition to Scheme, Guile includes compiler front-ends for ECMAScript and Emacs Lisp (support for Lua is underway), which means your application can be extended in the language (or languages) most appropriate for your user base.

Quoting from the Guile Manual

ECMAScript was not the first non-Schemey language implemented by Guile, but it was the first implemented for Guile's bytecode compiler. The goal was to support ECMAScript version 3.1, a relatively small language, but the implementor was completely irresponsible and got distracted by other things before finishing the standard library, and even some bits of the syntax. So, ECMAScript does deserve a mention in the manual, but it doesn't deserve an endorsement until its implementation is completed, perhaps by some more responsible hacker.

In the meantime, the charitable user might investigate such invocations as ,L ecmascript and cat test-suite/tests/ecmascript.test.

That is hardly a ringing endorsement...

Guile is LGPL. It's no more "locked down" than any of the other LGPL libraries that proprietary software uses, such as glibc or Gtk+ or SDL.

After all, open source was created to free people from proprietary code and people telling them what they can't do.

Free Software and specifically copyleft (as implemented by the GPL) was created to free people from proprietary code. Permissive licenses such as that of BSD and MIT were created to encourage as many people as possible to use the code rather than keep it Free for everyone. Both copyleft and permissive licenses make something both Free and Open Source and each has its place, depending on whether the goal is to keep the software Free for everyone or have it used by anyone in any way, possibly including making it proprietary.

Open Source was created to market Free Software to business. That was a important role which hadn't been fulfilled by the FSF or anyone else, so OSI's work is very important. However, since it's focused on marketing, it sometimes forgets about their Free Software roots. I think it's a shame that the FSF doesn't emphasize the value of Free Software to business more and the OSI doesn't emphasize the importance of the freedom of Open Source software more, since they have much more in common than not.

After all, open source was created to free people from proprietary code and people telling them what they can't do.

Free Software and specifically copyleft (as implemented by the GPL) was created to free people from proprietary code. Permissive licenses such as that of BSD and MIT were created to encourage as many people as possible to use the code rather than keep it Free for everyone. Both copyleft and permissive licenses make something both Free and Open Source and each has its place, depending on whether the goal is to keep the software Free for everyone or have it used by anyone in any way, possibly including making it proprietary.

Open Source was created to market Free Software to business. That was a important role which hadn't been fulfilled by the FSF or anyone else, so OSI's work is very important. However, since it's focused on marketing, it sometimes forgets about their Free Software roots. I think it's a shame that the FSF doesn't emphasize the value of Free Software to business more and the OSI doesn't emphasize the importance of the freedom of Open Source software more, since they have much more in common than not.

There are a lot of people who use IP law to keep their ideas available to others without allow those same others from profiting from their work. I do believe that's what is behind the idea of Copyleft & the use of IP law in OSS.

You're wrong. A license isn't neither Open Source (as defined by the OSI) nor Free Software (as defined by the FSF) if it prevents licensees from selling copies of the software.

Redistributing free software is a good and legitimate activity; if you do it, you might as well make a profit from it.

http://www.gnu.org/philosophy/selling.html

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources.

http://www.opensource.org/docs/osd

So in other words, yes, you have to release the user name and password, since it's part of the source and compiled into the binary, and the AGPLv3 requires that it all be released.

The GNUstapo strikes again. Last week it was FUD to try to get people to encourage Linux to move to the AGPLv3, which would kill Android on mobile devices, and now this. No thanks. Keep chipping away at the various freedoms - you just end up making the *BSDs look better and better.

Dude.

AGPL3 != GPL3

I mean, yes, the difference in name is slight, the difference in license is not. Indeed, the difference between the two is essentially what is being discussed here.

If you are actually interested and not simply *BSD license trolling, you can read about it here.

The main thing the "consumption only" argument misses is that most people only use their computers for consuption.

Consumption is tuberculosis.

Sure, someone may buy a computer with the intent to use it to view works and information created by someone else. But if the computer is also useful as a tool for creating works, then perhaps the user may be tempted to try his hand one day at creating. The leap from viewing to creating isn't so easy for people who own only a device for viewing.

Please be more specific

http://www.gnu.org/gnu/gnu-linux-faq.html

Yeah, but then he went and mispronounced GNU.

Still, good effort.

Why the hell didn't GNU complete the entire GNU system? Saw Linus' kernel and said "Forget it, he's already got one running"?

Pretty much, but it's still apparently under "active development".

Simply downloading another copy and conforming with the terms of the license re-establishes your right to redistribute.

Your License to the Program is terminated. The License doesn't apply to you anymore, none of it.

Wrong - your license for the previous copy was terminated. This doesn't affect future license grants. EACH copy you receive comes with its' own license, as per section 6 of the GPLv2, and any attempt to impose further restrictions on THAT copy (eg: for violating a previous instance of the license with a previous copy) is prohibited.

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

People using the GPLv2 license want people to conform to THAT license. Generating FUD about Android by saying that rights are permanently terminated when this is not the case, and that Linux should be relicensed as GPLv3 (which would kill Android dead, or at least force it to switch to BSD) is both stupid and almost impossible - you cannot use GPLv3 code in a "GPLv2-only" program such as linux., and with up to 10,000 contributors, it's not likely you'll get everyone's consent to switch (again, because it would kill using linux in commercial products dead dead dead).

Is GPLv3 compatible with GPLv2?

No. Some of the requirements in GPLv3, such as the requirement to provide Installation Information, do not exist in GPLv2. As a result, the licenses are not compatible: if you tried to combine code released under both these licenses, you would violate section 6 of GPLv2.

However, if code is released under GPL âoeversion 2 or later,â that is compatible with GPLv3 because GPLv3 is one of the options it permits.

In every situation where there is a potential conflict of interest, one party is going to have more freedom than the other(s).

The GPL is designed to (attempt to) maximise the freedom of the user, not both parties.

The BSD license maximises developer freedom. Also, as a developer, you are free to choose whichever licence you prefer.

Having the developer adhere to restrictions in order to maximise user freedom only sounds like doublespeak if you neglect to qualify who is being restricted, and who is being guaranteed freedom.

It would be logically impossible to maximise user freedom and developer freedom at the same time, so the FSF can't be criticised as being orwellian simply because they can't do the impossible. And they don't sinsterly cloak the fact they they are concerned purely on user freedom.

Free software is a matter of the users' freedom(3rd paragraph)

there most certainly is a "lose your rights forever" clause in GPLv2, as others have pointed out.

No there isn't. They pointed to some FUD on the FSF site that claims that there is, and that the GPLv3 is better because it provides provisions for reinstatement.

However, nobody has pointed to any such clause in the actual text of the GPLv2.

The clause in question says that if you are not in compliance, your right to redistribute terminates. Nowhere does it say that such termination is permanent. Simply downloading another copy and conforming with the terms of the license re-establishes your right to redistribute. Any attempt to claim otherwise is a violation of clause 6 of the GPLv2, which doesn't allow the imposition of greater restrictions than those in the license itself (permanent termination would be one such restriction).

You're absolutely right - it simply isn't there, and attempting to impose such a "you lose your rights forever, even if you get back into compliance" on GPLv2 code is a violation of clause #6 - "You may not impose any further restrictions on the recipients' exercise of the rights granted herein."

One of the reasons I'm reverting my code back to GPLv2 ONLY as opposed to GPLv3 is because of FUD like this. The action of the GPLv2 is well-understood, and its friendly to businesses that want to use code to implement software-as-a-service without having all the hassles of making every variant of their server source available for 3 years to anyone who visited their site.

The whole idea behind open source is that even if 99% of the people who use your stuff never give back their improvements, the ones who do will benefit from it because their improvements will be eyeballed, tested in other environments, more likely become standards, more likely have other useful additions added to it that they can benefit from in return (virtuous circle), etc. A carrot, rather than a stick.

The GPLv3 is a bit like "sharing is good, so we're going to force you to even if you never actually distribute code - just implementing services is enough" rather than educating and letting implementers find their own comfort zones.

If this sort of malarkey keeps on, I'll just switch to a BSD-style license and be done with it. Some things just aren't worth the hassle.

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

Please show where, in the terms of the license, it says that there is any additional requirement, over and above the actual terms of the license, to distribute, or that licenses are terminated in perpetuity, even if you come back into compliance.

The fact is, once you are in compliance again, you have the right to redistribute under the terms of the license. There is no such thing, anywhere in the license, that states you lose the right to redistribute forever.

What they were stating is that in order to regain your GPLv2 license you have to get approval from ALL copyright holders and in the case of something like the Linux kernel it would be nigh impossible to get this.

That's not what the GPLv2 says. It says very clearly what you must do to distribute.

As long as you comply, you can distribute. When you don't comply, you can't. There is nothing about any requirement to obtain the permission of the authors - which would be a violation of clause 6 of the GPLv2, as it would impose additional conditions beyond the license itself. Just complying with the license is sufficient.

Additionally, the recipients don't receive their license from the distributor, but from the original authors (clause #6). Even if the distributor is out of compliance, that does NOT affect recipients of the code.

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

See that second bolded section - nobody can demand that someone who was once out of compliance, once they are back in compliance, seek the approval of ANY of the copyright holders before recommencing distribution. The article is pure FUD.

I've thought that the reason for the triumph of the bourgeoisie in Europe is that in the middle ages, the aristocracy needed the products of the towns -- but the towns didn't need the aristocracy, and managed to obtain some independence of the aristocracy. This meant that, later on, when there were direct clashes, the aristocracy could never win, because they depended upon the products of the towns to control the towns.

So, I've thought that by analogy, if we want to move past capitalism, we want to develop facets of the economy which are socially owned, upon which capitalism will come to depend, but which do not depend upon capitalism. And it occurred to me that there are only a few entities in evidence that look like this, and the strongest (and the one I could most likely find a way to play a part in) was free software.

About the time I was thinking this, I was reading Free Software, Free Society and Open Sources: Voices from the Open Source Revolution. The former appealed to my radical left sensibilities (and my hankering for heterodoxy), and the latter, while a good read, irritated me in that almost every essay made a point of stating that open source software was not socialist.

It occurred to me, however, that if the idea I had in mind was to work at all, it would be necessary to both maintain the independence of free software, and to encourage businesses and governments to use it; thus, some sort of compromise between the (apparent) two approaches would be necessary.

It looks like gcc supports most of C++0x already.

See: http://gcc.gnu.org/projects/cxx0x.html

Of course! The point is that anyone who asks must be able to get the GPL'd source of what you built. Bear in mind that shipping the source to someone on CD is almost as difficult for the vendor (imagine the requester turns round and says the CD doesn't work) as ANYONE can ask for said the source and send in their cheques in currency that needs to be converted etc. Failing to get the source to them could result in your products being blocked so it's probably not worth being difficult about it.

Another point is that if you provide GPL binaries on a network server you also have to provide the sources on the network server. This may be difficult to avoid because various people may need the binaries for flashing purposes and once you give out a link...

Did You Say âoeIntellectual Propertyâ? It's a Seductive Mirage.

And who cares about how long the copyright is today since they've got the DMCA which says if they wrap their stuff in any lame user restricting wrapper, the user may never tamper with the wrapper, never mind the contents copyright status. Yes, you read that right, that's a permanent, unconsitutional copyright.

Even if he's right, do we really want the GPL to be a revokable license where an tiny mistake that might throw you out of compliance requires a Herculean effort to re-establish rights? That would make all GPL code nuclear hot for any and all commercial interests which would probably see 80-90% of all code development on GPL projects dry up.

That's just one of the ways GPL v3 improves on earlier versions. Of course many Linus and other Linux contributors remain irrationally opposed to it. From the GPL v3

However, if you cease all violation of this License, then your
license from a particular copyright holder is reinstated (a)
provisionally, unless and until the copyright holder explicitly and
finally terminates your license, and (b) permanently, if the copyright
holder fails to notify you of the violation by some reasonable means
prior to 60 days after the cessation.

The EULA for the free eBook converter now contains some extra stuff, such as:
"The source code of Hamster Free eBook Converter inherits GNU GPL 3.0 rights from Calibre. You may all operations with it permitted by law. GNU GPL 3.0 restrictions must be met. You will not use Hamster Free eBook Converter for illegal purposes. You will comply with all export laws. Hamster Free eBook Converter is licensed, not sold."
which looks like it was written hastily, and
"GNU GPL 3.0
Calibre source codes: http://code.google.com/p/calibre-ebook/downloads/list
Hamster Free eBook Converter source codes: http://ebook.hamstersoft.com/en/support
License GNU GPL 3.0: http://www.gnu.org/licenses/gpl.html"
So, they've included the GPL in their license terms, and have published the source code for the eBook converter. Looks like yet another win for GPL.

Derivative works is one of these grey areas that are improved in v3. Section 5.c of the GPL v3 states:

c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged.

So even if you keep the original work in a separate DLL, the whole must still be released under the GPL3. Besides, if you remove the DLL the whole doesn't do anything usefull anymore, so it's clearly derived, even by v2 standards.

Except that the license doesn't get to define the meaning of "derivative work". If the GPL were a contract, it could define whatever limitations it wanted, but it's not, it's a uni-directional license that provides specific exemptions from the exclusive rights defined in copyright law. This means that if copyright law permits a given usage of copyrighted material, the GPL can't remove that permission.

It's not clear whether or not copyright law considers dynamic linking to constitute creation of a derived work. If it does, then permission is required and the GPL can attach strings to that permission. If it doesn't, then no permission is required so Hamsersoft doesn't need the GPL's permission and therefore doesn't have to comply with its requirements.

c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged.

So even if you keep the original work in a separate DLL, the whole must still be released under the GPL3.

Besides, if you remove the DLL the whole doesn't do anything usefull anymore, so it's clearly derived, even by v2 standards.

what institutions do we have in place to protect OSS software effectively as small OSS devs? Do such institutions work?

Someone correct me if I'm wrong, but I thought this is why some projects assign their copyright to the FSF, so that there is a dedicated group that will pursue violations: http://www.gnu.org/licenses/gpl-violation.html

At any rate, since this seems to be getting a lot of attention and could turn into a high-profile case, you may want to contact the FSF or SFLC or both.

Sounds like you could benefit from running GNU Screen on a server somewhere (assuming all those sessions are SSH or other cli friendly interfaces to the various places you do stuff).

Multiplexing is a great way to keep those sessions open and allow you the same access from other nodes pn the network. Besides, desktops really benefit from regular reboots - helps clear out the memory leaks and all.

Or the fact that practically every major software project is developed using C++?

The page you linked to doesn't really back up that claim. It says right at the top that this page lists only software written in C++. Sure, there is a lot of software being developed in C++, but there is also a lot of software being developed in C (e.g. Linux, most of GNU, most projects on Freshmeat), Java (a lot of commercial development, and a growing number of open source projects, too), and don't forget PHP and JavaScript, which are widely used for programming for the Web (e.g. by Google and Facebook).

Of the applications I use on a daily basis, only my web browser (over time, this has been Opera, Mozilla, Konqueror and Firefox) is written in C++. Most of the rest is written in C, with a handful of things written in Perl and a handful in Ruby. Then again, I don't use Windows. It seems to me that C++ and C# are much bigger there than in the Unix world.

the PC model is obsolete and no longer fits the needs of consumers.

So what model fits the needs of people who do something other than consume?