3 ms·

> they can manage open source perfectly fine It's easy to "manage open source perfectly fine" if you just open-source less of your code, or release it without

> they can manage open source perfectly fine It's easy to "manage open source perfectly fine" if you just open-source less of your code, or release it without any patent grant at all. I'm not sure how much credit should be given for those non-efforts, though.

froweway 9y ago
No explicit patent grant has been functionally sufficient for decades so not sure what you're saying there. What about Google and Microsoft's FOSS contributions do you consider "non-efforts"?
- notacoward 9y ago
  > What about Google and Microsoft's FOSS contributions do you consider "non-efforts"? It's not the FOSS contributions that are non-efforts. It's the things that were never released at all. What percentage of engineers at Microsoft work on code that has been or ever will be open source? How is releasing 10% of your code with no patent grant better than releasing 20% of your code with a conditional one? Also, "no explicit patent grant has been sufficient" is no excuse for bashing a grant that has exactly that as its worst case. Any non-zero protection is still greater than zero. By way of analogy, would you yell at people on your team who you felt weren't working hard enough, then give a big pat on the back to one who played video games the whole time? Well, maybe you would, but an objective observer might think it seemed unfair. They might even wonder about what other motivations might be involved.
  - rhencke 9y ago
    So, until all (or some large quantity) of software produced by an organization is open source, any software produced by an organization that is open source should not be considered worthwhile efforts?
    - notacoward 9y ago
      Not what I said at all. I'm just saying they shouldn't get more credit for a non-release than for a release. Apparently the HN attitude is: * Release lots of software with a conditional patent grant: awful. * Release lots of software with no grant (e.g. BSD): OK. * Release very little software, and that under the no-grant license (e.g. MS): you rock. Sorry, but that's completely f-ing backward. It's literally impossible to get to there from open-source principles, so what what principles are people starting from?
      - thingerr 9y ago
        Though untested, many think the BSD and similar licenses provide an implicit grant that can't be strategically revoked. Future case law to the contrary would make a lot of open software unusable or at least a legal minefield. Providing an explicit grant with explicit conditions of termination makes it easy for Facebook to selectively restrict use of anything that might be under patent in ANY of their projects. At best it's not in the spirit of FOSS and at worst it asymmetrically weaponizes open licenses. It's true that, practically, most companies won't ever have to worry about Facebook infringing their patents, but I think it's garbage on principle to reserve first-strike litigation while making it impossible for someone else to do the same and use software you've made available under a supposedly permissive license.
        notacoward 9y ago
        > Though untested That phrase alone should swing the "legal risk" argument the other way that how it's being portrayed here.
