Hacker News Reader

Comment by didgetmaster | Hacker News Reader

I have a project that I have thought about open sourcing. When I hear horror stories about demanding 'customers' who don't pay you anything but somehow expect you to drop everything and address their immediate concern (feature, bug, documentation, etc.), that gives me pause.

I wonder how many other projects have also been kept out of the OSS realm for the same reasons.

View on HN

> horror stories about demanding 'customers' who don't pay you anything but somehow expect you to drop everything

But isn’t that just a matter of setting your own boundaries? Someone demands somethign you don’t want to deliver you say “no” and that is it. If they are unpleasant about it you block or filter them.

You don’t own them anything. Not legally, and not morally. Just say no.

Or if you feel like it today say yes, and when the circumstances change say no. No biggie. You didn’t promise anyone anything. Any expectation on their part is a figment of their imagination.

Just don’t wrap yourself into pretzels over other people being unreasonable.

I think that is how it should work but it seems if one day you decide to stop supporting your software, or stop distributing it, then you get a "left-pad" or "log4j" situation and the whole world decides you owe them supported available software.

I don't think any of those things are comparable to requirements to support.

Left-Pad: dev deleted their software name in a package manger. Nobody demanded any maintenance, however intentionally screwing other people over is entirely different. Dev could have just never touched left-pad again and everyone would have been fine with it.

log4j: That was a maintained package, so i don't really see the comparison at all.

So yeah, no requirement to maintain your software. Taking a positive action to screw other people over is going to get those people mad at you. You're free to do nothing, you're not free to intentionally cause problems without hurting your reputation.

If you choose a license like AGPL then this will exclude most corps who will not pay for open source from using it, which turns out to have a large overlap with the corps that expect you to drop everything and address their immediate concern. It keeps the project within OSS more, or those who are willing to invest in OSS (because if they do anything more than just use the library / application then they now have a burden to publish changes and be visible so they're forced to invest something from their side).

Recently this has been my thought... that my future projects should be AGPL from day one.

To the existing ones, especially the successful one... if it does get too much for me, I shall relicense.

Yes, I think so too.

> Recently this has been my thought... that my future projects should be AGPL from day one.

If that means that companies can't use it, because that would mean, if they use it they would be required to open-source their managed SaaS solution ... that's a feature?

Where I think it's a feature is that instead of them taking from open source and expecting to be able to do that without having to do anything from their side (except demand fixes / updates / features)... AGPL forces them to invest some time and money into sharing any changes they've made and contributing back.

It prevents corps running their own version without sharing those changes back, and it forces corps to think carefully about whether they are willing to invest (their time and effort) in the OSS projects that they consume.

I doubt it would mean that they have to OSS their SaaS offerings. Most likely things are all implemented as little services and the boundary of what they'd have to OSS at most is one of those. More it forces them to be a better and more mindful consumer of OSS.

AGPL doesn't force companies to share back upstream, only that their users can get the source code. Most of those users probably are non-technical folks who don't understand software development or even if they are power users won't bother to download the source, let alone contribute back upstream. The company can choose who their users are too, so they don't have to accept the OSS devs who want to get code back as users.

IANAL, but the AGPL scares people (like lawyers) simply because it’s untested legal waters. The GPL at least is clear about what counts as distribution, but the AGPL, depending on who you ask, may or may not be. The GPL also has case law in a few countries; the AGPL doesn’t.

Some developers at $BIGCORP may think they’d be fine using an AGPL library/utility in one spot, but legal gets nervous, so they recommend management shut it down to avoid lawsuits.

This appears to have been an AGPL related case, although it wasn't about the network clause.

https://www.theregister.com/2017/05/13/gnu_gpl_enforceable_c...

BTW, the AGPL network clause triggers on modification, not on distribution (which the AGPL has the same provisions for as the GPL) or public performance or something else.

Which is fine :) Then I don't get $BIGCORP demands for things for my lil' precious made-for-me-but-shared-with-the-world project.

"If you choose a license like AGPL then this will exclude most corps", period. It is nicknamed Anxiety GPL for a reason... the discussion of what other parts of your system are a 'derivative work', and would require licensing under AGPL, hasn't been settled and depends on individual lawyers' or judges' interpretation.

The definition of what counts as a "derivative work" has nothing whatsoever to do with the AGPL: it's defined by copyright law. (Although you're right that it's almost entirely defined by case law, rather than being explicitly defined in statutes or regulations.)

If something is a derivative work for the purposes of the AGPL, then it's also a derivative work for the purposes of the GPL, or any other copyright license.

Its not exactly hard to comply with the AGPL, just publish the source as part of the deployment process. I don't understand why corps refuse to use AGPL.

I beg to differ and say that requesting better documentation is fair, and it goes without saying that maintainers don't need to fulfill these requests, as I don't think that these requests are driven by an inexplicable sense of entitlement or unfairness to OSS maintainers, but instead a desire for more knowledge about the projects and since no one knows the codebase better than the creators themselves, it becomes obvious that you turn to them for answers to your questions or technical problems that you might face.

I don't think that most requests by OSS users are unreasonable or unfair. Anyone who puts out code that is not perfect (i.e. all code) should expect there to be bug fix requests, support questions, documentation requests, and suggestions for new or better features.

But even if you say NO to the vast majority of requests, it generally requires some real time and effort to address each one. If the originator does not feel like 'maintaining' a project and their is no financial incentive for doing so; then I think that can be a big barrier for many projects and can prevent them from being open sourced to begin with.

Reply on news.ycombinator.com