Follow

why is the "Proprietary" license-badge in the :ubuntu: softwarecenter green?

@milan
Weil die blöde sind! Das sollte orange/gelb oder so sein!

@milan How does the licences badge for Free Software looks? Green as well? Didn't used Ubuntu for many years now.

@bjoern @milan The badge is always green disregarding it's title. 🙄

@vinzv @bjoern @milan Black will be the right color – black like death – death for a better world.

@milan lets face it: because ubuntu endorses proprietary software. Just open the software center and have a look what they "feature".

@milan good point, I bet @popey might be able to look into getting that fixed.

@ted @milan To fix implies it's broken, which it isn't. It's a button in GTK land. We use the same colour for the channel button above it. Upstream chose to colour it red, we chose not to do that.

@popey @milan sure, you don't have to make it red. It could be grey for instance. Or desaturated version of the GTK theme's color.

I think the value here is to give a visual signal that free software is better. You don't need to mark proprietary software as 'red' or dangerous, but you can visually promote better choices.

So 'fix' is perhaps wrong. But, I think the visualization can be improved.

@ted @milan Sure, I understand why it's done. Now we start a conversation about defining "better". A bug ridden free software app is always "better" than a functional and beautiful proprietary one? We show the license type / text so users are empowered to make the choice. We don't judge. Putting a red mark implies "bad", and we didn't like that. (for the record, I filed the bug to get it changed from red to green)

@popey
*Insert the four essential freedoms of free software and their implications*. That's objectively better.
@ted @milan

@KekunPlazas @ted @milan Better for whom? The person who actually wants to join their team on a Slack call, or wants to sync their data with others on the same platform? I'm not about to get into an argument about Free vs Non Free software on a social media platform at 1am in my holiday thanks.

@popey @milan certainty when you consider the entire product there is more to consider than just the license. But here we are just talking about the visualization of the license field. Which is a simpler discussion.

I would agree that making proprietary red isn't fair either, but the western values associated with green are 'good' and 'go', which is saying it something you should do or find positive.

@ted @milan I agree that they shouldn't be coloured at all, or should be neutral. We recently did a lot of design work on GNOME Software - much of which is submitted for review and discussion on the GS gitlab. We presented different ways to show these fields. We will never please the fanatical FSF subscriber, but we can allow users to make informed decisions.

@popey @ted @milan Its not about "judging" or empowering users at all. Its not colored upstream cause GNOME is principled, and its *following* its principles on the Software it creates. Software Freedom is a principle of GNOME. See Allan's post:
blogs.gnome.org/aday/2017/08/0

Canonical is a multi-million, for-profit conglomerate that wants to make money.

Clearly different goals there. The problem there is that in this context its not distinguished that this is *Ubuntu* software, not *GNOME* software.

@alatiera @ted @milan We discuss these changes with GNOME Software devs, and work with GNOME devs all the time. Don't think we don't know the world in which we work.

@popey @ted @milan
Regardless of your political position regarding the licensing, making the button always use the suggested action regardless of the text in the label brakes the UX of the app.

What provides the "green" color is the "suggested-action" styleclass, and the "destructive-action" make it red accordingly.

It was designed that way upstream, cause its GNOME software and GNOME clearly has a stance on software licenses.

@popey @ted @milan
Patching the app downstream to always use the "green" color makes it so the styling is meaningless since its always the same. It brakes user expectations from the "suggested-action" styleclass widgets and leads to confusion and degrades the overall UX. This, in its current form, is clearly broken and needs to be fixed IMO.

Point being, if you want to downstream patch it to make it neutral, go ahead. But at least *don't* brake the UX of the app.

Sign in to participate in the conversation
Mastodon

One of the first Mastodon instances, there is no specific topic we're into, just enjoy your time!