71–80 of 117 posts
Reinventing GPL with less care. I can copy the code, re-license as plain-MIT, and now commercial companies can use it for free. A dual GPL-commercial license is the correct way to handle this. A more useful contribution to the license landscape would be to define a commercial sibling-license to the GPL that described how license payments would be disbursed.
Maybe I am missing something. If you release something under a non-copyleft license, as long as I make proper attribution, what I do with it should not be your concern. If you do not want people making money from your software without paying you, use dual copyleft/proprietary licenses instead. "Faircode" seems like an attempt to have it both ways: squeezing money out of people without being labeled copyleft (because…
> I am trying to avoid the word "shakedown", but this strikes me as exactly that. Yes, the $90/month cost is going to hurt all the companies that have revenue greater than $1,000,000/year. This will put them out on the streets, I'm sure. Let's be real: This does not apply to you, and on the off chance that it does, why are you complaining about paying $90 per month for something you should probably already be donatin…
Even a $1m/y company (which is not big at all) will be hard pressed to pay 1k/year for a git wrapper. The whole idea of OSS is that everyone benefits from the exchange and costs are distributed. This won’t scale at all - count your current open source dependencies and imagine paying that sum for each of them.
Earlier quoted context omitted.
I don't see the relation. Copyleft licenses and what the faircode license are attempting to do are pretty different things. I don't see any relation between them, other than that they are both licensing terms. They are different licensing terms. I do think the terms of this new license are going to be confusing and make it difficult to figure out how to use it legally. As with most if not all "non-commercial use only…
I understand that "Faircode" is not trying to protect downstream users from non-free software. That's my point; It's not about principle, it's about extorting money while appearing to be principled. Copyleft licenses force people to release their modifications as source code, or pay the copyright owner for an exception (if the owner is open to providing the exception) Non-Copyleft licenses say "do whatever you want,…
Only if you distribute the software.
I truncated some of the text to highlight a possible issue with the change written by the Ungit maintainer: > Permission is hereby granted (...) to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies ("Use") of the Software (...) And then: > If you are a commercial entity with a revenue in excess of $1,000,000 (...) you must acquire a commercial license grant (...) to Use this Software (...)…
https://opensource.org/osd-annotated
Restricting commercial use isn't anything new or a bold new experiment or anything. It's the same lesson we apparently need to relearn from the 1980s.
Earlier quoted context omitted.
I don't see the relation. Copyleft licenses and what the faircode license are attempting to do are pretty different things. I don't see any relation between them, other than that they are both licensing terms. They are different licensing terms. I do think the terms of this new license are going to be confusing and make it difficult to figure out how to use it legally. As with most if not all "non-commercial use only…
I understand that "Faircode" is not trying to protect downstream users from non-free software. That's my point; It's not about principle, it's about extorting money while appearing to be principled. Copyleft licenses force people to release their modifications as source code, or pay the copyright owner for an exception (if the owner is open to providing the exception) Non-Copyleft licenses say "do whatever you want,…
This is proprietary commercial software with a 100% discount for hobbyist customers. It's very common in other industries, such as with fonts (this is almost identical to the model Blambot uses for some of their comic-book fonts). And there's nothing wrong with that.
I truncated some of the text to highlight a possible issue with the change written by the Ungit maintainer: > Permission is hereby granted (...) to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies ("Use") of the Software (...) And then: > If you are a commercial entity with a revenue in excess of $1,000,000 (...) you must acquire a commercial license grant (...) to Use this Software (...)…
Or, can I as an individual who is an employee of the company, but not the company, "use" it myself and then "sublicense" it to my employer?
Honestly, I do not believe that companies will pay to use open source software when they can just download it.
Developers will prefer to just download instead of waiting for the legal department and the budget approval.
On the other hand, if it was simpler to just download the code/executable and then pay later, without any hassles from the legal department it could be the standard way to use Open Source.
However, there is still the problem of what to sell.
A great idea could be to distribute the executable when it applies, thinking about golang, C/C++, any compiled language. For languages that are interpreter you could distribute the ruby gem, or the python egg or the JS packet.
Now if we combine this mechanism with some rate-limiting and price structure.
Stuff like:
* 10€ for one time download of the current version.
* 50€ for one time download of any version forever, when a new version comes out you can download it too.
* 10€/month for 30 downloads/months of the current version
* 50€/month for 30 downloads/months of any version
* 100€/month for unlimited downloads.
... and so on.
This could already provide several benefits, and be enough for several projects.
However we could also go a little forward.
We could provide an incentive to the buyers to buy the software and that incentives could be to do not distribute the building instruction or the dependencies list as open source.
Of course it will be possible to reverse-engineer the build instructions or the dependencies, however, it will be so time-consuming that any sane actor will prefer to just pay a little fee.
Finally, we could provide, under a restrictive license, the above-mentioned build instruction to whoever wants to contribute to the code base in a non-automatic way. Just send an email, ask for them, explain what you are going to do, promise to do not use them to by-pass the above restriction and you are ready to go.
In this way:
1. We maintain most of the code open.
2. There will be incentives to just pay for open source.
3. There will be a trade-off between new contributors and time/resource the current maintainer will be able to support the project. (I don't believe that somebody willing to dive into the complexity of an open source project to add features will be scared off by contacting the maintainer, explain to him what he wants to add, maybe wait his feedback, and finally get the build instructions. Honestly, I see mostly benefits in this project)
I would love to hear feedback about this idea.
So please share your thoughts and if you are interested in trying something like that feel free to contact me via email :)
Reinventing GPL with less care. I can copy the code, re-license as plain-MIT, and now commercial companies can use it for free. A dual GPL-commercial license is the correct way to handle this. A more useful contribution to the license landscape would be to define a commercial sibling-license to the GPL that described how license payments would be disbursed.
I can copy the code, re-license as plain-MIT You can't relicense someone elses code. You dont have the right to do that. If you fork this code, only your changes would be under MIT. So you would have a mixed-license project, and users would need to comply with both licenses. If you don't want to use this license, you have to fork it from before the license change... giving up the changes that were made after the new…