| |||||||||||||
It's the other way aroundIt's the other way aroundPosted Jan 28, 2009 22:14 UTC (Wed) by dlang (✭ supporter ✭, #313)In reply to: It's the other way around by khim Parent article: The new GCC runtime library exemption
it is common for the source to include third-party libraries that have per-seat licenses.
but for the compiler to mandate a library that has such a license?
or for a compiler to require per-seat licensing of the binaries that it produces???
even in the cases of proprietary compilers, you could make your source code link against a free library and not worry that using a particular compiler 'tainted' the resulting binary so that you couldn't use it without the approval of the compiler company.
(Log in to post comments)
Is it REALLY so strange? Posted Jan 28, 2009 23:47 UTC (Wed) by khim (subscriber, #9252) [Link] If you'll go back decade or so you'll find many, many, MANY packages which required separate developer license and license for redistribution. You'll find countless offers like In addition to dBASE IV version 1.1, Ashton-Tate offers a version 1.1 developer's edition with a royalty-free unlimited RunTime distribution license, the template language source code, two extra LAN keys, and additional applications distribution tools and utilities (emphasis mine). dBASE IV can produce binaries - but you have no right to redistribute them while dBASE IV developer's edition (for extra cost, of course) gives you such a license. Now - I'm not saying such requirements are great, but they certainly are not uncommon. If you want to say "oh, it's Ok for xBase, but strange for C/C++" then I'll agree: it is stange. Most C/C++ compilers don't include such limitations. But... what's the difference between xBase and C/C++? I mean: from legal viewpoint? After all world is now accustomed to copyleft concept - and it was strange and unusual 20 years ago...
Is it REALLY so strange? Posted Jan 29, 2009 0:07 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
for DBASE by understanding was that the 'binary' just embedded the entire DBASE interpreter in the resulting binary.
that's not how a compiler is supposed to work.
Is it REALLY so strange? Posted Jan 29, 2009 0:57 UTC (Thu) by nix (subscriber, #2304) [Link]
Hah. It was more extreme even than that, IIRC. The Clipper 'compiler' at
least worked by compiling the program to bytecode and then simply appending the bytecode to a 180Kb-or-so interpreter-and-database-engine. (Despite that, the linker was astonishingly slow. I have no clue what it was doing: given that it was linking the same binary every time, I'm not even sure why they *needed* a linker.)
|
|||||||||||||