7 ms·

As I understand it, Microsoft has copied the Linux kernel system call interfaces and provided their own underlying implementation. Given that Microsoft support

• tacos 11y ago
  libc is LGPL. The "problem" you're highlighting here is EXACTLY opposite what the entire open source movement was designed to prevent. It couldn't be less of an issue.
  • atgreen 11y ago
    I'm not talking about libc. I'm talking about the kernel system call interfaces. They are defined by the kernel, not libc.
    • 1_player 11y ago
      IANAL but the kernel _code_ is GPL. Nothing forbids you to implement from scratch some functionality with a different license. As long as you don't copy and paste GPL code. A system call is a function entry point. The code executed when those functions are called is GPL licensed, and Microsoft wrote that from scratch.
      • atgreen 11y ago
        What I'm pointing out is the absurdity of the current state of law. It doesn't matter if Microsoft wrote all of the code from scratch, because according to them the definitions of the interfaces alone -- not code and not header files -- fall under copyright law.
        • tacos 11y ago
          Oracle's position is that their interfaces were Copyright (C) Oracle and to use them you had to abide by the license from Oracle. The whole point of open source licenses is to make it explicitly clear what you're allowed to do with the (yes, still copyrighted) material. They too provide strict terms and require you to honor the license.
      • bluejekyll 11y ago
        So what defines a derived work? If you implement from scratch, but in order to implement must look at the existing implementation in order to get it correct, then it's possible (probable?) that the new implementation is directly derived from the original implementation. It's not like Linux has a published license free spec. Unless they reverse engineered the system calls (possible but omg I think that would have been hard), then I'd be willing to bet that this could be easily considered derived work from the GPL.
        • atgreen 11y ago
          Well, that haven't been getting it correct, so they've got that going for them :) https://github.com/kernelslacker/trinity/pull/9 https://github.com/kernelslacker/trinity/pull/9
    • tacos 11y ago
      Those are effectively "header-only" and clearly documented as GPL. This is the basis of the entire movement!
