[osflash] Legal Considerations That Concern Us All - Was: Re: MTASC Future
hank777 at gmail.com
Tue Oct 25 19:54:39 PDT 2005
I do not believe the article that you post is on point with the issue at hand.
The article refers to reverse engineering in the context of
decompiling an actual product to figure out how it works. One may very
well be restricted in decompiling the flash or flex compiler. However,
the resulting swfs are the property of the author, not macromedia. I
can reverse engineer my own software to my hearts content. MM no more
controls a swf, than Microsoft owns an app I built with their C++
compiler. Using your argument, If Macromedia uses Microsoft compilers
then MM can't tweak or examine the compiled code of the flash player
or compiler without Microsoft's permission.
Regarding reverse engineering of a *protocol* the US law is even more
clear. I stand by the link I provided, which is currently the
controlling decision in this area, unless it is taken up by the
supreme court. The article that you provided in no way addresses
protocols which, in any case cannot be protected by either copyright
or patent law. Protocols are rules. They are not expressions, which
copyright law protects, and patents are protections of processes. So
unless the *process* of sending the protocol is protected by patent
law (which is possible), there would be no basis for protection under
that leg of IP law. I would imagine that aspects of MM code are, or
might be protected by trade secret law, but that only protects MM from
employees or others that steal information that is "locked up" so to
speak. That obviously doesn't cover things, like protocols, that are
by their very nature, things that travel across public networks where
anyone can observe them.
I am fairly certain I am right on this. Certainly, If you personally,
or MM believes I am wrong about this, it would be very helpful to be
pointed to directly pertinent case law regarding:
a. reverse engineering of communication protocols
b. the ownership of compiled code being owned not by the author of the
code but by the author of the compiler
On 10/25/05, Mike Chambers <mchamber at macromedia.com> wrote:
> Here is a more up to date discussion on the issue:
> which shows it is not as clear cut of an issue.
> mike chambers
> hank williams wrote:
> > I am not familar enough with these projects to know what their issues
> > might or might not be. But just to be clear, I believe the issue of
> > whether or not protocols can be reverse engineered is settled law.
> > http://news.com.com/Judges+OK+garage+door+openers+in+copyright+case/2100-1028_3-5341625.html
> > Of course, people can sue over anything, and that is a risk. People
> > sue over things about which there is no merit, and that could easily
> > include adobe. They have done so in the past.
> > In the case linked to above the court of appeals clarifies what should
> > be obvious. Copyright law cannot be used to prevent people from
> > reverse engineering communication protocols for interoperability. Now
> > Adobe could potentially claim that under the EULA, that they restrict
> > such reverse engineering. Now I think it is unlikely that the courts
> > will support that position since there are no known cases that support
> > that in the context of communications software. Moreover, it is
> > entirely possible to reverse engineer a protocol for these products
> > without agreeing to a eula. Flash is accessible without even click
> > signing a eula because it comes embedded in browsers and computers.
> > The bottom line is that the court stands firmly on the side of
> > companies who wish to create interoperable products. But, it is always
> > possible that Adobe could use the threat of lawsuit, regardless of how
> > baseless, to throw cold water on movements that dont have the funding
> > to fight.
> > Hank
> > On 10/25/05, Mike Chambers <mchamber at macromedia.com> wrote:
> >>Why do you assume they have no issues?
> >>mike chambers
> >>Thomas Wester wrote:
> >>>Thanks for the heads up Aral.
> >>>However I fail to see a clear connection with the MTASC future
> >>>discussion. The Red5 or amfphp projects have no issues with
> >>>deconstruction the AMF protocol I can't see how deconstructing a f8.5
> >>>.swf is any different.
> >>osflash mailing list
> >>osflash at osflash.org
> > _______________________________________________
> > osflash mailing list
> > osflash at osflash.org
> > http://osflash.org/mailman/listinfo/osflash_osflash.org
> osflash mailing list
> osflash at osflash.org
More information about the osflash