3 ms·
Speaking as someone whose job it is to make sure these issues don't happen at a similar large company: No org can be 100% perfect all of the time, no matter w
by DannyBee 11y ago
Speaking as someone whose job it is to make sure these issues don't happen at a similar large company:
No org can be 100% perfect all of the time, no matter what processes they put in place. This looks like just a regular process failure.
I don't know what MS's are specifically, but we do everything from training new employees to verifying headers on outgoing releases (much to the annoyance of plenty of engineers who just want to release shit). I suspect they do the same.
Replacing headers with a standard header is pretty common.
However, we require code segregation to prevent the issue that happened here (IE all third party codes goes in third party directories with an associating LICENSE file describing the license/notices). That makes it easy to tell that someone screwed up when replacing headers.
Doing that is uncommon for most companies in practice (at least, when i surveyed my counterparts, most want to be doing it, but it doesn't really happen in practice with a > 50% rate due to not being closely involved enough with engineering and development practices to make it easy).
Most of them are happy to mix up third party code with their own code, or really bad at enforcing, and then when you go to release it, you don't notice things like what happened here.
Then again, we also tell new employees that we care about getting the notices and credits right not because we are worried about legal repercussions, but because of the golden rule (you'd be pissed if you ask for one small thing to use you code, and they can't be bothered to do it, and we don't want other people to feel that way about us).
I suspect that is pretty different too :)
But this seems like an object lesson in proving that. The people whose headers were changed feel aggrieved regardless of the fact that it was probably a simple process screwup / whatever. They don't care about that. They care that somebody decided they really wanted to use it, and that it saved them time/energy/helped/whatever, but despite that, when they made the choice to use it, they didn't seem to bother to put the one small thing the author asked of them on "the list of things to do before release"
(Regardless of whether this is actually the case).
- randomfool 11y agoWhen I had to go through this at Microsoft 5 years ago or so, the process was incredibly rigorous. Not only did we have to attest that all of our code was actually ours, but any duly integrated third-party code had to be vetted by a separate group to check that the third-party code contained no IP issues of it's own. The process was incredibly cumbersome and I'm somewhat glad they've scaled back a bit, but this is much too far.
- JoshTriplett 11y ago> Replacing headers with a standard header is pretty common. It shouldn't be. That's a fundamentally bad idea. It'd be reasonable to put a standard header at the top, immediately followed by "Based on (other project):" and the header for that project. But changing those headers is never OK.
- teamhappy 11y ago> It shouldn't be. That's a fundamentally bad idea. I don't think it's that bad of an idea. The MIT license says: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. What that means is anybody's guess. I'd say if you include one copy somewhere you're pretty much off the hook.
- teacup50 11y agoA source file is reasonably "a substantial portion"; in fact, a per-file license is applicable to that file, and does not cover other files.
- teamhappy 11y agoYup. I'm saying (guessing, really) the header doesn't necessarily have to stay in the file. You might as well put it somewhere else (e.g., docs, license file). --- Per-file licenses are different. The only one I looked at is MPL2 and IIRC it mentions the little note doesn't have to be in the file.
- JoshTriplett 11y agoIt's theoretically possible to comply with that license while moving the notice elsewhere, sure. However, for the purposes of avoiding situations like this, it's a bad idea. Much easier to just keep the license in the file exactly as it was, and add a header above it if needed.
- DannyBee 11y agoSorry, i think you misunderstand. I meant: "Replacing your internal copyright/whatever headers" with a standard license header before releasing. Not "erasing MIT license headers", which is completely wrong.
- jameshart 11y agoSeconded - and it looks like this was an acquired codebase, which was put together probably under engineering constraints very different from those that exist in house for Microsoft and other similar large dev shops. Still, would expect Microsoft to have gone over it with even more care than usual before open sourcing it as a result... Something for startups to keep in mind: if an IP acquisition by a large tech player is among your exit strategies, it behooves you to get your intellectual property ducks in a row, otherwise you're in for some awkward conversations with the acquiring company's legal team about the provenance of your codebase.