Those were non-destructive comments so there is no need for me to reply to them, and also I wonder what you mean by this:
"For every one bug fixed in the current
implementation we probably could write a third of a replacement UI."
Can you elaborate? Do you mean the code is too messy to fix quickly? Or that the bugs are too hard compared to new features? I'm confused.
your definition of free.
fall into your definition of free.
When it comes to software, there are not multiple definitions of free.
https://www.fsf.org/about/what-is-free-software Thanks to the resource
you talked about, LibrePlanet, you never have to wonder whether
something is free software or not - so it doesn't need to be made into
such a big deal (or made to look like it's my personal definition).
I'd have something to say about that, but it doesn't belong here. So let's
just leave this.
parts of Chromium again, it probably wouldn't solve your problem
JavaFX with WebKit and all its libraries may not
So to sum it up quickly: Chromium's code is free, though the package has
freedom issues. Using the Embedded Framework that happens to share some
with it shouldn't bring its status into question.
Well it might just end up the same as the complete Chromium package if there
are files in CEF that lack a certain formatting of the license header.
OpenJDK is also perfectly free, I don't know why you would doubt it.
Yes, OpenJDK is. Java however is not because AFAIK the TCK is still not
freely licensed. WebStart, though less and less used, is AFAIK still not
I'm actually surprised not find anything related to Java on that page you
linked. I'm not - perhaps you missed the news that Sun freed Java 10
years ago. http://www.fsf.org/news/fsf-welcomes-gpl-java.html For any
more questions on Java freedom see:
They started open sourcing it 8 years ago. The last "binary plugs" were only
removed 4 years ago and JavaFX (or OpenJFX) only made it binary free (at
least I hope there's nothing left anymore) some months ago.
Now that that's covered, I find it interesting that you say
There's also a technical problem which we're not sure we can solve at all
because the feature works currently. What's wrong with it the way it
works now? Sure it can be rewritten better, but so can anything, and
something that works is better than nothing. If you don't currently have
the resources to reinvent the wheel then at least keep the current wheel
The point is: we cannot keep or make the current version bug free because it
became next to unmaintainable. For every one bug fixed in the current
implementation we probably could write a third of a replacement UI.
And for me (I don't work for BlueJimp) there IS some fun involved. When it
comes to anything related to Swing I'm trying to avoid it. It simply causes
too much frustration and wastes too much time that could be spent better.
We can take our time when it comes to funding the other
changes, there's no rush.