Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keyframes: Delivering scalable, high-quality animations to mobile clients

code.facebook.com

Post reply on HN
Print view View original

101–110 of 153 posts

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#101

Post by morvita »

omginternets wrote: post #85
dublinben wrote: post #21

Earlier quoted context omitted.

That restriction makes this quite blatantly not open source or free software, under the accepted definitions. Why couldn't they just release this under the MIT license or something else like that?

>Why couldn't they just release this under the MIT license or something else like that? I don't mean to be unpleasant (really!), but I don't understand what kind of answer you are expecting to get. The only non-trivial answer one can give is also the most obvious: Facebook doesn't want to make free software. Stated differently: why the assumption that Facebook is in the business of Free software? Or are you just expr…

> Today, we’re excited to open-source and share this library more broadly, so that others can work together to build more delightful products.

Facebook's post explicitly states they view this as an open source library. So, while I agree that we cannot assume Facebook is in the business of free software, their post says they are releasing an open source library under a license that does not appear to follow OSI definition of open source.

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#102

Post by BinaryIdiot »

mahyarm wrote: post #97
BinaryIdiot wrote: post #95

Earlier quoted context omitted.

> As someone who has to deal with mobile perf issues, JSON serialization/deserialization can take a lot more of a perf budget than you realize. A flatbuffer version would definitely be faster hands down With something that's grabbed once and cached likely forever I think the tiny bit of overhead for JSON won't make any difference. I've done this too and yes, of course a flatbuffer would be faster but the speed is jus…

Unless they store the cached version as a flatbuffer or similar format, you will suffer a penalty every app startup. And startup is where a lot of mobile perf is focused on. I haven't heard of SVG renderers storing SVG XML files in a more efficient format. It's like using jpeg2000 compressed images vs. PNG. And if you use a lot of them, it will add up.

> Unless they store the cached version as a flatbuffer or similar format, you will suffer a penalty every app startup. And startup is where a lot of mobile perf is focused on.

Why would you pull in data from one format and keep it in the same format forever if it's not optimal for the device AND it doesn't need to be modified and sent back? Whenever I work on mobile apps and I have to cache data coming over as JSON or XML I store it where I can quickly re-access and NOT in its original format.

This thread seems like a conversation about how you can shoot yourself in the foot when it's very easy to avoid.

> I haven't heard of SVG renderers storing SVG XML files in a more efficient format.

Me neither. Sounds like it could be doable. Not sure how this related to our conversation though.

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#103

Post by idbehold »

zwegner wrote: post #100
echelon wrote: post #27

Earlier quoted context omitted.

Why does the software license [1] include the following clause: > provided Your Software does not consist solely of the Software Why didn't you guys choose MIT or BSD? It feels like the custom Facebook license is close to the intent of these, but it has that mysterious gotcha. In any case, thanks for the software! It looks really slick, and I definitely have a use case for using it to replace the sprite sheet I used…

Note that, by publishing this repo publicly on GitHub, there is a right to fork granted by GitHub's ToS[0], which this license seems to conflict with (though IANAL of course...). Not sure what "fork" means in this context, whether it's just duplicating a repository or also modifying it. [0] https://help.github.com/articles/github-terms-of-service/#f-... Section F.1: "By setting your repositories to be viewed publicly…

Agreed. I've already contacted GitHub to report abuse.

This license seems to directly contradict GitHub's Terms of Service. It says:

> [...] you are hereby granted a non-exclusive, worldwide, royalty-free copyright license to (1) use and copy the Software; and (2) reproduce and distribute the Software as part of your own software ("Your Software"), provided Your Software does not consist solely of the Software; and (3) modify the Software for your own internal use. Facebook reserves all rights not expressly granted to you in this license agreement.

Where as GitHub's Terms of Service state:

> By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.

It seems impossible for me to fork this software without violating Facebook's license. To fork it on GitHub would require that I make the repo public (meaning I would be distributing the Software as "My Software" even though it consists solely of the Software). And any commits I made to the forked repo would violate their license because I am only licensed to modify the Software for my own "internal use".

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#104

Post by peller »

LeanderK wrote: post #90
peller wrote: post #44

Earlier quoted context omitted.

They want the user adoption, without giving up control, presumably.

this might be silly, but why? what does Facebook gain by getting this library user adoption (beside some bug-reporting). I would think that for fb user adoption of the open source projects is not the goal, but getting OSS developers attracted and getting fixes/features etc. developed from them. Or is it some kind of pride? Fake internet point for having repositories on github?

My long-time-range guess is that this is FB's play for becoming a standard replacement/upgrade for GIFs. From the post:

"Initially, we looked at common static image formats such as PNG sequences and GIFs, as well as even more compressed formats like WebP. It quickly became clear that these wouldn't work without drastically simplifying the animations for file size, and that we'd have to accept the drawback of static images not scaling up or down very well."

So, reading between the lines, they've made what they think is a better GIF. And perhaps it is, and if so, that's big business[1], and so having a first-mover advantage on mobile could be highly profitable. (They're a public A-corporation, after all.)

But who knows; I could be reading too far into it or just flat-out wrong, too!

[1] http://www.popularmechanics.com/technology/a21457/the-gif-is...

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#105

Post by electic »

scarhill wrote: post #80
lhorie wrote: post #69

Earlier quoted context omitted.

If I understand right, you can fork it and even redistribute it, as long as your software isn't a blatant plagiarism of this repo. So technically, taking this library and putting it together with some other library yielding some meaningful application is enough to satisfy that clause.

I read it as only allowing you to redistribute unmodified copies, because clause 3 only permits modification "for your own internal use."

Also, even if were to improve on it and release it as a fork, as an example, it still falls into the definition of "software" and is in violation of the terms.

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#106

Post by idbehold »

detaro wrote: post #55
CorpOverreach wrote: post #51

Earlier quoted context omitted.

Do you have access to the source? Yes? It's open source. Open Source need not be free as in beer, nor as in freedom.

No. Call that "source available", "source access" or something, but "Open Source" is pretty much established to be defined by the OSI definition of the term: https://opensource.org/osd

The OSI should trademark the phrase "open source". License it for anyone claiming their software is open source (as defined by OSI), and send cease and desists to anyone who is using the phase incorrectly.

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#108

Post by izym »

cosmotron wrote: post #96
echelon wrote: post #36

Earlier quoted context omitted.

I'm not misreading it. The license says we cannot fork the software. That's not open source.

Isn't a different interpretation that a fork is, presumably, their software _plus_ your modification(s)? Thus, a fork is not "solely" their software anymore and is allowed.

Yes, but forking on GitHub means that initially it will be just their software.

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#109

Post by Eridrus »

lozzle wrote: post #49
Eridrus wrote: post #35

Earlier quoted context omitted.

I get grey flashes over the animations/text in my HN reader (Materialistic).

Is there any way you can share a part of the composition, or something that produces a similar bug?

I can only replicate it in that app, I don't see it elsewhere.

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#110

Post by steveklabnik »

echelon wrote: post #89
steveklabnik wrote: post #86

Earlier quoted context omitted.

https://crates.io/crates/protobuf exists; though I haven't used it. Cap'n'Proto has pretty great support for Rust, from what I hear.

Oh awesome! I'll check this out. btw, I love all the work you do for Rust, Steve! :)

Thanks :)
Post reply on HN