ANNOUNCE: DTraq Released

ANNOUNCE: DTraq Released

[Marc A. Criley]

McKae Technologies announces the release of DTraq versions 1.000 for GNAT
3.15p and GNAT 1.100 for GNAT GPL 2005. DTraq is available on the
redesigned McKae Technologies website at http://www.mckae.com/dtraq.html.

DTraq is a data logging and playback debugging tool providing near realtime
   data logging and analysis to aid debugging and validation. Captured, or
'tapped' data from a program can be viewed live while the program is
running or, since it is being logged to a file, played back or printed out
later for off-line review and analysis.

DTraq differs from other logging and playback tools in that no data layout
maps or byte interpretations or "data dumpers" need to be manually created.
Nor is the application responsible for converting the raw binary data to
text form before logging it. DTraq handles all conversion automatically by
scanning the application's source code, identifying tapped data items, and
extracting the information it needs to properly convert and display the
logged items-simple scalar items as well as arrays and records. When the
layout of data items change, rescanning automatically picks up the changes.

Here are the most significant changes to DTraq since the last public
release, 0.986a:

- No more code generation and associated compilation needed when building a
logging server.  The logging server now uses an XML formatted configuration
file to recognize and process tapped data items.

- The command line driven "mkdtq" has been replaced with dtq-analyze,
providing a GUI-driven interface for source code scanning and generation of
the aforementioned configuration file.

- All the DTraq applications are now prefixed with "dtq": dtq-analyze,
dtq-vdt, and dtq-dv.

- Data transfer between tapped clients and the logging server has been
changed from a stream-based model to one of simply sending tapped data
items' bytes through a socket.  The result has been a significant
throughput increase, and, in conjunction with the use of configuration
files instead of code generation, a much simpler implementation.

- The data viewer can now be started independently of the logging server,
and the location of the logging server can then be interactively specified.
In addition, the data viewer can switch from one logging server to another.

- The need for temporary working directories has been reduced, and the
remaining use has been streamlined to reduce the chance of inconsistency
errors.


DTraq 1.000 for GNAT 3.15p is licensed using the GNAT-Modified GPL, i.e.,
GMGPL.

DTraq 1.100 for GNAT GPL 2005 is licensed using the full GPL, although the
instrumentation portion that is compiled into the client remains GMGPL, for
what it's worth.

A release for GNAT GPL 2006 will be provided once its downloading server's
traffic load eases.

Enjoy!

-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: ANNOUNCE: DTraq Released

[M E Leypold]

"Marc A. Criley" <marccriley@earthlink.net> writes:
> 
> DTraq 1.000 for GNAT 3.15p is licensed using the GNAT-Modified GPL, i.e.,
> GMGPL.
> 
> DTraq 1.100 for GNAT GPL 2005 is licensed using the full GPL, although the
> instrumentation portion that is compiled into the client remains GMGPL, for
> what it's worth.

Is that a change in policy or do you think/know that Code released for
use with GNAT 2006 cannot have the linking exceptions (for this part
of the code at least)?

Regards -- Markus

Re: ANNOUNCE: DTraq Released

[Marc A. Criley]

M E Leypold wrote:
> "Marc A. Criley" <marccriley@earthlink.net> writes:
> 
>>DTraq 1.000 for GNAT 3.15p is licensed using the GNAT-Modified GPL, i.e.,
>>GMGPL.
>>
>>DTraq 1.100 for GNAT GPL 2005 is licensed using the full GPL, although the
>>instrumentation portion that is compiled into the client remains GMGPL, for
>>what it's worth.
> 
> Is that a change in policy or do you think/know that Code released for
> use with GNAT 2006 cannot have the linking exceptions (for this part
> of the code at least)?

The licensing of DTraq is being driven by the licensing of the GNAT 
Run-time library.

I made an effort to keep the client instrumentation packages GMGPL (by 
replacing GNAT.Sockets in 3.15p with AdaSockets) so that one could at least 
theoretically use DTraq on non-GPL code.  Frankly I doubt the practicality 
of that, though, since DTraq uses ASIS, which is compiler-version specific, 
so to use the GNAT GPL 2005 version of DTraq one would have to compile and 
build their code with that compiler...which would require the code be GPL 
if it was to be distributed.

