3 ms·

I actually managed to contribute to it once, via the mailing list. This doesn't really invalidate (1), but maybe they just don't want GitHub-style forks ("modif

I actually managed to contribute to it once, via the mailing list. This doesn't really invalidate (1), but maybe they just don't want GitHub-style forks ("modifying the supplied code 'in place' is something that we discourage").

erikb 11y ago
It's unavoidable with open source. Take any project with daily tarballs and mailing list diffs and you can probably even code a solution that will transform it to a git repo. Actually a git repo is not that different from a tarball webshare with a shell client for diffs etc.
- nickpsecurity 11y ago
  You mean in theory it will happen. I think the real question is, "Does it work in practice?" We'd have to look at software like these to see how many got forked versus similar software with repo's and such. My guess: I bet it does work for a good many of them because of developers being too lazy to go through the trouble. If the functionality is useful enough, then it won't work because the maintenance is easier than duplicating their work. Still, I'm not sure of the value in doing this kind of thing. The licensing schemes where you can't use the projects name in derivatives made sense: poor knockoffs can hurt image and adoption. Yet, people not wanting code to be used so easily probably shouldn't be open licensing it in the first place. These people are weird lol...
  - erikb 11y ago
    Of course for small projects it won't happen. But for big ones it happens for sure. And then it doesn't matter if that (or these) repos are by the original author or not. If you can rely on regular updates to that repo then people will use it just as if it would be the original source and will spread just as far as any other repo based FOSS project. So I think for major projects the limitation you can achieve that way is minimal.
    - nickpsecurity 11y ago
      I agree.

3 ms·

I actually managed to contribute to it once, via the mailing list. This doesn't really invalidate (1), but maybe they just don't want GitHub-style forks ("modif

by bakabaka9 11y ago

erikb 11y ago
It's unavoidable with open source. Take any project with daily tarballs and mailing list diffs and you can probably even code a solution that will transform it to a git repo. Actually a git repo is not that different from a tarball webshare with a shell client for diffs etc.
- nickpsecurity 11y ago
  You mean in theory it will happen. I think the real question is, "Does it work in practice?" We'd have to look at software like these to see how many got forked versus similar software with repo's and such. My guess: I bet it does work for a good many of them because of developers being too lazy to go through the trouble. If the functionality is useful enough, then it won't work because the maintenance is easier than duplicating their work. Still, I'm not sure of the value in doing this kind of thing. The licensing schemes where you can't use the projects name in derivatives made sense: poor knockoffs can hurt image and adoption. Yet, people not wanting code to be used so easily probably shouldn't be open licensing it in the first place. These people are weird lol...
  - erikb 11y ago
    Of course for small projects it won't happen. But for big ones it happens for sure. And then it doesn't matter if that (or these) repos are by the original author or not. If you can rely on regular updates to that repo then people will use it just as if it would be the original source and will spread just as far as any other repo based FOSS project. So I think for major projects the limitation you can achieve that way is minimal.
    - nickpsecurity 11y ago
      I agree.