| |||||||||||||
The new GCC runtime library exemptionThe new GCC runtime library exemptionPosted Jan 27, 2009 22:05 UTC (Tue) by gmaxwell (subscriber, #30048)In reply to: The new GCC runtime library exemption by bkoz Parent article: The new GCC runtime library exemption
But there are modified versions of LLVM which are not.
For example, Adobe Alchemy is a hacked up binary-only copy of LLVM which targets the Flash virtual machine. It also includes its own binary-only intermediate format optimizer pass. Alchemy lets you take C code and run it in Flash. (my own interest in it is using it to create flash decoders for unencumbered formats— So that a website's decision to use Ogg/Theora doesn't limit them to just Firefox, Opera, Safari, and Java capable clients) When I first tried Alchemy I thought they had used GCC directly, since it uses GCC as a front end (using alchemy is exactly like using GCC to cross compile). I was hopeful that it meant Adobe was releasing their Flash VM targeting code, since this would be VERY HELPFUL for projects like haXe and Gnash. Unfortunately the backend is all proprietary, and the Alchemy license professes to forbid all forms of reverse engineering (too bad, because it outputs many undocumented FlashVM opcodes).
(Log in to post comments)
The new GCC runtime library exemption Posted Jan 27, 2009 22:33 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] Right, and it's precisely the intent of the new language to encourage plugins that are free software and discourage those that aren't. Sufficiently determined developers can find ways around the new language, but it helps the FSF feel better about allowing GCC to officially have a plugin architecture.
The new GCC runtime library exemption Posted Jan 28, 2009 1:23 UTC (Wed) by Ze (guest, #54182) [Link]
>>But there are modified versions of LLVM which are not.
The LLVM cfront front end will take care of that (and I'll be really happy when c++ support matures for it.
>>I was hopeful that it meant Adobe was releasing their Flash VM targeting code, since this would be VERY HELPFUL for projects like haXe and Gnash. Unfortunately the backend is all proprietary, and the Alchemy license professes to forbid all forms of reverse engineering (too bad, because it outputs many undocumented FlashVM opcodes).
Person A is complying with the license , whilst person B doesn't have too :)
The new GCC runtime library exemption Posted Jan 28, 2009 3:42 UTC (Wed) by jamesh (guest, #1159) [Link]
If the compiler is generating flash bytecode, presumably it is not directly linking the result to the GCC runtime library. So this sounds like another case that this license change will not affect – good for Adobe, not so good for the FSF.
That is assuming that the lawyers don't decide that running said flash code on a flash player linked to the GCC runtime library is covered ...
The new GCC runtime library exemption Posted Jan 28, 2009 4:27 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
the lawyers can decide that, but they need to get the judges to agree.
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.
It's the other way around Posted Jan 28, 2009 10:10 UTC (Wed) by khim (subscriber, #9252) [Link] 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).
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.)
|
|||||||||||||