GNUPro Development, v850

I would also include schemes like node-locking or verification by connecting to a license server etc as unacceptable. They are all too fragile, designed to break if the slightest thing is "suspicious".

I expect you are right. That is a commercial decision some vendors made, to protect their software at the expense of ease-of-use of customers. They evidently think that they gain more in sales to would-be pirates, than they lose to frustrated ex-customers like myself.

*I* have made a commercial decision to use gcc and friends for software development, where possible, which has worked out well for me.

I do still use (and pay for) some commercial software provided it is unprotected. My PCB cad system is an example - I bought it and still pay yearly maintenance. It can be copied freely to another machine, and runs under linux or under windows virtualisation without worrying about node-locking, dongles, software keys etc. I can be confident that I can maintain all my old designs indefinitely as I upgrade machines and OS, even if the vendor goes out of business.

--

John Devereux

Thanks very much for all your responses and the very interesting discussion.

We are planning to release an evaluation board. We don't want our partners to buy compilers when there are free alternatives. We will contact the Red Hat Global Engineering Services group to solve our problems.

Best regards, Norbert

"DJ Delorie" schrieb im Newsbeitrag news: snipped-for-privacy@delorie.com...

The problem is that it's the honest customers who suffer. On a recent project, I was unable to get the IAR dongle to work on the Win2K machine I normally did devlopment on. I would have preferred a Linux hosted compiler, but of course that's not at option with IAR.

As a last resort, I put the dongle+compiler on a Windows print server over in the corner of the office area and then installed Cygwin so could "ssh" into that machine to do compiles.

In the end it worked, but it was a PITA to set up, and a PITA to use.

And me.

I've been using gcc for commercial projects for about 10 years now on 5 or 6 different architectures, and I'm far happier with it than I ever was with any of the 4-5 different commercial compilers I've used.

Same here. Kudos to Cadsoft.

--
Grant

... snip ...

No, I mentioned standard, meaning ISO, on purpose. That means gcc can be ported to any system with a C compiler that meets standards.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

... snip ...

FYI it is impossible to steal GNU software. It is possible to misuse it. All you have to do to ensure legality is publish your adaptation, in source form, so anyone can follow (or ignore) it.

Read the GPL licence.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

We had to update a 15 year old product the other day. The compiler is an old DOS based one which requires a dongle. After quite a few hours getting an old DOS machine going, and installing the compiler, we found out that the dongle had an embedded battery, whcih has gone flat. Hence the dongle is useless. The company (Franklin) has disappeared a long time ago. Only a few lines of code needs to change, but we are unable to do so. Contractually we only had to supply support for 10 years, so we could inform our client that we CAN do it, but it will be a LOT more expensive than our original estimate.

These sort of things has convinced us that for any sort of product where we have to supply support for > 10 years, we cannot afford to use any tools which require a dongle or license server to function.

Regards Anton Erasmus

In message , Anton Erasmus writes

Strange.. I don't know of any dongles with batteries in them. What make was it? What was the compiler? (Email me off list if you like.)

AFAIK they just re-badged compilers. They did not do their own. Definitely email me off list.

Most of the companies who went bust still have a distributor who has the rights to the tools and can supply support or old binaries or dongles etc.

Difficult.

I understand. However the compilers I have which are dongled all the companies can supply old versions and normally undongle them.

I have quite a few customers who need a 5 (or more) year old version of a compiler. They buy a new one (with dongle) and get a copy of the old version that does not need a dongle.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Which would probably be true if the code were written for another compiler (including GCC) as well.

Yes, but the point is that gcc does not need a dongle - so I don't need to worry about not being able to use gcc in x years time. It will always be possible to run it.

--

John Devereux

Quite a few commercial compilers don't have a dongle

However you have the same problem. a compiled GCC may not run on new hardware. Recompiling the source on a different machine gives you a different compiler.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

