The fundamental tension of "unprofitability" was there from the very start, as real security is directly at odds with traditional business models. The goal of the businessman is to become a middleman, but security precludes having a man-in-the-middle!
Which is why these projects overwhelmingly flame out. The engineer figures there can't be much harm from a business type trying to design a business around their project, as they assume the project philosophy will remain unaffected. Meanwhile the business type is excited about having a new in-demand raw material to which they can add inefficiency to derive a revenue stream. The engineer figures they own the code, so whatever games the business monkey plays, they can only end up back in the same spot. Meanwhile the business type is busy conjuring and documenting bureaucracy like corporate structure and implicit contracts with which to seize power over the raw resource (the project) if the coder doesn't submit to his "real world" supervision.
It's likely that the engineer could prevail and end up owning the code, but only after an expensive and draining legal battle - it's simply easier to move on to productive non-zero-sum things. Meanwhile the business type is all too willing to fight said battle, as investing real money into paperwork games was basically their entire operation all along.
IMHO the real shame in this case was licensing the code base something other than GPL. GPL would have made continued use unambiguous even in the presence of ambiguous ownership.
> IMHO the real shame in this case was licensing the code base something other than GPL. GPL would have made continued use unambiguous even in the presence of ambiguous ownership.
I don't understand how GPLv2 or GPLv3 or BSDL and many (any, AFAICT) FOSS license would not have done the same. The problem is CC non-commercial. Its actually an anti competitive license. Imagine RedHat using that for all their software. Oracle not allowed to compete?
Yes, the non-commercial license is the bigger problem as it's an ambiguous club that a hostile copyright holder could FUDgeon any sizable community with.
I had been thinking that with BSD, a gone-hostile company could make an argument that more recent changes were not actually intended to be released under BSD, whereas with GPL we know they would have had to have stuck with the license to build on top. But that latter part isn't true if they're arguing that they're the copyright holder.
edit: Actually what I was thinking is true IF there is an additional contributor who's patch got accepted into the main tree. But in this case, given that the ostensible goal of CC non-commercial was so that the code could be dual licensed, we'd expect any such contributor to have been shuffled into copyright assignment.
Which is why these projects overwhelmingly flame out. The engineer figures there can't be much harm from a business type trying to design a business around their project, as they assume the project philosophy will remain unaffected. Meanwhile the business type is excited about having a new in-demand raw material to which they can add inefficiency to derive a revenue stream. The engineer figures they own the code, so whatever games the business monkey plays, they can only end up back in the same spot. Meanwhile the business type is busy conjuring and documenting bureaucracy like corporate structure and implicit contracts with which to seize power over the raw resource (the project) if the coder doesn't submit to his "real world" supervision.
It's likely that the engineer could prevail and end up owning the code, but only after an expensive and draining legal battle - it's simply easier to move on to productive non-zero-sum things. Meanwhile the business type is all too willing to fight said battle, as investing real money into paperwork games was basically their entire operation all along.
IMHO the real shame in this case was licensing the code base something other than GPL. GPL would have made continued use unambiguous even in the presence of ambiguous ownership.