bsimpson 9y ago
I've never worked at Facebook (so I can't compare directly), but I've never met a Googler who shied away from open sourcing code for legal reasons; no one ever said "I would open source this, but only if I could attach a patent grant to it." There are plenty of reasons that someone might choose not to open source code (e.g. they like working on only internal infrastructure or don't want to bother with external maintenance), but I don't think the patent grant has anything to do with why a developer at {Google, Facebook, Microsoft} would choose to open source (or not) a library.
- notacoward 9y ago
  I've never worked at Google either, but I have worked at other companies where people got in serious trouble for trying to open-source something that was associated with the company's IP. It's important to remember here that copyrights and patents are separate. A company might be very permissive when it comes to copyright (though woe betide the engineer who tries to open-source something related to trade secret IP) while still aggressively protecting their patents. Have you seen a Googler actually try to attach an explicit patent license to Google code? After Oracle, I'd be pretty surprised. The BSD/MIT non-license is the real stealth option here. It precludes no action by the patent holder, under any conditions, so of course your local legal department would have no problem with it.
  - bsimpson 9y ago
    Google defaults to Apache. The whole process is documented here (https://opensource.google.com/docs/releasing/approval/ https://opensource.google.com/docs/releasing/approval/) but here's the tl;dr: 1. Googler tells their director that they want to open source some code; the director approves it. 2. Googler tells the Open Source + Patents Office that they're releasing code. The OSPO says to use Apache as the license unless you have a good reason not to, and does a sanity check to ensure that the license information is in all the right places in the repo. 3. Googler posts the repo to GitHub. Googlers don't usually even think about licenses. The OSPO says to use Apache, so that's what we use.
    - 9y ago

froweway 9y ago

No explicit patent grant has been functionally sufficient for decades so not sure what you're saying there. What about Google and Microsoft's FOSS contributions do you consider "non-efforts"?

notacoward 9y ago
> What about Google and Microsoft's FOSS contributions do you consider "non-efforts"? It's not the FOSS contributions that are non-efforts. It's the things that were never released at all. What percentage of engineers at Microsoft work on code that has been or ever will be open source? How is releasing 10% of your code with no patent grant better than releasing 20% of your code with a conditional one? Also, "no explicit patent grant has been sufficient" is no excuse for bashing a grant that has exactly that as its worst case. Any non-zero protection is still greater than zero. By way of analogy, would you yell at people on your team who you felt weren't working hard enough, then give a big pat on the back to one who played video games the whole time? Well, maybe you would, but an objective observer might think it seemed unfair. They might even wonder about what other motivations might be involved.
- rhencke 9y ago
  So, until all (or some large quantity) of software produced by an organization is open source, any software produced by an organization that is open source should not be considered worthwhile efforts?
  - notacoward 9y ago
    Not what I said at all. I'm just saying they shouldn't get more credit for a non-release than for a release. Apparently the HN attitude is: * Release lots of software with a conditional patent grant: awful. * Release lots of software with no grant (e.g. BSD): OK. * Release very little software, and that under the no-grant license (e.g. MS): you rock. Sorry, but that's completely f-ing backward. It's literally impossible to get to there from open-source principles, so what what principles are people starting from?
    - thingerr 9y ago
      Though untested, many think the BSD and similar licenses provide an implicit grant that can't be strategically revoked. Future case law to the contrary would make a lot of open software unusable or at least a legal minefield. Providing an explicit grant with explicit conditions of termination makes it easy for Facebook to selectively restrict use of anything that might be under patent in ANY of their projects. At best it's not in the spirit of FOSS and at worst it asymmetrically weaponizes open licenses. It's true that, practically, most companies won't ever have to worry about Facebook infringing their patents, but I think it's garbage on principle to reserve first-strike litigation while making it impossible for someone else to do the same and use software you've made available under a supposedly permissive license.
      - notacoward 9y ago
        > Though untested That phrase alone should swing the "legal risk" argument the other way that how it's being portrayed here.

bsimpson 9y ago

I've never worked at Facebook (so I can't compare directly), but I've never met a Googler who shied away from open sourcing code for legal reasons; no one ever said "I would open source this, but only if I could attach a patent grant to it." There are plenty of reasons that someone might choose not to open source code (e.g. they like working on only internal infrastructure or don't want to bother with external maintenance), but I don't think the patent grant has anything to do with why a developer at {Google, Facebook, Microsoft} would choose to open source (or not) a library.

notacoward 9y ago
I've never worked at Google either, but I have worked at other companies where people got in serious trouble for trying to open-source something that was associated with the company's IP. It's important to remember here that copyrights and patents are separate. A company might be very permissive when it comes to copyright (though woe betide the engineer who tries to open-source something related to trade secret IP) while still aggressively protecting their patents. Have you seen a Googler actually try to attach an explicit patent license to Google code? After Oracle, I'd be pretty surprised. The BSD/MIT non-license is the real stealth option here. It precludes no action by the patent holder, under any conditions, so of course your local legal department would have no problem with it.
- bsimpson 9y ago
  Google defaults to Apache. The whole process is documented here (https://opensource.google.com/docs/releasing/approval/ https://opensource.google.com/docs/releasing/approval/) but here's the tl;dr: 1. Googler tells their director that they want to open source some code; the director approves it. 2. Googler tells the Open Source + Patents Office that they're releasing code. The OSPO says to use Apache as the license unless you have a good reason not to, and does a sanity check to ensure that the license information is in all the right places in the repo. 3. Googler posts the repo to GitHub. Googlers don't usually even think about licenses. The OSPO says to use Apache, so that's what we use.
  - 9y ago