25 Dec
2021
25 Dec
'21
12:34 a.m.
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(a)minnie.tuhs.org>
wrote:
> On 12/21/21 11:23 PM, jason-tuhs(a)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
>
>