34
Slint 1.14 Released (slint.dev)
submitted 1 year ago by to c/rust@programming.dev
21 comments fedilink hide all child comments
 

Universal graphical transforms, better async python integration, unified text layout, and more.

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 1 year ago (7 children)

But you do get all code under GPL, which you seem to agree is a freedom preserving choice. That does make Slint free software and as save to use as any other free software project out there.

The story is a bit different when you want to contribute to slint. Slint is not a even playing field for contributions. The company has an advantage in that if can use all contributions as MIT and you can only use the companies changes under GPL, commercial, or royalty free terms.

As a contributor you need to decide whether you contribute to the slint repository, or maybe write an add-on library which you are free to license as you see fit.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 1 point 1 year ago (6 children)

    I'm not sure if you're reading my message well?

    I'm saying that GPL-licensed *projects* protect themselves well. If you lean on a GPL project, it's likely going to hold. Not disappear because of a commercial incentive. Non-copyleft projects tend to disappear if they become valuable to companies, such as IntelliJ's Rust plugin, or BSD => MacOS.

    Again if you're developing a non-open-source project, Slint is fine. You'll be bound to each other with mutual commercial interests.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 1 year ago (5 children)

    You are fine with a free software project using Slint as well: Slint is a GPL project, with everything that implies. The releases are out there and the slint project is bound to the terms it released them under. In theory we could release new versions without the GPL option, but we can not take the sources of the released versions away. Neither the other licensing options nor the contribution rules change that. If youbare happy with GPL dependencies, you can use Slint just as any other GPL dependency, with the same risks and benefits.

    The copyright holders of any GPL project can decide to relicense their (future) releases. I admit that it is a bit simpler in Slints case due to the contribution rules, but other projects have similar rules in place. Copyright assignments, CLAs, ..., they all exist to simplify a possible future relicensing effort. And even GPL projects without such provisions in place have manged to relicense before.

    As a user of Slint you typically never get into contact with our contribution setup at all. Only a contributor might pause and decide not to spend time on Slint due to that. IMHO that is entirely normal: I use tons of free and open source projects that I would never contribute to -- for various reasons ranging from contribution terms, to programming language being used or the projects community.

    In many cases you can also publish slint related code in your own repository under whatever license you like. While this obviously does not work for core functionality that has to live in Slint itself, it does work for a wide range of things you might want to make available (like new widgets, ...).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 1 year ago* (last edited 1 year ago) (4 children)

    I think we can't find an agreement on our angles on the topic so much that it's simply not constructive to push the conversation further. I'm afraid that if I'll try to say anything now, it'll be a repetition of what was already written earlier.

    In short, I see Slint as a not GPL project (but rather as a commercial project that happens for now to triple-license the code and includes GPL). I see GPL projects as fundamentally different to Slint, in a sense that, once you have enough external contributors, you simply cannot revert back and stop being a GPL project, whereas in Slint I see it as possible. I trust GPL projects and I know I can "lean" on them, whereas I'd advise to rely on Slint only if you have commercial entanglement that you want to keep.

    I'd propose to agree to disagree.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 1 year ago (3 children)

    So to be a GPL project you need to be able to trust the project to release all future releases under GPL in addition to having released existing code under GPL?

    I do not like this approach:

    First of, you need a crystal ball to decide whether a project is GPL or not: Some projects managed to pull off a license change before, just by asking devs whether they are ok and replacing code from devs that did not agree. Its rare, but it happens, so checking for CLAs, copyright assignments, ..., is not enough.

    Secondly this definition excludes lots of projects that release their source code under GPL, including the GNU project. They ask for copyright assignment, both to defend the GPL license, as well as to be able to relicense when weaknesses in the current licenses are found. I give you that GNU is probably way more trustworthy wrt. not changing away from the free software spirit than some random company.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 1 year ago* (last edited 1 year ago) (2 children)

    Some projects managed to pull off a license change before

    I think you're right, the reality is not actually so black-and-white. With the GNU project indeed being a notable "exception" of sorts. And, while I can't think of any single project that would change from GPL and still be alive, I think I've heard about at least attempts of doing so once, more than a decade ago, not too successful IIRC.

    So to be a GPL project

    But to answer the question.. I'm not trying to say what is a GPL project. But sometimes I can tell when something isn't [a GPL project], and Slint isn't. It doesn't revolve around copyleft and its ideology. Neither is MySQL. MariaDB is. MariaDB is easier to fork off MySQL than it would be off Slint though. Slint has much broader API, more evolving too I'd assume (but I don't know).

    So my recommendation on when to use or not use Slint would still hold. And I still insist that it's factually correct to say that Slint is not a GPL project.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 year ago (1 child)

    I revolve very much around copyleft and its ideology. Free software formed my entire career, just as it did for the founders of Slint. From my point of view slint is GPL and offers some other license options for users that do not want GPL for whatever reason.

    Forking slint is just as easy as forking any other GPL licensed project: Take all off slints code under GPL and you are done. Yes, you can not relicense that fork to a more permissive license without replacing all the code that you did not write... but that is exactly the same as with any other GPL project you fork. Any use of Slint under GPL is exactly as using any other GPL project, with the same obligations and protections to all parties involved.

    I get that you are feeling slint is not GPL, but I do not understand where that feeling comes from. Is it "just" because there is a company backing it? Or because that company is selling their product in addition to oing it under GPL? That is fine for the GNU project from all I understand. Or is it because of contributions happen under MIT terms? But that does not effect the end users that the GPL is protecting in any way.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 11 months ago

    I get that you are feeling slint is not GPL, but I do not understand where that feeling comes from.

    I think it's because the for-profit nature of the company may not create an actual community of FOSS enthusiasts around it. So if something were to happen to the business side of Slint-the-company, there would not be a strong community with known leaders and vision to save the situation. It's not like this is guaranteed for FOSS projects, but it's much more likely there. Single-person FOSS projects are scary to me for this reason as well.

    That is the biggest factor for me. (There are other important factors, too.)

  • permalink
  • fedilink
  • source
  • parent