Hello All,
Robert Dewar wrote:
Gerald Pfeifer wrote:
On Wed, 1 Oct 2008, Basile STARYNKEVITCH wrote:
is the goal to only permit FSF copyrighted GPLed plugins
The FSF is concerned about making and keeping software free.
Copyright assignment to the FSF is required to get code into the FSF
version of
GCC; it is not needed otherwise.
Gerald
Free software is a concern I do have and do share. But notice that
GPL-ed software is different from FSF copyrighted software. First, there
exist GPL-ed software which are not FSF copyrighted, and second (and
much more relevant to GCC plugins) getting authorized to contribute to
GPL-ed software is (at least for me, and probably many others) much less
difficult than getting the FSF copyright transfer form signed by his/her
employing organization (with the additional issue, that FSF copyright
transfers are not exactly public).
Just because of that, I believe (maybe wrongly) that the plugin legal
effort, once approved by FSF (ie once the yet unknown runtime license is
adopted & published) might have as a side effect that GPL-ed code which
is not FSF copyrighted may be more common in GCC (as plugins). At least
in Europe, be authorized to publish GPL-ed code is much less difficult
than getting the FSF copyright transfer.
And of course, as always, it is fine to do anything with your
own personal copy of gcc, including fiddling with plugins. But
when it comes to distribution, the FSF would like to encourage
only free software plugins, and discourage or if possible
prohibit propietary plugins (what can be prohibited is quite
unclear for a number of reasons, which is why this is under
discussion).
I do think (but I am perhaps naive, and certainly not a lawyer, and I
know nothing about the US law system) that a way to make proprietary
plugins harder is to avoid stabilizing an API. By the way, my MELT
branch in practice enforces that quite well. For technical reasons, when
a core part of MELT is slightly modified (and this might probably
happens when GCC with MELT is evolving) all the MELT generated C files
(which are generated from MELT sources gcc/melt/*.bysl) have to be
generated again. This means that in practice MELT is useful only for
code for which you have the MELT source files [of course this technical
restriction does not technically require GPL on the MELT source files;
the GPL requirement on *.bysl files is a legal consequence of GPL in
GCC], so a proprietary MELT plugin is nearly impossible.
For those having compiled the MELT branch, to be more specific, if you
modify gcc/melt/warmelt-first.bysl [I agree you might not do that often]
then you have to regenerate every warmelt*.c files, their warmelt*.so
files, and every other MELT generated file. Hence, the MELT source code
should be accessible, and the installation of a MELT branch GCC does
install every *.bysl file. In practice proprietary MELT plugins would be
very impractical (assuming MELT would be inside gcc-4.y with y>=5, i.e.
a *.so file produced thru MELT for gcc-4.y.3 won't work with gcc-4.y.4
unless regenerated from its MELT source). BTW, there are other languages
with similar proprieties. For example, an Ocaml file compiled by
ocaml-3.10 cannot be linked into an Ocaml program compiled by
ocaml-3.11; you need to recompile all the Ocaml code at every Ocaml release.
Notice also that I don't know about any proprietary library which does
not ship its header files "*.h", but only a precompiled header file.
This seems significant to me.
In practice, I strongly believe that the main way of avoiding
proprietary plugin is just to code as usual, i.e. avoid freezing any
internal API or internal data representations inside GCC. This is
already the case (and won't change soon even if people wanted to). So I
don't think that a lot of proprietary plugins will appear. Also, while
there is a real market for services around software tools like compiler,
the market on proprietary compilers is apparently shrinking (partly
thanks to the success of GCC) - outside of Microsoft systems at least.
So I don't think that proprietary plugins to GCC will be very
successful; I don't perceive them as a significant threat to GCC (but I
understand some of the FSF concerns regarding the runtime license).
But then, I am French, politically more on the social democrat side,
working in a government owned organization, so not struggling with the
market each hour (even if I do have market related concerns, because I
have to find fundings which require market relevances.).
The compiler landscape has significantly changed thanks to GCC. Few
organizations can ignore GCC!
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
