Making Haiku Free Software

70

Let me try…

We are not going to switch to the GPL. We use the 2-clause MIT license, which is compatible with it, for the code we write. This decision was made when the project started so the code could be reused in an eventual continuation of the original BeOS. This didn't really happen, but I think projects like Zeta used some of the code. There were some patches for BeOS based on Haiku code as well.

One of the initial goals of the project was to provide an OS to people trying to run (or sell) their proprietary applications written for BeOS. There is one succesful example of this with TuneTracker Systems. For this reason, our point of view about free software is quite different from the FSF one. Have you tried one of the Linux versions they advertise? You will quickly notice that you likely can't connect to Wifi without first installing a "binary blob" firmware for your Wifi adapter. This is why Haiku includes them. We think the most important thing is that people can use the computer, and if there is no other solution than including a binary blob, we go for that.

We also include some proprietary software such as WonderBrush and liblayout (used by Beam and BePDF) in our releases. This is also on purpose: we think there is nothing wrong with non-free software, if that's what people prefer distributing their programs like. Who are we to decide which licence people should use to write their software? And why would we not distribute it if they allow us to do so?

Over time, people found that free and open source software was a good thing, as they tried to use old BeOS software, they saw how having the source makes it much easier to debug and fix things, even after the author has moved to other projects. We even had some success at getting the sources for BeOS software back from some people old backups and open sourced. So I'd say our way to handle things is working very well, and making people do open source in the long term. While we will probably never do well enough to be on the official FSF list, we are not in bad terms with them. We disagree on some things, that's it.

Personally, I think the no-compromise decisions of the FSF is not a good thing. IT is for this reason that a lot of projects are using llvm instead of gcc. While gcc is free software (under the GPL), writing a proprietary plug-in for it is disallowed. What is that free software licence that prevents you from doing whatever you want with the code? Isn't that just as restrictive as proprietary software? The goal of the GPL is to create a separate bubble of software, which never mix with existing proprietary things. Bridging the gap between the two are BSD-licensed (or similar) projects, and there will always be some there, because when a company has a choice between a BSD and a GPL project, they will often take the former, even if they plan to contribute to it or release their code as open source.

1 Like
71

Surely anyone wishing to use the GPL could fork Haiku and GPL their copy.

It would not be possible the other way though.

+1 for the MIT license - I think it’s the right license for this project.

Edit: actually, maybe that’s not allowed unless the copyright holder gives permission…

72

I would also like to point out that one program I am working one uses a 4MB Zobrist hashing table. That table is delivered as a binary blob. The program to create that blob is open source but by it’s nature each different computer will generate a different blob when the program is ran.

Thus to insure all copies will work together, they need to include the same blob to work the same together.

Second, the program requires 3,000 seconds to create the blob on my I7 3.4GHz machine, so unless you want long start-up times you needed the blob.

PS. There is a way to make the program create the same blob every time, but it requires it runs as a single thread instead of the 755 threads it presently uses and the run time climbs to something like 45,000 seconds. Plus the Zobrist table starts showing certain patterns in the generated numbers. Not good.

Haiku’s rules are easier to follow.

73

[quote=PulkoMandy]
Personally, I think the no-compromise decisions of the FSF is not a good thing. IT is for this reason that a lot of projects are using llvm instead of gcc.[/quote]
I’m not so sure, I think the reason that a lot of projects are using LLVM instead of GCC is because of the JIT properties made available by LLVM as well as it being a newer and as such better code base than GCC (although it is being improved continously as well), LLVM was initially written as a new backend for GCC, and has relied on GCC’s fronted for most of it’s development.

As for Apple, yes they switched and started funding LLVM because of GPLv3, as GPLv3 contained patent clauses, and should Apple distribute GPLv3 licenced software they may end up unable to sue for certain software patents, which of course is something they like to do. So they were stuck with GCC 4.21 (last version under GPLv2) and as such had to look for an alternative, hence LLVM, which they later combined with their c language frontend CLANG.

As it stands, LLVM is a more modern compiler toolchain than GCC in design, obviously. GCC still remains better at code generation (as in speed of generated code) and has started to modernize it’s codebase in response to the competition from LLVM/Clang and as such we have two great open source and free compiler toolchains available, both with strong development, which is great.

[quote=PulkoMandy]
While gcc is free software (under the GPL), writing a proprietary plug-in for it is disallowed. What is that free software licence that prevents you from doing whatever you want with the code? Isn’t that just as restrictive as proprietary software?[/quote]
No, you can do whatever you want with the code, however when you are ‘distributing’ the code to others, you have to pass on the same rights to them as those you recieved under the GPL licence.