I haven't acquired GNAT GPL 2006 yet, but I have every expectation that it, 
too, will be GPL.

Continued DTraq development will be for the GNAT GPL 200x compiler 
versions, since those are AdaCore blessed and maintained.  Unless of course 
someone contracts for a GNAT Pro or other version :-)

-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: ANNOUNCE: DTraq Released

[Ludovic Brenta]

"Marc A. Criley" <mcNOSPAM@mckae.com> writes:
> The licensing of DTraq is being driven by the licensing of the GNAT
> Run-time library.
>
> I made an effort to keep the client instrumentation packages GMGPL (by
> replacing GNAT.Sockets in 3.15p with AdaSockets) so that one could at
> least theoretically use DTraq on non-GPL code.  Frankly I doubt the
> practicality of that, though, since DTraq uses ASIS, which is
> compiler-version specific, so to use the GNAT GPL 2005 version of
> DTraq one would have to compile and build their code with that
> compiler...which would require the code be GPL if it was to be
> distributed.
>
> I haven't acquired GNAT GPL 2006 yet, but I have every expectation
> that it, too, will be GPL.
>
> Continued DTraq development will be for the GNAT GPL 200x compiler
> versions, since those are AdaCore blessed and maintained.  Unless of
> course someone contracts for a GNAT Pro or other version :-)

I have downloaded the sources (not the binaries) of GNAT GPL 2006
Edition and I confirm that ASIS is pure GPL.

In addition, I am preparing a Debian package of ASIS 2006 under pure
GPL.  This is in contrast to the GNAT run-time library and every other
library, which will remain GMGPL.

So, if someone makes a Debian package of DTraq, that will be pure GPL.

-- 
Ludovic Brenta.

Re: ANNOUNCE: DTraq Released

[Simon Wright]

M E Leypold <development-2006-8ecbb5cc8a-REMOVETHIS@m-e-leypold.de> writes:

> "Marc A. Criley" <marccriley@earthlink.net> writes:
>> 
>> DTraq 1.000 for GNAT 3.15p is licensed using the GNAT-Modified GPL,
>> i.e., GMGPL.
>> 
>> DTraq 1.100 for GNAT GPL 2005 is licensed using the full GPL,
>> although the instrumentation portion that is compiled into the
>> client remains GMGPL, for what it's worth.
>
> Is that a change in policy or do you think/know that Code released
> for use with GNAT 2006 cannot have the linking exceptions (for this
> part of the code at least)?

(below, 'you' means Marc)

I'm slightly out of the loop on this one, since my paid work has an
AdaCore support contract; for my own OSS work, my position is:

* code meant for a user to include in her product, GMGPL

* code intended for tutorial/example/prototype, no restriction

* code that's part of the toolset, GPL

So for instance the Makefiles and GNAT Project files would be GPL, and
so would code generation stylesheets.

I think the lack of restriction on code meant to be customised is
quite important; "this is customisable, here is the default, I place
no restrictions on the use you make of it".

As a potential customer of yours, I would want the part of your code
that's linked with mine in my product (your runtime) to be GMGPL,
regardless of the compiler you use to develop it[1]. If your code uses
GNAT.Sockets, that means that if I want to distribute a non-OSS
product in binary I can do so provided that I use a version of GNAT
that is GMGPL -- so no change there! (and using AdaSockets would make
no difference, since the rest of the runtime is in the same boat).

Unless I've misunderstood DTraq, though, the recorder side _isn't_ in
the same boat, it's not intended to be released to my customers; so
the licence terms aren't so crucial. Clearly the binary distribution
terms have to match the compiler runtime, but why should the source
code?

That said, I can't see any reason why the 'instrumenter' and
'recorder' parts of DTraq shouldn't be pure GPL anyway, since they're
not intended to be part of my distribution; and even if they were I
could comply with GPL terms for them without affecting my own
product. I guess it might be different if my work and the recorder
were integral parts of my overall product, but that doesn't seem very
likely.


