On May 2, 2012, at 10:54 AM, Om wrote:
>> From the catalog.xml I/we could write some air as3 code using describeType
>> to gen a copy of the playerglobal api.
>>
>
>
> Even if we succeed in doing it, we still need mxmlc or compc to compile the
> actionscript files into the library.swf which go
On 5/2/12 2:24 PM, "olegsivo...@gmail.com" wrote:
> That doesn't really matter... it's not my question, whether player's API
> are written in AS3 or not :S it could be COBOL for all I care - what
> bothers me is why there is code in that library that shouldn't be there.
>
> And yeah, I'm gett
That doesn't really matter... it's not my question, whether player's API
are written in AS3 or not :S it could be COBOL for all I care - what
bothers me is why there is code in that library that shouldn't be there.
And yeah, I'm getting used to the sort of answer "everyone wears their
pants on the
On 5/2/12 12:33 PM, "olegsivo...@gmail.com" wrote:
> I'm still puzzled - why does that library contains actual code?
For the third time, I believe some player APIs are written in AS and the abc
is embedded in the player. Instead of having both a stub copy for
playerglobal and an actual copy f
I'm still puzzled - why does that library contains actual code? Maybe
asking Adobe for a *normal* library without that code (which we seems like
don't even need!) would sort out the patents / copyright issues?
On the other hand, I feel bad telling someone they have to download a piece
of *software
> From the catalog.xml I/we could write some air as3 code using describeType
> to gen a copy of the playerglobal api.
>
Even if we succeed in doing it, we still need mxmlc or compc to compile the
actionscript files into the library.swf which goes inside
playerglobal.swc. That would not be possib
On 5/2/12 1:09 AM, "olegsivo...@gmail.com" wrote:
> Regardless of how the legal side of this pans out, I'm terribly confused
> about the content of playerglobal.swc - again, it is not "fakes". Or, if
> you consider that analogy with C - it is not the headers only, it is both
> the headers and
On 5/2/12 10:41 AM, "Clint Modien" wrote:
> Read an article this morning that I felt was a parallel to this threadŠ
> http://www.forbes.com/sites/oliverherzfeld/2012/05/01/oracle-v-google-are-apis
> -covered-by-copyright-law/
>
> From the articleŠ
>
>
> The heart of the copyright phase of t
Read an article this morning that I felt was a parallel to this thread…
http://www.forbes.com/sites/oliverherzfeld/2012/05/01/oracle-v-google-are-apis-covered-by-copyright-law/
From the article…
The heart of the copyright phase of the trial is Oracle’s claim that Google is
infringing its copyr
On 5/2/12 1:41 AM, "Simon Morvan" wrote:
> Le 02/05/2012 10:34, Bertrand Delacretaz a écrit :
>> I think considering them as build tools that people have
>> to download separately is fine for now.
> For what is worth, I think that this denote that the comparison with the
> Java JDK is biased.
But isn't creating an exact copy of the API our goal, in order to have
feature and functional parity?
If I don't match the function signatures, then the world goes to shit.
-Nick
On Tue, May 1, 2012 at 8:18 PM, Alex Harui wrote:
>
>
>
> On 5/1/12 4:54 PM, "Jeffry Houser" wrote:
>
> > It sh
Hi,
On Wed, May 2, 2012 at 10:41 AM, Simon Morvan wrote:
> ...Maybe Java JDK needs build tools to be downloaded separately by the
> developper in order to perform some specific task, but with a vanilla JDK,
> without downloading anything else, you can produce a working 'Hello World'
>From a
Le 02/05/2012 10:34, Bertrand Delacretaz a écrit :
I think considering them as build tools that people have
to download separately is fine for now.
For what is worth, I think that this denote that the comparison with the
Java JDK is biased.
Maybe Java JDK needs build tools to be downloaded sep
Hi Alex,
On Thu, Apr 26, 2012 at 2:36 AM, Alex Harui wrote:
...
> We discovered yesterday that playerglobal.swc is not under MPL and
> is still under Adobe license. Same for the AIR SDK
Based on your clarifications in FLEX-53, I think it's fine to go ahead
and implement a mechanism to downl
Regardless of how the legal side of this pans out, I'm terribly confused
about the content of playerglobal.swc - again, it is not "fakes". Or, if
you consider that analogy with C - it is not the headers only, it is both
the headers and the actual code / implementations. And implementations are
the
NAL (not a lawyer) either but when I was working on music copyright issues
you could use copyright materials if you were granted permission from the
copyright holder. ie "...you may not reproduce, redistribute or otherwise
use any materials *without* the express written consent..." etc
Not sure if
On 5/1/2012 8:18 PM, Alex Harui wrote:
On 5/1/12 4:54 PM, "Jeffry Houser" wrote:
It shouldn't violate copyright; because we are writing our own code
from scratch. Unless Adobe wants to claim copyright on the API which is
possible. I know I read about a API related lawsuit at one point,
On 5/1/12 4:54 PM, "Jeffry Houser" wrote:
> It shouldn't violate copyright; because we are writing our own code
> from scratch. Unless Adobe wants to claim copyright on the API which is
> possible. I know I read about a API related lawsuit at one point, but I
> have no idea what the result
On 5/1/2012 6:02 PM, Alex Harui wrote:
On 5/1/12 2:51 PM, "Justin Mclean" wrote:
Hi,
Perhaps we can consider this as a fallback?
I was just look at this thread on the Adobe forums [1] where the same issue
come up before (for creating a Fedora package for the OS Adobe SDK) and it's
suggests t
On 5/1/12 4:12 PM, "olegsivo...@gmail.com" wrote:
> For flash.* classes there seem to be only their constructors / some
> rather innocuous pieces of code, but the ES code is entirely embedded there.
> There's something difficult for me to understand though - what pieces of AS
> code from playe
For flash.* classes there seem to be only their constructors / some
rather innocuous pieces of code, but the ES code is entirely embedded there.
There's something difficult for me to understand though - what pieces of AS
code from playerglobal actually go into resulting SWF, and why that code is
th
On 5/1/12 3:40 PM, "olegsivo...@gmail.com" wrote:
> Alex, why are you sure it violates anything?
I'm not sure.
> I believe there must be a
> legal procedure to declare it a reverse engineering. I saw it done many
> times before in a similar context, and beside Oracle trying to press
> charg
As I looked inside the playerglobal.swc, it has actual AS3 code compiled
into it, not just dummy definitions :S
All classes listed here:
http://hg.mozilla.org/tamarin-redux/file/fdf1416a3536/core are there (maybe
there are more of them, I didn't count).
Alex, why are you sure it violates anything?
On 5/1/12 2:51 PM, "Justin Mclean" wrote:
> Hi,
>
> Perhaps we can consider this as a fallback?
>
> I was just look at this thread on the Adobe forums [1] where the same issue
> come up before (for creating a Fedora package for the OS Adobe SDK) and it's
> suggests that it may be possible to
Hi,
Perhaps we can consider this as a fallback?
I was just look at this thread on the Adobe forums [1] where the same issue
come up before (for creating a Fedora package for the OS Adobe SDK) and it's
suggests that it may be possible to create our own dummy swc using code like so:
package flas
On 5/1/12 1:41 PM, "Nicholas Kwiatkowski" wrote:
> The files are not needed to be included separately in the final output, but
> they are compiled in to the final output. I'm not sure if this distinction
> makes life easier or harder for us.
>
I will double check, but I am pretty sure no cod
The files are not needed to be included separately in the final output, but
they are compiled in to the final output. I'm not sure if this distinction
makes life easier or harder for us.
-Nick
On Tue, May 1, 2012 at 6:54 AM, Bertrand Delacretaz
wrote:
> Hi Alex,
>
> On Fri, Apr 27, 2012 at 5:11
Hi Alex,
On Fri, Apr 27, 2012 at 5:11 PM, Alex Harui wrote:
> ...I'm still confused about how to "resolve" FLEX-53. In my
> understanding, given the current license, we aren't really looking to
> "include in a distribution" so I'm not clear we have to meet the definition
> of "build tools"...
I
On 4/27/12 6:09 AM, "Bertrand Delacretaz" wrote:
>
> If there are more such issues, best is probably to create jira issues
> like FLEX-53 and make them blockers for FLEX-4, so that we can keep
> track of things.
Hi Bertrand, I'm still confused about how to "resolve" FLEX-53. In my
understa
Nick,
I don't understand why is it illegal to write an alternative
playerglobal.swc. This does not reproduce what Adobe has done, this is just
a program that serves the same purpose, which, as a consequence, exhibits
similar behavior. It is easy to show that you don't need to reverse
anything in o
Hi,
On Fri, Apr 27, 2012 at 2:25 PM, Nicholas Kwiatkowski wrote:
> ...My hope is that we clear these legal hurdles soon. I know a lot of people
> are antsy to get our first release out the door :)...
If there are more such issues, best is probably to create jira issues
like FLEX-53 and make the
On Thu, Apr 26, 2012 at 6:58 PM, Alex Harui wrote:
> On 4/26/12 12:22 AM, "Bertrand Delacretaz" wrote:
>>... If you can document (in JIRA I'd say) what makes you consider those
>> files as build tools, that relaxes some of the licensing requirements
>> as described at http://apache.org/legal/res
Hi Carol,
On Thu, Apr 26, 2012 at 6:46 PM, Carol Frampton wrote:
> ...The code in question is
>
> 1) playerglobal.swc to compile the majority of the Flex components
> 2) airglobal.swc to compile the Flex components targeted at AIR
> 3) many pieces of the AIR Integration kit which are need to do F
Oleg, et. all..
One of the key aspects of Apache is that any software that is submitted to
the project is 100% clear and legal, and can be used by others knowing that
they won't have any legal threats against it. We want to make sure that we
abide by this or we will never get out of incubation.
sorry, wrong email thread..blame it on my android os.
Russ
Russell Doi wrote:
wendy booked Tanyas flight. i gave her your yahoo address for flight
confirmation..let me know if you got it.
r
Alex Harui wrote:
On 4/26/12 10:30 AM, "olegsivo...@gmail.com" wrote:
>
> But there's publis
wendy booked Tanyas flight. i gave her your yahoo address for flight
confirmation..let me know if you got it.
r
Alex Harui wrote:
On 4/26/12 10:30 AM, "olegsivo...@gmail.com" wrote:
>
> But there's published documentation with precise description of what the
> API do - why copying that
On 4/26/2012 4:19 PM, Alex Harui wrote:
On 4/26/12 10:30 AM, "olegsivo...@gmail.com" wrote:
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
Le 26/04/2012 19:02, Alex Harui a écrit :
On 4/26/12 4:48 AM, "Simon Morvan" wrote:
Le 26/04/2012 02:36, Alex Harui a écrit :
BTW, playerglobal is redistributed in the 'mavenized' version you can
find on Sonatype repository that is crafted by velo (Flemojos author).
Redistribution of that s
On 4/26/12 10:30 AM, "olegsivo...@gmail.com" wrote:
>
> 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 a
On 4/26/12 10:33 AM, "Rick Winscot" wrote:
> Is this not a clear case where playerglobal.swc could be 'stubbed-out' to
> side-step the dependency?
>
I'm not sure what you mean. It is already stubs for VM/runtime APIs.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/a
On 4/26/12 12:19 PM, "Rick Winscot" wrote:
> ( 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
( 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' o
Is this not a clear case where playerglobal.swc could be 'stubbed-out' to
side-step the dependency?
On Thursday, April 26, 2012 at 1:04 PM, Alex Harui wrote:
>
>
>
> On 4/26/12 6:09 AM, "olegsivo...@gmail.com (mailto:olegsivo...@gmail.com)"
> mailto:olegsivo...@gmail.com)> wrote:
>
> > On t
>
> 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
On 4/26/12 6:09 AM, "olegsivo...@gmail.com" wrote:
> On the other hand, playerglobal.swc library isn't a separate product
> distributed by Adobe.
It can be downloaded from the FlashPlayer page.
>
> I mentioned this problem before, but the discussion got carried away in a
> different direction
On 4/26/12 4:48 AM, "Simon Morvan" wrote:
> Le 26/04/2012 02:36, Alex Harui a écrit :
>
> BTW, playerglobal is redistributed in the 'mavenized' version you can
> find on Sonatype repository that is crafted by velo (Flemojos author).
> Redistribution of that stuff had never lead to complaint
On 4/26/12 12:22 AM, "Bertrand Delacretaz" wrote:
>
> What's that Adobe license exactly? URL?
http://www.adobe.com/products/eulas/pdfs/adobe_flex_software_development_kit
-combined-20110916_0930.pdf
>
>
>> 3. Since these are required files, we cannot download them as part of the
>> build
Bertrand,
I know you like inline responses but not sure how to do that with the
information I want to add.
The code in question is
1) playerglobal.swc to compile the majority of the Flex components
2) airglobal.swc to compile the Flex components targeted at AIR
3) many pieces of the AIR Integrat
>
> I'll try to rephrase to make sure I understand - IIUC someone needs to
> tell people to unpack the Apache Flex source distribution and mix that
> with other files which do not come from Apache, in order to use
> FlashBuilder which is an external tool that does not belong to us.
No, files like
Le 26/04/2012 02:36, Alex Harui a écrit :
We discovered yesterday that playerglobal.swc is not under MPL and is still
under Adobe license. Same for the AIR SDK.
This is kinda weird.
playerglobal.swc is (and has always be) part of the 'opensource' version
of the SDK
(http://opensource.adobe.
BTW, playerglobal.swc is aviable here:
http://www.adobe.com/support/flashplayer/downloads.html
We can just note user that he needs to manually download this binary.
How about that?
On Thu, Apr 26, 2012 at 11:22 AM, Bertrand Delacretaz
wrote:
> Hi Alex,
>
> On Thu, Apr 26, 2012 at 2:36 AM, Alex
Hi Alex,
On Thu, Apr 26, 2012 at 2:36 AM, Alex Harui wrote:
> We discovered yesterday that playerglobal.swc is not under MPL and is
> still under Adobe license. Same for the AIR SDK
What's that Adobe license exactly? URL?
> ...I want to check my understanding of how to handle these bi
Hi Mentors,
We discovered yesterday that playerglobal.swc is not under MPL and is still
under Adobe license. Same for the AIR SDK.
Since these files represent the Flash Platform, I would think they should be
defined as “build tools”. If you agree, I want to check my understanding of
how to h
53 matches
Mail list logo
