4 ms·
Reading the google groups discussion raises some interesting questions: What prevents other open source projects from being taken down with a "management did n
by lazyjeff 14y ago
Reading the google groups discussion raises some interesting questions:
What prevents other open source projects from being taken down with a "management did not authorize this" notice? For example, what prevents Twitter from saying Bootstrap was released by a rogue employee, invalidating the open source license and rendering millions of websites in copyright violation?
What happens to the commits by other authors to the source tree? Do they own the copyright to their commits, even if they modify invalid open source code?
How does the open source community react when this happen? Do they fork and pretend the source code is legit open source? (from reading the discussion, it seems like many developers have already forked the code and encouraged others to work off it)
Perhaps there are reasonable solutions to these, but I'm interested to see how this story unfolds, since it may affect how people think of companies open sourcing code in the future.
- foobar2k 14y agoThat's also what was most interesting to me. This smells like the whole Twitter Bootstrap thing a few weeks ago, but the bootstrap guys had enough pull to take the brand with them after they left Twitter.
- dietrichepp 14y agoWell, if it were a contract it might be covered by the "Apparent Authority" doctrine. But I know jack about this.
- bentoner 14y agoWhat prevents other open source projects from being taken down with a "management did not authorize this" notice? Estoppel
- pygy_ 14y agoFor the non-enlightened (as I was 1 minute ago): Estoppel in English law is a doctrine that may be used in certain situations to prevent a person from relying upon certain rights, or upon a set of facts (e.g. words said or actions performed) which is different from an earlier set of facts. Estoppel could arise in a situation where a creditor informs a debtor that a debt is forgiven, but then later insists upon repayment. In a case such as this, the creditor may be estopped from relying on their legal right to repayment, as the creditor has represented that he no longer treats the debt as extant. A landlord may tell his tenant that he is not required to pay rent for a period of time ("you don't need to pay rent until the war is over"). After the war is over, the landlord would be "estopped" from claiming rents during the war period. Estoppel is often important in insurance law, where some actions by the insurer or the agent estop the insurer from denying a claim. http://en.wikipedia.org/wiki/Estoppel_in_English_law http://en.wikipedia.org/wiki/Estoppel_in_English_law
- jarrett 14y agoIt's highly questionable whether a company has the legal authority to retroactively revoke an open source license. The legal doctrine of promissory estoppel is generally considered to protect open source licensees. If you license something for free, and people come to rely on that free licensing, they generally have a right to keep using it, even if you change your mind and try to revoke it later. You can, however, stop licensing the software to new parties. Novus seems to be trying to get around this by claiming that the license was never valid to begin with, because it was issued by a rogue employee. However, I would argue that the doctrine of apparent authority applies here. That is, to a potential licensee, there was no reason to believe that the open source licensing was anything but company-sanctioned. (The rules for apparent authority are actually a bit more nuanced than that, but the main point is the same.) Thus, even if the employee did indeed act without authorization, I think Novus would still be bound by the license. Novus seems to be on shaky legal ground, and I find its cease-and-desist questionable. Unfortunately, it would appear that the recipients of the cease-and-desist opted to comply rather than risk a fight. So the scary thing is not that companies can arbitrarily revoke an open source license--in fact, they can't. Rather, it's that a letter containing vague legal threats can have such a strong chilling effect.
- jakejake 14y agoIt is a conundrum. If I were to hack into Microsoft and obtain the source to Windows 8, release it on github under the GPL - it seems highly unlikely that would be honored. Although if even one single person downloaded it under GPL then technically they should be able to distribute their own version under GPL. It seems like if the code is considered "stolen" there must be some legal common sense. I would also imagine the longer the code stays as open source, the less likely you'd be able to claim theft. If you immediately took it down claiming copyright that would be one thing. If you knowingly left it up for a year, though, that would certainly be a different situation.
- aptwebapps 14y ago"... If you knowingly left it up for a year, though, that would certainly be a different situation." It would be different but it would still be utterly unlike what jarrett describes.
- csense 14y agoI'm not a lawyer, but here are my best guesses: > What prevents other open source projects from being taken down with a "management did not authorize this" notice? Retracting an open-source product is a move without a lot of upside. What business goal is promoted by such a retraction? It seems like it will just generate controversy, tarnish the company's reputation, and lead to endless ownership fights with contributors. In addition, I suspect that major open-source projects usually actually do have the approval of people who have the authority to make that decision. > What happens to the commits by other authors to the source tree? Do they own the copyright to their commits, even if they modify invalid open source code? My understanding is that a contributor (or his employer) owns the copyright to his own patches when they are written. Larger open-source projects often require contributor agreements before they'll accept patches; the contributor must legally give the copyright to the project as a condition of their patch being incorporated into the official tree. If there's no contributor agreement in place, the patches continue to belong to the contributor. You can think of the pre-patch tree and the patch as two parent nodes of the patched version. Novus owns the pre-patch tree; the contributor owns the patch; the post-patch tree is a derivative work of both of them, and can only be distributed with permission of both owners. The contributor's patches may be useless without the parent tree to patch against. But if the contributors own the copyright to their patches, they can still use that copyright to forbid Novus from using or distributing the patched child tree. > How does the open source community react when this happen? Read the Google group and see. My feeling of how they should react is by the contributors banding together and telling Novus the following: We contributed patches to Novus based on the understanding that the patched software would be released publicly as open source. As soon as Novus became aware of the situation, it made a clear, unambiguous statement that Novus is not, and never was, willing to agree to these terms. Therefore, since Novus does not accept the terms under which we gave them the patches, we revoke all permission for Novus to use these patches, or any version of the software which includes them. If the contributors do this, and Novus is using the project internally, then Novus will have to either (1) back down and say that they're okay with open-source after all, (2) spend engineering resources on proprietary reimplementation of the features the community gave them for free, or (3) live without those features. Only option (1) lacks significant cost and/or risk from Novus's point of view. > Perhaps there are reasonable solutions to these This suggests that the more contributors an open-source project has, the stronger it is against any one person or company claiming ownership in this way. The remaining contributors can band together in response and pull out their patches, leaving the proprietary project at a feature-poor, ancient version -- especially compared to people's still-fresh memories of the open-source version -- if not making it entirely nonfunctional. The contributors could even attempt to make their patches useful again with an independent implementation which presents the same interface as Novus's now-proprietary code. Or they could toss their patches and rewrite the library from scratch. It would presumably take much less effort because, while they can't re-use the proprietary code from the Novus version, it should be okay to re-use the design decisions and API that may have been a big reason that the Novus version was so successful.