Making Haiku Free Software

61

No. I’m one of the biggest advocates of software freedom that you’ll meet. I’m not interested in the idea of a FSF approved distribution of Haiku for these reasons:

“Distributions” work great for Linux. Due to the differences between Linux development and Haiku development, I believe creating any Haiku distributions will be bad for Haiku overall. It would be better for there to be just the one Haiku operating system: Haiku.

Also, Haiku is not done yet. It hasn’t even had an official release yet. I believe it would be better to “finish” Haiku, and then remove non-free software from it. Otherwise, there would be just too many difficulties in creating a new OS and getting it to be used.

Anyway, my point is, if even I’M not currently interested in a free software version of Haiku, then you won’t find anyone who is, at least, not on these forums. :wink:

62

FSF is a joke in my opinion, linux is a huge mess (i do use linux for the last 10 years, though) the distro war is a nice thing to see and it also shows the flaw of that type of development. a distro uses an ABI/api and another distro uses the same ABI but a diferent APi,they fork respectively the API and follow a new path so does happens for the original ABI making it so different that it isn’t compatible any more. well looking at that, it really makes me giggle to think that FSF will/would sponsors Haiku.

Haiku is just fine as it is i would never change it’s development structure or license. I would discourage the idea of distro simply it would slow down the haiku dev cycle. if you want to make FSF approved or sponsored OS better off with linux or forking haiku for that matter.

63

[quote=strypey]
I guess the most pertinent question is this: is anyone else interested in the idea of a distro of Haiku that meets the software freedom criteria set by the FSF?[/quote]
Apart from not enforcing these criterias through a licence change (which is extremely unlikely) it seems to me that Haiku already meets them.

Having FSF approval hardly constitutes as a reason for Haiku to re-licence to copyleft (and thus enforce the software freedom criteria). Again, the only possible situations where I could see Haiku re-licence (or rather have new code be licenced under copyleft as it would be hard to track down all existing contributors) would be if either:

A) Haiku wants/needs to be able to use GPL licenced code in the base system

B) A proprietary fork of Haiku comes along and doesn’t contribute back, which could potentially piss off the Haiku developers enough to re-licence to copyleft.

I find both these situations to be extremely unlikely.

64

[quote=drcouzelis]
“Distributions” work great for Linux. Due to the differences between Linux development and Haiku development, I believe creating any Haiku distributions will be bad for Haiku overall. It would be better for there to be just the one Haiku operating system: Haiku.[/quote]
Yes, Haiku and Linux is not comparable as Haiku is a ‘full’ operating system while Linux is just a ‘kernel’.

And while the Linux kernel has a great deal of functionality (more than Haiku’s equivalent will ever have I’m sure), it needs lots of other software components in order to make it an operating system.

This is where Linux distro’s come in. They are for all intents and purposes separate operating systems with one defining factor which is that they all use the Linux kernel (in practice this typically includes glibc, GCC etc aswell).

They often share many other components between them aswell, but there is no ‘rule’ which defines a ‘standard’ as there are often numerous alternatives for each and every component.

Haiku on the other hand is developed as a ‘whole’ operating system, this makes it much less flexible than Linux and it’s surrounding components, but also brings a much more (in my opinion) ‘cohesive’ environment where all components have been written to directly interface with eachother rather than being glued together as is often the case with Linux distro components.

And while the flexible Linux model has great advantages for many different uses (which is why Linux is so huge in so many different areas of computing), it stands to reason that when you are targeting a single area as Haiku is doing (the end user desktop), a ‘whole’ system written top-down for that single purpose will be superior.

65

What ‘distro war’? People creating distro’s is something you can’t avoid in open/free software and neither will Haiku be able to prevent people from doing so. Anyone can do it, and it doesn’t make it a ‘war’.

The reason it’s possibly less likely to happen to Haiku (but I’m certain it will anyway) is that Haiku comes as a complete system which consists of ‘standard’ components rather than as in Linux distros where there is ‘basically’ one single standard component (the Linux kernel) and the ‘distro’ picks the rest.

This ‘complete system’ aspect of Haiku means that apart from creating distros which come loaded with different types of user space software and some small modifications, there isn’t a whole lot with which to differentiate distro X from the official Haiku version.

Even so, I’m certain that if Haiku does ever reach a certain measure of popularity we will have these Haiku ‘distros’ which does the aforementioned software bundling aswell as some degree of desktop customization.

Personally I don’t see that as a bad thing, if some combination of software and desktop settings prove to be very popular it will help improve the overall Haiku experience and could be made default in the official version.

What the heck are you talking about?

66

All I can say is that my nerves are shot from listening to Richard Stallmans endless blah blah blah.

Bblah blah blah, blah blah blah blah blah blah, blah blah blah blah blah blah blah blah blah! bblah blah blah.

FTFSF >> Even bigger FTRICHARDSTALLMAN’SBLAHBLAHBLAH.

Talk about “crying wolf”. Even the Grand Canyon couldn’t shut that up! It’s quite possibly the only human voice audible from space!

J/K thought we could all use a bit of humour, eh!

67

I think it’s really sad that so many of those commenting here have not even taken the time to read and understand my original posting, or even tried to answer the reasonable questions that I’ve asked. I’m not sure what they think is gained by lashing out at me, Stallman, the FSF, the GPL, copyleft, Linux etc.

When I joined this forum I was really excited about Haiku, and keen to help promote it to other software freedom advocates. This discussion has left me feeling jaded, discouraged, and unwelcome, and really put me off having anything to do with Haiku. Pat yourselves on the back folks, you’ve successfully stoned the blasphemer :frowning:

68

Our general FAQ should probably be enhanced with appropriate answers to your reasonable questions.

Bye,
Jerome

69

Hey, I appreciate what RMS did, and the Gnu project, and even call Gnu/Linux just that to this day, but I do agree with a previous poster that the “only free software” and having a “free software checklist” are detrimental to usability of a product.

One thing driving me away from Gnu/Linux is the fact that more firmware now has to be manually added to the OS, when as long as no one modifies it, it could exist inside that distribution in the first place.

And Haiku IS free software. Some components might not be, but that certainly does not place it with the likes of Windows.

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.