Buying a popular addon with the express purpose of subverting its original intent for commercial monetization seems like it should be against Atom's TOS
This instance is razor thin close to being malware
What's to stop the next enterprising company from intentionally uploading all your code to their servers? Modifying your code? Or holding your code hostage? Atom has git support backed in, so how likely is it an addon could inject code and commit it without you ever seeing that it happened.
Atom's automagic update approach to addons can't survive this kind of exploitation. If I have to re-vet every addon every time there's an update, their entire ecosystem just turned to shit.
Do we need virus scanners for Atom packages now? An addon that scans repos to see if the primary contributor suddenly changed?
Maybe Github should have an informal policy that punishes bad actors by penalizing how they're listed in Atom's built-in package browser. Or create a convention of documentation that is machine-readable and easy to preview in the editor's package-updater tool. But making blanket rules regarding commercialization would likely have unwanted unintended effects.
FWIW, Atom's community manager wrote a long comment in one of the Kite plugins' Github issues:
As a steward of the Atom editor and the Atom package ecosystem, I'm of course concerned about packages being used for nefarious purposes. But I'm also loathe to impose blanket rules on what is or isn't valid functionality for packages without some very well-thought-out rationalization and justification for those rules. I've been watching this topic hoping that the smart people here would give me some ideas
[an analogy to the value of advertising in other contexts]
...I'm definitely keeping my eye on this kind of thing and if advertisements become a problem, I'm sure that the Atom team will consider specific rules. I just don't think we're there yet.
For starters, packages should probably be considered non-transferable. If someone buys a package, they shouldn't keep the existing rankings and ratings.
It would be challenging to be proactive about it, but it was be a clear solution when they get caught.
If I'm the maintainer of an OSS plugin with 3m users, I'd better be _very_ careful about what I do with it, and keep my SSH keys, etc., _safe_. It's a responsibility not to be taken lightly.
Practically speaking, it means you have to be comfortable with knowing you have a (tiny?) chance of being hit with a remote code exploit at any time. Avoiding that means disabling auto update and other such conveniences. Personally, I treat developer computers as untrusted by default.
Giving ad networks tracking information of your editor usage and possibly access to the code you're working (which they didn't do, but the original statement was 'close to being malware') on is beyond mere adware.
Adware always had telemetry. But I get your point. Let's call it spyware then if we think companies might use our source as a consequence. I find it highly unlikely but admit it is possible.
Comments
Buying a popular addon with the express purpose of subverting its original intent for commercial monetization seems like it should be against Atom's TOS
This instance is razor thin close to being malware
What's to stop the next enterprising company from intentionally uploading all your code to their servers? Modifying your code? Or holding your code hostage? Atom has git support backed in, so how likely is it an addon could inject code and commit it without you ever seeing that it happened.
Atom's automagic update approach to addons can't survive this kind of exploitation. If I have to re-vet every addon every time there's an update, their entire ecosystem just turned to shit.
Do we need virus scanners for Atom packages now? An addon that scans repos to see if the primary contributor suddenly changed?
Maybe Github should have an informal policy that punishes bad actors by penalizing how they're listed in Atom's built-in package browser. Or create a convention of documentation that is machine-readable and easy to preview in the editor's package-updater tool. But making blanket rules regarding commercialization would likely have unwanted unintended effects.
FWIW, Atom's community manager wrote a long comment in one of the Kite plugins' Github issues:
https://github.com/atom-minimap/minimap/issues/588#issuecomm...
For starters, packages should probably be considered non-transferable. If someone buys a package, they shouldn't keep the existing rankings and ratings.
It would be challenging to be proactive about it, but it was be a clear solution when they get caught.
I think what it really means is this:
If I'm the maintainer of an OSS plugin with 3m users, I'd better be _very_ careful about what I do with it, and keep my SSH keys, etc., _safe_. It's a responsibility not to be taken lightly.
Practically speaking, it means you have to be comfortable with knowing you have a (tiny?) chance of being hit with a remote code exploit at any time. Avoiding that means disabling auto update and other such conveniences. Personally, I treat developer computers as untrusted by default.
Picking nits I think you mean adware not malware. I think it's worth making the distinction.
Giving ad networks tracking information of your editor usage and possibly access to the code you're working (which they didn't do, but the original statement was 'close to being malware') on is beyond mere adware.
Adware always had telemetry. But I get your point. Let's call it spyware then if we think companies might use our source as a consequence. I find it highly unlikely but admit it is possible.
Literally the only distinction is how many lawyers they're packing.