[CentOS] Real sh? Or other efficient shell for non-interactive scripts

Joerg Schilling Joerg.Schilling at fokus.fraunhofer.de
Mon Apr 27 18:26:59 UTC 2015


Les Mikesell <lesmikesell at gmail.com> wrote:

> On Mon, Apr 27, 2015 at 11:57 AM, Joerg Schilling
> <Joerg.Schilling at fokus.fraunhofer.de> wrote:
> > >>
> >> You can't distribute GPLd programs unless 'the work as a whole' is
> >> covered by the GPL.   There can't be a distinction between binary and
> >> source since one is derived from the other.
> >
> > Now you just need to understand what "as a whole" means....
>
> Apparently we live in different universes.  Or at least countries -
> where meanings are relative.  But it doesn't matter how either of us
> understand it, what matters are how the legal system understands it in
> our native countries.

NO, you just still do not understand the legal rules that apply. I recommend 
you to inform yourself about the rules that apply. Fortunately all serious 
lawyers basically say the same here...


> > Maybe you are a native english speaker and thus lazy with reading the GPL.
> > If you carefully read the GPL, you of course understand that it is _very_ careful
> > about what parts the GPL applies to. It definitely does _not_ apply to the
> > "complete source".
>
> Yes, in english, 'work as a whole' does mean complete.  And the normal
> interpretation is that it covers everything linked into the same
> process at runtime unless there is an alternate interface-compatible
> component with the same feature set.

You of yourse need to understand what this means in a legal context and not in 
kitchen english...

> > If you have problems to understand the GPL, read one of the various comments
> > from lawyers, but avoid Mr. Moglen - he is well known for intentionally writing
> > false claims in the public and only uses correct lawful interpretations if he
> > is in a private discussion.
>
> No one is interested in setting themselves up for a legal challenge
> with opposing views by experts.

So could you please explain why all distros that asked specialized lawyers ship 
the original cdrtools and thos distros that do not did never ask a lawyer?

> > And fortunately, Larry didn't publish "patch" under GPL, so I was able to write
> > a non-GPLd POSIX compliant patch (note that gpatch is not POSIX compliant).
>
> Larry is a nice guy.  He doesn't want to cause trouble for anyone.
> Apparently that's not universal....

I am also a nice guy who in interested in collaboration amongst OSS projects. 

BTW: I could relicense mkisofs to CDDL if I remove the apple HFS filesystem 
support. This is why the code originally from Eric Youngdale did drop much 
below 50%, it is even below 10%. I am a nice guy and leave things as they are 
as long as possible after I asked specialized lawyers. 

If you ask a lawyer, you will learn that you believed the wrong people before.

> > You need to _understand_ the GPL and avoid to just lazyly read it as you did
> > before. The GPL does _not_  apply to _everything_. The GPL just applies to the
> > "work" that is under GPL. For the rest, you just need to include it under _any_
> > license and if you did ever carefully read the GPL, you of course did know that
> > already.
>
> It applies to everything copyright law applies to since it is really
> copyright law that restricts distribution and the GPL simply provides
> the exceptions.  There's a valid case for linked components to be
> considered derivative works of each other if they require the other
> for the work as a whole to be functional.

Read the GPL, to learn that the GPL does not include the term "linking". The 
law applies instead and the law is related to the term "work" - not linking.

I explained already, that every part of the GPL that uses GPLs own definition 
of a derivative work is void because it is in conflict with the law.

BTW: It seems to be a progress that you now admit that parts that are usable 
separately are independend works. This applies to the cdrtools. You just need 
to check the cdrtools instead of listening to the false claims from the 
anti-social people at Debian.



> >> My question is 'why not do it?'.   You don't lose anything but the
> >> restrictions that you pretend aren't there since a dual license allows
> >> you to choose the terms of the other if you prefer.  I don't like the
> >> GPL restrictions either, but I just say so instead of pretending
> >> otherwise.   A dual license is clearly needed unless your point is to
> >> make people choose between either using your code or anything that is
> >> GPL'd.
> >
> > If I did add the GPL to my code, I would not win anything, because antisocial
> > people would still prevent it from being included in Debian or RedHat.
>
> Beg your pardon?   You lost me here.  If you remove the reason for
> exclusion, what evidence do you have that the work would still be
> excluded, other than perhaps your long history of keeping it from
> being usable?

There _never_ was any reason for exclusion.

You should verify that you are serious with your claims and include the 
original cdrtools now since there is no reason for exclusion: the claimed 
problems do not exist and did never exist.

Let me give a hint on the true background: the license change towards CDDL was 
a reaction of the antisocial activities from Debian. Any person who is 
interested could check the true and not fakeable timeline in the internet to 
verify this. 

> How do you imagine such a 'false claim' affects anyone's use of
> released code and source or why it would be a factor in their choice?
> Personally I can't reconcile RedHat's restriction on redistributing
> binaries with the GPL's prohibition on additional restrictions, but
> Centos makes that a non-issue.

If redhat follows the rules of the GPL, redHat should ship the original 
cdrtools now!

Jörg

-- 
 EMail:joerg at schily.net                    (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'



More information about the CentOS mailing list