IMO

In any area of business and activity related to business, the idea behind, and protection of, trademarks is critical. But what some people don't understand is that in the Open Source/Free Software world, trademarks are, in many ways, the only real asset that a FOSS project has.

Think about this: in most normal areas of software development, the software itself (the code) is intellectual property. It is itself an asset, with value. But in an open source world, the code is free and open to all. "Having" the code isn't any sort of asset, since anyone can also have it as well; in fact, it is encouraged to share that code with as many people as possible. So whereas in other circumstances, the resulting work behind the effort of coding is an "asset", and, in many ways, the most valuable asset, with FOSS projects it is the least valuable.

So what is the main asset of a FOSS project?

The trademark. The brand and goodwill associated with that project. And for many projects, it's the only asset, and it's the main reason why people contributed to, and use, the code. For example, one significant reason why projects enter the Apache Software Foundation is that they want to leverage and benefit from the Apache brand. Being an Apache project automatically gives a project a sense of credibility, as well as a promise on how it will be governed and managed, and how code provenance will be done. It is a reputation obtained from years and years of doing things the right way; The Apache name means something. It has become a brand.

With this in mind, it should be somewhat obvious why FOSS projects walk that fine line between wanting (and needing) to protect their trademarks (and brand) yet, at the same time, allowing people to use those marks in as unrestricted ways as possible. On one hand, you want to use that brand to encourage even wider sharing and usage of the code, yet on the other hand, you must protect those marks from usage which would damage the brand, or confuse people. And so most FOSS projects or foundations create trademark policies that describe acceptable and unacceptable usage.

So I was shocked and extremely disappointed to hear that GNOME is having to battle Groupon over Groupon's unacceptable use of the GNOME mark. There are only 2 possible ways this could have come about:

1. Those at Groupon tasked with this effort are so incompetent and clueless that they never heard of GNOME
2. That Groupon is simply thumbing their noses at GNOME and, by extension, the entire FOSS community as well.

This is totally unacceptable, and is, IMO, an attack on all FOSS projects and foundations. When well-funded corporate entities, especially those who directly benefit from FOSS, go ahead and simply decide they can steam-roller over the FOSS community, it is time for all of us to take a stand. Help GNOME defend their mark!

In any area of business and activity related to business, the idea behind, and protection of, trademarks is critical. But what some people don't understand is that in the Open Source/Free Software world, trademarks are, in many ways, the only real asset that a FOSS project has.

Think about this: in most normal areas of software development, the software itself (the code) is intellectual property. It is itself an asset, with value. But in an open source world, the code is free and open to all. "Having" the code isn't any sort of asset, since anyone can also have it as well; in fact, it is encouraged to share that code with as many people as possible. So whereas in other circumstances, the resulting work behind the effort of coding is an "asset", and, in many ways, the most valuable asset, with FOSS projects it is the least valuable.

So what is the main asset of a FOSS project?

The trademark. The brand and goodwill associated with that project. And for many projects, it's the only asset, and it's the main reason why people contributed to, and use, the code. For example, one significant reason why projects enter the Apache Software Foundation is that they want to leverage and benefit from the Apache brand. Being an Apache project automatically gives a project a sense of credibility, as well as a promise on how it will be governed and managed, and how code provenance will be done. It is a reputation obtained from years and years of doing things the right way; The Apache name means something. It has become a brand.

With this in mind, it should be somewhat obvious why FOSS projects walk that fine line between wanting (and needing) to protect their trademarks (and brand) yet, at the same time, allowing people to use those marks in as unrestricted ways as possible. On one hand, you want to use that brand to encourage even wider sharing and usage of the code, yet on the other hand, you must protect those marks from usage which would damage the brand, or confuse people. And so most FOSS projects or foundations create trademark policies that describe acceptable and unacceptable usage.

So I was shocked and extremely disappointed to hear that GNOME is having to battle Groupon over Groupon's unacceptable use of the GNOME mark. There are only 2 possible ways this could have come about:

1. Those at Groupon tasked with this effort are so incompetent and clueless that they never heard of GNOME
2. That Groupon is simply thumbing their noses at GNOME and, by extension, the entire FOSS community as well.

This is totally unacceptable, and is, IMO, an attack on all FOSS projects and foundations. When well-funded corporate entities, especially those who directly benefit from FOSS, go ahead and simply decide they can steam-roller over the FOSS community, it is time for all of us to take a stand. Help GNOME defend their mark!

Reading over http://paste.lisp.org/display/143864, I am surprised just how wrong the entire post is.

The gist of the post is that the Shellshock bug is not bash's fault, but rather, in this argument, the fault of Apache and other facing programs in not "sanitizing" the environment before it gets into bash's hands.

Sweet Sassy Molassy! What kind of horse-sh*t is that?

As "proof" of this argument, pjb uses the tired old excuse: "It's not a bug, it's a feature", noting that bash's execution of commands "hidden" in environment variables is documented; But then we get the best line of all:

The implementation detail of using an environment variable whose value starts with "() {" and which may contain further commands after the function definition is not documented, but could still be considered a feature 

As far as outlandish statements, this one takes the cake. Somehow, Apache and other programs should sanitize magical, undocumented features and their failure to do so is the problem, not that this magic is undocumented as well as fraught with issues in and of itself.

Let's recall that if any other Bourne-type shell, or, in fact, any real POSIX-compliant shell (which bash claims to be), were being used in the exact situation that bash was being used, there would be no vulnerability. None. Nada. Zero. Replace with ksh, zsh, dash, ... and you'd be perfectly fine. No vulnerability and CGI would work just fine. And also let's recall, again focusing on Apache (and all web servers, in fact; It's not just Apache is affected by this vulnerability but any web server, such as nginx, etc...), the CGI specification specifically makes it clear that environment variables are exactly where the parameters of the client's request lives.

Also, let's consider this: A shell is where the unwashed public interfaces with the OS. If there is ANY place where you don't want undocumented magic, especially in executing random code in an undocumented fashion, it AIN'T the shell. And finally, the default shell is also run by the start-up scripts themselves, again meaning that you want that shell to have as few undocumented bugs... *cough* *cough*, sorry "features" as possible, and certainly not one's that could possible run things behind your back.

Yes, this bug, this vulnerability is certainly bash's, no doubt at all. But it also goes without saying that if bash was not the default shell (/bin/sh) on Linux and OSX, that this would have been a weaker vulnerability. Maybe that was, and is, the main takeaway here. Maybe it is time for the default shell on Linux to "return" to the old Bourne shell or, at least, dash.