5 ms·

The proprietary "forks" are often not distributed as source, they're either internal forks, or simply part of a larger product. The difference is that proprieta

The proprietary "forks" are often not distributed as source, they're either internal forks, or simply part of a larger product. The difference is that proprietary forks of permissive code is often kept in sync with upstream and you only ever learn of its existence when they decide to contribute back patches. They typically have the courtesy of making those available under the original license terms for everyone to benefit from.

cyphar 10y ago
> The difference is that proprietary forks of permissive code is often kept in sync and you only learn of its existence if they decide to contribute back patches. They typically have the generosity of making those available under the original permissive licence. This sounds like cherry-picking to me. "If they decide to contribute back patches" is something that is not up to you -- and the same logic applies to copyleft forks just as much as it applies to proprietary forks (the quotes are not necessary, proprietary forks of lax licensed software are forks like any other kind of fork). Just because someone has used a license that gives users freedom should not be construed as it being a contribution to you. > They typically have the generosity of making those available under the original permissive licence. They also typically have the "generosity" of not providing source code to users, meaning that the users have no freedom when using the software. But hey, at least you got some marginally useful patches that probably aren't all that great. Yay. Also, please note that some projects do dual-license their changes. I don't understand why you're so salty on this topic.
icebraining 10y ago
Internal forks are not subject to the GPL requirements anyway, so that can't be an argument against it.
- cyphar 10y ago
  In fact, licenses that do not permit private copies of the modified software are not considered free software according to the FSF[1] (which I agree with). [1]: https://www.gnu.org/licenses/license-list.en.html#NonFreeSoftwareLicenses https://www.gnu.org/licenses/license-list.en.html#NonFreeSof...

cyphar 10y ago

> The difference is that proprietary forks of permissive code is often kept in sync and you only learn of its existence if they decide to contribute back patches. They typically have the generosity of making those available under the original permissive licence. This sounds like cherry-picking to me. "If they decide to contribute back patches" is something that is not up to you -- and the same logic applies to copyleft forks just as much as it applies to proprietary forks (the quotes are not necessary, proprietary forks of lax licensed software are forks like any other kind of fork). Just because someone has used a license that gives users freedom should not be construed as it being a contribution to you. > They typically have the generosity of making those available under the original permissive licence. They also typically have the "generosity" of not providing source code to users, meaning that the users have no freedom when using the software. But hey, at least you got some marginally useful patches that probably aren't all that great. Yay. Also, please note that some projects do dual-license their changes. I don't understand why you're so salty on this topic.

icebraining 10y ago

Internal forks are not subject to the GPL requirements anyway, so that can't be an argument against it.

cyphar 10y ago
In fact, licenses that do not permit private copies of the modified software are not considered free software according to the FSF[1] (which I agree with). [1]: https://www.gnu.org/licenses/license-list.en.html#NonFreeSoftwareLicenses https://www.gnu.org/licenses/license-list.en.html#NonFreeSof...