incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Winscot <rick.wins...@gmail.com>
Subject Re: [MENTORS] Handling Adobe Binaries
Date Thu, 26 Apr 2012 19:19:00 GMT
( I'm speaking to Apache Flex in general - excluding Adobe or its employees )

At this point in time, Apache Flex has a direct dependency on playerglobal.swc as well as
other bits and bobs... all of which provide interoperability ( which was promised ) with Flash
Player. Any kind of 'Iron Fist' or cease and desist would be difficult to dismiss as not being
discriminative, anti-competitive, and a direct attempt to undermine our efforts ( just sayin'
).

'How' this detail was missed is inconsequential... and we are all gainfully engaged in trying
to find a solution - which is good... but it might be better ( I might be going out on a limb
here ) if we place the burden on Adobe.

* We require a reasonable degree of freedom to explore ( without the fear of Adobe Legal )
interoperability with the Flash ecosystem
* We require documentation of any attachment points that may raise concerns of patent infringement

* We require substitutions ( stubs ) of primary dependencies or well-documented alternative(s)
that are Apache compatible

In other words... we should raise the red flag, deliver our best laundry list, and let them
get to work on a solution. 

As a disclaimer... I want to offer the fact that there are great minds here - without a doubt!
My concern ( aka tirade ) is that we can easily get side-tracked on items that we are not
well equipped to handle... or perhaps _shouldn't_ be handling. Again, speaking to Apache Flex
in general and not Adobe employees. 


On Thursday, April 26, 2012 at 1:30 PM, Left Right wrote:

> > 
> > I'll ask legal about this, but it might fall under the reverse engineering
> > restriction.
> > 
> 
> 
> 
> But there's published documentation with precise description of what the
> API do - why copying that would be a reverse engineering? It's like if I
> wanted to write a driver for NVidia adapter - there's no way I would avoid
> copying all the same API they have in the hardware, and, eventually it
> would have all the same interface as the NVidia proprietary drivers. That's
> not stealing from NVidia (in the case outlined above), it's just creating
> an alternative, which cannot vary from the original because of what it does.
> 
> Best.
> 
> Oleg 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message