6 ms·

You can't port fixes and new features unless you have a license to do so. That's true in all cases. If you only license you have is GPL, it doesn't allow you t

You can't port fixes and new features unless you have a license to do so. That's true in all cases. If you only license you have is GPL, it doesn't allow you to use those in a non-Free way, which I think is the point you are making, and I agree that's how it works. But that's a feature of GPL, not a bug. If you are a company producing code and trying to make a living from it, it's risky to release code as BSD/MIT unless you can afford to have someone clone it, close it and sell an improved version, passing it off as their own without giving you anything (like Microsoft did with the BSD TCP stack, and with NCSA mosaic for example). If you release as GPL however, that can't happen. It's much safer in that regard, and more socially considerate too, which is why it's the license of choice for most Linux distro vendors and other major open source vendors such as MySQL.

k_sze 10y ago
Yes, I do understand that people can take the BSD/MIT codebase and make a proprietary/closed source version. In that case you don't even see how the bug fixes are implemented in the new closed source version. So you are free to independently come up with the most obvious, efficient fix. My point is that with GPL, the implementation of the fixes/new features is right in front of you, you see it, yet you can't merge it into your GPL-incompatible codebase. Let's say we are talking about a security fix that turns out to be really easy. Somebody patched it in the GPL version, the fix turns out to be dead-easy and obvious, but now you can't use the same dead-easy and obvious fix in your own non-GPL version because it would be a violation of GPL. So now you have to come up with a suboptimal, ugly fix. In this case, GPL makes it painful for the original author of the proprietary version.
- sokoloff 10y ago
  Independent creation is a valid defense against copyright (as contrasted with patent law where it's not). If the fix is dead-easy and obvious ("change that = in a if statement to an ==", "add a check for foo", or "make this assignment a 1 instead of a 0"), the GPL license of patch A doesn't prevent anyone from creating (from scratch) patch B that does the same thing. For legal proof purposes, you probably want to ensure that the author of patch B hasn't seen the contents of patch A, though for something as obvious as the cases I present, I'm not even sure I'd worry about that.
  - lightdot 10y ago
    Such things might not even be copyrightable.
  - AstralStorm 10y ago
    Additionally, you can always require copyright reassignment for the main repository.
- martingxx 10y ago
  "My point is that with GPL, the implementation of the fixes/new features is right in front of you, you see it, yet you can't merge it into your GPL-incompatible codebase." 1) You almost certainly can as long as it's trivial, or you didn't look at the fix but did it independently based on a description of the bug. Legally, it all comes down to whether your work was a derived work or the original, not whether the result looks the same. 2) That's the idea anyway! Allowing someone to copy the work of others into a codebase that doesn't allow similar copying is exactly what the GNU GPL is designed to prevent. It's a risk you take if you decide to maintain a proprietary fork.
  - alexvoda 10y ago
    K_sze's point was that it is a lot harder to prove you have not seen and were not inspired by publicly available code than it is to prove you were not inspired by code that was kept secret. And while someone using free software in a non-free fork can release the changes as shared-source leading to the same problem, this has rarely happened.
- _delirium 10y ago
  Yes, I do understand that people can take the BSD/MIT codebase and make a proprietary/closed source version. In that case you don't even see how the bug fixes are implemented in the new closed source version. So you are free to independently come up with the most obvious, efficient fix. My point is that with GPL, the implementation of the fixes/new features is right in front of you, you see it, yet you can't merge it into your GPL-incompatible codebase. There BSD/MIT licenses don't prevent you from doing this either, though it's possible in practice it happens less. You can create not only closed-source proprietary forks of a BSD/MIT code base, but "source-available" or "shared source" proprietary forks, where the source is public but under a proprietary license that prohibits unauthorized redistribution or derivative works. There's nothing in the BSD/MIT license that requires you to keep your proprietary forks secret.
- deleted 10y ago
  [deleted]
alexvoda 10y ago
" If you only license you have is GPL, it doesn't allow you to use those in a non-Free way" I consider your wording deceptive. Why do fans of GPL engage in this deception? Stallman, the FSF and everyone else agrees that MIT, BSD, Apache and other are Free (as in freedom) software licenses and conform to the FSF definition of free software. Therefore your sentence should be "If the only license you have is GPL, it doesn't allow you to use those in certain Free ways (non-GPL Free ways) or in any non-Free way". While GPL licensed software is undoubtedly free software, the GPL is not synonymous with free software and by it's nature it is at odds with all other licenses free or non-free. It is incompatible with every other free license. I agree that the virality of copyleft is incredibly useful to drive adoption and resilience of free software but it is not the only way software can be free. There are multiple ways to drive software freedom: social pressure, standards, law reform, etc. Between a project developed behind closed doors with periodical GPL code dumps and no community and an MIT/BSD/Apache licensed project with a vibrant and involved community I think the latter is a lot closer to the spirit of free software and is a lot more resistant to close sourcing even without the added protections of the GPL. From the point of view of a user there is not much difference between: 1.a software maker deciding to abandon the GPL and release future versions of a project as closed source 2.and a software maker deciding to incorporate MIT/BSD/etc. code into a closed source project And both are equally vulnerable to being turned into SAAS. The GPL does not guarantee software freedom for the users unless there is no CLA (and there are multiple copyright holders like in the case of Linux) or in the case of a CLA there is some other agreement like the Qt-KDE. To make clearer the issue MIT/BSD/Apache/etc. projects have with the GPL think of it like this: It is the same issue you would have if you have a GPL project and you want to use an AGPL library or if someone creates improvements to your GPL project and releases the combined work (yours + his/hers improvements) under AGPL.