A closed-source commercial compiler targeted at a specific OS (usually, but not always, windows) with its dongle code disabled is *far* more likely to have trouble running on different hardware and a different OS than software that is at the outset designed for portability. You are also likely to have an easier time running portable and freely copyable software with things like virtual machines or emulators (a common way to get compatibility with old OS's).

If that fails, then you can always recompile gcc. I agree that you have a different binary, and therefore any validations or certificates are no longer technically valid. However, in *practice* you can have a very high level of confidence that the newly built compiler *will* function in exactly the same way as the old one. You can test it on old source code and compare the generated binaries. Which is better - a validated tool that you can't use, or a non-validated tool which you *can* use and which you are confident works identically to the old tool?

Actually, "stealing" software is just as rare for commercial software as for FOSS. "Stealing" requires that someone unlawfully takes something and denies the rightful owner use of it - it must be taken away from the owner. If you shoplift a software CD, you are stealing - if you download a copy from somewhere or hack a program's security locks, you are not stealing. If someone steals your portable computer, they are also stealing the software on it (totally regardless of the license) from you.

Misuse of software, source code or binaries, can be copyright violations, breach of contract or licence, or a breach of a number of other laws. It might also be a crime (though normally it is not - generally there must be economic gain involved for it to be a crime, or you must live in a country with Mickey Mouse laws). It's certainly a problem for both FOSS and CCSS - but I'm far from convinced that dongles or other locks are an effective way to prevent it.

No recompiling needed. As I already explained, in my experience gcc always does run on new hardware (assuming a x86 platform), since it only requires minimal, standardized OS support. Unlike a dongle or node locked etc. compiler.

And even if for some strange reason it doesn't, it could easily do so using virtualization/emulation. For example I have (another) old DOS IAR compiler which happens to *not* require a dongle. I run it under dosbox under Linux, no problem (about 50 times faster of course). If that one had happened to need a dongle, I would still be booting off floppies into my 512k of RAM.

Even a recompiled gcc *should* produce the same binary image AFAIK, although I have not needed to try this. It is easy enough to check.

--

John Devereux

We both effectively already said it, but I think it worth pointing out that of course commercial compilers cannot be recompiled *at all* by end users. The ability to do this is an extra bonus, but even leaving this aside open source compilers are far more portable, in practice, at just the binary level.

--

John Devereux

Really, the last one I bought was dongled with FlexLm. Who are the good guys?

Robert

** Posted from **

The dongle is none of the "Standard" dongles that came with OrCAD, IAR etc. It looks quite home made and it would probably take 5 minutes for an experience cracker to crack. I'll have to check exactly which version it is. We switched over from this Franklin C51 compiler to IAR

51 on V4 for DOS.

We have found that in many cases the dongle-free tools are only available to Europe and North America. We are in Africa, and since the total market share in Africa for these tools are probably less than in a single city in Europe, we are not high on anybodies priority list. In South Africa we also had to contend with sanctions, so these old tools were bought via agents. No support whatsoever. Now we can buy via official agents, but "support" is mostly a rumour.

I am currently running WinAVR (gcc-avr on Windows) and a version built from source on a Linux machine. Same source versions, with the same patches applied. Some days I use the Windows version and some days the Linux version. I compare the generated binaries once in a while. So far they have been 100% the same.

Regards Anton Erasmus

[...]

Interesting - as I said I never actually tried this myself. I wonder if the gcc developers use this as one of the checks before release? As far as I can see the only reason for a mismatch would be a bug... although perhaps there is room for ambiguity somewhere. Maybe something like interpretation of floating point constants could be host-dependent?

--

John Devereux

Bugs are the only reason why there might be a difference in the generated binary when you have the same gcc source, the same patches applied, the same configuration options (although most configuration options that affect code generation can be overridden with command-line options), the same libraries, and the same binutils tools (binutils versions are unlikely to be a significant influence).

A mismatch in floating point calculations used to be possible (such as rounding differences that are still within IEEE standards), although they were unlikely to occur for two compilers running on the same processor (regardless of the OS). In fact, this is a situation where the same binary may give different results on different computers - there could be minor differences in the floating point results on different x86 processors (remember the Pentium FDIV bug...).

Since gcc 4.3, gcc uses the MPFR library for all floating point calculations. This library is independent of the host's floating point implementation, and should follow exactly the implementation on the target.