craftbeerpi3
craftbeerpi3 copied to clipboard
Manuel83
Please use a real open source license or stop calling open source
@Manuel83 This is a most important point.
It has come up numerous times on the various support forums and has gone unanswered.
Please make this software truly open source, or stop calling it opens source.
From the OSI website definition of Open Source: https://opensource.org/osd
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
From your Readme and License:
It's not permitted to distribute the modified software.
CraftBeerPi is a free & open source project.
These statements do not agree with one another. Many of us would love to contribute and use this software but cannot due to the horrible restrictive custom license.
Also. Please answer #75 this is very important to this being a usable, modifiable open source project.
@jarrodconnolly just this week in the CBPi user group on Facebook @Manuel83 mentioned that he will be providing the more thorough source for the new version of his UI he is working on, so that may cover #75 .
That being said, I agree with sentiment that more of us would like to contribute to this project, and that is not currently being facilitated.
I personally would like an answer to the question of if Forks (something allowable by the Github platform natively) are permitted.
I fear the viability of this project over the long term is somewhat on the line here with this issue.
Thank you for the comment.
Glad to hear that the UI source might be made available. Sadly, if it is under the same non open source restrictive license it will not be of much use to anyone.
My understanding is that a fork does not provide you any license or conditions outside of the project license at the time you fork it. Other than having your own copy of the source to view, you are still bound by the original license. (Not a lawyer or license expert, just my own understanding)
Changing the license now could end up being very difficult, depending on the individual contributors to the project. Moving from a restrictive license to an actual open source one requires the permission of each person that made commits or contributions to the project (currently 14 people). This has been covered in detail here: https://opensource.guide/legal/#what-if-i-want-to-change-the-license-of-my-project
I am not even sure changing the license is something that is desired by the project owners, I would just like that to be clarified in the README and the removal of the erroneous use of the term Open Source. There are a lot of restrictively licensed projects that enjoy the benefits of free QA testing and pull requests, I have nothing wrong with that, just spell it out. Many of these licenses are listed here that include similar restrictions as placed on this software: https://www.gnu.org/licenses/license-list.en.html#NonFreeSoftwareLicenses
I fear the viability of this project over the long term is somewhat on the line here with this issue.
I couldn't have said it better, thank you.
Please answer #75 this is very important to this being a usable, modifiable open source project.
Sadly, if it is under the same non open source restrictive license it will not be of much use to anyone.
These two statements seem to contradict each other. Personally I believe providing the UI source code to be useful. I've developed a CraftBeerPi SDK called Swill for this very issue, among other reasons.
Changing the license now could end up being very difficult, depending on the individual contributors to the project.
I am not even sure changing the license is something that is desired by the project owners, I would just like that to be clarified in the README and the removal of the erroneous use of the term Open Source.
So when you originally asked that the license be changed OR to stop using the term "Open Source", what you really were asking for was latter not the former?
(^^ really not trying to be antagonistic, just trying to grok the meaning of this Git issue.)
It is my opinion that if this project doesn't start accepting maintainers (people who can accept Pull Requests, fix bugs, close issues, etc.), this is all a moot point. There is an extreme community desire to contribute back to the core project and a distinct lack of ability to do so. Regardless of whether the license is open source or not, we need to be able to react to change more quickly than we currently can.
You are correct, i may have made somewhat contradictory statements. I seem to have gotten a little grumpy and off track. I believe strongly in open source software and spend a large portion of time dealing with licenses, this is probably what got me all angered up :)
I believe I have the same or similar goals as yourself though.
I love the idea of this project, would love to see more people able to work on it and hope is has future here on github.
Maintainers is a great start but I believe something should done about the license, this would really help ease peoples fears about forking and contributing to this project.
Again, thank you for your responses and input on this issue @jonrhall
Really looking forward to some feedback from the maintainers.
It is my opinion that if this project doesn't start accepting maintainers (people who can accept Pull Requests, fix bugs, close issues, etc.), this is all a moot point. There is an extreme community desire to contribute back to the core project and a distinct lack of ability to do so. Regardless of whether the license is open source or not, we need to be able to react to change more quickly than we currently can.
Totally seconding that. The licensing paradigm will change when the project management philosophy will switch from single man centralized pushes to a collaborative approach. Which takes time, effort and willingness.
Let's show Manuel that there are reliable arms to help him pass this crucial step!
This project has such potential but it needs maintainers to help it along. There is a strong community of very willing and very able users that can help it reach it's full potential. Come on! Let us make this the best truly open source brewing tool available. There are so many good ideas that need to acted upon.
Have a look at CraftBeerPi 4 there it is MIT + Commons Clause
https://github.com/Manuel83/craftbeerpi4/blob/master/LICENSE
You are allowed to use CBPi4 for private and commercial brewing as you like accept selling it. But even there I’m still the only developer.
@Manuel83 your license type cannot be both MIT and Commons Clause. Commons Clause is more restrictive and is not Open Source, and therefore is the applicable license until you state otherwise. See here: https://commonsclause.com/
If you use Commons Clause, you are not Open Source. You are not allowed to call yourself Open Source unless you use an Open Source license type. If you are using an MIT license, then you must provide an MIT only license file in your repository.
I’m not calling it open source. The question is what is your motivation? As a private home brewer or commercial brewer you can use it as you like. For each plugin you can set the license of your choice. The only thing I want to avoid is that other just taking CBPi and selling it.
You are calling it Open Source.
Have a look at CraftBeerPi 4 there it is MIT + Commons Clause
MIT = Open Source
Commons Clause = Not open source
You also say it right here, using it as a selling point to solicit donations
It can't be both. All we're saying is there's a conflict between you saying it's open source and the project actually being open source. If it is open source, people are allowed to take your project, add value to it, and resell it as their own. That's part of open source, it always has been and always will be.
If the project isn't open source, that's fine, just please don't label it as such. That's being disingenuous at best, malicious at worst--especially when being directly used as a mechanism to solicit donations.
I think we should all take a step back here!
My 2 cents:
Manuel has spent a lot of his own time working on this and as far as donations go, have you donated? If not, curb your feined outrage and maybe devote you energy to developing your own CBPi alternative that will be fully open source, and everyone will all hold hands and nod to each other in the glow of our own self righteousness.
It seemn pretty clear that this is a transitional phase, and he's simply trying to find a balance between open source for home brewers and closed source for commercial brewers.
Nothing disingenuous with that.
Cheers,
Kal
Manuel has spent a lot of his own time working on this and as far as donations go, have you donated?
Couldn't be further from the point everyone is making here.
curb your feined outrage and maybe devote you energy to developing your own CBPi alternative that will be fully open source
Again, this personal attack has nothing to do with CBPi's open source status. I personally would like CBPi to be open source, but that's not the issue here. The issue is saying it is open source when it is in fact not and never has been.
everyone will all hold hands and nod to each other in the glow of our own self righteousness.
Oh I get it now, "taking a step back here" just means insulting people
It seemn pretty clear that this is a transitional phase, and he's simply trying to find a balance between open source for home brewers and closed source for commercial brewers.
There is no such thing as a project being open source AND closed source at the same time. It has to be one or the other. That is the only point anyone in this thread is trying to make. It's why the topic of this thread is "Please use a real open source license or stop calling it open source".
It is disingenuous to call something open source when it's not, that's pretty plain and simple. CBPi as it stands today is not an open source project. Using the open source moniker literally in the same paragraph as an appeal for donations is using the appeal of the project being open source as a reason for people to donate. That too is disingenuous. It is perfectly fine to solicit donations for closed source projects, but it is not OK to be soliciting donations for a project that you call open source but actually is closed source.
Something needs to change here. Either stop calling it open source, and this whole issue can be resolved. Or, call it open source, and actually make it open source.
Sounds fine to call it just "free to use", sounds honest to not call it Open Source because ... it's not, period.
@Manuel83 I just want to highlight that closing the source code does not at all protect you from being copypasted and repackaged by some low effort, low ethics company. It's hard to explain that it's not Open Sourced because of fear-reasoning, since these kind of projects are much more resilient to copypastas when they are Open Source. Mostly because the real value of such product is the maintainability over time brought by a dynamic community. Copypastas do "one shots" and are quickly "busted" on the market
My fear when I read this reasoning, is that there might be other reasons, from you wanting to keep exclusive hands on the code (which is fine and can be understood), up to a strategy of free-to-use that would soon switch to paywall (scarier from a user perspective).
Why aren't we writing a CBPi replacement ? Seems to be enough developers interested in doing something with CBPi and yet we aren't allowed to.
It is ridiculous that the entire project is controlled by one person. I'm pretty sure he is doing this because one day he wants to withdraw it from the public domain and take it private.
It is time for us to build a clone/replacement for CBPi.
I built a bit of a class framework last night. Just simple stuff like Brewstand, Vessel, Controller, Sensor and Actor.
A Brewstand has one or more Vessels. A Vessel has one or more Controllers. A Controller has one or more Sensors and controls one Actor. Sensors have type temperature, flow, weight, etc. Actors have type heater, pump, mixer.
To add a controller, you superclass Controller like class myPID (Controller):
To add a sensor, you superclass Sensor like class myDS18B20(Sensor)
To add an actor, you superclass Actor like class myElement(Actor)
Everything is in Python3.
I am thinking I'll develop a framework and run it as a console app (process) first and then add a flask app on top that communicates with the framework. That way if someone wants to build something different, they can still use the framework.
Wrong approach ? Feedback ?
It´s a little convoluted to have 2 controles on the same Vessel to have coll and heat control. Could be both on if miss configured. The same can happen now on CBPi if the thresholds ar badly set.
El mié., 13 feb. 2019 a las 14:07, linuxguy123 ([email protected]) escribió:
It is time for us to build a clone/replacement for CBPi.
I built a bit of a class framework last night. Just simple stuff like Brewstand, Vessel, Controller, Sensor and Actor.
A Brewstand has one or more Vessels. A Vessel has one or more Controllers. A Controller has one or more Sensors and controls one Actor. Sensors have type temperature, flow, weight, etc. Actors have type heater, pump, mixer.
To add a controller, you superclass Controller like class myPID (Controller):
To add a sensor, you superclass Sensor like class myDS18B20(Sensor)
To add an actor, you superclass Actor like class myElement(Actor)
Everything is in Python3.
I am thinking I'll develop a framework and run it as a console app (process) first and then add a flask app on top that communicates with the framework. That way if someone wants to build something different, they can still use the framework.
Wrong approach ? Feedback ?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Manuel83/craftbeerpi3/issues/196#issuecomment-463282529, or mute the thread https://github.com/notifications/unsubscribe-auth/AK4bcaNkzdX1baE3FGH1rq93fNh9rehzks5vNEY5gaJpZM4UPIMk .
One can easily limit a vessel to one controller, but there might be a controller for the heater, one for the mixer and one for the pump in a complex system. I'm just thinking ahead.
One more thing... I wasn't going to give actors their own switches. A switch would be a type of controller. So a mash tun (a Vessel) could have a PID to control a heater and a switch to control a pump. It adds a bit of complexity to have a switch Controller to turn a pump on and off, but it makes the class system uniform later on, when we add data logging.
FYI, discussion is going on here: https://github.com/Manuel83/craftbeerpi/issues/67
Fork the project, switch to a suitable license, submit a pull request. If any contributor has a problem with the new license... who knows.
The license as it is now isn't going to stop bad guys from trying to profit from it. @Manuel83 is probably just acting in fear with the current license.
Look at Android. Google's using the Apache 2.0 license which is as open as you get. How many man hours do they have into Android? They aren't afraid of anyone turning around and trying to sell it on them. There's no business in that besides tricking a few people. The real deal is free in every sense of the term.
I believe it is clear that people looking for a true open source solution need to move on.
The author has created the repo for v4 and it uses a similar terrible license clause.
https://github.com/Manuel83/craftbeerpi4/blob/master/LICENSE It is MIT with a “Commons Clause” License Condition restricting selling. This is by definition NOT an open source compatible license by any means.
There was a lot of discussion/backlash around this type of license when Redis moved its core modules to this license. https://jaxenter.com/redis-commons-clause-open-source-148558.html
Agreed, I think Manual just doesn't understand how software licensing works. And personally I gave up trying to explain. The clause shows lack of understanding of what Open Source means.
However starting from scratch would require, or migrating to something and building on top of it would take require someone to initiate this, I am willing to lend a hand with deployment on a RaspberryPi and shipping distros.
Any input into how the controllers, etc. should be drawn on the web page ? I'm thinking an HTML5 Canvas ? Someone want to take this on ?
If each UI object (controller, pot, switch, element) is it's own canvas then people can develop custom UI elements for their custom controllers. Or reuse an existing one, as long as it has the right IO, etc. I'm new to the canvas object, but I think it does everything we need it to do. Developers can add special effects like change the color of a coil to match the duty cycle controlling it, etc.
How is the web UI done in CraftBeerPi ? What tool was used to generate it ?
The CBPi Ui is based on ReactJS. Is there a solution to have 2 licenses? One for private use and one for commercial use?
Please explain to us why you want this software open source for non commercial use and non open source for commercial use.
The CBPi Ui is based on ReactJS. Is there a solution to have 2 licenses? One for private use and one for commercial use?
Yes, you could have two septate license, one for commercial and one for non-commercial. I think I mentoied that to you in the user group on Facebook> However, restricting commercial use means the license is not Open Source. Open Source means other people can sell it, but if they make any changes they must release them back to the community.
@linuxguy123 @guysoft Gents, I'm wondering if you have made any headway in the discussion of building a proper open source replacement? I too have had the same concerns, and have made edits in my own offline repo, for the same reasons (as I'm sure everyone has too since there's no merges or maintains happening). PM me, I'd like to toss my hat in the ring for a true FOSS replacement.
