23 ms·

For iOS 4.1, which came out in September 2010, absolutely no GPL code for it (or later versions, like 4.2) was posted until March 2011. That's not 8 weeks: that

by Xuzz 15y ago

For iOS 4.1, which came out in September 2010, absolutely no GPL code for it (or later versions, like 4.2) was posted until March 2011. That's not 8 weeks: that's about 6 months. When comex (http://twitter.com/comex http://twitter.com/comex) and saurik (http://saurik.com/ http://saurik.com/) asked for it (via emails to opensource@apple.com and copyright@apple.con) around last November, I don't think they got any response from Apple —until this year. Then, Apple let them know that it would be up "within a week". I think the iOS 4.1 and 4.2 code actually went up about three weeks after they received that email. saurik has even more examples of them not releasing the [L]GPL'd code near the top of this post: http://www.saurik.com/id/4 http://www.saurik.com/id/4 — "Frankly, I wouldn't be surprised at all if Apple ends up on the bad end of a GPL-related lawsuit." (In my opinion, the fact Apple has posted any code for iOS 4.3 at this point is a big step in the right direction: they're not perfect yet, but at least they've got 8/10 of the projects up.)

masklinn 15y ago
> In my opinion, the fact Apple has posted any code for iOS 4.3 at this point is a big step in the right direction: they're not perfect yet, but at least they've got 8/10 of the projects up. The truly weird part, to me, is that with as much (L)GPL code Apple releases they don't seem to have an automatic, systematic system in place to handle that. Even for a project as big as iOS.
- jpk 15y ago
  I think the problem is that doing so is a zero-revenue effort. Why spend man-hours putting together an automated workflow for source release when you can just do it manually (and lazily) every time someone complains? That doesn't justify it, of course, but looking at it that way makes it seem not-weird.
  - jrockway 15y ago
    This is risky, because lawsuits can have damage awards. If you decide not to comply with a contract you've agreed to because "it's a zero-revenue effort", that could look bad in court. Legality aside, it looks pretty bad from a human interaction perspective: "we took thousands of man-hours worth of code from the community, but we were too lazy to spend even one man hour to upload a tarball to our website and follow that community's wishes". The fact that they are legally-obligated to not act like that just makes it even worse.
    - Xuzz 15y ago
      But is it really an hour? I doubt that Apple uploads the code they actually used: it's likely that code, and then lots of removed components that would reveal too much about how something works (e.g. there are no build scripts or Xcode projects for JavaScriptCore releases, only the code itself). At least, they would need to make sure that none of their proprietary code slips out. That likely involves more than "svn checkout; tar; ftp", maybe even lawyers to check it.
      - openbear 15y ago
        there are no build scripts or Xcode projects for JavaScriptCore releases, only the code itself Not true. See JavaScriptCore.xcodeproj in ... http://www.opensource.apple.com/source/JavaScriptCore/JavaScriptCore-7533.20.20/ http://www.opensource.apple.com/source/JavaScriptCore/JavaSc... http://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore/ http://svn.webkit.org/repository/webkit/trunk/Source/JavaScr... ... and if Xcode isn't your thing, just run the script "build-webkit" ... http://svn.webkit.org/repository/webkit/trunk/Tools/Scripts/ http://svn.webkit.org/repository/webkit/trunk/Tools/Scripts/ ... build instructions in plain English here ... http://www.webkit.org/building/build.html http://www.webkit.org/building/build.html
        Xuzz 15y ago
        That's true for standard WebKit, and even the Mac OS X version, but not for iOS. For example, the latest iOS JavaScriptCore release (4.2, http://www.opensource.apple.com/source/JavaScriptCore/JavaScriptCore-621.1/ http://www.opensource.apple.com/source/JavaScriptCore/JavaSc...) has no Xcode files like the one you linked does. I haven't read the LGPL lately, but is that a violation? Do they have to provide enough information to build your own copy?
        comex 15y ago
        Yes, it is. "For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library."
  - masklinn 15y ago
    > Why spend man-hours putting together an automated workflow for source release when you can just do it manually (and lazily) every time someone complains? Because doing it manually every time ends up costing more man-hours than having an engineer or two bang up some check/upload script in a morning.
  - pnathan 15y ago
    It's not that hard, I don't think. E.g., All GPL repositories live in this /gpl/ directory; it gets tarballed and gzipped and dumped into the /other/ location immediately prior to creating the build image. Maybe Apple's got some whacked-out approach to code management brought on by some funky OS Classic approach, but I doubt it, they are smart people over there.
- matwood 15y ago
  Apple seems to have a lot of odd processes with respect to code and development tools. One super annoying one is having to re-download the entier Xcode bundle (4GB+) every time they make a minor change.
  - masklinn 15y ago
    Yeah, Apple is chronically unable to ship diff updates (or more generally updates). They just can't do it apparently. iTunes update? Download everything. Xcode update? Download everything. AppStore app update? Download everthing. iOS firmware update? Download everything.
    - msbarnett 15y ago
      Complete, non-diff updates have predictability on their side; if something was corrupted on the user's end, the update will overwrite it, whereas a diff will leave it in an unpredictable state. I suspect Apple prefers the simplicity and explainability of "here's the update, same thing for everyone" to "well if this smaller update didn't work in any of a huge variety of ways, you could optionally try this other update"
      - ori_b 15y ago
        we have a way to detect if it's broken. Do it by checksum. If the checksums don't match, then redownload the changed parts. This is also fully predictable, but it's also far faster.
      - mentat 15y ago
        This can easily be automated. You could send a hash of the binary and have a custom patch either pulled from cache or created (the largest "patch" being the whole binary). You'd end up with a fairly complete cache very fast though. Binary diffing is a mostly solved problem. This assumes that there's a list of hashes that correlate to known historical binaries. If the hash doesn't match you fall back to sending the whole thing.
      - drivebyacct2 15y ago
chuckywhat 15y ago
6 mo. is ridiculous but I roll my eyes @ GPL lawsuit.
saurik 15y ago
It is actually worse than that, as Apple has /never/ been in compliance with this license: I want the code to WAK*. It is simply not possible to compile a copy of iOS WebCore with the incomplete code that Apple has chosen to provide.

by Xuzz 15y ago

masklinn 15y ago

> In my opinion, the fact Apple has posted any code for iOS 4.3 at this point is a big step in the right direction: they're not perfect yet, but at least they've got 8/10 of the projects up. The truly weird part, to me, is that with as much (L)GPL code Apple releases they don't seem to have an automatic, systematic system in place to handle that. Even for a project as big as iOS.

jpk 15y ago
I think the problem is that doing so is a zero-revenue effort. Why spend man-hours putting together an automated workflow for source release when you can just do it manually (and lazily) every time someone complains? That doesn't justify it, of course, but looking at it that way makes it seem not-weird.
- jrockway 15y ago
  This is risky, because lawsuits can have damage awards. If you decide not to comply with a contract you've agreed to because "it's a zero-revenue effort", that could look bad in court. Legality aside, it looks pretty bad from a human interaction perspective: "we took thousands of man-hours worth of code from the community, but we were too lazy to spend even one man hour to upload a tarball to our website and follow that community's wishes". The fact that they are legally-obligated to not act like that just makes it even worse.
  - Xuzz 15y ago
    But is it really an hour? I doubt that Apple uploads the code they actually used: it's likely that code, and then lots of removed components that would reveal too much about how something works (e.g. there are no build scripts or Xcode projects for JavaScriptCore releases, only the code itself). At least, they would need to make sure that none of their proprietary code slips out. That likely involves more than "svn checkout; tar; ftp", maybe even lawyers to check it.
    - openbear 15y ago
      there are no build scripts or Xcode projects for JavaScriptCore releases, only the code itself Not true. See JavaScriptCore.xcodeproj in ... http://www.opensource.apple.com/source/JavaScriptCore/JavaScriptCore-7533.20.20/ http://www.opensource.apple.com/source/JavaScriptCore/JavaSc... http://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore/ http://svn.webkit.org/repository/webkit/trunk/Source/JavaScr... ... and if Xcode isn't your thing, just run the script "build-webkit" ... http://svn.webkit.org/repository/webkit/trunk/Tools/Scripts/ http://svn.webkit.org/repository/webkit/trunk/Tools/Scripts/ ... build instructions in plain English here ... http://www.webkit.org/building/build.html http://www.webkit.org/building/build.html
      - Xuzz 15y ago
        That's true for standard WebKit, and even the Mac OS X version, but not for iOS. For example, the latest iOS JavaScriptCore release (4.2, http://www.opensource.apple.com/source/JavaScriptCore/JavaScriptCore-621.1/ http://www.opensource.apple.com/source/JavaScriptCore/JavaSc...) has no Xcode files like the one you linked does. I haven't read the LGPL lately, but is that a violation? Do they have to provide enough information to build your own copy?
        comex 15y ago
        Yes, it is. "For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library."
- masklinn 15y ago
  > Why spend man-hours putting together an automated workflow for source release when you can just do it manually (and lazily) every time someone complains? Because doing it manually every time ends up costing more man-hours than having an engineer or two bang up some check/upload script in a morning.
- pnathan 15y ago
  It's not that hard, I don't think. E.g., All GPL repositories live in this /gpl/ directory; it gets tarballed and gzipped and dumped into the /other/ location immediately prior to creating the build image. Maybe Apple's got some whacked-out approach to code management brought on by some funky OS Classic approach, but I doubt it, they are smart people over there.
matwood 15y ago
Apple seems to have a lot of odd processes with respect to code and development tools. One super annoying one is having to re-download the entier Xcode bundle (4GB+) every time they make a minor change.
- masklinn 15y ago
  Yeah, Apple is chronically unable to ship diff updates (or more generally updates). They just can't do it apparently. iTunes update? Download everything. Xcode update? Download everything. AppStore app update? Download everthing. iOS firmware update? Download everything.
  - msbarnett 15y ago
    Complete, non-diff updates have predictability on their side; if something was corrupted on the user's end, the update will overwrite it, whereas a diff will leave it in an unpredictable state. I suspect Apple prefers the simplicity and explainability of "here's the update, same thing for everyone" to "well if this smaller update didn't work in any of a huge variety of ways, you could optionally try this other update"
    - ori_b 15y ago
      we have a way to detect if it's broken. Do it by checksum. If the checksums don't match, then redownload the changed parts. This is also fully predictable, but it's also far faster.
    - mentat 15y ago
      This can easily be automated. You could send a hash of the binary and have a custom patch either pulled from cache or created (the largest "patch" being the whole binary). You'd end up with a fairly complete cache very fast though. Binary diffing is a mostly solved problem. This assumes that there's a list of hashes that correlate to known historical binaries. If the hash doesn't match you fall back to sending the whole thing.
    - drivebyacct2 15y ago

chuckywhat 15y ago

6 mo. is ridiculous but I roll my eyes @ GPL lawsuit.

saurik 15y ago

It is actually worse than that, as Apple has /never/ been in compliance with this license: I want the code to WAK*. It is simply not possible to compile a copy of iOS WebCore with the incomplete code that Apple has chosen to provide.