• talles 11y ago
  This new Microsoft is open sourcing everything, maybe this own underlying implementation is on the way to be opened (maybe it's open somewhere already).
  • pekk 11y ago
    The new Microsoft is the same one that has been continuously and recently involved in copyright litigation. That didn't just go away overnight because they started a PR campaign.
    • deleted 11y ago
      [deleted]
  • xorblurb 11y ago
    This implementation is definitively a work derived from the NT kernel. If reimplementing and API propagates copyright, the only allowed licensing situation would be that MS releases the complete NT kernel under the GNU GPLv2 license. This is not going to happen. And this is not a too bad news, because this might give us leverage (by estoppel) if MS ever wants to litigate against free software on the theory that reimplementing API propagates copyright.
    • atgreen 11y ago
      But didn't they support Oracle's suit against Google's free software Dalvik on this very basis?
    • munin 11y ago
      is it a derived work of the NT kernel if it's contained in a separate loadable driver? my understanding is that's where this system call interface is contained, and as I understand it, you can have GPL NT drivers..?
      • xorblurb 11y ago
        It is not very probable that only public interfaces are used to implement this subsystem. Therefore, we can think that the special exception of the GPL that exclude major components of the OS would not apply. It also explicitly won't apply in the first place because MS is absolutely in the case: "that component itself (1) accompanies the executable (2)" (1) core NT kernel (2) Linux subsystem
• captainmuon 11y ago
  One could argue that the Linux syscall interface is closer to an ABI than an API, since you don't directly code against it. Don't know what implications that has in this context, though. One legal thing that I'm also wondering about is the "Linux" trademark. I thought the Linux Foundation kept close tabs on how you were allowed to use the trademark, and one requirement was that the Linux kernel was actually involved?
  • atgreen 11y ago
    I'd say that this part of the ABI is definitely something people code directly against - so there's really no distinction between API and ABI. The parts of the ABI you don't are things like the function calling conventions, type widths, etc.
  • annnnd 11y ago
    > One legal thing that I'm also wondering about is the "Linux" trademark. This probably explains why they never talk about Linux (at least I never saw it), but always about Ubuntu. I guess they have an agreement with Canonical.
    • dlandis 11y ago
      They mention "Linux" all the time. The feature is called Windows Subsystem for Linux (Beta).
      • dboreham 11y ago
        It is perfectly legal to mention someone else's trademark. Else we would have text in books like "He walked over to the bar and ordered a popular sugared caffeinated beverage made by a company headquartered in Atlanta". You just can't say something that might confuse the reader into thinking that you own the trademark.
        • simonh 11y ago
          But doesn't calling it "Windows Subsystem for Linux" imply that actual Linux is involved, or even included? Suppose I marketed a range of flavoured additives to put in you Coke and called it "Simon's Flavours for Coca Cola"?
• jjuel 11y ago
  Do you really think a multi billion dollar company like Microsoft wouldn't have their legal team all over this? Do you not think they would have researched this out. Discussed their implementation, and made sure everything they were doing was going to meet the GPL copyright standards?
  • atgreen 11y ago
    Sure, but that doesn't answer my question of 'why'.
    • spdustin 11y ago
      Because it's a faulty premise? There is no license violation, that's why a license violation isn't being discussed (your question).
  • osweiller 11y ago
    This same "multi billion dollar" company had an AI bot tweeting Nazi propaganda a week ago. They spectacularly failed in their xbox one release, having to completely retool and regroup. Their Windows Phone efforts remain a complete disaster and are now doomed to failure. The whole "they're a big company...don't you think they've thought of this!" argument (and its many "do you really think they'll lose?" variations) is always a fallacy. That doesn't make the argument about the copyright of ABIs valid, but at the same time the notion that Microsoft is big therefore they must be right is absurd.
    • dubcanada 11y ago
      Well if we really believe the bot was AI, then it wasn't Microsoft's bot. It was was it's own "artificial intelligence". But the rest of those have nothing to do with their legal team. They wouldn't implement a copy of another OS into this OS without making sure it was legal to do so.
      • fizzbatter 11y ago
        I think the AI comment was more to the fact that, they didn't safeguard against seemingly obvious outcomes - such as internet trolls trying to get the bot to say bad things. Many companies put no-go words during username creation, hitler, racist words, etc - so why didn't Microsoft? It might not have been simple to do, but still - hard not to see the outcome.
• curt15 11y ago
  MS doesn't seem to think that long-standing programming practices have suddenly been outlawed, as it is continuing to implement Apple's proprietary iOS frameworks in Project Islandwood (https://github.com/Microsoft/WinObjC https://github.com/Microsoft/WinObjC). The ruling on API copyrightability does not set precedent in any of the courts that normally hear copyright cases.
• rhinoceraptor 11y ago
  It would be pretty weird if, for example, the SFC used the same legal argument as Oracle.
• the_ancient 11y ago
  Yes but they gave money to the Linux Foundation so that makes it all betterer... /s
• pdabbadabba 11y ago
  Hmm. This is an interesting question. Who would the copyright holder be in this situation?
• dboreham 11y ago
  Perhaps it is an evil plot to get that ruling overturned by presenting an obviously beneficial counterexample?
• deleted 11y ago
  [deleted]
• hsitz 11y ago
  "As I understand it, Microsoft has copied the Linux kernel system call interfaces and provided their own underlying implementation." Not sure your understanding is correct, but in any case is that not precisely what Wine does on Linux when running Windows apps? Are you worried about Windows copyright violations with Wine? From Wine webpage, "Wine translates Windows API calls into POSIX calls on-the-fly. . ." [1] [1] https://www.winehq.org/ https://www.winehq.org/
  • koenigdavidmj 11y ago
    Windows doesn't provide consistency between versions at the interrupt level, and Wine doesn't provide any interface at that level. It's basically a COFF loader, and a bunch of regular userspace functions in DLLs that do everything. Linux, on the other hand, provides exactly that, and this wrapper makes it so that you can actually run "movl $1, %eax; movl $0, %ebx; int $0x80" and it will actually call the equivalent of exit(0).
    • ultramancool 11y ago
      Yes Windows does provide such a thing: http://j00ru.vexillium.org/ntapi/ http://j00ru.vexillium.org/ntapi/ Would be very interesting to see a Wine based on this concept instead...
      • koenigdavidmj 11y ago
        Of course it does at some point, but they're not meant to be used by the public, which is why: * you're linking to a URL with leetspeak in it, and not MSDN. * the codes change so frequently. * some of them disappear or are renumbered, even in service packs. If we wanted to do this for Wine, then it would also require emulation or something like OS X's Hypervisor.framework to catch system calls, which seems heavyhanded when we have working code already.
        • ultramancool 11y ago
          > If we wanted to do this for Wine, then it would also require emulation or something like OS X's Hypervisor.framework to catch system calls, which seems heavyhanded when we have working code already. It could also be done as a kernel level loadable module in the sort of style this Linux subsystem is being done, which is more what I was thinking. Changing a few numbers for every Windows service pack (really, not even necessary if you only support certain versions of ntdll for example) might not be so bad compare to re-implementing bug level compatibility with every Windows API. Calling Wine "working" in its current state is a bit of an overstatement.