[1] Do you think there's any issue with generated code? One might
think that fragments of text copied into generated code could carry
licence implications with them. I adapted the GMGPL & bison terms
(bison copies text into generated parsers):

     As a special exception, when portions of this file are copied by
     a stylesheet processor into an output file, this file does not by
     itself cause the resulting file to be covered by the GNU General
     Public License.  This exception does not however invalidate any
     other reasons why the output file might be covered by the GNU
     Public License.

Re: ANNOUNCE: DTraq Released

[Marc A. Criley]

Simon Wright wrote:
> I'm slightly out of the loop on this one, since my paid work has an
> AdaCore support contract; for my own OSS work, my position is:
> 
> * code meant for a user to include in her product, GMGPL
> 
> * code intended for tutorial/example/prototype, no restriction
> 
> * code that's part of the toolset, GPL

Though I've not explicitly codified it before as a position, these bullets 
are consistent with my approach, though I might perhaps be a little more 
explicit by adding:

  * code _available_ for a user to include in her product(s), GMGPL

These covers the situation for XPath In Ada (XIA) and XML EZ Out, which 
were written because of DTraq, but since they have areas of application 
beyond that product were broken out on their own for community use.

> As a potential customer of yours, I would want the part of your code
> that's linked with mine in my product (your runtime) to be GMGPL,
> regardless of the compiler you use to develop it[1].

Which it now is.  I removed the GNAT dependencies from that code, which was 
primarily the replacement of GNAT.Sockets with AdaSockets, so as to get 
GMGPL instead of GPL (for GNAT GPL 2005 and beyond).

> Unless I've misunderstood DTraq, though, the recorder side _isn't_ in
> the same boat, it's not intended to be released to my customers; so
> the licence terms aren't so crucial. Clearly the binary distribution
> terms have to match the compiler runtime, but why should the source
> code?

That is true, the source code license terms aren't so crucial, the code 
could turn out to be tailored for a specific compiler and runtime, but 
distributed solely as source code, and therefore merely "inherit" the 
licensing of the RTL with which it is linked.  I opted for GPL on the DTraq 
core components because it gave me the most flexibility:  I could use 
AdaCore's free software releases, GNAT GPL 2005 and now 2006; I can 
utilitize any GPL or GMGPL or LGPL licensed software that I find useful; 
and I don't have to worry about tracking what software is under what 
license and who might "own" portions if modifications or enhancements were 
done under contract.

> That said, I can't see any reason why the 'instrumenter' and
> 'recorder' parts of DTraq shouldn't be pure GPL anyway, since they're
> not intended to be part of my distribution; and even if they were I
> could comply with GPL terms for them without affecting my own
> product. I guess it might be different if my work and the recorder
> were integral parts of my overall product, but that doesn't seem very
> likely.

The 'recorder', i.e., the DTraq Logging Server is pure GPL. The 
'instrumenter' portions, DTraq.Tap, et.al., could be GPL, but their removal 
would be required before the distribution of your product if you're 
licensing with something less than GPL.  However, I've suggested that the 
instrumentation be retained in the product because the taps can be disabled 
and your product run without a logging server present, and that way you 
retain the ability to run a deployed application in a remote debug or 
monitoring mode.  And also, if your app requires integrated logging, DTraq 
can fill the bill for that as well.

> [1] Do you think there's any issue with generated code? One might
> think that fragments of text copied into generated code could carry
> licence implications with them.

 From the DTraq perspective this is not an issue because the only part that 
would be at all likely to show up in generated code would be 
_instantiations_ of DTraq.Tap, and the GMGPL already covers that.

-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - XPath In Ada -- XML EZ Out

Re: ANNOUNCE: DTraq Released

[Simon Wright]

"Marc A. Criley" <mcNOSPAM@mckae.com> writes:

> Simon Wright wrote:

>> As a potential customer of yours, I would want the part of your
>> code that's linked with mine in my product (your runtime) to be
>> GMGPL, regardless of the compiler you use to develop it[1].
>
> Which it now is.  I removed the GNAT dependencies from that code,
> which was primarily the replacement of GNAT.Sockets with AdaSockets,
> so as to get GMGPL instead of GPL (for GNAT GPL 2005 and beyond).

