10 ms·

Sounds a bit like a modern, open approach to the problems that were solved by QNX. Excited to see how it evolves!

by jpm_sd 6y ago

Animats 6y ago
Not really open. If you submit code, you grant a license to Google to use it in non-proprietary code.[1] So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones. Like they did to Android with Google Play Services. [1] https://cla.developers.google.com/about/google-individual https://cla.developers.google.com/about/google-individual
- rstat1 6y ago
  Google Play Services was never open. You can however still submit changes to the actual OS though. People said the same thing about Android in its early days. It was wrong then, still wrong now, and will likely be just as wrong in the future.
  - kick 6y ago
    'Animats didn't claim they were ever open. His claim was more along the lines of: Google Play Services has over time subsumed more and more of core functionality, enough to stop the creation of clones. Which is true.
    - joshuamorton 6y ago
      That's not what he claimed. He claimed that 1. Code submitted by third parties to android 2. was moved into Google Play Services 3. And this was possible only due to the CLA. This isn't true for a couple of reasons. 2 is unsubstantiated (it's possible this is true, but I don't think it is). Functionality certainly moved, but I don't think there's reason to believe that code was copied. 3 just isn't true. Android is Apache licensed, so code in android can be reused in proprietary code without a CLA. What you can't do is relicense Android without a CLA. Another user mentions that the Fuschia CLA doesn't allow relicensing anyway, but I'm not an expert and don't have knowledge of that.
    - smnrchrds 6y ago
      Once upon a time, Android had a mail client that was part of the open source components. There was also GMail app that was closed source. Then a couple of versions later, the open source email app was discontinued and its functionality was incorporated into GMail. And the same thing has happened to many more apps and functionalities.
      - snazz 6y ago
        Part of that has more to do with the fact that AOSP is not used nearly as much and updating the default AOSP apps is not a good use of time for Google. The AOSP browser was never [edit: not recently] competitive with Chrome and the AOSP mail app was never [edit: not recently] competitive with Gmail.
        nradov 6y ago
        Yes if no one puts time into updating the default AOSP apps then they will stop being competitive. That seems like a tautology.
        kllrnohj 6y ago
        > The AOSP browser was never competitive with Chrome That's really not true, and not how it worked. Chrome was very late to the mobile game (first released 2012, a year after Android 4.0 / ICS was released) and its first few attempts on Android sucked. It was incredibly slow & laggy when it first finally came to Android. It's obviously not a good use of resources to make two webkit-based browsers both targeting the same market, but it was a complete swap out from one to the other over a relatively short time-frame. It's not like the mail vs. gmail situation where it was actually two "competing" apps for quite a long while.
      - zozbot234 6y ago
        The F-Droid store provides compelling alternatives to essentially all of the old AOSP apps. (LineageOS also maintains varieties of them.) The one component where there's been a real issue for FLOSS apps is support for centralized push notifications, and that's reliant on 3rd-party services so "open" is not a very meaningful characterization anyway.
- 101404 6y ago
  So basically you'd work for free for one of the wealthiest companies. That's f'ed up.
  - cycloptic 6y ago
    It's not because you're also asking the same of them. If you're submitting code upstream, you're essentially asking the maintainers to perform code review and start maintaining your contributions, for free.
    - 101404 6y ago
      You're comment makes no sense.
      - 101404 6y ago
        *your
  - plerpin 6y ago
    Uh, that's how the BSD and Apache licenses work.
- wmf 6y ago
  All permissively-licensed (MIT/BSD/Apache) code has that property. If you contribute to BSD anyone can create a proprietary derivative.
