Forking old GMGPL libs ?

Forking old GMGPL libs ?

[Patrick]

Hi Everyone

I am really tense right now! please forgive me if this post is not a good one.

I've been on a FSF mailing list for the past few days and I am really PO'd with the FSF right now.

They lecture about their "four freedoms" but they deny that there are any valid concerns for end users rights outside of this.

I am working on two projects. One of them is a data collection/analysis tool to help parents of special needs kids record data for use by professionals like speech therapists later. I want to release it with source code but I don't ever want anyone to end up being charged for it.

I want it to be free-as-in-beer forever as well as well as open sourced. The FSF is against this. If you search on Ebay for basically any large FLOSS application, like Gimp for instance, you will find them being sold to people who already have internet connections (because they can bid)but again not a problem to the FSF that people are being charged $20 + shipping for Gimp, even though they could download it for free if they understood the situation. It's exploitation of people who don't understand whats available.

Now I have to forgo all FSF licensed libraries and it's going to be harder. Sure I have GCC and the runtime exception for basic Ada use but what about all the GNAT libraries. I don't have $20K + lying around for the non-GPL versions.

So to the point!(thanks for your patience)

I was thinking about forking older GNAT libraries that were licensed under GMGPL. If someone gives me an older library that they received under the GMGPL then don't' they still have the right to redistribute it under the GMGPL ? Adacore can't retroactively change licences on software they already distributed can they?

If they can't I could try to take on a few libraries. Maybe over time I could improve them a bit and I could keep GMGPL libraries available for the 99 % that can't afford the current way that GMGPL GNAT libraries are distributed.

One more thing...


This is total crack smok'in, I hardly know anything about the clang compiler and don't have the time of intelligence to fork GNAT but does anyone think it would be technically possible to retool GNAT's to output clang's AST. It sounds like clang  is able to output it's AST and read it in later. A totally freestanding Ada compiler could be completely decoupled from the clang codebase as long as it outputted a compatible AST.

Thanks for reading and if I have upset anyone please don't come back at me too hard, I probably am not thinking straight!

Thanks-Patrick

Re: Forking old GMGPL libs ?

[Georg Bauhaus]

On 06.10.12 00:51, Patrick wrote:
> I was thinking about forking older GNAT libraries that were licensed under GMGPL. If someone gives me an older library that they received under the GMGPL then don't' they still have the right to redistribute it under the GMGPL ?

If you follow the text of the GMGPL, it speaks about
instances and linking of *this*. Not of derivative works,
not of changed works, and not about transferring the right
to decide on the copyright to anyone merely because they
also want their changes to be GMGPLed.

I cannot but read the exception as to apply to the software
*as* *is*. Period.

The Wikipedia entry on "GNAT Modified General Public License"
is junk, on several accounts. I'd rather not venture changing
it now, but perhaps it is best to just remove the introductory
sentence and add some links to legal prose that hopefully
exists somewhere.

Re: Forking old GMGPL libs ?

[Patrick]

Hi George

maybe I am mixed up about the GMGPL. 

Judging from this link:
http://libre.adacore.com/comparisonchart/

I thought that GMGPL is basically LGPL, allowing static linking with other licences and that GNAT GPL was GPL only and was only suitable for so-called free software development.

Did I get this wrong?

Re: Forking old GMGPL libs ?

[Georg Bauhaus]

On 06.10.12 05:28, Patrick wrote:
> I thought that GMGPL is basically LGPL,

The Lesser GPL is different from GMGPL, and from the more
recent library exceptions; this seems certain.

One LGPL difference appears to be about changing "your parts" or
"their parts" and how this affects conveying works;
there are a number of definitions of terms at the start
of the license that indicate its direction.

To the extent I speculate what the legal status of GNAT GPL is,
the name, I think, surely indicates that it is better used only
when GPL compatible licenses are fine. A decent programmer will
choose in consideration of the wishes of GNAT's producers, I'd say.

I'll try an example. We use a notification program that is written
in Ada, for the most part. (Though not much else is written in Ada
at this site). Since our contractual obligations require that we
deliver both executables and source anyway, our choice of compilers
can include GNAT GPL.

Re: Forking old GMGPL libs ?

[Stephen Leake]

Patrick <patrick@spellingbeewinnars.org> writes:

> I want it to be free-as-in-beer forever as well as well as open
> sourced. The FSF is against this. If you search on Ebay for basically
> any large FLOSS application, like Gimp for instance, you will find
> them being sold to people who already have internet connections
> (because they can bid)but again not a problem to the FSF that people
> are being charged $20 + shipping for Gimp, even though they could
> download it for free if they understood the situation. It's
> exploitation of people who don't understand whats available.

You can't fix ignorance thru a license, only thru education. In this
case you need better marketing of your free version.

You also can't fix bad people (exploiters) thru a license. Again, one
solution is to do a better job of marketing than they do.

Of course, marketing costs money, which is one reason the people that
are charging money for free software packages do so; it pays for the
marketing.