What I don't see is why using GNAT.Sockets, which as an abstract
interface can be obtained GPL or GMGPL, ditto its implementations,
should make a difference to the licence under which _your_ source is
released?

Anyone is free to use eg the Booch Components with any Ada compiler
they like; certainly Aonix, probably Apex, either flavour of
GNAT. Instantiating a GMGPL source using a GPL runtime is going to
result in a binary that has to be issued under the GPL, sure.

I would find it quite hard to justify using AdaSockets given that
there is a perfectly workable and supported functionality in GNAT
already.

I also don't see why you've jumped through hoops to use AdaSockets
instead of GNAT.Sockets "so as to get GMGPL instead of GPL (for GNAT
GPL 2005 and beyond)". If I use GNAT GPL I _must_ release under GPL
(if at all), regardless of any GMGPL freedoms on other library
components.

Re: ANNOUNCE: DTraq Released

[M E Leypold]

Simon Wright <simon@pushface.org> writes:

> "Marc A. Criley" <mcNOSPAM@mckae.com> writes:
> 
> > Simon Wright wrote:
> 
> >> As a potential customer of yours, I would want the part of your
> >> code that's linked with mine in my product (your runtime) to be
> >> GMGPL, regardless of the compiler you use to develop it[1].
> >
> > Which it now is.  I removed the GNAT dependencies from that code,
> > which was primarily the replacement of GNAT.Sockets with AdaSockets,
> > so as to get GMGPL instead of GPL (for GNAT GPL 2005 and beyond).
> 
> What I don't see is why using GNAT.Sockets, which as an abstract
> interface can be obtained GPL or GMGPL, ditto its implementations,
> should make a difference to the licence under which _your_ source is
> released?

<...>

> I also don't see why you've jumped through hoops to use AdaSockets
> instead of GNAT.Sockets "so as to get GMGPL instead of GPL (for GNAT
> GPL 2005 and beyond)". If I use GNAT GPL I _must_ release under GPL
> (if at all), regardless of any GMGPL freedoms on other library
> components.

OK, here we're approaching the point why I have been asking the about
the reason for GPL licensing in the GNAT-6000 edition of
DTRAQ. Because I'm a bit confused about the supposed interaction
betwenn GPL and GMPL-Parts:

If I'm writing a library L and linking it with another L2 which is
under GPL (like the GNAT 2006 runtime) to obtain a product P, can I
not put my Library L under GMPL?

The customer would get L and supposedly L2 [*] as source (which is the
intention of the GPL) with P and would be under the obligation to
package L, L2 also with P2 if he happens to create modified
executables and distribute them (which is also the intention of the
GPL). But he would have further the option to pick the source of L from
the source package and link it into som application A of his own w/o
the application becoming GPL automatically.

One other questions BTW (I don't know wether I'm totally serious)

 - Since the GNAT 2006 runtime is GPL, don't I have to distribute the
   GNAT runtime with the executable and my own source?

Regards -- Markus

Re: ANNOUNCE: DTraq Released

[Georg Bauhaus]

On Mon, 2006-06-19 at 22:12 +0200, M E Leypold wrote:

> One other questions BTW (I don't know wether I'm totally serious)
> 
>  - Since the GNAT 2006 runtime is GPL, don't I have to distribute the
>    GNAT runtime with the executable and my own source?

See GPL, §3.

Re: ANNOUNCE: DTraq Released

