> My limited understanding is that the GPLed parts of the product must be
made available.  But I'm not aware that using GPLed parts means that
/everything/ /else/ must also be made available.

From what I read, you are correct -it doesn't. At least that's what the FSF
appears to say themselves:
https://www.gnu.org/licenses/gpl-faq.en.html#GPLAndNonfreeOnSameMachine
There's been some attempts over the years (eg Microsoft's "get the facts"
campaign) to muddy the waters on that issue and paint the GNU license as
acting "cancerous"; but I'm not aware of any legal precedents backing that
up.

Another part of the same page that you might find interesting (regarding
distributing sources):
https://www.gnu.org/licenses/gpl-faq.en.html#DistributeWithSourceOnInternet

Of course if someone is acting as an owner or employee of a company they'll
want to consult their legal staff in addition to reading what the GNU have
to say as well.

/disclaimer; I do not work in IT, but have used Unix and Linux for 25 years
now -make of that what you will

On Fri, Dec 24, 2021 at 1:52 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 12/21/21 11:23 PM, jason-tuhs@shalott.net wrote:
> > As an end user, you would not care.
>
> That tends to explain why I've not personally cared.
>
> > As a vendor or distributor, you would care.  Anyone doing an OS or other
> > software distribution (think the BSDs, of course; but also think Apple
> > or Microsoft) needs to care.  Anyone selling a hardware device with
> > embedded software (think switches/routers; think IOT devices; think
> > consumer devices like DVRs; etc) needs to care.  GPL (or similar
> > "virally" licensed) software carries legal implications for anyone
> > selling or distributing products that contain such software; and this
> > can be a motivation to use software with less-restrictive license terms.
>
> Okay.
>
> My limited understanding is that the GPLed parts of the product must be
> made available.  But I'm not aware that using GPLed parts means that
> /everything/ /else/ must also be made available.
>
> Also, I believe /made/ /available/ means that it must be accessible or
> provided when asked.  Thus it does not mean that the GPLed code needs to
> be shipped with the product.
>
> > I'm aware of a few random features that are in ksh93 but not other
> > shells (random, trivial, example that I saw just today*: "printf
> > %(FORMAT)T"). That said, my first impulse would have been to say no,
> > there aren't any meaningful (technical) advantages to ksh over bash --
> > except that it seems there's still some amount of active development
> > going on in ksh:
>
> The biggest motivation I had in a previous job was to make sure that my
> account's shell was set to a shell that lived on the root file system.
>
> I could easily have that shell test to see if my preferred shell was
> available and start or exec it.  That way I could still log in if the
> file system with my preferred shell was not mounted.  As if I needed to
> address the underlying issue that was preventing the desired shell from
> being accessible.  E.g. /usr/bin/bash wasn't available b/c /usr wasn't
> automatically mounted at boot.
>
> > So I guess, for some people at least, there are indeed reasons to prefer
> > it, including (according to users in those github issues) performance.
>
> At my last job I helped administer some systems that didn't have any
> shells other than was was in the base OS installation.  (We won't talk
> about why.)
>
> > On the licensing front, the GPL is an issue for bash; but zsh is
> > available as a more modern, fully-featured shell that avoids any GPL
> > issues.  This is why Apple switched the default shell in OSX from bash
> > to zsh: they wanted to avoid the GPLv3.  Previously, they had been
> > shipping the last GPLv2 version of bash, which was from 2006.  According
> > to this blog, they've been avoiding any GPLv3 code and actively working
> > to remove even GPLv2 code in OSX for quite a while:
>
> That makes sense.
>
> > * bash seems to recognize %(FORMAT)T, but only takes epoch seconds as an
> > argument.  ksh93 takes anything vaguely date-like.  zsh and pdksh don't
> > recognize it at all.
>
> Interesting.
>
> Thank you for the informative reply Jason.
>
>
>
> --
> Grant. . . .
> unix || die
>
>