I would have preferred Rust, a language created by Mozilla instead of one with ties to Apple, but I’m not a dev so I can’t really judge. What are your thoughts?

  • JustMarkov@lemmy.ml
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    20
    ·
    3 months ago

    If I wanna modify and redistribute their language and use Rust or Cargo in the name I should not have to ask for an explicit permission, this is the freedom 3 problem.

    This is also why I gave Python and Perl examples. I can modify both Python and Perl, calling them the same way, but I can not do the same thing with Rust.

    I’ll leave their trademarks comparsion under the spoiler for those, who interested.

    Spoiler

    Rust:

    Distributing a modified version of the Rust programming language, compiler, or the Cargo package manager with modifications other than those permitted above and calling it Rust or Cargo requires explicit, written permission from the Rust Foundation.

    And Python:

    Use of the word “Python” when redistributing the Python programming language as part of a freely distributed application – Allowed. If the standard version of the Python programming language is modified, this should be clearly indicated. For commercial distributions, contact the PSF for permission if your use is not covered by the nominative use rules described in the section “Uses that Never Require Approval” above.

    Let’s also look at Perl:

    People sometimes ask if TPF’s use of an onion in the Perl logo means that independent projects that use or relate to Perl need TPF’s permission to use an onion of their own design in connection with their project. ​ The answer is “not necessarily” as long as no likelihood of confusion is created. One of the fundamental legal bases for trademark protection is to make sure that the public can depend on a mark as an accurate indicator of a particular source or relationship, and one way of defining trademark infringement is to say that the infringing mark creates a likelihood of confusion. Likelihood of confusion is determined based not only on making a comparison of the marks side-by-side, but also on making a comparison of the contexts in which they are actually used. Thus, it’s easy to imagine independent onions that would be fine, and independent onions that might not be.

    • Jim@programming.dev
      link
      fedilink
      English
      arrow-up
      24
      arrow-down
      1
      ·
      3 months ago

      Please read this and try again.

      https://www.gnu.org/philosophy/free-sw.en.html#packaging

      Rules about how to package a modified version are acceptable, if they don’t substantively limit your freedom to release modified versions, or your freedom to make and use modified versions privately. Thus, it is acceptable for the license to require that you change the name of the modified version, remove a logo, or identify your modifications as yours. As long as these requirements are not so burdensome that they effectively hamper you from releasing your changes, they are acceptable; you’re already making other changes to the program, so you won’t have trouble making a few more.

      • Norah - She/They@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        8
        ·
        3 months ago

        Yeah, I don’t exactly think it’s particularly burdensome to have to rename your fork so that people don’t confuse it with the software you forked from. Without this restriction, FOSS projects would have absolutely zero recourse against bad actors. A non-FOSS competitor could just waltz in, fork their code and turn it into absolute hot garbage, convincing enough people that it’s the original project to make it all worth their while.

      • JustMarkov@lemmy.ml
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        9
        ·
        3 months ago

        Please read this and try again.

        Try again what? This is a debatable topic. I can simply refer to this line:

        As long as these requirements are not so burdensome that they effectively hamper you from releasing your changes, they are acceptable;

        And point out, that rebranding a whole programming language is not a piece of cake. So this is burdensome and hence is the issue for freedom.

        • Jim@programming.dev
          link
          fedilink
          English
          arrow-up
          7
          ·
          3 months ago

          Dude, if you’re being obtuse on purpose because you have an ax to grind against Rust, try a different approach. You’re not getting anywhere, clearly by the fact that no one agrees with you.

          If you don’t like that Rust has a restricted trademark, then call that out instead of trying to label the software and it’s license as non-free. It’s literally called out in my source that name restrictions ipso facto does not violate freedom 3.

          But if you genuinely believe that the implementation of the Rust language and it’s trademark is burdensome to create a fork, and you want people to believe you, then you gotta bring receipts. Remember, the benchmark that we both quoted is that it “effectively hampers you from releasing your changes”. It being “not a piece of cake” doesn’t cut it.

          Hint: Google Rust forks since their existence also undermines your claim.

          Good luck.

          • refalo@programming.dev
            link
            fedilink
            arrow-up
            3
            arrow-down
            1
            ·
            3 months ago

            As an outsider with no skin in anyone’s game, I find it a bit disingenuous to say that one person’s interpretation of subjective terms is somehow less “correct” than anyone else’s.

          • JustMarkov@lemmy.ml
            link
            fedilink
            English
            arrow-up
            2
            arrow-down
            2
            ·
            3 months ago

            Remember, the benchmark that we both quoted is that it “effectively hampers you from releasing your changes”. It being “not a piece of cake” doesn’t cut it.

            The easiest example is that you’ll have to adapt all Rust-dependant applications to the Rust fork, 'cause it is a programming language.

            But still, don’t get me wrong. I’m not trying to say that Rust is a bad language or something. I’m just trying to point out on the problem, that was adressed to Rust Foundation before.

            Good luck to you too.