[M E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Mon, 2006-06-19 at 22:12 +0200, M E Leypold wrote:
> 
> > One other questions BTW (I don't know wether I'm totally serious)
> > 
> >  - Since the GNAT 2006 runtime is GPL, don't I have to distribute the
> >    GNAT runtime with the executable and my own source?
> 
> See GPL, �3.

Probably you're referring to the following sentence:

   However, as a special exception, the source code distributed need
   not include anything that is normally distributed (in either source
   or binary form) with the major components (compiler, kernel, and so
   on) of the operating system on which the executable runs, unless
   that component itself accompanies the executable.

And exactly that sentence I had in mind when I asked my question
(tongue in cheek). Isn't it rather ironical that I have to distribute
my source with the produced executable and that exactly that piece of
code from which the "infection" started which brought my code under
GPL is exactly what the receiver/user of my executable won't get? 

How ... well, ironic.

Regards -- Markus

Re: ANNOUNCE: DTraq Released

[Marc A. Criley]

Simon Wright wrote:

> What I don't see is why using GNAT.Sockets, which as an abstract
> interface can be obtained GPL or GMGPL, ditto its implementations,
> should make a difference to the licence under which _your_ source is
> released?

This, like your other points, is true...when considered strictly on its own 
merits.  But in context it's not so cut and dried.

There are two major personal factors that affect my OSS development 
efforts.  First is that I want to stay as close to a vendor-supported 
configuration as I can, therefore my progression from 3.15p to GNAT GPL 
2005, and soon to 2006.  (The advocate-maintained distributions are 
perfectly fine and their maintainers are to be commended, but AdaCore's 
GNAT is the de facto standard and so I want to stay close to that.)

Second is that I do want to make binary distributions, I usually prefer 
those, so I assume others do as well.  (I know this makes me less than an 
OSS purist, but I prefer that I have _access_ to the source, rather than it 
being _required_.  For most things I'm a user, not a builder.  :-)

So, since I'm now on the GNAT GPL 200x track, that means, in this specific 
case, that I'm using its version of GNAT.Sockets, which is licensed as GPL.

The DTraq logging server and data viewer both use that specific package, so 
simply for that reason alone they and their executables are GPL.

The DTraq.Tap client code needs a socket package, so while I could use the 
GNAT.Sockets abstract interface and then you the application builder can 
link with a GMGPL version of that package, you won't.  Why?  Because DTraq 
uses ASIS, and ASIS-for-GNAT is compiler and version specific, so in order 
for the DTraq source analyzer program to work, your application must be 
compilable with the same GNAT version that the source analyzer uses, i.e., 
GNAT GPL 2005.  I know that simply compiling the code (and building the 
trees used by ASIS) doesn't require that your app by GPLed, but I doubt 
many are going to compile and test their code with one version of a 
compiler, but then deliver it having used another.  (If for no other reason 
than you'd not be testing what you're delivering.)

You can certainly build DTraq from source using another compiler and ASIS 
version, and the result will conform to the relevant licenses, and I'd be 
happy to do that if someone were to make it worth my while, or would 
certainly make available a contributed distribution alongside the 
distributions I maintain.

All this is why in the original posting I stated "for what it's worth" when 
mentioning transitioning from GNAT.Sockets to AdaSockets for DTraq 1.100. 
Since your app is in all likelihood going to be built with the GPLed 
runtime if you're using DTraq 1.100, your app is going to have to be GPL 
anyway because of the RTL.  _But_ it's not going to be DTraq that's 
directly causing that, so I can use the same instrumentation code for 
different compilers and versions (concerning myself _only_ with AdaSockets' 
one license, not the different GNAT.Sockets ones).  In other words, the 
instrumentation code ought to be software _and_licensing_ portable across 
different compilers and versions (though I've not verified the software 
portability).  It's simply then that the rest of the DTraq application be 
able to accommodate whatever compiler is being used on the application.

> Anyone is free to use eg the Booch Components with any Ada compiler
> they like; certainly Aonix, probably Apex, either flavour of
> GNAT. Instantiating a GMGPL source using a GPL runtime is going to
> result in a binary that has to be issued under the GPL, sure.

Because of ASIS, though, DTraq is not like the Booch Components. ASIS is 
tied to a specific compiler-version distribution, and therefore its license.

> I would find it quite hard to justify using AdaSockets given that
> there is a perfectly workable and supported functionality in GNAT
> already.

GNAT.Sockets actually has some extra functionality (regarding 'socket 
select') that I took advantage of in the DTraq core components.

> I also don't see why you've jumped through hoops to use AdaSockets
> instead of GNAT.Sockets "so as to get GMGPL instead of GPL (for GNAT
> GPL 2005 and beyond)". If I use GNAT GPL I _must_ release under GPL
> (if at all), regardless of any GMGPL freedoms on other library
> components.

Actually I didn't have to jump through hoops, it was an easy changeover. 
The initial releases of DTraq used AdaSockets, and I had previously 
migrated to GNAT.Sockets primarily to gain access to the socket select 
capabilities.

And yes, "if [you] use GNAT GPL [you] _must_ release under GPL", but that's 
because you are using _GNAT_GPL_, _not_ DTraq.Tap.

-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: ANNOUNCE: DTraq Released

[Simon Wright]

Thanks for a valuable discussion.

The only reason I got involved was that I felt that people were
getting the wrong end of the stick about GPL licensing and the impact
on their own code, which is as we all know an emotive issue round
here.

A question -- is DTraq endian-independent? that is, could the client
be a PowerPC (in our case, running VxWorks) and the logging server be
an Intel machine? We achieve this using the stream attributes, with a
special little-endian System.Stream_Attributes body that converts
to/from the native PPC form. This has the advantage that the target
runtime is the vendor's, unmodified.

Re: ANNOUNCE: DTraq Released

[Marc A. Criley]

Simon Wright wrote:
> Thanks for a valuable discussion.
> 
> The only reason I got involved was that I felt that people were
> getting the wrong end of the stick about GPL licensing and the impact
> on their own code, which is as we all know an emotive issue round
> here.

Agreed, on both counts :-)  Licensing can get tricky, particularly when 
part of the product has to get compiled/linked into the client.

> A question -- is DTraq endian-independent? that is, could the client
> be a PowerPC (in our case, running VxWorks) and the logging server be
> an Intel machine? We achieve this using the stream attributes, with a
> special little-endian System.Stream_Attributes body that converts
> to/from the native PPC form. This has the advantage that the target
> runtime is the vendor's, unmodified.

At the moment, no.  I have the approach worked out for adding that, but its 
addition has to compete with numerous other improvements on the list :-)