TANSTAAFL.

-- 
-- Stephe

Re: Forking old GMGPL libs ?

[Florian Weimer]

> This is total crack smok'in, I hardly know anything about the clang
> compiler and don't have the time of intelligence to fork GNAT but
> does anyone think it would be technically possible to retool GNAT's
> to output clang's AST.

Clang's AST is very specific to the C family of languages.  You'd have
to generate LLVM directly.

Re: Forking old GMGPL libs ?

[Simon Wright]

Patrick <patrick@spellingbeewinnars.org> writes:

> I am working on two projects. One of them is a data
> collection/analysis tool to help parents of special needs kids record
> data for use by professionals like speech therapists later. I want to
> release it with source code but I don't ever want anyone to end up
> being charged for it.

Laudable.

> I want it to be free-as-in-beer forever as well as well as open
> sourced. The FSF is against this. If you search on Ebay for basically
> any large FLOSS application, like Gimp for instance, you will find
> them being sold to people who already have internet connections
> (because they can bid)but again not a problem to the FSF that people
> are being charged $20 + shipping for Gimp, even though they could
> download it for free if they understood the situation. It's
> exploitation of people who don't understand whats available.
>
> Now I have to forgo all FSF licensed libraries and it's going to be
> harder. Sure I have GCC and the runtime exception for basic Ada use
> but what about all the GNAT libraries. I don't have $20K + lying
> around for the non-GPL versions.

I think you may have the wrong end of the stick here.

The point of the GMGPL (or the GCC Runtime Library Exception[1]) is that
it allows a software product to be distributed *without* the source
code:

    "You have permission to propagate a work of Target Code formed by
    combining the Runtime Library with Independent Modules, even if such
    propagation would otherwise violate the terms of GPLv3, provided
    that all Target Code was generated by Eligible Compilation
    Processes. You may then convey such a combination under terms of
    your choice, consistent with the licensing of the Independent
    Modules."

So, given GCC, your best bet is surely to write your own code uder the
GPL without the exception and to use similar libraries.

I don't see why people shouldn't offer a CD of GIMP on Ebay for £2.95 +
50p p&p. If I want a CD instead of downloading, why should you want to
stop me? If *you* provide me the software on a CD, won't you expect me
to pay for it?

[1]<http://www.gnu.org/licenses/gcc-exception.html>

Re: Forking old GMGPL libs ?

[Brian Drummond]

On Fri, 05 Oct 2012 15:51:04 -0700, Patrick wrote:


> This is total crack smok'in, I hardly know anything about the clang
> compiler and don't have the time of intelligence to fork GNAT but does
> anyone think it would be technically possible to retool GNAT's to output
> clang's AST. 

Hi Patrick. 

I'm not going to comment on licensing issues, but since I am in the 
process of messing about in the gcc front end for another project:

Grab the gcc sources and look for yourself.
The GNAT compiler is in the gcc/ada folder and it is HUGE. 
However there is a separate folder labelled "gcc-interface" containing 
only 17 files.

Unfortunately these are all in C and some of them are quite large.
Central to the interface is "struct lang-hooks" in misc.c and the defines 
around it. For example, "gnat_parse_file" is the hook into the main 
parser. Hopefully this is written in Ada and exported to the C layer...

This will give you an idea of the size of the project. 

Looking at it, I am glad my project is much smaller, and even that would 
have been too much for a first gcc project.

I am currently trying to get GHDL to build with gcc 4.7; it last built 
successfully with gcc4.3.4 or so. Like Gnat, it is written mostly in Ada, 
with a thin layer of C between it and the GCC internals. However it is 
about an order of magnitude smaller than Gnat.

There have been a couple of suggestions on the GHDL-discuss mailing list 
that GHDL would have been better re-written in C or C++. These take no 
account of the fact that the porting difficulty has ALL been in the 
existing C code (2% or so), the 98% written in Ada has not needed a 
single change...

As to targetting Clang versus LLVM, I haven't looked at Clang. But LLVM 
looked to me like a virtual machine (asm-like) rather than a syntax tree 
(AST like Generic or Gimple in gcc terms). Which to me, would raise the 
question of whether the LLVM back end can do the optimisations you want.

The benefit of targeting Generic or Gimple is that you can then run GCC's 
extensive optimisation tools before descending to machine output. 
One would hope that Clang can do similar optimisations, given a tree. But 
I don't know the answer to that. 
It looked to me as if LLVM could not; and the DragonEgg plugin for GCC to 
let it output LLVM (after optimisation) suggests there is a need for a 
good optimiser ahead of LLVM. I would be delighted if someone could show 
me otherwise...

- Brian

LLVM and GCC (was: Forking old GMGPL libs ?)

[Ludovic Brenta]

