Prev: &optional combined with &rest
Next: local-time on Clozure CL windows vista 64 Can't resolve foreign symbol "gettimeofday"
From: Pascal J. Bourguignon on 28 Sep 2009 07:55 gnubeard <gnubeard(a)gmail.com> writes: > On Sep 28, 2:05 pm, Raffael Cavallaro > <raffaelcavall...(a)pas.espam.s.il.vous.plait.mac.com> wrote: >> On 2009-09-27 22:48:10 -0400, gnubeard <gnube...(a)gmail.com> said: >> >> > Circumventing one, or all, of those limitations while continuing to >> > use it non-commercially is not in violation of the license agreement. >> >> "You may not translate, reverse >> engineer, decompile, disassemble, modify or create >> derivative works based on the materials, except as >> expressly permitted by the law of this Agreement." >> >> Seems to me that your hack entailed some reverse engineering >> (admittedly simple, but reverse engineering nevertheless), which >> reverse engineering was not expressly permitted by the agreement. Seems >> to me like you've laid yourself open to section 16. > > I'm baffled. How is creating my own implementation of a standard C > function reverse engineering, in any sense of the term? Or how is > loading said function with a standard ld feature reverse engineering? > > I just read the entire wiki article on reverse engineering, thinking > that my understanding of the term might be the problem.. the thesis of > the article is thus: > > Reverse engineering (RE) is the process of discovering the > technological principles of a device, object or system through > analysis of its structure, function and operation. It often involves > taking something (e.g., a mechanical device, electronic component, or > software program) apart and analyzing its workings in detail to be > used in maintenance, or to try to make a new device or program that > does the same thing without copying anything from the original. > > I don't see how any of that that applies, at all. I agree with you. However, I can imagine a lawyer arguing that modifying the behavior of an external library function such as gettimeofday that is called by the program in question is a kind of probing, and thus you "analyzed" its workings with respect to time and timeouts. After all, before you didn't know how it would behave. After having implemented this new gettimeofday, you know how Lispworks behaves. So you analyzed it and reverse engineered this part. Granted, as a blackbox, without taking it apart, but still... -- __Pascal Bourguignon__
From: gnubeard on 28 Sep 2009 08:30 On Sep 28, 9:43 pm, Joost Kremers <joostkrem...(a)yahoo.com> wrote: > gnubeard wrote: > > I'm baffled. How is creating my own implementation of a standard C > > function reverse engineering, in any sense of the term? Or how is > > loading said function with a standard ld feature reverse engineering? > > you found out how LW keeps track of the 5hr limit. that's reverse-engineering, > because you had to analyse LW's functioning and operating to do so. hmm, ok .. I suppose I can see the argument in a way. In actual point of fact though, I didn't analyze a thing. I knew apriori that LW would be using gettimeofday() because thats what C programs do: they use the C standard library. But I could have been wrong about them having written it in C though, so I guess I "learned" that too. IMO this is pretty weak, though.. and certainly not clear cut. I can imagine a judge throwing this out just as easily as I can see it being considered.
From: gnubeard on 28 Sep 2009 08:41 On Sep 28, 9:55 pm, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > I agree with you. However, I can imagine a lawyer arguing that > modifying the behavior of an external library function such as > gettimeofday that is called by the program in question is a kind of > probing, and thus you "analyzed" its workings with respect to time and > timeouts. After all, before you didn't know how it would behave. > After having implemented this new gettimeofday, you know how > Lispworks behaves. So you analyzed it and reverse engineered this > part. Granted, as a blackbox, without taking it apart, but still... Yeah, I suppose I could see this being argued back and forth in a court. My argument to the judge in such a case would be that using such weak criteria to establish "reverse engineering" would equally prohibit me from using a replacement C library such as FreeVec (Altivec/SSE/etc accelerated C library) in debug mode where it tells me what functions are being called, SIMD registers, etc. My aim for such a thing might be to simply debug FreeVec, and the fact that I learn about LW is secondary only because it might be LW that triggers the trouble in FreeVec. Prohibition of an entire class of usage on the grounds that I might secondarily learn something about LW would be dangerous precedent, and I think most judges would rule that reverse engineering entails primarily trying to establish the functioning and details of the system in question, and not merely learning a bit about it by using it.. even if that usage is out of the ordinary. Interesting stuff, though :)
From: Pascal J. Bourguignon on 28 Sep 2009 08:54 gnubeard <gnubeard(a)gmail.com> writes: > On Sep 28, 9:55 pm, p...(a)informatimago.com (Pascal J. Bourguignon) > wrote: > >> I agree with you. However, I can imagine a lawyer arguing that >> modifying the behavior of an external library function such as >> gettimeofday that is called by the program in question is a kind of >> probing, and thus you "analyzed" its workings with respect to time and >> timeouts. After all, before you didn't know how it would behave. >> After having implemented this new gettimeofday, you know how >> Lispworks behaves. So you analyzed it and reverse engineered this >> part. Granted, as a blackbox, without taking it apart, but still... > > > Yeah, I suppose I could see this being argued back and forth in a > court. > > My argument to the judge in such a case would be that using such weak > criteria to establish "reverse engineering" would equally prohibit me > from using a replacement C library such as FreeVec (Altivec/SSE/etc > accelerated C library) in debug mode where it tells me what functions > are being called, SIMD registers, etc. My aim for such a thing might > be to simply debug FreeVec, and the fact that I learn about LW is > secondary only because it might be LW that triggers the trouble in > FreeVec. > > Prohibition of an entire class of usage on the grounds that I might > secondarily learn something about LW would be dangerous precedent, and > I think most judges would rule that reverse engineering entails > primarily trying to establish the functioning and details of the > system in question, and not merely learning a bit about it by using > it.. even if that usage is out of the ordinary. > > Interesting stuff, though :) Of course it depends on the country. In France, you'd have a case about interoperability: you'd be allowed to reverse engineer LispWorks, if need be, to make it run with your own libc. -- __Pascal Bourguignon__
From: Frank Buss on 28 Sep 2009 09:03
gnubeard wrote: > Yeah, I suppose I could see this being argued back and forth in a > court. No, I think it would be very short. You have modified the libc, because you don't want to pay for a good product. It is the intention that counts. There are other examples for this concept, e.g. involuntary manslaughter and murder. Both have the same result, but the punishment is much different, because the intention of the offender was different. -- Frank Buss, fb(a)frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de |