Correct me if I'm wrong. Scenario: A business discovers their proprietary licensed product uses your Parity licensed product by 2 levels of indirection. (They use an MIT lib that uses an Apache lib that uses your Parity lib). So far as I know, their choices are to either pay you for a commercial license or to replace your lib in their product within 30 days, which could be intractable.
An otherwise permissibly-licensed (e.g. MIT or Apache) project would be bringing a lot of hidden risk/liability to their users by creating a dependency on a Parity-licensed lib. It seems like the only way to make that risk transparent is for the project to change their license to Parity. If projects don't do this, then it will start requiring extra risk assessment to use "permissible" license libs. I remember in the early days of open source that businesses were afraid to use anything with the "open source" label due to risk/liability. I even had to get special lawyer approval for an MIT lib once. I'd hate to go back there.
Another thing that always bothered me about the business model of using AGPL (and I guess Parity) is that the project still isn't really an open source community project. Ownership rights are exercised to do a private commercial release. But if you disappear without sharing or transferring those rights, no one else can ever do a commercial release and those customers are stuck (depending on their commercial license terms). Others can fork it, but they can't choose to release it under a different license. Whereas something like MIT doesn't have this problem since it doesn't cut off any practical usage rights if the author goes off the grid. (Although MIT doesn't solve the "free labor" problem that popular open source projects can have.) Anyway, it's a contingency to think about.
Scenario A (surprise library): this is partly why I explicitly said I'm only recommending this model for devtools, not libraries.
Scenario B (developer going away): shrug. I don't see this as a big issue. Products disappear all the time, people adapt. Look at Google shutting down major projects apparently on a whim.
Dev tools are often packaged up or depended on by other dev tools. Not to mention things like starter templates. Or maybe my definition of dev tools is too broad. Were you thinking like endpoint apps like VS Code or vim? (Although VS Code has been adapted for other uses too.)
I suppose it’s true that products disappear. We’ve had that happen to us or seen it happen to others with some vendors. Because they weren’t making enough money. Anyway, I guess in my mental model, if I decided I was tired of an OSS project I can just stop and someone else can keep it going if it’s important to them. But this is different. It is really a business model, not a community project.
I think if you're concerned about that first scenario, it's important to understand where your tool stands in the ecosystem. I also think it's perfectly acceptable that all those users will, in fact, need to pay for proprietary use. And we can build tools to make that easier.
And... now thinking again. This whole problem can be solved with registering a non-profit which will hold the copyright instead of you personally? Of course you still need to have (initially, later the co-maintainers?) few people in that body - family or peers and friends. That way, there would have "official" protocol & rules what and how to happen.
In the US anyway, my understanding is that non-profits have ongoing requirements (requires a board, annual meetings, some financial reporting) and are not controlled by a single person -- the board could out-vote you on an issue. So it has non-trivial overhead and some risk as just a vehicle for ownership rights.
I could be wrong on some of the details, but I believe the gist of what I'm saying is true. I have been an observer in formation of one non-profit as well as working for another. Definitely investigate it for yourself.
Ааh, yea, probably. Good to know, I'm looking at UK ones currently.
and are not controlled by a single person -- the board could out-vote you on an issue.
That's okay. In governance of bigger open source projects it's almost the same thing. There's no problem for smaller ones to be similar too.
My case is that I'm concentrating everything in a single monorepo of independent libraries & devtools and pieces - some connected to each others, others completely not related to other packages.
Anyway, thanks. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Correct me if I'm wrong. Scenario: A business discovers their proprietary licensed product uses your Parity licensed product by 2 levels of indirection. (They use an MIT lib that uses an Apache lib that uses your Parity lib). So far as I know, their choices are to either pay you for a commercial license or to replace your lib in their product within 30 days, which could be intractable.
An otherwise permissibly-licensed (e.g. MIT or Apache) project would be bringing a lot of hidden risk/liability to their users by creating a dependency on a Parity-licensed lib. It seems like the only way to make that risk transparent is for the project to change their license to Parity. If projects don't do this, then it will start requiring extra risk assessment to use "permissible" license libs. I remember in the early days of open source that businesses were afraid to use anything with the "open source" label due to risk/liability. I even had to get special lawyer approval for an MIT lib once. I'd hate to go back there.
Another thing that always bothered me about the business model of using AGPL (and I guess Parity) is that the project still isn't really an open source community project. Ownership rights are exercised to do a private commercial release. But if you disappear without sharing or transferring those rights, no one else can ever do a commercial release and those customers are stuck (depending on their commercial license terms). Others can fork it, but they can't choose to release it under a different license. Whereas something like MIT doesn't have this problem since it doesn't cut off any practical usage rights if the author goes off the grid. (Although MIT doesn't solve the "free labor" problem that popular open source projects can have.) Anyway, it's a contingency to think about.
Same disclaimer: I am not a lawyer.
Scenario A (surprise library): this is partly why I explicitly said I'm only recommending this model for devtools, not libraries.
Scenario B (developer going away): shrug. I don't see this as a big issue. Products disappear all the time, people adapt. Look at Google shutting down major projects apparently on a whim.
Dev tools are often packaged up or depended on by other dev tools. Not to mention things like starter templates. Or maybe my definition of dev tools is too broad. Were you thinking like endpoint apps like VS Code or vim? (Although VS Code has been adapted for other uses too.)
I suppose it’s true that products disappear. We’ve had that happen to us or seen it happen to others with some vendors. Because they weren’t making enough money. Anyway, I guess in my mental model, if I decided I was tired of an OSS project I can just stop and someone else can keep it going if it’s important to them. But this is different. It is really a business model, not a community project.
I think if you're concerned about that first scenario, it's important to understand where your tool stands in the ecosystem. I also think it's perfectly acceptable that all those users will, in fact, need to pay for proprietary use. And we can build tools to make that easier.
Very true. I was thinking about that in a twitter thread too twitter.com/tunnckoCore/status/123....
And... now thinking again. This whole problem can be solved with registering a non-profit which will hold the copyright instead of you personally? Of course you still need to have (initially, later the co-maintainers?) few people in that body - family or peers and friends. That way, there would have "official" protocol & rules what and how to happen.
Hm. I may try that way. Thoughts?
In the US anyway, my understanding is that non-profits have ongoing requirements (requires a board, annual meetings, some financial reporting) and are not controlled by a single person -- the board could out-vote you on an issue. So it has non-trivial overhead and some risk as just a vehicle for ownership rights.
I could be wrong on some of the details, but I believe the gist of what I'm saying is true. I have been an observer in formation of one non-profit as well as working for another. Definitely investigate it for yourself.
Ааh, yea, probably. Good to know, I'm looking at UK ones currently.
That's okay. In governance of bigger open source projects it's almost the same thing. There's no problem for smaller ones to be similar too.
My case is that I'm concentrating everything in a single monorepo of independent libraries & devtools and pieces - some connected to each others, others completely not related to other packages.
Anyway, thanks. :)