Licenses like these are a logistical nightmare. If someone deploys software under that license, paying that person for the job is the smallest item on the bill: Now I have to connect my legal department with my techies and with the finance folks. Let's schedule meetings every 3 months to review for which software we have to pay now! Just the logistical overhead alone justifies a fork for any of the targeted users^wcu…
"Paying people for their work sucks, what a drag. Undercutting their work so we can continue to profit more is a much better strategy."
Changing the Ungit license from MIT to Faircode
81–90 of 117 posts
Re: Changing the Ungit license from MIT to Faircode
#82Re: Changing the Ungit license from MIT to Faircode
#83Earlier quoted context omitted.
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…
I think actually you can. If you rewrite 75%? 80%? You can relicense it. Legally I think the law views that as new code not a modification. A lawyer may need to correct me but I seem to recall something like this.
[deleted]
Re: Changing the Ungit license from MIT to Faircode
#84This thread and the culture of those replying to it fascinate me. Do you really enjoy spending this much time debating licenses, clauses, and legal matters?
I personally, just have to many more important things to do than worry about and waste time on compliance, laws, enforcement. It just seems like such a rediculous waste of time.
I just 2 clause BSD license my code and move on. Compensate me, don't compensate me, I'm busy writing other code, or designing systems, etc
Do people people posting replies here really spend this much time on licensing issues instead of producing?
It just seems so needless to me.
Re: Changing the Ungit license from MIT to Faircode
#85Earlier quoted context omitted.
That's called business competition. Stay in business by delivering greater value. It's likely the maintainer is in the best position to start a company about the product to deliver more features faster and at higher quality along with more inherent trust.
As someone being in a similar situation, it's a really difficult business model. Unlike many other business models with a natural moat (i.e. by virtue of having all the data, being deeply integrated into organisational processes, etc), commercialising open source is a struggle because simply justifying making money already requires constant improvement.
Almost all businesses require constant improvement to be commercially viable. This is the common scenario.
Natural moats are rare and highly sought after and fought for, and is actually much harder to build than a typical business based on product value.
Re: Changing the Ungit license from MIT to Faircode
#86Earlier quoted context omitted.
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…
I think actually you can. If you rewrite 75%? 80%? You can relicense it. Legally I think the law views that as new code not a modification. A lawyer may need to correct me but I seem to recall something like this.
Most certainly not. I recall that, in the SCO vs. IBM case, they discussed copyright of individual code snippets, on the range of a dozen lines of code, that were part of a bigger codebase.
Re: Changing the Ungit license from MIT to Faircode
#87Earlier quoted context omitted.
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…
You're right, but both the MIT and the non-commercial portion of this new license explicitly grant the right to sublicense. It's not obvious to me that a free use case can't sublicense its use to a huge organization.
If it was possible to re-license something in a way that removed restrictions from the original license, then no license would be worth anything. You could do a relicense end-run around any terms you wished.
(As another commenter said,) sublicensing does not permit you to grant any rights under the new license that you yourself have not been granted under the original.
Re: Changing the Ungit license from MIT to Faircode
#88Earlier quoted context omitted.
I would like a companion contributors agreement to the GPL that provides the correct legalese to assign copyright back to the project owner. I decided to go the GPL route, but am not currently accepting contributions. I've managed to successfully license the code under a companion license, which is doable since I'm the only copyright holder. My thoughts are that there should be a contrib fork for major contributions…
I personally feel that assigning copyright on commit is a stopgap. What if you die? What if you abandon the project? How can a fork of your project work with that if they want to change the license down the road? Copyright basically lasts forever now, so any choice about "assignment" will last forever. Personally I really feel we need a solution that allows the current "maintainers" to have control over it. I don't r…
I feel it really depends on the type of project. In my case the code is rather niche and would only really be licensed by a small number of companies doing embedded robotics or AR. However, this type of stuff is also fun for hobbyists, so I wanted to make it available. I don't foresee a huge developer community springing up around this, and since I'm the only person who will realistically be making major contributions and I'm working on it more or less full time, I need a way to fund it.
The real problem for me isn't major contributions, if these started coming in I may reevaluate my position. The problem is minor bug fixes where the complexities of acquiring another copyright holder outweigh the benefits of accepting the contribution.
As above, I don't have a good solution.
Re: Changing the Ungit license from MIT to Faircode
#89Earlier quoted context omitted.
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,…
You misunderstand the purpose of the license. 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 don't think there's anything "wrong" with nearly any license. If your project has been written without including other open-source components, feel free to license it under whichever license you choose. Closed-source commercial licensing is an option, and might be the best option if you're actually expecting to make a living from the code in question.
Just don't be surprised when the community doesn't respond well when you take an open-license project, accept unpaid contributions from others, and later convert it to a non-open license to pay nobody other than yourself.
Re: Changing the Ungit license from MIT to Faircode
#90If this becomes a trend I'm afraid it will hurt business use of all open source software, since companies will never know if their dependencies are going to suddenly start charging money. Even though you can use the old versions, getting stuck on outdated libraries is a big problem for a lot of projects, where you try to stay up-to-date. It feels like we are only recently at a point where managers and lawyers will pe…
> since companies will never know if their dependencies are going to suddenly start charging money
It is more of a risk for some open source projects than others. Look for example at React – I very much doubt Facebook will try to relicense it into a commercial product, simply because they are not in the business of selling software and probably don't want to get into that business. But, compare that to many small companies who have a product (such as a development tool or database or whatever) and they offer an open source version and a commercial version with extra features–there is a much bigger risk they might decide their open source offering is harming their commercial one, and therefore should be discontinued.
Similarly, an open source project run by a single individual or small community is more likely to be closed up than one run by a large community. On the other hand, a project run by a single individual is likely to be a smaller code base, and hence more feasible to fork or maintain in-house.
So, I think businesses should be aware of this risk, but should evaluate that risk for each open source dependency independently.