-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: ANNOUNCE: DTraq Released

[M E Leypold]

Simon Wright <simon@pushface.org> writes:

> Thanks for a valuable discussion.
> 
> The only reason I got involved was that I felt that people were
> getting the wrong end of the stick about GPL licensing and the impact
> on their own code, which is as we all know an emotive issue round
> here.

It's less emotion on my part or obsessiveness for my code. It's just
simple "business considerations". Let's take GtkAda which now seems to
be GPL only. With the new situation I have 2 options:

  - Develop GPL code only. Some customers don't like that, since they
    don't want to grant me the right to distribute the control
    programs I'm writing for them. Probably that could be fixed by
    having a contractual agreement (perhaps, IANAL), but usually their
    lawyers are unsettled enough by the vicinity to GPL code that they
    are not sure wether I'm actually bound to that agreement: So to be
    sure they prefer to let their process control made in C# or Java
    (That case is real so don't coplain to me anyone).

  - I start big and pay the ACT support with (one hears $ 15000.- /
    year). Of course that would rise the fix cost for Ada programming
    so much that I would be forced to programm Ada in almost 100% of
    the projects. There is no market for this. 

    The market could be bootstrapped by starting small projects with
    Ada and using them as reference and the knowhow acquired there to
    get the next customer(s) to try Ada instead of Java or
    .Net. Unfortunately that bootstrapping needs time.

With the old GMPL license for GtkAda one could try to bootstrap a
clientele of Ada customers slowly. With GPL-or-buy-ACT-support and an
entry barrier of $15000.- its a all-or-nothing proposition. Certainly
nothing to stimulate a community which would use Ada instead of C.

A bit emotion admittedly comes in at the point where license change
from GMPL to GPL (this is a restriction as I have tried to explain),
after on has inversted time and effort into Ada infrastructure (which
is now over day and year only good for option 1: GPL
softwaredevelopment). 

I've been following the discussion on c.l.a. on the issue of GNAT GPL
in c.l.a end of last year and have to say that I found the GPL
protagonists ("Do you expect AdaCore to work for nothing") also not
quite so cool and rational then. Obviously there is emotion on both
sides here. One of the reasons I didn't participate then and one of
the reasons I already sort of regret that I started this discussion.

Regards -- Markus

Re: ANNOUNCE: DTraq Released

[Martin Dowie]

M E Leypold wrote:
> It's less emotion on my part or obsessiveness for my code. It's just
[snip]
> the reasons I already sort of regret that I started this discussion.

GNAT isn't the only Ada compiler out there - there are low cost <$1000 
Ada compiler available from Aonix and RR Software. Both have GUI 
builders (at least for Windows).

Cheers
-- Martin

Re: ANNOUNCE: DTraq Released

[M E Leypold]

Martin Dowie <martin.dowie@btopenworld.com> writes:

> M E Leypold wrote:
> > It's less emotion on my part or obsessiveness for my code. It's just
> [snip]
> > the reasons I already sort of regret that I started this discussion.

> GNAT isn't the only Ada compiler out there - there are low cost <$1000
> Ada compiler available from Aonix and RR Software. Both have GUI
> builders 

> (at least for Windows).

Exactly: "at least for windows". As I said: I regret I started the
discussion. I actually wanted to understand why someone thinks he must
license under GPL when I thought wether he could use GMGPL.

But the discussion is already being distorted into "but you can use
other compilers than GNAT". Sorry, Martin, but "just any Ada compiler"
is hardly a criterion to select a programming system. And to "GNAT
isn't the only Ada compiler" out there I'm tempted to respond that
GNAT isn't even the only compiler out there. :-).

Again: I already regret that I started this. I also don't know what
"GNAT" has to do with licensing terms of libraries (DTRAQ, or what I
used as an example in my recent post, GtkAda).


Regards -- Markus

Re: ANNOUNCE: DTraq Released

[Martin Dowie]

M E Leypold wrote:
> Martin Dowie <martin.dowie@btopenworld.com> writes:
> 
>> M E Leypold wrote:
>>> It's less emotion on my part or obsessiveness for my code. It's just
>> [snip]
>>> the reasons I already sort of regret that I started this discussion.
> 
>> GNAT isn't the only Ada compiler out there - there are low cost <$1000
>> Ada compiler available from Aonix and RR Software. Both have GUI
>> builders 
> 
>> (at least for Windows).
> 
> Exactly: "at least for windows". As I said: I regret I started the
> discussion. I actually wanted to understand why someone thinks he must
> license under GPL when I thought wether he could use GMGPL.
> 
> But the discussion is already being distorted into "but you can use
> other compilers than GNAT". Sorry, Martin, but "just any Ada compiler"
> is hardly a criterion to select a programming system. And to "GNAT
> isn't the only Ada compiler" out there I'm tempted to respond that
> GNAT isn't even the only compiler out there. :-).

No, but it seems to be the one you're interested in otherwise why 
mention AdaCore and their ~$15k license? :-)

Cheers
-- Martin

Re: ANNOUNCE: DTraq Released

[Jeffrey R. Carter]

M E Leypold wrote:
> 
> It's less emotion on my part or obsessiveness for my code. It's just
> simple "business considerations". Let's take GtkAda which now seems to
> be GPL only. With the new situation I have 2 options:

The versions of GtkAda I've got (1.13, 2.2.0, and 2.4.0 for Windows) all 
include only the GMGPL licensing language, so I'm fairly confident that 
that is the license for them.

Are your clients going to distribute binaries? If not, it doesn't seem 
to be anything that you even need to mention. You create the SW, give 
them binaries and the source (which they probably will never look at), 
and everyone's happy.

>   - I start big and pay the ACT support with (one hears $ 15000.- /
>     year). Of course that would rise the fix cost for Ada programming
>     so much that I would be forced to programm Ada in almost 100% of
>     the projects. There is no market for this. 

Does anyone (other than you) really care what language you use? I think 
the figure you're quoting is for GNAT Pro; I don't know what support for 
GtkAda only would cost, or even if it's available.

-- 
Jeff Carter
"To Err is human, to really screw up, you need C++!"
St�phane Richard
63