k_sze 10y ago

Yes, I do understand that people can take the BSD/MIT codebase and make a proprietary/closed source version. In that case you don't even see how the bug fixes are implemented in the new closed source version. So you are free to independently come up with the most obvious, efficient fix. My point is that with GPL, the implementation of the fixes/new features is right in front of you, you see it, yet you can't merge it into your GPL-incompatible codebase. Let's say we are talking about a security fix that turns out to be really easy. Somebody patched it in the GPL version, the fix turns out to be dead-easy and obvious, but now you can't use the same dead-easy and obvious fix in your own non-GPL version because it would be a violation of GPL. So now you have to come up with a suboptimal, ugly fix. In this case, GPL makes it painful for the original author of the proprietary version.

sokoloff 10y ago
Independent creation is a valid defense against copyright (as contrasted with patent law where it's not). If the fix is dead-easy and obvious ("change that = in a if statement to an ==", "add a check for foo", or "make this assignment a 1 instead of a 0"), the GPL license of patch A doesn't prevent anyone from creating (from scratch) patch B that does the same thing. For legal proof purposes, you probably want to ensure that the author of patch B hasn't seen the contents of patch A, though for something as obvious as the cases I present, I'm not even sure I'd worry about that.
- lightdot 10y ago
  Such things might not even be copyrightable.
- AstralStorm 10y ago
  Additionally, you can always require copyright reassignment for the main repository.
martingxx 10y ago
"My point is that with GPL, the implementation of the fixes/new features is right in front of you, you see it, yet you can't merge it into your GPL-incompatible codebase." 1) You almost certainly can as long as it's trivial, or you didn't look at the fix but did it independently based on a description of the bug. Legally, it all comes down to whether your work was a derived work or the original, not whether the result looks the same. 2) That's the idea anyway! Allowing someone to copy the work of others into a codebase that doesn't allow similar copying is exactly what the GNU GPL is designed to prevent. It's a risk you take if you decide to maintain a proprietary fork.
- alexvoda 10y ago
  K_sze's point was that it is a lot harder to prove you have not seen and were not inspired by publicly available code than it is to prove you were not inspired by code that was kept secret. And while someone using free software in a non-free fork can release the changes as shared-source leading to the same problem, this has rarely happened.
_delirium 10y ago
Yes, I do understand that people can take the BSD/MIT codebase and make a proprietary/closed source version. In that case you don't even see how the bug fixes are implemented in the new closed source version. So you are free to independently come up with the most obvious, efficient fix. My point is that with GPL, the implementation of the fixes/new features is right in front of you, you see it, yet you can't merge it into your GPL-incompatible codebase. There BSD/MIT licenses don't prevent you from doing this either, though it's possible in practice it happens less. You can create not only closed-source proprietary forks of a BSD/MIT code base, but "source-available" or "shared source" proprietary forks, where the source is public but under a proprietary license that prohibits unauthorized redistribution or derivative works. There's nothing in the BSD/MIT license that requires you to keep your proprietary forks secret.
deleted 10y ago
[deleted]

alexvoda 10y ago

" If you only license you have is GPL, it doesn't allow you to use those in a non-Free way" I consider your wording deceptive. Why do fans of GPL engage in this deception? Stallman, the FSF and everyone else agrees that MIT, BSD, Apache and other are Free (as in freedom) software licenses and conform to the FSF definition of free software. Therefore your sentence should be "If the only license you have is GPL, it doesn't allow you to use those in certain Free ways (non-GPL Free ways) or in any non-Free way". While GPL licensed software is undoubtedly free software, the GPL is not synonymous with free software and by it's nature it is at odds with all other licenses free or non-free. It is incompatible with every other free license. I agree that the virality of copyleft is incredibly useful to drive adoption and resilience of free software but it is not the only way software can be free. There are multiple ways to drive software freedom: social pressure, standards, law reform, etc. Between a project developed behind closed doors with periodical GPL code dumps and no community and an MIT/BSD/Apache licensed project with a vibrant and involved community I think the latter is a lot closer to the spirit of free software and is a lot more resistant to close sourcing even without the added protections of the GPL. From the point of view of a user there is not much difference between: 1.a software maker deciding to abandon the GPL and release future versions of a project as closed source 2.and a software maker deciding to incorporate MIT/BSD/etc. code into a closed source project And both are equally vulnerable to being turned into SAAS. The GPL does not guarantee software freedom for the users unless there is no CLA (and there are multiple copyright holders like in the case of Linux) or in the case of a CLA there is some other agreement like the Qt-KDE. To make clearer the issue MIT/BSD/Apache/etc. projects have with the GPL think of it like this: It is the same issue you would have if you have a GPL project and you want to use an AGPL library or if someone creates improvements to your GPL project and releases the combined work (yours + his/hers improvements) under AGPL.