News for hackers. Stuff that matters.
Re:Openrsync imported into the tree by derefr on Monday February 11, 2019 @09:18PM (#19140450)
Just because some forks of a project aren’t free, doesn’t mean that the project itself isn’t free. Especially if the project, like much of the e.g. MIT-licensed code in the world, is “done” for all intents and purposes and there is no reason at all to fork, proprietary or otherwise. (This comes up in the context of pure algorithms code a lot.)

Also, even if a project is copylefted, people can still just do... exactly what they did here. Which, while different in the weak sense of “avoiding copyright” or maybe “avoiding patents”, in the context of systems code like this almost always results in the same code on both sides anyway. If the choice is between either giving the proprietary developers your code to use, or making them re-implement exactly what you wrote without your copy for reference—with no option for “they don’t implement it at all”—then exactly what is the point of choosing the latter over the former?

Re:Openrsync imported into the tree by StavrosK on Monday February 11, 2019 @09:25PM (#19140475)
> Just because some forks of a project aren’t free, doesn’t mean that the project itself isn’t free

We aren't talking about non-free, we're talking about less-free.

> Just because some forks of a project aren’t free, doesn’t mean that the project itself isn’t free

No. The fact that there can be forks of the project that aren't open is what means that the project itself is less free than a project where all forks must be open.

> Especially if the project, like much of the e.g. MIT-licensed code in the world, is “done”

I don't consider this relevant to the argument at hand.

> then exactly what is the point of choosing the latter over the former?

Are you asking me what the point is of making something you don't want people to do hard for them vs making it easy?