|
Thanks again to this forum's inquiry on such a thick topic, and sorry to be so long in returning a reply (and in replying so long): | -----Original Message----- | From: mi400-bounces@xxxxxxxxxxxx [mailto:mi400-bounces@xxxxxxxxxxxx]On | Behalf Of Leif Svalgaard | Sent: Monday, March 01, 2004 10:06 PM | From: Tom Liotta <qsrvbas@xxxxxxxxxxxx> | > "jt" <jt@xxxxxx> wrote: | > >I would guess not, but I'd just be guessing. (I sure DO know that Most | > >Every software agreement I've Ever seen disallows | reverse-engineering, but | > >it seems to be done an awful lot anyway in all niches of the | IT industry, | so | > >I dunno?.?) | > | > Also note that the practice of 'reverse engineering' is | generally legally | protected activity. I've seen no definitive answer about | continuing questions | over how much licensing language may successfully prohibit it; | which doesn't | mean it doesn't exist, just that I haven't seen it. | > | | A license agreement is a contract and as such falls under state law, not | federal law. In many states the standard EULA is not an enforceable | contract, being a "contract of adhesion", meaning, as far as I know, | that the contract did not result as a negotiation between the parties. I wuz gonna get the textbooks out. I do know that insurance policy forms are contracts, as well as "contracts of adhesion". Although an insurance contract (ie, policy) may or may NOT be negotiated.. and one of the quickest ways to get fired or lose license is to imply there are benefits besides or in addition to what is stated in the contract. (Although there will always be scammers.) A contract is offered (in Ohio, and I believe "universally" through the U.S.) on a take-it-or-leave-it basis. If neither accepted nor rejected, the contract can usually be amended and counter-Offered. (But the first party is under no obligation to then accept that counter-proposal.) IANAL, goes without saying. I'm not sure where Ohio stands on EULA, or to what extent all this has been tested in courts either. I'm afraid I'll hafta agree at this time, with Leif's first thoughts on this subject way back when: | -----Original Message----- | From: mi400-bounces@xxxxxxxxxxxx [mailto:mi400-bounces@xxxxxxxxxxxx]On | Behalf Of Leif Svalgaard | Sent: Thursday, February 26, 2004 10:54 AM | To: MI Programming on the AS400 / iSeries | Subject: Re: [MI400] modify program object | | | From: jt <jt@xxxxxx> | > First off, isn't this the technique Arctirex (sp?) DOES use in their | > Web-facing-like product? (They just duplicated some functionality in | > another library, iirc. I don't recall if they modify the SEPT, | but concept | > is basically the same, afaik from reading these lists.) Has | IBM hurt their | > product or sued them?? I dunno. | > | | What they did, was to make a local copy of the SEPT, then modify | that. Now, making a copy is theoretically an infringement on the copyright | holder's right, so is technically illegal, but, again, it is the copyright | holder's decision to complain about this or not. That right is weakened, | though, if one doesn't complain ALL the time. But all of this is extremely | murky and has scarcely been considered by the courts, so nobody | knows. I guess that is the bottom line: nobody knows. And this is | the sad thing. It is hard to be legal when nobody knows what the | law really is. As it stands now, the (unknown) legal issues may | have a chilling effect on the whole problem, which is OK, I guess, | for IBM and others of that ilk. Btw, was reading just now that, according to Jeff Bezos a patent does NOT need to be continually in-force/enforced in order to remain valid (unlike, apparently, trademarks and copyrights). (Old, but still good: http://www.oreilly.com/news/amazon_patents.html) I would re-emphasize that "As it stands now, the (unknown) legal issues may have a chilling effect on the whole problem, which is OK, I guess, for IBM and others..." More OK for some, than others, I'd guess. I noticed that "decentralization" has scored another hit (with HSIN http://www.ozzie.net/blog/2004/02/26.html) all, apparently, CENTRALIZED through GROOVE and the Groove company that supplies it!! As Ray Ozzie himself ironically said, "the code can define outcomes - inadvertently or intentionally - that might have an impact on society." With apologies in advance to Mr. Ozzie, I think this was mostly intentional. And wrt the Point #5 of The Action Plan (Exhibit A of HSIN report) it seems to over-emphasize the PRIVATE part of the "public-private process". Interesting a decentralized approach was selected exclusively, and that Groove apparently happens to not include centralized processing or RAS-Server-Server Architecture, afaik. Security??? I wouldn't be the first to note that the 400 has received press as the ONLY platform that has never been infected by virus (but, personally, do not know of a big-iron mainframe getting these either). And I'm not aware of ANY press that *nix (including BSD) or Windows have gotten that stated they were NOT susceptible to viruses. As Phil mentioned on the Security list, "The trusted translator (Force Conversion on Restore) is the best protection you have." Wuz GONNA say that any system not operating under Level 7 on the QObjRstFrcCnv-whatever?? SYStem VALue is hosed as far as security goes, right?... So, therefore, if the data hits a Windows or *nix (and/or big-iron??) system on the grid, you network is exposed. Wonder if Groove runs on a 400...? And even if so.. wonder if it's another one-a THEM ports that actually INCREASES THE EXPOSURE on a 400, due to buffer overruns and archaic "Open" or "closed" source security methods and such...?? Dunno. And, waybacking some more, I would emphasize what Phil said, below: Especially the fact that [2] is a Large market presence and is not limited to the DCMA issue either. (And I'll take a pass on discussion of the DCMA at this time, although it Would be interesting, due to time and my (imagine THAT!) unpopular views on these issues...;-D)) | -----Original Message----- | From: mi400-bounces@xxxxxxxxxxxx [mailto:mi400-bounces@xxxxxxxxxxxx]On | Behalf Of Hall, Philip | Sent: Monday, March 01, 2004 10:05 PM | To: MI Programming on the AS400 / iSeries | Subject: RE: [MI400] RE:modify program object | | | | > -----Original Message----- | > From: Tom Liotta [mailto:qsrvbas@xxxxxxxxxxxx] | > Subject: RE: [MI400] RE:modify program object | > | > | > "jt" <jt@xxxxxx> wrote: | > | > >I would guess not, but I'd just be guessing. (I sure DO | > know that Most | > >Every software agreement I've Ever seen disallows | > reverse-engineering, but | > >it seems to be done an awful lot anyway in all niches of the | > IT industry, so | > >I dunno?.?) | > | > Also note that the practice of 'reverse engineering' is | > generally legally protected activity. I've seen no definitive | > answer about continuing questions over how much licensing | > language may successfully prohibit it; which doesn't mean it | > doesn't exist, just that I haven't seen it. | | I'm not sure even that's the case these days, given the DCMA can | be twisted[1] to prosecute[2] almost all forms of reverse | engineering. And before anyone says "The DCMA is just for the US" | - Europe and Australia are currently close to signing in to law | very similar (since they were modelled off of the DCMA) legislation. | | --phil | | [1] This is because it was purposely written to be 'flexible' | [2] In some cases, it's not so much the final prosecution that's | the play, but the cost to defend against the claim that ends up | making the DCMA 'work'.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.