1. 22
  1.  

  2. 6

    I wouldn’t consider the LGPL to be a bureaucratic or a bad license. I certainly wouldn’t want to use a proprietary graphics library; nor would I want to see my contributions to a library made proprietary. The GPL & LGPL create a software commons, which is pretty awesome.

    1. 5

      This is a popular point of contention. It’s like VIM vs. Emacs. These days I release under effective public domain (I can’t place anything in real PD in my jurisdiction) because I take whatever chance I can to have other people finish or build on top of my work in any form whatsoever, and screw attribution. They’re free to add any arbitrary restrictions if it makes them happy.

      1. 3

        It’s really nothing like vim vs. emacs. Vim vs. emacs is a matter of opinion and is about personal preference. Licenses are the opposite: if you support one over another you should be able to back that up with good reasoning.

        because I take whatever chance I can to have other people finish or build on top of my work in any form whatsoever, and screw attribution. They’re free to add any arbitrary restrictions if it makes them happy.

        If you’re fine with people taking your work and using it to abuse end users that’s for your conscience to deal with and not mine, but don’t pretend that it has anything to do with how ‘bureaucratic’ a license is.

        1. 1

          Why not just do a BSD-like license since public domain isn’t a thing in some countries but it is? If public domain isn’t always recognized, then putting stuff in the public domain might go against freedom or uptake given it limits who might use the work with its uncertainty. Whereas, people see BSD or MIT, they go “Hell yeah! Nothing to worry about!”

          1. 4

            The stress is on “effective”: 0BSD erases 1 half-sentence from the ISC license I used before.

            1. 1

              Ok, so it is licensed instead of just public domain. I didn’t know about that license either. Thanks for the tip!

        2. 1

          Agree. I got the impression that a lot of stupid would follow, as soon as I read this gem:

          Why C? It’s a clean, rather simple language that I’ve ‘mastered’ at one point […]

          “Mastering C” and thinking it is “a clean, rather simple language” are at opposite ends of the knowledge spectrum.

          1. 7

            I think what the author meant is that at some point you learn enough of the C language that you’re able to read and understand 99% (maybe 100%?) of C code. The language is small enough and changing at such a slow pace that it’s possible to “master” it. I agree with the author that C is a clean and simple language perhaps made slightly dirtier with the incorporation of the preprocessor and various preprocessor macros but those are usually used sparingly.

            1. 0

              Then either all C developers must be trolling us with decades of security issues and crashes in their software, or describing C as “clean and simple” is an idea limited to people with the mistaken believe that they mastered the language.

              1. 3

                Just because a language doesn’t have facilities to reason about complex mechanisms expressively doesn’t mean it’s not simple. It’s a simple, clean, and flawed language. These things are orthogonal.

                I think that there’s an extremely popular Unix-bias in online programming communities where all complexity is viewed as the same thing to be avoided without realizing that a lot of what you want to express is actually quite complex to express correctly.

          2. 1

            Though the problem is Go is always statically linked, so wouldn’t the application have to be LGPL then too?

            1. 5

              Actually, not always. Cgo is typically used with dynamic linking, and pure Go can also link dynamically since 1.5. I haven’t experimented with it yet.

            2. 1

              Yeah there’s nothing at all ‘bureaucratic’ about any license. They’re all as bureaucratic as each other.

            3. 2

              I must draw attention to a big problem with developing a whole new GUI toolkit: Your applications won’t be accessible to people who need assistive technologies, e.g. blind people with screen readers. Unless, of course, you implement the host platform’s accessibility API. For modern Unix desktops, that API is called AT-SPI, and that’s based on D-Bus.

              But if, like the OP, you’re just using this for personal tools, it’s not a problem. And writing a new GUI toolkit is certainly a good learning exercise.

              1. 2

                If someone wants to email the author a patch that fixes those problems I’m sure they’ll happily accept them.

                1. 1

                  Yea I see posts like this more of an educational/curiosity more than anything else .. although I wonder how many curiosities turned into big OSS packages. Samba was definitely one of those.

                2. 1

                  Dang it, I just saw the author’s comment that he’s not necessarily ready to share this w/the public yet. Can we delete this please?

                  1. 2

                    It’s still a nice summary of the starting point with helpful links. People can build on this. It might also make them think or inspire action. So, it still has value here.

                    1. 1

                      It’s fine, I’ve just reacted to that one comment, and added Double buffering notes this week.

                    2. 1

                      I do like how the author mentions Wayland, even though the post goes down the X11 path.

                      I can understand this. I have some FreeBSD/OpenBSD machines and I think it will be a while before we see devs porting Wayland to replace X on those systems. (The Docker port for FreeBSD would be more useful honestly, but that hasn’t been maintained since the big Docker modular refactor).

                      I can see the author’s choice for an experiment/writeup like this considering there is a lot more X documentation out there.