Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

FASM's license (Announce)

posted by Rugxulo Homepage, Usono, 13.09.2010, 01:49

> > EDIT: I think GCC will allegedly accept 20 lines or less without
> copyright
> > assignment but nothing greater.
>
> Really? That would be ridiculous, especially from the GNU zealots that talk
> about freedom all the time. If I want to write a source code file without
> any copyright notices, free tools should allow me to do that! (It's also a
> question of privacy - the tools should not scan my data for such things at
> all.)

Sorry, didn't mean to confuse you. No, I meant the GCC devs (on behalf of FSF?) won't accept any contributions to the compiler itself without copyright attribution, but I think they don't need it for trivial code that is 20 lines or less.

> > But I'm no lawyer though I'll admit I don't care what they think, they
> can
> > invent any crazy idea, and it's insane to pretend I'll just comply
> blindly
> > to whatever some crackpot can come up with.
>
> The BSD and GPL licenses make perfect sense to me.

I meant lawyers and their crazy (constantly changing and new) laws. There's no way to please them across the board. It's just insane to pretend I can even understand their ideas, much less would be willing to comply (at a loss) at every random decision they make. I'm not trying to be a bastard, but they can't just say whatever they want and get away with it.

> > The world doesn't truly "need" FASM,
>
> Quoting that out of context might not AMUSE some :-P

Well, let's be honest, how many assemblers does one person need? I can name at least 30 for x86, and that's surely more than I need! I could maybe live exclusively off of NASM, YASM, FASM, JWASM, or OCTASM if I had to. Some people seem to only use GAS (blech). Well, okay, it truly depends on OS and compiler support that my projects use, etc, but you get the idea: there are (too) many! Doesn't mean somebody can't write yet another with some innovative ideas (like OCTASM or SolarASM or even FASM did).

> > but it's a truly awesome tool, a good compliment to NASM, IMHO.
>
> I don't know. True, there's a few things that FASM can do but NASM can not.
> NASM, in turn, is freer and more portable.

NASM is cool, but it has few true advantages over FASM, esp. for my needs. Then again, I'm just a hobbyist, just a lame hacker. I do like both a lot, though, truly.

> > I don't think Tomasz intends to restrict anyone from doing anything with
> > it, including proprietary changes, which would indeed not work if it was
> > GPL.
>
> Is proprietary adaptation really allowed by that license? It says not to
> redistribute FASM code under any other license. Although it has the
> loophole that you can distribute only binaries (i.e. make the code base
> proprietary), you still would have to use the FASM license for your source.
> That means you wouldn't be allowed to combine the source with any other
> source code that has a license conflicting with FASM's. (For example,
> suppose there is a program FOO which has a license very similar to FASM's.
> Now you wouldn't be allowed to combine FOO's and FASM's source code,
> because both require all source code to use their license.) This
> is a practical problem, because no company would risk to violate the
> license like that even though arguably it would be hard to prove from the
> outside (when they only distribute binaries).
>
> True, the GPL doesn't allow proprietary adaptation, but I don't think
> FASM's license does either. Whether that's intentional I don't know.

To be honest, I'm not sure, but he said something recently that sounded like he didn't care what somebody did with their changes (e.g. Wink). Plus there's the (recently updated) FASM DLL, which makes it even easier to use in proprietary apps. (I think PureBASIC just uses the FASM.EXE directly, though.)

> > Honestly, I think he has looked at NASM before, but obviously he's
> > rewritten everything to suit his own ways of doing things (different
> > macros, always did opcode size reduction similar to YASM, different
> > algorithms).
>
> The point was that he could now (and even before) implement OMF support by
> using NASM's low-level implementation as reference. Assembler syntax
> doesn't come into this.

He's already said it's pretty complex to do correctly, and it's clearly low priority as he was quite busy with real life (PhD?) for a long time. Also, like I said, there are other assemblers who already do it, hence probably why GAS and YASM also still don't support it. Face it, old closed source 16-bit OBJ libs are rare these days, esp. considering how far Linux and *BSD have come pretty much reimplementing everything from scratch. (But honestly, he is going to implement Mach-O support soon, so I guess adding yet another format isn't too far from his mind.)

 

Complete thread:

Back to the forum
Board view  Mix view
22649 Postings in 2111 Threads, 402 registered users, 903 users online (1 registered, 902 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum