3 ms·

This makes an assumption that a bunch of companies are maintaining their own forks of MIT software with bug fixes and features and not giving it back. I find t

by spott 1y ago

This makes an assumption that a bunch of companies are maintaining their own forks of MIT software with bug fixes and features and not giving it back. I find that hard to believe.

canyp 1y ago
Not really. A company that does not bother contributing to a liberally-licensed project will 100% avoid GPL software like the plague. In either case, they won't contribute. In the latter case, they don't get to free-ride like a parasite.
- ninjin 1y ago
  It is reasonable to assume that this is true. But an equally effective way other than making your license unpalatable to them, is just to say no and state clearly: "Patches or GTFO". Also, have a homepage to link with your (hefty?) consulting rates? I have mentioned this in the past, but there was this weird shift in culture just after 2000 where increasingly open source projects were made to please their users, whether they were corporate or not, and "your project is your CV" became how their maintainers would view their projects. It does not have to be this way and we should (like it seems to be the case with libxml2) maybe try to fix this culture?
  - tzs 1y ago
    > It is reasonable to assume that this is true. But an equally effective way other than making your license unpalatable to them, is just to say no and state clearly: "Patches or GTFO". Also, have a homepage to link with your (hefty?) consulting rates? That's fine for feature requests, but the issue in the present case is bug reports.
    - ninjin 1y ago
      I fail to see how that is different. Ultimately, you have released a piece of software into the wild with a clause stating: "The software is provided 'as is' and the author disclaims all warranties with regard to this software including all implied warranties of merchantability and fitness". Thus, it is purely cultural that somehow others and yourself expect you to cancel your family time on a Saturday night solely because an issue has been found in a piece of software you have given away for free. This "value add" is wearing people out and if we want this expectation to remain, maybe it is time for those profiting or those with a monopoly on violence to explore ways to support those that kindly provide free labour like this?
      - tzs 1y ago
        > I fail to see how that is different. A feature request is for something new. A bug report is reporting an error in the already released and distributed software. Here is why that is relevant. > Ultimately, you have released a piece of software into the wild with a clause stating: "The software is provided 'as is' and the author disclaims all warranties with regard to this software including all implied warranties of merchantability and fitness". When there is a bug in that released software the 'as is' is not the 'as is' that the developer intended. Probably 99% of free software developers would like to be informed about this, especially if it is software that they are continuing to develop and distribute. > Thus, it is purely cultural that somehow others and yourself expect you to cancel your family time on a Saturday night solely because an issue has been found in a piece of software you have given away for free Huh? If I report a bug on a Saturday night (to a free software project or a proprietary project) I expect that someone will look at the report during the normal hours when they look at bug reports and if they decide it is something that needs fixing the work will be scheduled the same way they schedule work to fix bugs that their own testing reveals.
- jenadine 1y ago
  > will 100% avoid GPL software like the plague. Not true. Many companies uses Linux for example. They will just avoid using GPL software in ways that would impact their own intellectual property (linking a GPL library to their proprietary software). Sometimes they will even use it with dubious "workaround" such as saying "we use a deamon with IPC so that's ok"
  - quietbritishjim 1y ago
    > > will 100% avoid GPL software like the plague. > Not true. Many companies uses Linux for example. I thought it was clear, given that this is a discussion about an open source library, that they were talking about GPL libraries. The way that standalone GPL software is used in companies is qualitatively quite different.
    - canyp 1y ago
      That is precisely what I meant.
adastra22 1y ago
No, they're mostly not. They're throwing the maintenance demand back on the unpaid, understaffed open source developers. That's what TFA is about.
roryirvine 1y ago
One of the comments on the LWN article is an analysis of exactly that happening with this very library - https://lwn.net/Articles/1026956/ https://lwn.net/Articles/1026956/ In short, Apple maintain a 448 kB diff which they 'throw across the wall' in the form of an opaque tarball, shorn of all context. Many of the changes contained within look potentially security-related, but it's been released in a way which would require a huge amount of work to unpick. That level of effort is unfeasible for a volunteer upstream developer, but is a nice juicy resource for a motivated attacker. Apple's behaviour, therefore, is going to be a net negative from a security point of view for all other users of this library.
- spott 1y ago
  My reading of this wasn’t that Apple has a bunch of security bug fixes they aren’t upstreaming, it is that they are maintaining their own forks of an old version and back porting security bug fixes from upstream into their fork. Maybe they are doing their own security fixes, but at this point they are so far diverged from upstream that it isn’t clear that those security bugs exist in upstream. But that is my guess, I don’t really have enough information to say much for sure.
  - roryirvine 1y ago
    Digging into it further, it looks like there's a mix - backported bugfixes, Apple-specific fixes, and security issues which may or may not have been fixed by upstream long ago. Some of it almost certainly would be useful upstream (eg. the clang warnings, and any unfixed security issues), and some might warrant being reimplemented in a different way (those Apple-specific ifdefs in the middle of platform-independent code blocks). But that's not ever going to happen, because of the way Apple jumbles it all together.
    - om2 1y ago
      We have contributed a number of upstream fixes $ cd gnome-libxml2.git $ git log --oneline --author=@apple.com | wc -l 43 The main reason we have a fork at all is that upstream libxml2 has broken source and binary compatibility in various ways, and we can't take those changes because libxml2 is public API on our platforms. We do make an effort to upstream all security fixes, though we sometimes get to it only after we ship.
deleted 1y ago
[deleted]
baobun 1y ago
Oh, I've seen it plenty. Cultural awareness is just very low in places for some reason.
__turbobrew__ 1y ago
I work a bigco and this happens all the time. I have probably written 20 patches for open source stuff like kubernetes, but when I open a pull request nobody on the project looks at it and it sits open forever. We keep patch sets internally and rebase on top of upstream as some project will not take our contributions.

by spott 1y ago

This makes an assumption that a bunch of companies are maintaining their own forks of MIT software with bug fixes and features and not giving it back. I find that hard to believe.

canyp 1y ago

Not really. A company that does not bother contributing to a liberally-licensed project will 100% avoid GPL software like the plague. In either case, they won't contribute. In the latter case, they don't get to free-ride like a parasite.

ninjin 1y ago
It is reasonable to assume that this is true. But an equally effective way other than making your license unpalatable to them, is just to say no and state clearly: "Patches or GTFO". Also, have a homepage to link with your (hefty?) consulting rates? I have mentioned this in the past, but there was this weird shift in culture just after 2000 where increasingly open source projects were made to please their users, whether they were corporate or not, and "your project is your CV" became how their maintainers would view their projects. It does not have to be this way and we should (like it seems to be the case with libxml2) maybe try to fix this culture?
- tzs 1y ago
  > It is reasonable to assume that this is true. But an equally effective way other than making your license unpalatable to them, is just to say no and state clearly: "Patches or GTFO". Also, have a homepage to link with your (hefty?) consulting rates? That's fine for feature requests, but the issue in the present case is bug reports.
  - ninjin 1y ago
    I fail to see how that is different. Ultimately, you have released a piece of software into the wild with a clause stating: "The software is provided 'as is' and the author disclaims all warranties with regard to this software including all implied warranties of merchantability and fitness". Thus, it is purely cultural that somehow others and yourself expect you to cancel your family time on a Saturday night solely because an issue has been found in a piece of software you have given away for free. This "value add" is wearing people out and if we want this expectation to remain, maybe it is time for those profiting or those with a monopoly on violence to explore ways to support those that kindly provide free labour like this?
    - tzs 1y ago
      > I fail to see how that is different. A feature request is for something new. A bug report is reporting an error in the already released and distributed software. Here is why that is relevant. > Ultimately, you have released a piece of software into the wild with a clause stating: "The software is provided 'as is' and the author disclaims all warranties with regard to this software including all implied warranties of merchantability and fitness". When there is a bug in that released software the 'as is' is not the 'as is' that the developer intended. Probably 99% of free software developers would like to be informed about this, especially if it is software that they are continuing to develop and distribute. > Thus, it is purely cultural that somehow others and yourself expect you to cancel your family time on a Saturday night solely because an issue has been found in a piece of software you have given away for free Huh? If I report a bug on a Saturday night (to a free software project or a proprietary project) I expect that someone will look at the report during the normal hours when they look at bug reports and if they decide it is something that needs fixing the work will be scheduled the same way they schedule work to fix bugs that their own testing reveals.
jenadine 1y ago
> will 100% avoid GPL software like the plague. Not true. Many companies uses Linux for example. They will just avoid using GPL software in ways that would impact their own intellectual property (linking a GPL library to their proprietary software). Sometimes they will even use it with dubious "workaround" such as saying "we use a deamon with IPC so that's ok"
- quietbritishjim 1y ago
  > > will 100% avoid GPL software like the plague. > Not true. Many companies uses Linux for example. I thought it was clear, given that this is a discussion about an open source library, that they were talking about GPL libraries. The way that standalone GPL software is used in companies is qualitatively quite different.
  - canyp 1y ago
    That is precisely what I meant.

adastra22 1y ago

No, they're mostly not. They're throwing the maintenance demand back on the unpaid, understaffed open source developers. That's what TFA is about.

roryirvine 1y ago

One of the comments on the LWN article is an analysis of exactly that happening with this very library - https://lwn.net/Articles/1026956/ https://lwn.net/Articles/1026956/ In short, Apple maintain a 448 kB diff which they 'throw across the wall' in the form of an opaque tarball, shorn of all context. Many of the changes contained within look potentially security-related, but it's been released in a way which would require a huge amount of work to unpick. That level of effort is unfeasible for a volunteer upstream developer, but is a nice juicy resource for a motivated attacker. Apple's behaviour, therefore, is going to be a net negative from a security point of view for all other users of this library.

spott 1y ago
My reading of this wasn’t that Apple has a bunch of security bug fixes they aren’t upstreaming, it is that they are maintaining their own forks of an old version and back porting security bug fixes from upstream into their fork. Maybe they are doing their own security fixes, but at this point they are so far diverged from upstream that it isn’t clear that those security bugs exist in upstream. But that is my guess, I don’t really have enough information to say much for sure.
- roryirvine 1y ago
  Digging into it further, it looks like there's a mix - backported bugfixes, Apple-specific fixes, and security issues which may or may not have been fixed by upstream long ago. Some of it almost certainly would be useful upstream (eg. the clang warnings, and any unfixed security issues), and some might warrant being reimplemented in a different way (those Apple-specific ifdefs in the middle of platform-independent code blocks). But that's not ever going to happen, because of the way Apple jumbles it all together.
  - om2 1y ago
    We have contributed a number of upstream fixes $ cd gnome-libxml2.git $ git log --oneline --author=@apple.com | wc -l 43 The main reason we have a fork at all is that upstream libxml2 has broken source and binary compatibility in various ways, and we can't take those changes because libxml2 is public API on our platforms. We do make an effort to upstream all security fixes, though we sometimes get to it only after we ship.

deleted 1y ago

[deleted]

baobun 1y ago

Oh, I've seen it plenty. Cultural awareness is just very low in places for some reason.

__turbobrew__ 1y ago

I work a bigco and this happens all the time. I have probably written 20 patches for open source stuff like kubernetes, but when I open a pull request nobody on the project looks at it and it sits open forever. We keep patch sets internally and rebase on top of upstream as some project will not take our contributions.