- mbrukman 6y ago
  Disclosure: I work at Google (but not on Fuchsia), and I contribute quite a bit to open-source projects. Disclaimer: I'm not a lawyer, this is not legal advice, etc. I'm not sure what you mean by "you grant a license to Google to use it in non-proprietary code" — was that a typo and did you mean "proprietary"? In any case, Apache/BSD/MIT licensed code can already be used in proprietary code, the CLA does not change that. The Google ICLA you cited [1] is basically the same as the ASF ICLA [2]; the gist is that you retain copyright of your contributions, you're not giving up your copyright — i.e., it's a copyright license, not a copyright assignment (as some other CLAs are). And, naturally, anyone can fork it if they wish, or distribute proprietary, non-open-source versions of an Apache/BSD/MIT-licensed project, subject to appropriate attributions, if required, by the relevant licenses. However, neither you (nor Google) can claim copyright over the entire project, because the copyrights are held by the relevant contributors. Changing the license for the entire project requires agreement from all copyright holders — for example, see what LLVM had to do when they chose to add a clause to their license [3]. [1] https://cla.developers.google.com/about/google-individual https://cla.developers.google.com/about/google-individual [2] https://www.apache.org/licenses/icla.pdf https://www.apache.org/licenses/icla.pdf [3] https://llvm.org/foundation/relicensing/ https://llvm.org/foundation/relicensing/
  - ColanR 6y ago
    >> If you submit code, you grant a license to Google to use it in non-proprietary [sic, I assume] code. > it's a copyright license, not a copyright assignment >> So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones. > you're welcome to fork it if you wish, or distribute proprietary, non-open-source versions of the code It sounds like you're agreeing completely with everything the parent said.
    - mbrukman 6y ago
      Sorry for not making it more clear; I was responding to the statement: > Not really open. If you submit code, you grant a license to Google to use it in non-proprietary code.[1] So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones. The CLA does not change anything about the license, and does not prevent or make it possible (or easier) to make proprietary versions of the software (or your contributions) — all those conditions are in the license itself, the CLA does not override or amend any terms of the license. In other words, you can make the same argument about any Apache, BSD, or MIT software, while the poster is claiming that it's the CLA that enables making future releases proprietary, which is why I pointed out that the Google CLA is the same as the ASF CLA. If the argument is that Apache/BSD/MIT licenses are "not really open" because they allow incorporating them into proprietary software without releasing code, that's a different argument and is really a distinction between the "permissive" licenses like Apache/BSD/MIT and the "copyleft" licenses like GPL, but again, that has nothing to do with the CLA.
- magicalist 6y ago
  > Not really open Not many people still consider non-copyleft open source licenses not "open" (even the FSF disagrees on the need for copyleft to be considered libre) and MIT, BSD, and Apache 2.0 in particular are widely considered proper open source, so I think you just mean "Not really copyleft", which, sure.
- on_and_off 6y ago
  agree on the issue but I don't think that Play Services is a great exemple. It has always been closed source and can be replaced in any AOSP build. Google has no obligation to provide open sources apps and services on top of AOSP.
CyberDildonics 6y ago
Lets hope. I think QNX programs were often made out of smaller processes. It would be interesting and cool if this is the case with Fuchia.

Sounds a bit like a modern, open approach to the problems that were solved by QNX. Excited to see how it evolves!

by jpm_sd 6y ago

Sounds a bit like a modern, open approach to the problems that were solved by QNX. Excited to see how it evolves!

Not really open. If you submit code, you grant a license to Google to use it in non-proprietary code.[1] So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones. Like they did to Android with Google Play Services. [1] https://cla.developers.google.com/about/google-individual https://cla.developers.google.com/about/google-individual

rstat1 6y ago
Google Play Services was never open. You can however still submit changes to the actual OS though. People said the same thing about Android in its early days. It was wrong then, still wrong now, and will likely be just as wrong in the future.
- kick 6y ago
  'Animats didn't claim they were ever open. His claim was more along the lines of: Google Play Services has over time subsumed more and more of core functionality, enough to stop the creation of clones. Which is true.
  - joshuamorton 6y ago
    That's not what he claimed. He claimed that 1. Code submitted by third parties to android 2. was moved into Google Play Services 3. And this was possible only due to the CLA. This isn't true for a couple of reasons. 2 is unsubstantiated (it's possible this is true, but I don't think it is). Functionality certainly moved, but I don't think there's reason to believe that code was copied. 3 just isn't true. Android is Apache licensed, so code in android can be reused in proprietary code without a CLA. What you can't do is relicense Android without a CLA. Another user mentions that the Fuschia CLA doesn't allow relicensing anyway, but I'm not an expert and don't have knowledge of that.
  - smnrchrds 6y ago
    Once upon a time, Android had a mail client that was part of the open source components. There was also GMail app that was closed source. Then a couple of versions later, the open source email app was discontinued and its functionality was incorporated into GMail. And the same thing has happened to many more apps and functionalities.
    - snazz 6y ago
      Part of that has more to do with the fact that AOSP is not used nearly as much and updating the default AOSP apps is not a good use of time for Google. The AOSP browser was never [edit: not recently] competitive with Chrome and the AOSP mail app was never [edit: not recently] competitive with Gmail.
      - nradov 6y ago
        Yes if no one puts time into updating the default AOSP apps then they will stop being competitive. That seems like a tautology.
      - kllrnohj 6y ago
        > The AOSP browser was never competitive with Chrome That's really not true, and not how it worked. Chrome was very late to the mobile game (first released 2012, a year after Android 4.0 / ICS was released) and its first few attempts on Android sucked. It was incredibly slow & laggy when it first finally came to Android. It's obviously not a good use of resources to make two webkit-based browsers both targeting the same market, but it was a complete swap out from one to the other over a relatively short time-frame. It's not like the mail vs. gmail situation where it was actually two "competing" apps for quite a long while.
    - zozbot234 6y ago
      The F-Droid store provides compelling alternatives to essentially all of the old AOSP apps. (LineageOS also maintains varieties of them.) The one component where there's been a real issue for FLOSS apps is support for centralized push notifications, and that's reliant on 3rd-party services so "open" is not a very meaningful characterization anyway.
