Version 1.0.1: release source code and tag it

[rodolforg]

Related: #4047 #3881

Please comply with GPL v3 license the source code is released under.

[johnBrereton]

What is the status of this, is Fritzing still open source? The latest update to this repo is June, but the latest version on the Frtizing website (1.0.1) was released in September.

[rodolforg]

I don't know.
The project has 65 contributors listed in this Github page.
Did they agree on the license changing of their contributed code ?

[cgobat]

Bumping this. @KjellMorgenstern et al., this is pretty serious. Unless the recent v1.0.1 is no longer released under the same license as Fritzing ≤1.0.0 (in which case that should be clearly disclosed), the terms of the GPL require that source code be made available to the public. It has now been over a month (nearly two!) since the release of the 1.0.1 binaries, and the corresponding source code is still not available. This should be rectified as soon as possible.

[ashtana]

When I try build app from this repository...
I got to this error:
\fritzing-app\src\sketch\zoomablegraphicsview.cpp(89): error C2039: 'device': is not a member of 'QWheelEvent'
I to comment all code where been variable device(), but I got new fatal error LNK1104: cannot open file 'quazip1-qt5.lib'

[cgobat]

@ashtana I'd recommend that you open a new issue—compilation errors don't really pertain to the discussion here.

[ashtana]

@ashtana I'd recommend that you open a new issue—compilation errors don't really pertain to the discussion here.

I'm sorry. Yes, of course.

[cgobat]

No worries, just want to keep things on-topic here given the importance of this.

Pinging @KjellMorgenstern again. Any update on where things stand?

[FREEWING-JP]

Pinging @KjellMorgenstern again. Any update on where things stand?

How to get Fritzing 1.0.0 for free - Compile Fritzing on Windows
https://youtu.be/cC82PULJq6g

[rodolforg]

I think he won't answer.
His history here with Fritzing code and repo says it.
He is constantly tagging issues (categorizing them besides marking them as solved) but ignores this one and the previous one.

We could fork, but maybe he gets the new code and use it not as licensed.

[cgobat]

How to get Fritzing 1.0.0 for free - Compile Fritzing on Windows
https://youtu.be/cC82PULJq6g

I would like to stress that the core of this issue is not the fact that there is a fee to download the installer. That alone is perfectly acceptable under the terms of the GPL, is understandable/reasonable in many respects, and has already been discussed/debated at length on the Fritzing forums.

I/we are not simply complaining about the fact that Fritzing is no longer free (as in "free beer"), but rather that (by not releasing the source code) it is no longer free (as in "free speech"). That is not acceptable under the terms of the license that this application is released under.

I do not know why any developer/maintainer would want to willfully ignore this issue. By violating your own license, it seems like you are only opening yourself and your organization up to possible legal trouble.

Pinging @vanepp @jfmorgenstern @failiz as well in the hopes that someone can get @KjellMorgenstern's attention.

[KjellMorgenstern]

First off, you are right, there is nothing to debate. We released the binary as GPLv3 build. The code I wrote must be made available to anyone who uses the binary, as per the terms of that license.

However, there is a problem.
Constant misunderstandings of the GPL, and the resulting attacks stemming from them, don't make it easier to stick to that license. Fritzing is made possible via payments received through https://fritzing.org . The view of some people that this charge is unethical is bewildering, to say it politely.

It seems to be overlooked, so let me mention one aspect of my ongoing history with the project. With huge support from others, I have clocked in about half the commits in the github-history of this project, and probably more than 95% of what has been coded on it in the last four years, or eight years if you count the time the project was at a standstill. I met and worked with the people who started Fritzing. This isn't just a hobby or a side project, it is a full time job for several. It is a great project to work on, and I try to make sure that contributors are happy, too.
Developers should be able to work on complex Open Source projects, and getting paid for that is important. Only few can (and want to) afford working for free.

With the payment, Fritzing indeed deviates from many Open Source projects, and this makes it a hard sell quite some times. It is not only students who understandably might care about the (small) 8€ payment. Also, big clients use the reasoning that they would not pay (for us working on the integration of features), because it is Open Source. Surprisingly enough, this is not a deal breaker, but certainly slows things down. We even considered and prepared changing the license to adapt for that (something like MIT, or GPL+Fritzing). But after all, I believe it would be great if direct payments for GPLed software would be more common and widely accepted.
We need to find a balance between financial sustainability and the open source ethos.

