4 ms·

I find these first-party interop libraries from Microsoft really interesting, in light of the fact that Oracle v. Google is still ongoing. Depending on how tha

I find these first-party interop libraries from Microsoft really interesting, in light of the fact that Oracle v. Google is still ongoing. Depending on how that case finally comes back, I'd expect that could really affect Microsoft's strategy, here.

endianswap 11y ago
Can you elaborate what you mean? What risk is there to what Microsoft is doing?
- deleted 11y ago
  [deleted]
  - amlgsmsn 11y ago
    Surely FFMPEG being mostly LGPLv2 and some GPLv2 would have a bearing on the API reuse issue? Especially since they're open sourcing the code.
  - kyberias 11y ago
    I think you're mistaken. This project does not "implement and API written by someone else". They implement a Windows API interface (MediaStreamSource) that wraps the FFmpeg library so that it can be easily used in various Windows OSs.
- keeperofdakeys 11y ago
  If APIs are copywritable, then the GP2.1 license of ffmpeg would apply to this library, which is only licensed under the Apache license. This issue has popped up a number of times for Linux kernel modules, and at what point they are a derived work - https://lwn.net/Articles/13398/ https://lwn.net/Articles/13398/. Here is an email thread concerning this http://yarchive.net/comp/linux/gpl_modules.html http://yarchive.net/comp/linux/gpl_modules.html.
  - zaroth 11y ago
    The way I see it, this is an open source shim layer. I don't see any copyright issue whatsoever. Whoever chooses to use the shim is using ffmpeg anyway, so they are already exposed to the license in exactly the same way. This just makes it easier to use ffmpeg 'the right way' on various devices, if I understand correctly. If somehow MS can't make and open source clean compatibility layers for their own software, then that's a big problem.
  - zanny 11y ago
    ffmpeg is also distributed under LGPL, which would be necessary to link this library against it, otherwise the whole product would be GPL anyway.
  - cbd1984 11y ago
    > If APIs are copywritable Is that distinct from being copyrightable? I'm sure that if it becomes a big enough problem, the problem will be buried in lawsuits once Microsoft or IBM or similar stub their toes on it.
deleted 11y ago
[deleted]
magicalist 11y ago
> Depending on how that case finally comes back, I'd expect that could really affect Microsoft's strategy, here Remember that because there were originally patent claims in the suit, the appeal went to the Federal Circuit -- even though the patent claims were dropped -- not the Ninth Circuit where the district court is located. As a result, the Federal Circuit's ruling that APIs are not uncopyrightable is not precedent since it doesn't concern patents (the Federal Circuit's remit). Their reasoning might influence future rulings, but precedence-wise the ruling has no bearing on the future of copyright on APIs in the US. edit: the EFF has a little more detail: https://www.eff.org/deeplinks/2015/06/bad-news-supreme-court-refuses-review-oracle-v-google-api-copyright-decision https://www.eff.org/deeplinks/2015/06/bad-news-supreme-court... https://www.eff.org/deeplinks/2015/06/eff-stands-innovative-developers-wake-oracle-v-google https://www.eff.org/deeplinks/2015/06/eff-stands-innovative-...
stevehiehn 11y ago
Isn't this a wrapper lib? If its just calling public APIs I can't see a problem with that.

endianswap 11y ago

Can you elaborate what you mean? What risk is there to what Microsoft is doing?

deleted 11y ago
[deleted]
- amlgsmsn 11y ago
  Surely FFMPEG being mostly LGPLv2 and some GPLv2 would have a bearing on the API reuse issue? Especially since they're open sourcing the code.
- kyberias 11y ago
  I think you're mistaken. This project does not "implement and API written by someone else". They implement a Windows API interface (MediaStreamSource) that wraps the FFmpeg library so that it can be easily used in various Windows OSs.
keeperofdakeys 11y ago
If APIs are copywritable, then the GP2.1 license of ffmpeg would apply to this library, which is only licensed under the Apache license. This issue has popped up a number of times for Linux kernel modules, and at what point they are a derived work - https://lwn.net/Articles/13398/ https://lwn.net/Articles/13398/. Here is an email thread concerning this http://yarchive.net/comp/linux/gpl_modules.html http://yarchive.net/comp/linux/gpl_modules.html.
- zaroth 11y ago
  The way I see it, this is an open source shim layer. I don't see any copyright issue whatsoever. Whoever chooses to use the shim is using ffmpeg anyway, so they are already exposed to the license in exactly the same way. This just makes it easier to use ffmpeg 'the right way' on various devices, if I understand correctly. If somehow MS can't make and open source clean compatibility layers for their own software, then that's a big problem.
- zanny 11y ago
  ffmpeg is also distributed under LGPL, which would be necessary to link this library against it, otherwise the whole product would be GPL anyway.
- cbd1984 11y ago
  > If APIs are copywritable Is that distinct from being copyrightable? I'm sure that if it becomes a big enough problem, the problem will be buried in lawsuits once Microsoft or IBM or similar stub their toes on it.

deleted 11y ago

[deleted]

magicalist 11y ago

> Depending on how that case finally comes back, I'd expect that could really affect Microsoft's strategy, here Remember that because there were originally patent claims in the suit, the appeal went to the Federal Circuit -- even though the patent claims were dropped -- not the Ninth Circuit where the district court is located. As a result, the Federal Circuit's ruling that APIs are not uncopyrightable is not precedent since it doesn't concern patents (the Federal Circuit's remit). Their reasoning might influence future rulings, but precedence-wise the ruling has no bearing on the future of copyright on APIs in the US. edit: the EFF has a little more detail: https://www.eff.org/deeplinks/2015/06/bad-news-supreme-court-refuses-review-oracle-v-google-api-copyright-decision https://www.eff.org/deeplinks/2015/06/bad-news-supreme-court... https://www.eff.org/deeplinks/2015/06/eff-stands-innovative-developers-wake-oracle-v-google https://www.eff.org/deeplinks/2015/06/eff-stands-innovative-...

stevehiehn 11y ago

Isn't this a wrapper lib? If its just calling public APIs I can't see a problem with that.