101404 6y ago
So basically you'd work for free for one of the wealthiest companies. That's f'ed up.
- cycloptic 6y ago
  It's not because you're also asking the same of them. If you're submitting code upstream, you're essentially asking the maintainers to perform code review and start maintaining your contributions, for free.
  - 101404 6y ago
    You're comment makes no sense.
    - 101404 6y ago
      *your
- plerpin 6y ago
  Uh, that's how the BSD and Apache licenses work.
wmf 6y ago
All permissively-licensed (MIT/BSD/Apache) code has that property. If you contribute to BSD anyone can create a proprietary derivative.
mbrukman 6y ago
Disclosure: I work at Google (but not on Fuchsia), and I contribute quite a bit to open-source projects. Disclaimer: I'm not a lawyer, this is not legal advice, etc. I'm not sure what you mean by "you grant a license to Google to use it in non-proprietary code" — was that a typo and did you mean "proprietary"? In any case, Apache/BSD/MIT licensed code can already be used in proprietary code, the CLA does not change that. The Google ICLA you cited [1] is basically the same as the ASF ICLA [2]; the gist is that you retain copyright of your contributions, you're not giving up your copyright — i.e., it's a copyright license, not a copyright assignment (as some other CLAs are). And, naturally, anyone can fork it if they wish, or distribute proprietary, non-open-source versions of an Apache/BSD/MIT-licensed project, subject to appropriate attributions, if required, by the relevant licenses. However, neither you (nor Google) can claim copyright over the entire project, because the copyrights are held by the relevant contributors. Changing the license for the entire project requires agreement from all copyright holders — for example, see what LLVM had to do when they chose to add a clause to their license [3]. [1] https://cla.developers.google.com/about/google-individual https://cla.developers.google.com/about/google-individual [2] https://www.apache.org/licenses/icla.pdf https://www.apache.org/licenses/icla.pdf [3] https://llvm.org/foundation/relicensing/ https://llvm.org/foundation/relicensing/
- ColanR 6y ago
  >> If you submit code, you grant a license to Google to use it in non-proprietary [sic, I assume] code. > it's a copyright license, not a copyright assignment >> So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones. > you're welcome to fork it if you wish, or distribute proprietary, non-open-source versions of the code It sounds like you're agreeing completely with everything the parent said.
  - mbrukman 6y ago
    Sorry for not making it more clear; I was responding to the statement: > Not really open. If you submit code, you grant a license to Google to use it in non-proprietary code.[1] So, at some point, once users and developers are locked in, Google can make later versions closed and proprietary enough to stop clones. The CLA does not change anything about the license, and does not prevent or make it possible (or easier) to make proprietary versions of the software (or your contributions) — all those conditions are in the license itself, the CLA does not override or amend any terms of the license. In other words, you can make the same argument about any Apache, BSD, or MIT software, while the poster is claiming that it's the CLA that enables making future releases proprietary, which is why I pointed out that the Google CLA is the same as the ASF CLA. If the argument is that Apache/BSD/MIT licenses are "not really open" because they allow incorporating them into proprietary software without releasing code, that's a different argument and is really a distinction between the "permissive" licenses like Apache/BSD/MIT and the "copyleft" licenses like GPL, but again, that has nothing to do with the CLA.
magicalist 6y ago
> Not really open Not many people still consider non-copyleft open source licenses not "open" (even the FSF disagrees on the need for copyleft to be considered libre) and MIT, BSD, and Apache 2.0 in particular are widely considered proper open source, so I think you just mean "Not really copyleft", which, sure.
on_and_off 6y ago
agree on the issue but I don't think that Play Services is a great exemple. It has always been closed source and can be replaced in any AOSP build. Google has no obligation to provide open sources apps and services on top of AOSP.

CyberDildonics 6y ago

Lets hope. I think QNX programs were often made out of smaller processes. It would be interesting and cool if this is the case with Fuchia.