This one is something that were brought up a lot by developers including me who are very weary about corporations profiting off of our work for free and this basically put us off from contributing to open source in general.

We get a bunch of dialogues about this such as:

Developers like me: “Many of us who create are concerned about our work being exploited. The possibility of corporations profiting from our open-source contributions without giving back to the community disincentivizes us from participating in such endeavors.”

Open-Source Advocates: “The AGPL exists to mitigate such concerns. It requires derivative works to also be open-source.”

Developers like me: “While I appreciate the intention behind AGPL, there is a loophole - a ‘condom code’ if you will. Even though Linux Kernel prevents such strategies by refusing to merge these changes and that it’s difficult for a singular corporation to force an adoption of a forked version of Linux Kernel, a corporation can fork our much smaller project however and introduce such legal bypass to the copyleft restrictions. This bypass can be justified by them under the guise of extending the software’s capabilities with a plugin interface or an interprocess communication protocol layer, similar to how PostgreSQL allows User Defined Functions. However, I must caution that I’m not well-versed in the legal intricacies.”

When bringing up on non-commercial clause for licensing

Open-Source Advocates: “Disallowing commercial use of your project contradicts the principles of open-source.”

Developers like me: “Well, then perhaps we need a new term, something like ‘Open Code Project’. We can create projects that encourage collaboration and openness while also restricting commercial exploitation.”

So I created this post, because we do need to discuss on a path forward for Open Source in general knowing that corporation can shirk around this restriction and discourage developers like me from participating in open source or open code projects.

  • MJBrune@beehaw.org
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    1 year ago

    Simply put, for works you want to prevent from being commercialized by other companies. Don’t open-source it. Keep it closed source. If you feel like it, put an email address out there and say something like “if you want access to the source, let’s talk.” It requires you to vet everyone who has access but if you are wanting to be that guarded with your code then that’s what you need to do.

    That said you could just BSD/MIT license your code. If your project is small it’s unlikely to even be noticed. In the end, any license you create that offers the source code without applications means it’s open for any corporation to just take. Regardless of the code license. The fact is that you are a small-time developer and don’t have the power of lawyers to counter them. So either open your code for everyone, vet each entity you open the code for, or don’t introduce the headache of dealing with any of this and keep it closed. Tell yourself you will open the source later on after you are done with it.

    Realistically, these are your options. There are plenty of creative commons or such licenses that exist to exclude commercial works but again, lawyers cost money. If you aren’t willing to fight the battle you might as well CC0 the code because that’s essentially what it is.

    • TheTrueLinuxDev@beehaw.orgOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      You sum up what I thought about as well, yep. There are compromises to each license and obviously the loophole that is presented for each one. One of the idea I was exploring is licensing my GUI Toolkit (alternative to GTK and QT) something similar to Community License in Visual Studio (it allows commercial use for personal/small business and if organization is larger than that, then it would have to purchase a separate license.)

      • MJBrune@beehaw.org
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Check out Epic’s Unreal Engine License. Essentially after a certain amount of income they require revenue percentages from sales of the product. You could likely do something except as a flat fee rather than a percentage of sales. Again, though, enforcement takes money though. Is your GUI toolkit so revolutionary that people will even use it? It’s more likely to get more people using it if it’s open source but of course, it means you can’t really monetize it to commercial projects.

        • TheTrueLinuxDev@beehaw.orgOP
          link
          fedilink
          English
          arrow-up
          0
          ·
          edit-2
          1 year ago

          I don’t think it’s that revolutionary, but there are some things that doesn’t exist in current GUI Toolkit worlds.

          The GUI Toolkit I wrote utilize few things:

          1. It runs on Vulkan and the pipeline use custom developed 2D rendering context, not 3D so there is a significant boost in performance and reduction in computation requirements on both GPU and CPU. Vulkan allows GUI to work on just about any devices made in the last decade and can fallback on CPU using Swiftshader.
          2. I established FFI-JSON to simplify binding for any programming languages to bind to my GUI Toolkit as well as extending the GUI Toolkit itself.
          3. Designed for Buffer-based controls - If you want to load up a 2GB text file into a textbox, it offers a way that it would work without freezing up the program.
          4. Accessibility protocol in IPC - Similar to DBus, but documentations are provided to simplify the process of utilizing such protocol and it’s focusing on cross-platform conventions where Dbus might not be available.
          5. Library itself is Cross-platform and written in C Language, enabling the larger cross-section of compatibility
          6. The project is built for IR linkage purposes hence why the code should be open source, because the code is already open by IR anyway. By offering IR linkage by default rather than Object files or dynamically linked library, IR allows everyone to gain immense performance boost through compiler’s features of auto-vectorization, dynamic dispatch converting to static dispatch when possible, internalization pass and more aggressive dead code eliminations. It’s not unusual to see a 80% reduction in code size through this process and see as much as 10x performance improvement compared to dynamically linked libraries.
          7. Conventions for stylizing/theming the GUI through CSS (the goal is to offer a permanent theming capability in GUI even though it can be a challenge to maintain.)

          That on top of my head, I wanted to have a GUI that focuses on making it easier to extend while keeping it conventional for those familiar with Windows Forms on Microsoft Windows and eventually WPF if time allows.

          That the gist of why I wrote my GUI Toolkit and I have spend 4 years working on it, it’s reaching the point that it could be ready for prime time basically.

          The licenses you brought up is interesting and it could work too.

          • MJBrune@beehaw.org
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 year ago

            Okay, now I am interested in learning more about this GUI toolkit even though I am a game developer, not an app developer. Got a website or such?

            • TheTrueLinuxDev@beehaw.orgOP
              link
              fedilink
              English
              arrow-up
              2
              ·
              1 year ago

              Currently early atm, but generally, I got the backend code sorted out where we have cross-platform windowing context, vulkan code, accessibility protocol, and so forth. The challenges are the front end GUI, making it looks pretty, it’s still have a way to go.

              And of course the documentation which is still WIP. I wrote other docs sometime like this for C language development community which I have put off for a while since I worked on few projects:

              1. Finish making deliverable for AI Framework to replace Pytorch/Tensorflow that uses IREE Compiler for my client. (IREE Compiler basically takes in your MLIR code and compile that to either SPIR-V shader code, CUDA code, ROCm, or anything else really rather than just mainly CUDA on Pytorch/Tensorflow.) I should have this done by tomorrow, it just making a web for my client that is 90% done and I just have to plug my AI into it.
              2. Work on Melosynthos which is basically a Compiler Generator, it’s about 60% done and can help a lot on building unit tests for GUI Toolkit.
              3. Finish up GUI Toolkit and try to make GUI that takes some inspirations from this
              4. Finish up documentations for that GUI Toolkit
              5. Build a web to demonstrates GUI Toolkit and let people go nut with it.

              The best part is… I solo-develop all of it… facedesk