| |||||||||||||
It's the other way aroundIt's the other way aroundPosted Jan 28, 2009 10:10 UTC (Wed) by khim (subscriber, #9252)In reply to: The new GCC runtime library exemption by dlang Parent article: The new GCC runtime library exemption
frankly, getting anyone to say that taking valid, standard to International standards C++ code and having a compiler convert it to an executable makes that source derived from the binary (and affected in _any_ way by the compilers license) should be a long shot. Source is unaffected, the binary is. You can continue to sell source under any license after said compilation - not so fo the binary. There were a lot of precedents where runtime package (needed to run the compiled code) required separate license (often on per-seat basis).
(Log in to post comments)
It's the other way around Posted Jan 28, 2009 22:14 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
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.
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.)
|
|||||||||||||