Re: Emacs contributions, C and Lisp

[David Kastrup]

Jacob Bachmeyer <address@hidden> writes:

> David Kastrup wrote:
>> Jacob Bachmeyer <address@hidden> writes:
>>   
>>> Richard Stallman wrote:
>>>     
>>>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>>> [[[ whether defending the US Constitution against all enemies,     ]]]
>>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>>
>>>> The situation with Emacs will be the same as it is with GCC now:
>>>> plug-ins have to be GPL.
>>>>         
>>> This illuminates the central question at hand:  if an Emacs plugin is
>>> GPL, and provides access to internals of GCC, which is also GPL, can
>>> nonfree software use that Emacs plugin?
>>>     
>>
>> That's not the central question at hand.  The central question is: if an
>> Emacs plugin can provide access to internals of GCC, what keeps nonfree
>> software from using the same mechanism as the Emacs plugin to get access
>> to internals of GCC?
>
> What stops nonfree software from doing that is that the mechanism used
> to get access to internals of GCC is very low-level (using ptrace(2)
> to directly access GCC's memory would not be out of the question) and
> transfers GCC internal structures over the link, which are interpreted
> within the Emacs process.  According to the GPL FAQ:  "Using shared
> memory to communicate with complex data structures is pretty much
> equivalent to dynamic
> linking."(<URL:http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins>)
> I expect that GCC's internal trees qualify as "complex data
> structures".  There is certainly not a nice, readable, text AST dump
> involved at any point.

So gdb has to be licensed identically with any program you debug using
it because it is accessing the respective program's memory?

At any rate, does not sound like an interface one could keep steady
across different GCC versions.  To make that the case, you need
something describing the internals' meaning, akin to how debug
information describes memory layout.  Once you have that kind of "my raw
memory means $x" description, this constitutes an interface.  Possibly
an awkward interface, but that's not legally significant.

>> The price for interoperation is interoperation.  And since it is
>> rather more than less important for free as opposed to proprietary
>> software that independent teams can create cooperating applications,
>> I don't see that it makes sense for us not to pay that price.  And
>> the latest point to which we can delay this is when a concrete
>> application is imminent.
>>
>> We can't guarantee that such an application will be successful if we
>> allow it.  But it will definitely fail if we don't.
>
> You are right, which is why I am seeking a workable solution that all
> can be happy with.

It sounds to me like we are looking for a snakeoil bottle label text
that will placate Richard and/or ourselves for some while so that we
might carry on a bit.  But I don't think we can terminally avoid dealing
with the fact that we cannot achieve interoperation between separate
free software applications without enabling interoperation with separate
nonfree software that does not trigger copyright.

And our limited and distributed resources and skills as free software
developers mean that our success depends on interoperation within free
software.  We can't afford this process every time we want something to
work together.

-- 
David Kastrup