Prev: aeBIOS Test Request
Next: CMOVcc vs. Jcc
From: Evenbit on 10 Oct 2007 15:22 On Oct 8, 8:26 am, Herbert Kleebauer <k...(a)unibwm.de> wrote: > > Maybe you should ask in a linux group. I did this a year ago, but without > much success: > > http://groups.google.com/group/comp.os.linux.development.apps/browse_... An interesting read. I learned about XFrame and TinyPTC from that thread. Has anyone played with these from ASM?? Nathan.
From: randyhyde on 10 Oct 2007 19:29 On Oct 8, 10:25 am, Betov <be...(a)free.fr> wrote: > "rh...(a)cs.ucr.edu" <rh...(a)cs.ucr.edu> écrivaitnews:1191862598.232372.317580(a)50g2000hsm.googlegroups.com: > > > The bottom line is that they *didn't* write these applications you > > talk about. > > Right, clown. They did *not* wrote Applications, Then why do you keep talking about the "applications" they wrote? hLater, Randy Hyde
From: randyhyde on 10 Oct 2007 20:03 On Oct 8, 4:46 pm, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote: > > > "Compatible with the GPL" basically means that someone can take the > > code, modify it, and release it under a GPL. Please have your lawyer > > brother explain why someone can't take a PD piece of software, modify > > it, and release the result under public domain. > > Didn't I already explain that somewhere: > > "The US Supreme court has stated that a derivative of a copyrighted or > previously copyrighted work [i.e., PD] is only copyrightable if it is > sufficiently different from the original to be considered 'unique' in it's > own right." > So I guess the question is how one defines "unique", eh? > > Indeed, there is little reason they can't take the PD software, > > without modification, and release it under the GPL. > > As I pointed out, it depends on how "little reason" is defined 1) someone > suing Again, someone can sue for *any reason whatsoever at all*. That's how, apparently, people like your brother stay in business :-) > 2) legalities. > > > PD implies permission to use the material however you want > > No. Yes. > You can't copyright PD code. It was copyrighted already. And a declaration of PD *assigns* that copyright, effectively. To whom the copyright is assigned, they can make any changes and recopyright the whole thing. Happens all the time. Ever seen notices on Microsoft software like "copyright 1997, 1998, 1999, ..."? If I hold the copyright to something, whether it's because I created it in the first place, or someone assigned that copyright to me, I have the write to make modifications and release that new artistic item under a new copyright. > It can be > modified. If the resulting work is sufficiently different to be unique, > then it may copyrighted. Of course. But what is "unique"? > However, if it isn't sufficiently different, then > the Supreme court said all derivative works fall under the rights of the > original copyright, which has been released as PD. And, as such, have been assigned (non-exclusively) to whomever wants to run with it. > So, depending on the > result, the modified code may be copyrightable or be PD. I guess it really depends on what you do with the "copyright" you obtain, eh? For example, if you make a "one byte change" to the program and no one else has ever made that same one byte change, you clearly have a "unique" work. OTOH, if you make a trivial one-byte change (say, to fix a defect in the code) and someone else makes that same one-byte change (independently), I agree that you would have a hard time defending your "copyright" in court. But that's not what we're talking about here. We're talking about that second person taking a PD program, making some changes to the code, and not having to worry about being sued for what they've done (assuming, of course, they didn't intentionally copy what someone else has done). > I've seen more > than a few GPL'd programs which are predominantly PD, but the author's > expectation that his changes are GPL'd could be wrong. His changes may be > PD instead. Really? Please show me *anyone* who has been sued and lost by taking PD code, changing it, and releasing it under a different license. Particularly, as we *are* talking about *my* code here, when the author has made it *very clear* that anyone can do whatever they wish with the code; including making it a part of some GPL package. > > > And boy would they have a hard time suing them if they released all > > rights via a declaration of PD and then tried to retract them. > > PD doesn't mean no rights. Of course not. What it means is that I've assigned non-exclusive rights to whomever wants to use the PD code. > By law, PD has one right: it can't be > copyrighted again. Well, it would be ridiculous if someone tried it -- as they would never be able to prove that a copyright violator didn't just grab the original code rather than the "copyrighted" version. > This right can't be retracted and shouldn't be violated > IMO. If you don't want that "right" violated, then release your code under the GPL. That's the purpose of the GPL -- to guarantee that the code and any modifications to it remain under the GPL. The purpose of releasing something into the PD is to provide everyone free access to that thing without any restrictions (other than, perhaps, attempting to remove it from the PD). But if someone makes *a single byte change* to a PD program, who cares if they remove *that* from the PD? The original code is still there. The fact that a trivially different copyrighted version has now appeared doesn't *remove* the original code from the PD. And if the change *is* so trivial, then just about *anyone* with appropriate skill can replicate that new code. If someone is not so skilled, and they *really* want the new code, then they should be willing to negotiate for a copy of the new code. And the person who *made* that change should have every right to release that code on their terms -- after all, they're the ones that did the value add. > > > Bottom line is that if someone uses PD software in good faith (that > > is, they reuse the software because they were given explicit > > permission to do so via a declaration of PD, as exists in my code), > > they're not going to lose any lawsuits over the matter. > > If they applied a copyright to the PD code, and the courts decide it's form > doesn't constitute a unique work, they could be sued to remove the > copyright. They can be sued for anything. How do you think lawyers stay in business? OTOH, if a company takes a PD program, makes some trivial changes to it (i.e., "not sufficiently unique" in your terms) and then *sues* someone who has independently made such changes, they get what they deserve. > Such a tactic could "destroy" GPL code by forcing it to become PD. Incredibly hypothetical. It requires: 1) The GPL code to be trivially different from the PD version. 2) Someone who really cares enough to sue over it. And what would be the end-result of this lawsuit? Why, the PD software is still in the PD. What has someone achieved with such a lawsuit? They haven't hurt the GPL one iota; all they've done is waste a lot of money to make some software PD that was trivial to create from PD. Who's going to waste the money on such a lawsuit? Your brother? > This would be advantageous to a commercial enterprise which prefers to not > have to comply with open source licensing requirements such as only linking > to open source code. They could then link. Uh, they could link against the original PD code. What are you talking about? Note that "copyright" is not the same thing as "patent". The fact that someone can copyright a one-byte change (and let's say it holds up in court) is virtually useless for most cases. After all, given the resources available on most machines today, it's fairly likely that the commercial enterprise could have their programmers come up with a *two-byte* solution that satisifies their needs. And if there really was a need to have a one-byte solution (e.g., you only have one byte of ROM left, or something similar), then clearly that one-byte solution is something special and should be protectable. hLater, Randy Hyde
From: randyhyde on 10 Oct 2007 20:06 On Oct 8, 10:33 am, Betov <be...(a)free.fr> wrote: > "randyh...(a)earthlink.net" <randyh...(a)earthlink.net> écrivaitnews:1191862858.697772.199240(a)r29g2000hsg.googlegroups.com: > > > Perhaps if FASM compiled HLA code, you would have a point > > :)) > > Is not HLA now self-compilable, clown? What does that have to do with the above comment? What does that have to do with anything? Do you not understand the difference between a language and the implementation of that language? > If so, as long as > your HLL Pre-Parser does nothing but obfuscating the FASM, Last time I checked, it really does nothing more than obfuscating machine code :-) > how could it be that FASM would not compile HLA, at the end? > Explain, please: This is too funny. Here's a sample HLA function. Feel free to explain how FASM will compile this: procedure conv.atoi32( var buffer:var in esi ); @nodisplay; @noframe; begin atoi32; push( ebx ); push( ecx ); push( edx ); push( edi ); test( esi, esi ); jz refNULL; dec( esi ); whileDelimLoop: NextChar; cmp( eax, $80 ); jae IllegalChar; bt( eax, (type dword Delimiters )); jc whileDelimLoop; cmp( al, '-' ); jne notNegative; // If this number has a leading minus sign, then skip over it, // convert the number to an unsigned integer, check for overflow, // and then negate the result. inc( esi ); _atou32(); // We need to pass $8000_0000 on through, but all other // values greater than this cause an exception. cmp( eax, $8000_0000 ); ja raiseVOR; neg( eax ); // Because of the leading '-'. jmp done; notNegative: // If the number does not have a leading "-" character, then // treat it like an unsigned integer. Note, however, that // the H.O. bit of the result must be clear or we have an // overflow. _atou32(); cmp( eax, $8000_0000 ); jae raiseVOR; done: pop( edi ); pop( edx ); pop( ecx ); pop( ebx ); ret(); raiseVOR: raise( ex.ValueOutOfRange ); refNULL: raise( ex.AttemptToDerefNULL ); IllegalChar: raise( ex.IllegalChar ); end atoi32; hLater, Randy Hyde
From: randyhyde on 10 Oct 2007 20:16
On Oct 8, 10:43 am, santosh <santosh....(a)gmail.com> wrote: > > > Is not HLA now self-compilable, clown? > > No. HLA 1.xx is written in C with small amounts of Bison and, I think, a > single file in HLA. Uh, the bison file is over 95,000 lines long. I'd argue that constitutes a bit more than "small amounts of Bison" :-) There are, in fact, two HLA files in the program today (not counting the .hhf header files): hlaasm.hla (about 11,000 lines of code) and hfasm.hla (about 25,000 lines of code). There is also a single Flex file (hla.flx, about 12,000 lines of code) and about a dozen C files (no line count, but given that output.c is 20,000 lines of code all by itself, I'd guess that there are somewhere in the neighborhood of 50,000 lines of C code). > > The FASM inside HLA bears only little resemblance to FASM as distributed > at it's author's website. It has been converted into HLA syntax and > some algorithmic and structural modifications have been made, which, > IIRC, Randy claims, sped up it's performance considerably. Well, I wouldn't claim "considerably". More like 15% or so. The real reason for the massive structural changes are these: 1) The original code, apparantly, was written to fit in a 64K code section with 16-bit pointers used to transfer control to various routines throughout the source file. FASM itself has grown to the point where these 16-bit offsets prevent a whole lot of future growth. One of the major changes I made was to change this to a table of 32- bit pointers (still using 16-bit offsets into that table) to remove this restriction from the program. 2) Because the original code was crammed into 64K, it was a bit difficult to maintain. Lots of procedures overlapping one another, stuff like that (great for compacting code, hard to modify). So I refactored the code and made *most* of the procedures stand-alone. This makes the code far easier to modify. > > The HLA front-end compiles HLA source into FASM source which > the "embedded" FASM then translates to executable machine code. > > HLA -----> FASM ------> Binary > GCC -----> GAS ------> Binary > > The difference of course is GCC cannot compile assembly language while > HLA claims to do so. The HLA program compiles the HLA language. It doesn't "claim" anything. I, on the other hand, claim that HLA is an assembly language. To date, I've seen no one give a credible argument that the HLA language is *not* an assembly language that doesn't also eliminate a good number of the other "assembly languages" out there. hLater, Randy Hyde |