4 ms·

Why is it "not very nice" to GPL a fork of a BSD-licensed project? If an author believes in their permissive license, they shouldn't complain about how their c

Why is it "not very nice" to GPL a fork of a BSD-licensed project? If an author believes in their permissive license, they shouldn't complain about how their code is used. Edit: fixed a typo.

xenophonf 12y ago
Because the authors may intend to permit their code to be combined into some proprietary code base (which is to say that their idea of what constitutes permissiveness differs from yours).
- dllthomas 12y ago
  The thrust of the question is why it's reasonable for them to not consider a GPL project either another instance of "some proprietary code base" or something better. I think there are two answers. One is potentially ratios of old code to new code. But I think a bigger one is the threat to take "the community" with the code. Forks typically involve drama.
- _delirium 12y ago
  Isn't the intent of the BSD license specifically to refrain from dictating what licenses downstream users may add to their derived works? If you're okay with a downstream user making a fully "all rights reserved" proprietary product incorporating your code, I don't see how you could be against that same downstream user open-sourcing the resulting product under the GPL. In what sense would it be more free for them to keep it fully proprietary and not release it under the GPL? I can see an argument that BSD-licensing any derived works so they can go back to the original project under the original license is the friendly thing to do. But then you would frown at both GPL and proprietary downstream licensees, since neither one is doing the friendly thing (in this definition of "friendly") and BSD-licensing their contributions.
  - logn 12y ago
    While I agree with you, one could argue that developers of BSD works are ok with proprietary use but would rather not see an open source fork that divides the community. And the fork would not be available to them for further proprietary commercial use.
- quadrangle 12y ago
  The authors intending to make proprietary derivatives is itself not very nice.

Why is it "not very nice" to GPL a fork of a BSD-licensed project? If an author believes in their permissive license, they shouldn't complain about how their code is used. Edit: fixed a typo.

xenophonf 12y ago

Because the authors may intend to permit their code to be combined into some proprietary code base (which is to say that their idea of what constitutes permissiveness differs from yours).

dllthomas 12y ago
The thrust of the question is why it's reasonable for them to not consider a GPL project either another instance of "some proprietary code base" or something better. I think there are two answers. One is potentially ratios of old code to new code. But I think a bigger one is the threat to take "the community" with the code. Forks typically involve drama.
_delirium 12y ago
Isn't the intent of the BSD license specifically to refrain from dictating what licenses downstream users may add to their derived works? If you're okay with a downstream user making a fully "all rights reserved" proprietary product incorporating your code, I don't see how you could be against that same downstream user open-sourcing the resulting product under the GPL. In what sense would it be more free for them to keep it fully proprietary and not release it under the GPL? I can see an argument that BSD-licensing any derived works so they can go back to the original project under the original license is the friendly thing to do. But then you would frown at both GPL and proprietary downstream licensees, since neither one is doing the friendly thing (in this definition of "friendly") and BSD-licensing their contributions.
- logn 12y ago
  While I agree with you, one could argue that developers of BSD works are ok with proprietary use but would rather not see an open source fork that divides the community. And the fork would not be available to them for further proprietary commercial use.
quadrangle 12y ago
The authors intending to make proprietary derivatives is itself not very nice.