This is the whole point of GPL and as such of FSF, that you as a recipient of GPL software should have the rights to the source code of said software, so that you can examine, modify, copy and run modifications of said software.

It’s perfectly fine not to think these are end-user rights that are worth protecting (and thus disagree with FSF), but claiming that it’s ‘as restrictive as proprietary software is ridicoulus’, what GPL does through copyright is to give and preserve rights to end users which proprietary typically removes (source code availablitiy, right to copy and distribute etc).

This of course ties in with why FSF would not allow proprietary plugins for GCC, the whole point of GCC was to provide a compiler toolchain under the conditions of GPL, which gave end users the right to examine and modify the code of the compiler and ALL it’s components.

Proprietary plugins fly in the face of that, as it does the exact opposite. Actually this is one of the areas where I fear popularity of LLVM could be detrimental to the point fully of open toolchains, there’s already proprietary plugins for LLVM and they will continue to grow, this in turn most likely means that features that would be included in to the open source LLVM project will instead be pay-for proprietary plugins, or worse only available on certain platforms in their forked versions of LLVM/CLANG (like how Swift is only available on OSX LLVM/Clang forked toolchain, with no word on whether or not it will be made available as open source and included in to the open LLVM / Clang projects.

What made GCC such a huge force in computing and bootstrapped what we today call the open source ecosystem is that it was fully competitive with proprietary offerings (eventually eclipsing most if not all of them in most aspects) which in turn was due to every enhancement being made to GCC actually making it in to the project and available to all, not as proprietary plugins which would have fragmented it’s usefulness.

So if you find LLVM’s plugin system which makes it easy to tap in to and extend LLVM through proprietary plugins a great boon, just keep in mind that there is a downside to it as well.

On the contrary, it’s my impression that if a company intends to contribute code they will be very happy to do so under GPL which means that anyone else using their code will have to return the favour (this is in part why Linux is the largest cooperatively developed piece of software in the world in my opinion), while if they want to make use of open source software then permissively licenced software is of course favoured as it means they can do whatever they want.

1 Like
74

Hi,

Of course, there is nothing wrong with the no-compromise way of the FSF and the GPL. Both this and what we are trying to do are valid solutions, and I think they are actually helping with making a complete free software ecosystem. With only the GPL, some people would not do free software at all. But without the BSD-like licenses, and all other compromises existing for the GPL (GCC runtime libraries exception, font exceptions, etc) the GPL would be isolated from proprietary projects, and it would be impossible to mix GPL code with anything else. Again, there is nothing wrong with that, and it's actually what the FSF is trying to do: make the GPL ecosystem so great that everyone wants to use it, and make it impossible to mix it with proprietary software so people have to completely switch to it.

Now, the GPL can be a good license, if that's what you want, for a single software project. A compiler like gcc, a kernel like Linux, a C library like glibc, for example. Haiku is a whole operating system, and has several components that are MIT licensed, and as such, are GPL compatible when considered separately (we could do a file-by-file listing if needed). However, we don't want to restrict ourselves to GPL-compatible-only stuff. We are welcoming to proprietary software, wich we think is better than no software at all (and yes, GPL software would still be better). It is not our goal in Haiku to advocate the use of the GPL, or any other license, to other projects. So we went with the MIT license for the code we write, and integrate whatever we think is useful in the system, living with the licenses the authors have set on it.

2 Likes
75

Finally, someone has actually answered my questions. Thanks a lot @PulkoMandy for the information and the clarifications.

To return the favour, a few points:

  1. I never said that everything must be GPL. Not everything in GNU-Linux is GPL. I support copyleft licenses (GPL, LGPL, AGPL and others) as a strategy for preventing proprietary software companies from taking away rights from end users. But any license that allows source code to be freely shared, re-used, and modified, is a free software license (by the FSF’s definition). Even in the GNU-Linux distros endorsed by the FSF there are many programs under Apache, “BSD” / “MIT” and other non-copyleft licenses, and neither I nor the FSF consider this a problem (maybe a missed opportunity but …).

  2. “Who are we to decide which licence people should use to write their software? And why would we not distribute it if they allow us to do so?”

Of course you can’t decide which license people should use, the point is you can decide which software you distribute. One reason not to distribute proprietary software is that software’s license misuses copyright law to stop users doing things I believe they have a fundamental right to do with any software on their computer. That is; view the source code, modify is to suit their needs (or have someone else do so), and distribute the original or modified source to help others get better use our of their computer (as defined in the 4 freedoms).

Another reason is that although you have permission to distribute the proprietary code in your releases, that doesn’t automatically mean anyone else does. That makes Haiku much less attractive to people looking for an OS to distribute as the default OS with their hardware, as they would have to negotiated a whole bunch of commercial licenses with the companies who own that proprietary software. But if you don’t care whether Haiku gets used outside your hobby community, I guess that doesn’t matter.

  1. I’m very pleased to hear that some old BeOS apps have decided to release their code under free software licenses (which ones?). Many companies have also released their modified versions of GPL software, after being politely reminded that they are legally obliged to extend to others the same freedom that allowed their fork to exist. I agree there is a place for both carrot and stick.

@Rox has addressed your other points with much more technical knowledge than I could have brought to the table, and I thank him for taking the time.

@philcostin
"Surely anyone wishing to use the GPL could fork Haiku and GPL their copy."

As I mentioned above, the GPL is not actually what my OP was about. Also, you can’t really fork an OS because it is a collection of programs, not a single program. But yes, someone could remove all the proprietary bits of Haiku and distribute that as a free software OS under a new name (FreePoem or whatever). I’m curious to know if such an OS would be usable, or if it would be missing some essential components. Replacing those components with free code would then be the priority for anyone interested in creating a 100% free code distro of Haiku.

Also, yes people could fork any non-copyleft free software in Haiku, and relicense under GPL, for the same reason they can fork it and put it under a proprietary license. Non-copyleft licenses are essentially the same as putting software in the public domain, and relinquishing all copyright claims.

@Earl_Colby_Pottinger
You seem to misunderstand what I mean by “binary blobs”. I’m talking about situations where the compiled strings of zeros and ones are published, instead of actual source code that would allow people to audit or recompile the blobs for themselves (or their own modified versions). In your example, your source code is available (at least I presume it is when you say your program is “open source”), so that’s not a proprietary binary blob, and not a problem for inclusion in a free system distribution.

It’s a pleasure to get some constructive responses on this thread. Thanks for taking the time to reply.

76

I’m still a bit confused as to the need for FSF endorsement. While I loudly applaud the FSF for the role it continues to play in the advocacy of free and open source software, I don’t feel they are the all holy single source of open source. The open source community existed long before the FSF. I’m willing to bet that open source will be around long after the FSF is no more. While an endorsement from them would a great hat decoration, I don’t feel their endorsement should be necessary for a project to succeed in it’s stated mission.

77

In recent years, various source parts have been replaced by new ones due to unclear or unclarifiable licenses and rights. So it’s not like nothing has changed. The changes meant that many old programs were no longer running. We have lost these forever because the resources are missing and / or the developers are no longer active. This is the other side of the medal. The topic is complex and probably not finished yet. Whether one should change the license of haiku? I do not know.

Most of all, we need an official release so that software developers have an existing base that does not change every three days.

78

What you mean isn’t clear: a release with updates will be about the same, the existing base will still change “every three days”…

79

That depends on our plans for after the release.

Last time I discussed this with other Haiku devs (it was just a few of us during a coding sprint), a possible way would be that starting from beta1, we keep an “R1” branch where we are careful about not breaking things too much. And meanwhile, the trunk starts to get some work towards R2.

But, this leaves the question of what is considered a “breaking change”. Is changing private APIs allowed? Should we freeze some of the private APIs and make them public? Should we be more careful about keeping private APIs in libshared and not in .so libraries so that they can be changed without breaking old apps?

In fact, none of this actually needs a release. So apps developers should be more vocal about such breakage and blame the Haiku devs for lack of seriousness on this, until the Haiku devs properly handle this and are careful about it. The technical solutions are already in place for that, it’s just that sometimes they are not properly used.

1 Like
80

If we have a official haiku release, software developers have a better Support for her software, because you need to use haiku r1, for example. If people use a nightly revision and things does not run anymore the software developet can ignore it and does not need to change every three days his apps. Past this point we have a haiku System for users and not only for developers.

81

I think this is everytime pending of the apps who are broken then. Somethink like qt, interpreter languages like yab and egsl, popular third party apps should be saved to this point.

So we need too different system update sources

82

I think the biggest problem is there to report such things. In the bugtracker should be only system errors and programs be reported. Third party on haiku ports right? Diffetent support bases need to be declared to the user.

I can report bug over the bug tracker without any problem but i does not understand how to do this on haiku ports.

83

Haiku itself rarely changes for the sake of it, we only fix things here and there. Breaking changes mostly happen at HaikuPorts nowdays, actually since the buildbots are active…

84

I thought it was already decide and voted. If not what we are waiting for? I think this is the only reasonable solution to both provide a stable release and begin advancing the system.

My impression instead is that some people here fear that R1 would be basically abandoned since it’s so much time…but the fact is that we have to do a release or the project is going to certain death.

The fact that some people are keeping the project in hold because of their likes isn’t a justification for holding the release more.

Having a static libshared may be a good compromise. My thoughts are:

  • We don’t have more time to wait for more APIs to become public, everyone had enough time to do so.
  • Private APIs aren’t provided with the warranty they become stable.
  • I didn’t decide this model of development, advancement in the Haiku API were usually opposed by some devs, now we can just live with the consequences.

In any case, if needed I don’t see why we can’t have an R1.5 release where compatibility with BeOS is kept but also more advancements in the system are included.

For now, my idea is that we need to do a release with what we have.

1 Like
85

To be honest there were so much different plans for R1 and different approaches tried that I don’t even remember what is agreed upon or not. If no one else has an alternative plan, let’s use this one for now.

I offered to be the maintainer for the R1 branch, with the condition that a proper tool for managing that would be setup. Now that Gerrit is up and running, I will assume the responsibility - help from others is welcome, of course, but back in the discussion I mentioned other people present were mostly interested in moving onto new things for R2.

I don’t, however, feel the pressure to do a release. I think it is way overrated. I know it will attract a lot of attention and I wouldn’t want to ship something with embarrassing bugs.

The main reason for not having a release yet is not there, however: we still need the last mile in terms of system administration, namely setting up a separate package repo for it. This probably also means figuring out a scheme for managing haikuports. I think korli’s trimestrial branches should be used here (the idea is that every 3 month he makes a new branch based on the trunk, and then for 3 months, backport only important fixes from the trunk while trying to not update too many recipes - this should provide something more stable than using the trunk of haikuports directly)

On libshared: there already is a libshared.a, and the BPrivate namespace. Both should be used when introducing new private APIs, and there is no problem doing that. This way, when we make changes, old software linked against an old version of the lib continues to run. I think we have more than enough features for R1 already, so no need to wait more on getting things out of that lib for now. We can do that later.

As for advancement in the API, my view is “not yet”. The goal here is to force people to finally branch out the R1 branch (without introducing new unstable things in it continuously). Once the R1 branch is created, the R2 branch can be used as a playground for experimenting with new things, and when they reach some maturity and stability, they can be integrated in master and unleashed on unsuspecting users. There is no problem adding things in that way. What I have a problem with is things getting directly in our current trunk branch which is what we also tell users to download and use. Note that with Gerrit, it’s possible to have such changes stored in Gerrit and easily grabbed from there by developpers (just a git cherry-pick away). So this may be another way to deal with such “exploratory” changes.

86

Why not some release each year? With some natural cycle.

Naming and releasing natural cycle:

Haiku 18 V (vernal equinox) — the birth of a new system, old still receive bug fixes.
Haiku 18 S (summer solstice) — finished form of new system,…
Haiku 18 A (autumnal equinox) — system’s release of year, from that moment sources can accept only bug fixes and finishing what is started but not finished yet, no new things must be added.
Haiku 18 W (winter solstice) — from this moment system accepts only bug fixes, if some things not finished they goes to ‘experimental’ of that release; start of new branch of Haiku 19 next year (NY), new system formulation. Much older Haiku (17, for beta and alpha) stop receive fixes (after Haiku maturing, cycle of supporting system must extend to 7 or 10 years, that means that after releasing R1 it must receive important updates and fixes for 7 years or 10).

Yours input in perfecting cycles are welcom.

1 Like
87

I think with respect but you are wrong there.

88

Let me clarify then.

We could take any nightly build, rename the file, and go “there, have your release”. It would get some media attention, which is a good thing. But people would soon find out about the many problems with it. As a result, two months later we would be telling people to use the nightlies because they are better. So, the release wouldn’t accomplish anything in terms of providing a stable platform for developers.

The important things in “making a release” is not the release, but the making. It is all the work that has been going on for years to set up proper tools, and get everything running smoothly. As a result of all these efforts, we will be able to ship something great, a stable platform that devs can base their apps on. There will of course still be bugs, but we will have a plan to get them fixed and the fixes sent to our users, without bringing in regressions at the same time.

If we are succesful in this, then yes, a release is a good thing. Otherwise, you could consider any of our nightly builds to be a release, but that won’t get you any further than the current situation.

Also, I still don’t believe that making a release will suddenly attract dozens of developers who were just waiting for it and refraining from touching Haiku because “oh no, it’s still in alpha”. If people are interested in Haiku, they should be contributing now and sharing their nice apps :slight_smile:

1 Like
89

I agree.

In fact, until we reach a stable release process, I’m for removing Alpha 4 promotion on our website and instead turn people to some nightly-of-the-month-or-something image.
That would attract some small attention (but small is better than none) while reducing the “in-alpha-state-since-N-years-oh-that-bad” factor we kinda suffer lately.

2 Likes