Re: [Nasm-devel] My involvement and the future of NASM

[H. P. A. <hp...@zy...>]

Victor van den Elzen wrote:
> 
>> NASM being licensed under LGPL is, quite frankly, awkward as hell.  It
>> means we can't pull in code from GPL'd projects, like using libbfd for
>> backends, but it *also* means that it is not available for CPU vendors
>> who are concerned about unreleased features, which have to be under NDA.
>>  The LGPL is designed for libraries, but NASM isn't really structured
>> as a library.
> It might interest you that LGPL can be "upgraded" to GPL, so there is
> no *legal* reason to not do that. It's in section 3:
> 
> "You may opt to apply the terms of the ordinary GNU General Public
> License instead of this License to a given copy of the Library.  To do
> this, you must alter all the notices that refer to this License, so
> that they refer to the ordinary GNU General Public License, version 2,
> instead of to this License.  (If a newer version than version 2 of the
> ordinary GNU General Public License has appeared, then you can specify
> that version instead if you wish.)  Do not make any other change in
> these notices.
> 
> Once this change is made in a given copy, it is irreversible for
> that copy, so the ordinary GNU General Public License applies to all
> subsequent copies and derivative works made from that copy.
> 
> This option is useful when you wish to copy part of the code of
> the Library into a program that is not a library."

Yes, the question is if this is the direction we want to move in.

> P.S. Good job fixing stuff for 2.03.01, almost all regression tests
> pass now. Only using incbin as a label broke because now it's a macro
> instead of an instruction. Not a problem imho.

Agreed; we could consider the general case of namespace conflicts with 
mmacros, but it doesn't seem like a burning issue.

	-hpa