Announcement

Collapse
No announcement yet.

Experiment: system with only GNU licensed software

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Experiment: system with only GNU licensed software

    Since there were some people talking about how they can replace everything with non-GNU tools, and there are BSDs, I came up with an interesting challenge: how far can I get in building an OS using nothing but GNU licensed software ( https://www.gnu.org/licenses/ - so no BSD, Expat, public domain etc. licenses)? I'm using Gentoo as a base, since it has this nice ACCEPT_LICENSE portage variable that allows me to automatically filter licenses out. And it's all in VirtualBox.

    So far it's been going fine, I installed it (deblobbed kernel, GRUB2, GPT and EXT4) and got internet working, although I haven't gone through the effort of replacing the non-GNU base bits with something GNU just yet. There was a bit of a problem with DHCP clients: both dhcpcd and dhcp are under permissive licenses. Thankfully, busybox (GPL-2) includes its own DHCP client called udhcpc which works just fine (busybox udhcpc -i enp0s3 brings it up). Another issue is that e2fstools are also BSD-licensed, which is kind of a problem... I should have used XFS or Btrfs, since both their tool packages are GPL. Oh well, hopefully there will just be no FS problems in the mean while Another thing I can't install is sudo, but I'll manage with su - (and maybe polkit down the line). Python and Perl are a bit problematic as well, so I can't install gentoolkit. eix also requires a shell that's non-GNU-licensed, so I can't have that either.

    I'll have to install systemd soon (OpenRC is also permissively licensed). Unfortunately I won't be able to have any sort of desktop, since obviously both Xorg and Wayland are permissive. That does leave Mir, however... I wonder if that's possible to set up at the moment...

    So yea, just a crazy experiment, but it's going interestingly so far. I might very well end up learning about more GNU-licensed software from this in the end

  • #2
    Originally posted by GreatEmerald View Post
    I'll have to install systemd soon (OpenRC is also permissively licensed).
    systemd on Gentoo will not work without OpenRC installed, AFAIK, since some of the scripts are needed.
    You will have to choose something different.

    Comment


    • #3
      Nope, thankfully that has already been solved. The required functions now live as a separate package called gentoo-functions, and it's GPL-2 to boot!

      A bigger problem is all kinds of dependencies that strictly shouldn't be dependencies. For instance, unzip. It's not GPL, but the XML DTD docbook requires it, and glib requires the docbook. So I'll have to either make an exception, or make/hack an ebuild to use the busybox unzip, or live without glib (but pretty much everything depends on it). The second option is probably the easier one, hmm... I can probably make use of layman, too.

      Comment


      • #4
        Originally posted by GreatEmerald View Post
        Nope, thankfully that has already been solved. The required functions now live as a separate package called gentoo-functions, and it's GPL-2 to boot!
        Thanks for the correction, didn't know that this was already fixed.

        Comment


        • #5
          Build glib without docs?

          Comment


          • #6
            Originally posted by curaga View Post
            Build glib without docs?
            Unfortunately that's not an option. It's not a dependency controlled by a USE flag, it's just a flat-out dependency. Besides, I'd have to deal with unzip sooner or later anyway. So I did: I made a custom overlay, added a virtual/unzip ebuild, made it pull in either unzip or busybox, then altered the docbook ebuild to depend on virtual/unzip, then unmerged unzip and added a symlink to busybox, and there we go, everything works fine! I'm actually surprised there is no unzip virtual, given that there is one for awk (also satisfied by busybox). Maybe worth opening a ticket for that, hm...

            The next issue I ran into is a lot more severe and I'll have to add an exception for it, since it affects portage itself. Portage depends on python, but specifically with SSL turned on (to verify the downloaded files, I'd assume). And python only supports OpenSSL at this point... No option to use GnuTLS or anything else. So OpenSSL needs an exception for now, no way around it without changing the distro.

            Comment


            • #7
              Obvious cheat: in most cases you can grab "permissive license" and convert it to GPL, he-he. This is not anyhow worse than conversion to EULA which is conducted by proprietary corps. Most permissive licenses are permissive enough to allow such trick.

              Comment


              • #8
                Yea, obviously I'm not doing that I'm standing by what the upstream project has defined.

                Comment


                • #9
                  Originally posted by System25 View Post
                  Obvious cheat: in most cases you can grab "permissive license" and convert it to GPL, he-he. This is not anyhow worse than conversion to EULA which is conducted by proprietary corps. Most permissive licenses are permissive enough to allow such trick.
                  Have to disagree here. Permissive licenses do not generally allow re-licensing, but rather are *compatible* with GPL and compatible with typical EULAs so you can use them in either GPL-licensed or proprietary code.
                  Test signature

                  Comment


                  • #10
                    Yeah, the only way to relicense code is to actually own it (GPL does not transfer ownership technically, that can only be transferred by entity to entity special contract like the one FSF makes people sign so FSF owns the code)

                    Comment

                    Working...
                    X