Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Thu, 30 Oct 2014 17:58:37 +0100

On Tuesday 28 October 2014 15:27:49 J. Lewis Muir wrote:
> On 10/24/14 3:13 PM, Johnson, Andrew N. wrote:
> > Hi Lewis,
> >
> > Read all of the answer to the last question at
> > http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins and
> > consider: If the act of loading and executing a plugin that just
> > runs
> > to completion and returns a result is regarded as "borderline" but
> > just about acceptable, and communicating with one via shared memory
> > is equivalent to dynamic linking, then any additional communication
> > between a main program and a plugin, say through an I/O stream, is
> > almost certainly to be on the wrong side of borderline.
> >
> > I may be splitting hairs, but someone reading that using fork &
> > exec to invoke a GPL plugin can free the program from the GPL's
> > restrictions may start them thinking about using that to subvert the
> > GPL and not realize that they're on a slippery slope to probable
> > infringement.
>
> Hi, Andrew.
>
> OK, I see where you're coming from.
>
> Consider the FAQ question, "What is the difference between an
> 'aggregate' and other kinds of 'modified versions'?":
>
>   http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
>
>   ...
>
>   "Where's the line between two separate programs, and one program
>   with two parts? This is a legal question, which ultimately judges
>   will decide. We believe that a proper criterion depends both on the
>   mechanism of communication (exec, pipes, rpc, function calls within
>   a shared address space, etc.) and the semantics of the communication
> (what kinds of information are interchanged)."
>
>   ...
>
>   "By contrast, pipes, sockets and command-line arguments are
>   communication mechanisms normally used between two separate
>   programs. So when they are used for communication, the modules
>   normally are separate programs. But if the semantics of the
>   communication are intimate enough, exchanging complex internal data
>   structures, that too could be a basis to consider the two parts as
>   combined into a larger program."

In other words: what it means to be "one combined program" versus "two
separate programs" is impossible to define in general terms. Not only
does it depend on circumstantial details of the environment in which the
program(s) are run, if one takes the language of the above lines
seriously it also depends on custom, viz. the repeated use of the word
"normally".

Imagine a new generation of operating systems where things such as
"exec, pipes, rpc" have been replaced by other mechanisms. A system
could be designed to consist of many very small "programs" that are
plugged together *by the user* to form complex functionality. The FSF
expressly states that GPL does not restrict *use* of (GLP-licensed)
programs in any way, so it could not regard such use as forbidden
without contradicting itself.

On the other hand, think about systems in which there are no "programs"
in usual sense, just subroutines (e.g. VxWorks, RTEMS): using a GPL'ed
subroutine together with another non-free subroutine inside the same
system would then be forbidden because one has to regard the whole thing
as one big program and thus a "derived work". So have we already been
violating the GPL all the time or what?

>From a technical or scientific perspective, attempting to stipulate a
strict boundary between a program and its surrounding environment is
worthless at best, and hindering progress at worst. IMHO the FSF is
running a pretty dangerous course here, not only because their
"definitions" might easily become obsolete, but also because making
technically unsound distinctions tends to turn technical people off.

The FSF has expressly stated that the GPL *is* a political instrument,
designed not only to defend free software against attacks (theft) from
proprietors (any free license would do that), but also to proliferate
free software. Whatever one's position on this goal, it seems that
trying to pursue it by abusing the existing copyright law can only be
done at the price of making artificial, technically unsound
distinctions, very similar in nature to those that need to be made to
support the abuse of the copyright law to defend the interests of
software producing companies; all this leading to endless (and
completely pointless) confusion and controversy among technical people.

Sorry for continuing this off-topic discussion here, but I think it
makes sense to remember once in a while *why* it can never come to any
sensible conclusion...

Cheers
Ben
--
"Make it so they have to reboot after every typo." â€• Scott Adams

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System