Brian Drummond writes on comp.lang.ada:
> I am currently trying to get GHDL to build with gcc 4.7; it last built
> successfully with gcc4.3.4 or so. Like Gnat, it is written mostly in
> Ada, with a thin layer of C between it and the GCC internals. However
> it is about an order of magnitude smaller than Gnat.

I'm glad you're doing this; the package ghdl in Debian unstable is stale
and is the last one that still requires gnat-4.4; all other Ada packages
have migrated to gnat-4.6 long ago.

> As to targetting Clang versus LLVM, I haven't looked at Clang. But
> LLVM looked to me like a virtual machine (asm-like) rather than a
> syntax tree (AST like Generic or Gimple in gcc terms). Which to me,
> would raise the question of whether the LLVM back end can do the
> optimisations you want.

LLVM is both the virtual machine and an intermediate representation[1].
Contrary to GCC, LLVM's IR is serializable: one can save it to disk and
re-load it into the virtual machine for ahead-of-time or just-in-time
compilation.  LLVM is also a good optimizer that works on that IR; just
not yet as good as GCC.  The IR is, I think, better designed than that
of GCC because it was designed from the onset as language-neutral and
very rich.  The IR of GCC was initially designed for C only and was
later extended in ad hoc ways for other languages.

[1] http://llvm.org/docs/LangRef.html

A hypothetical Ada front-end for LLVM needs only emit this
well-specified IR.  Duncan Sands once made such an Ada front-end based
on the Ada front-end in GCC 4.2.  I'm not sure how this worked at the
time; I suppose Duncan replaced the GCC interface you mentioned with an
LLVM interface.  This has now been superseded by DragonEgg, whereby the
GCC Ada front-end feeds its AST into LLVM, which then translates it to
its IR, runs its optimizers and emits the final assembly.

-- 
Ludovic Brenta.

Re: LLVM and GCC (was: Forking old GMGPL libs ?)

[Patrick]

I'm home :) I love this list, thanks for all the great feedback

Thanks Stephen L and Florian

 Hi Simon

"I think you may have the wrong end of the stick here."

I can see why you would say this. This is not the typical BSD vs GPL thing. I actually want the option to release under what IMHO would be a more restrictive license. There are a few no-commercial use licenses that look promising.


 Thanks again Georg

Between your last post and a snippet from Simon's, I might be getting the picture now. Is it that GMGPL allows GPL code to ship without source but does not allow it to link to otherwise GPL incompatible code like BSD?

 Hi Brian

GNAT is immense and I don't really think I have the skills to do anything with it but in a tribute to Ada, someone of my skill level can still read it. It is about 10X easier for me to read Ada then C. Thanks for the DragonEgg tip

 Hi Ludovic

As always, it's great to see you helping on the list day in and day out :)

Re: LLVM and GCC (was: Forking old GMGPL libs ?)

[Brian Drummond]

On Sat, 06 Oct 2012 13:27:48 +0200, Ludovic Brenta wrote:

> Brian Drummond writes on comp.lang.ada:
>> I am currently trying to get GHDL to build with gcc 4.7; it last built
>> successfully with gcc4.3.4 or so. 

> I'm glad you're doing this; the package ghdl in Debian unstable is stale
> and is the last one that still requires gnat-4.4; all other Ada packages
> have migrated to gnat-4.6 long ago.

Thanks. I'm working with 4.7 (home built) on Debian, but it should back 
port to 4.6 easily. If you would permit, I may have to bug you with 
questions on the gcc build system, I am very weak in that area.

So far it builds, and compiles the VHDL standard library (with some 
fiddling) but the make process then falls over building libgcc, so I 
can't get as far as "make install".

I have also fiddled with the makefiles; I need to learn how to back-
propagate these fiddles into the inputs to ./configure. (Running a 
configure each time you change something gets old fast!)

Later it might be worth turning GHDL into a gcc plugin, though that may 
be more than I want to try...

>> LLVM
>> looked to me like a virtual machine (asm-like) rather than a syntax
>> tree (AST like Generic or Gimple in gcc terms). Which to me, would
>> raise the question of whether the LLVM back end can do the
>> optimisations you want.
> 
> LLVM is both the virtual machine and an intermediate representation[1].
> Contrary to GCC, LLVM's IR is serializable: one can save it to disk and
> re-load it into the virtual machine for ahead-of-time or just-in-time
> compilation.  

It's very neat stuff and thanks for the reference. But on a brief 
reading, it does not quite answer my question ... can the intermediate 
representation (IR) represent a tree?

> ... DragonEgg, whereby the
> GCC Ada front-end feeds its AST into LLVM, which then translates it to
> its IR, runs its optimizers and emits the final assembly.

which suggests the AST is in ANOTHER format, albeit one which LLVM can 
read and transform into IR. I saw no mention of that other format ( or 
dialect of IR)? or a tree reader in the reference manual. (It is entirely 
possible I missed it!)

The way I read, DragonEgg uses the GCC tools to work on the tree, and 
feeds something lower level (e.g. SSA) which is already close to the LLVM 
IR.

- Brian