With the release of Fritzing 1.0.0, several people jumped on the "How to build Fritzing for free" bandwagon. We encourage tinkering, however, it's likely not the best approach if your only goal is to obtain the software. If you're not skilled in Qt and C++, attempting to build Fritzing can be very frustrating, and there's a high chance of producing an unstable build even for those who are experienced.

This topic reemerges in one form or another frequently. If you are interested, please also see my post not so long ago https://forum.fritzing.org/t/can-t-find-source-code/19723/7?u=kjellm

I'll prepare something for the github README as well, so hopefully less energy has to be spend on these questions.

[cgobat]

Thanks for addressing this. There is no need to justify the existence of the payment to me—I have no qualms with it, especially if it's what enables development to keep happening. This issue is solely about the availability of the source.

I think that your quote

We released the binary as GPLv3 build. The code I wrote must be made available to anyone who uses the binary, as per the terms of that license.

is all there is to it, full stop. It would certainly be nice if you could tag it, but I guess that is not technically required by the license.

I will echo exactly the points made by folks in response to your message on the Fritzing forums that you linked:

roboteach
Thanks for the explanation @KjellM. No complains here about the 8€ fee (more than happy to pay) but, the same as @gsgx, I share with him the idea that

gsgx:
open-source projects should be developed in the open

I think if you are interested in not having to spend so much energy dealing with these kinds of questions, the best solution would be to simply keep the publicly available source code up to date, rather than doing development behind closed doors and making your community try (and fail) to get your attention for a month or more after each release. The essence of free software (in the GPL sense) is respect for users. I don't think that any of #3881, #4047, the question about 1.0.0 on the Fritzing forums, this issue here, or any of the numerous others dealing with the same topic (as you noted) would had to have been raised/asked if a more open dialogue had been maintained and sources had been published with releases from the start. This is not to mention the fact that I'm sure a more open development model would encourage contributions from more people,¹ which only makes Fritzing better for everyone in the end.

As for your explanation of why you don't keep the GitHub repository up-to-date,

a single CI run could easily cost more than $10 there.

I frankly have no idea where this figure comes from. GitHub provides 2000 minutes of free CI, each month.² Even then, GitHub charges for increases to that number by the month, not per CI run. Many, many free software projects with many more PRs and more regular commits than Fritzing use GitHub's CI just fine. Plus, there are not even any GitHub Actions in this repository, so I am simply confused by that justification.

I'd like to conclude by saying I do appreciate you and the work you've done for this project. Don't get me wrong—Fritzing is a fantastic resource and tool—I just think an adjustment to the development philosophy would serve everyone better: we wouldn't have to spend weeks begging for source code, you wouldn't have to spend so much time dealing with people begging for source code, users/community members would feel more welcome to submit contributions of their own, etc.

Footnotes

1. The number of currently open issues is greater than the all time number of pull requests in this repository. This is quite unusual for a popular open source project, and I think is indicative of an environment in which community members do not feel as welcome to contribute as they could. ↩

2. See Pricing ↩

[the-exodus]

Chiming in.

I'd decided to use Fritzing as a tool while learning electronics from watching some video reviews alone, and it being foss was a large contributing factor. I was just about to pay the neglectible download fee, but wanted to make sure it would build first as I have some ideas on features I'd like to add.

Lucky thing I did. After spending an inordinate amount of time on tracking down the undocumented dependencies and getting the build to find them there were still some issues. Since the documentation about building was so hideously out-dated (I have a PR updating it about 95% done) I figured I'd missed something and came to check the issue tracker for clues, finding all this about private repos etc.

There's absolutely no way I'm paying for this without being able to modify (and preferably contribute to) it.

I completely understand the difficulties with people only wanting the source code so that they can avoid paying for it, but this just isn't the way to handle things. I fully agree with @cgobat , and in addition to it would suggest that rather than making the application code unavailable, wouldn't it be simpler to just put the parts download behind a login? The app is useless without them, and by changing the license on those now anyone using a foss licensed version would miss out of any additional spice stuff?

I really want to be able to use this. Please make it possible.

[KjellMorgenstern]

@the-exodus Build system is a bit off topic for this issue. Not sure how hiding the part database would be a good idea. Revenue for creating parts has been tried several times, it doesn't work at this scale. Also getting off topic, but one future idea is rather to integrate with 3rd party part providers.

The source code is up to date. Closing this issue.

[rodolforg]

The view of some people that this charge is unethical is bewildering, to say it politely.

I, and I think nobody in this issue, didn't say you can't or shouldn't charge.

With huge support from others, I have clocked in about half the commits in the github-history of this project, and probably more than 95% of what has been coded on it in the last four years

I'd like to point some stuff here:

• Recently the code was never with the releases; issues are closed/solved (mostly by you); (very few ☹️ ) PR are merged, but the current code isn't available. Contribute to something that is not up-to-date can be meaningless or useless, if issue can already be solved or code changed enough to be difficult to merge a PR
• The current build system/script is horrible and how the dependencies are handled too. You need to know where place a folder of QuaZip, the fritzing-parts folder (instead of a git-submodule, for example). It doesn't help new contributors.
• Some (very few ☹️ ) PR here are ignored without any answer; example: Fix leaks #4017 - and work done there could be pointless, because the source code he based on wasn't up-to-date.

a single CI run could easily cost more than $10 there.

I follow @cgobat words here. From Github pricing page:

And it works for macOS and Linux. For MS Windows, I use AppVeyor, also free for open-source:

You can and could try to use services Patreon, Ko-fi, Buy Me A Coffee to try to get donations too; some users probably would contribute monthly if they work is being done.

Anyway, I intended to help the project: I started to ease the building system and to change it to Qt6. But now I understand your point to make it fuzzy and your business model. It wouldn't be good.

Anyway, congrats for your effort and good work being done in Fritzing. I'll skip now to new found librePCB project.

We even considered and prepared changing the license to adapt for that (something like MIT, or GPL+Fritzing).

PS: note that Qt isn't really free if your code is not GPL:

https://www.qt.io/licensing

https://www.qt.io/pricing

[the-exodus]

@KjellMorgenstern the idea was that closing the parts library is that it would render the app useless for anyone not paying, as they would have outdated parts. That way you could keep the app itself open, but only usable by paying users.

But i hear you, I think, saying you're happy without contributions from the public. That's a perfectly valid choice, albeit one I wouldn't have made, and all it means is that I have to look elsewhere for something that provides both usable schematic editing and spice. I'm sure you'll do just fine without me :)

Best of luck!

[KjellMorgenstern]

For future readers.
Please use forum.fritzing.org for discussions.
We have tried many of these things, almost word by word everything that has been suggested here, years ago. TravisCI, CircleCi, AppVeyor. Donation services. It did not cut it.

Changing the build system or the business model is not a minor tweak. It is something I am happy to discuss with people who are deeply involved with the project. I'll try to improve the README for people who stumble across the project for the first time.

We are on Qt6 since the 1.0.0 release. Like most Qt applications, Fritzing has that info the "About Dialog". Actually, that is one of their license requirements "...& explicitly acknowledge Qt use". Of course, we are aware of these.
Changing from open to commercial Qt license is usually not possible, and not intended, and moreover, not needed. So the link to refer in this topic would be https://www.qt.io/download-open-source instead.

[rodolforg]

Changing the build system or the business model is not a minor tweak. It is something I am happy to discuss with people who are deeply involved with the project.

Sorry. If you are in trouble to change the build system, maybe this draft file helps you: CMakeLists.txt. I took me exactly 43 minutes to write it and test it, because I'm a Autotools guy, so I started to read CMake official docs, and then I discovered Qt already directs how to do it since Qt5, remembered what the (chaotically named) Qt dev dependencies I had to reinstall (because I "hate" them), and to successfully build the project on my Linux/Debian.

The missing dependencies in my Debian testing machine were :

qtbase5-dev [libqt5concurrent5 libqt5opengl5-dev qtbase5-dev-tools]
libqt5svg5-dev
libqt5serialport5-dev
libquazip1-qt5-dev [libquazip1-qt5-1]
libsvgpp-dev [libboost-chrono1.74-dev libboost-chrono1.74.0 libboost-timer-dev libboost-timer1.74-dev libboost-timer1.74.0]
libngspice0-dev [libngspice0]

If you don't have time to take a look, please show to people who are deeply involved with the project to your profit but for some reason didn't have time or interest to do it.

No, I didn't test it on Windows, but it should work with MSYS2 (except svgpp....).

We are on Qt6 since the 1.0.0 release.

Yes, I read it from the source code.
When I wrote "Anyway, I intended to help the project: I started to ease the building system and to change it to Qt6." - I was referring to when I intended to help the project back on 0.99.9 release-ish. But I gave up when things became not OK to me after 0.9.10 hidden/delayed sources and only binaries were available.