> Theo de Raadt (/ˈθiː.oʊ dɛˈrɔːt/; Dutch: [ˈteː.o dɛˈraːt]; born May 19, 1968) is a software engineer who lives in Calgary, Alberta, Canada. He is the founder and leader of the OpenBSD and OpenSSH projects, and was also a founding member of the NetBSD project.
Living in Canada allowed him to avoid the USA's onerous export restrictions on strong encryption; at a time when good, consumer-accessable encryption was expensive and patent-encumbered. The 'net is secure in no small part to his efforts and that of the rest of the OpenBSD team.
You mean DJB, Zimmerman, and others fighting the governments to change the status quo encryption policy followed by deployment of higher-quality stuff than average proprietary in FreeBSD and Linux that got widely adopted by most of the Internet? Nobody has ever showed me evidence that Theo or OpenBSD had any impact on the security of the Internet as a whole. Maybe on specific users of OpenBSD or the developers' higher-quality software. Not the big picture, though.
I'm open to specific examples if you have them of widespread changes in INFOSEC or massive adoption of better tech due to Theo de Raadt.
EDIT: I'm aware of many good apps they've made. To clarify, my comment is addressing this broad claim:
"The 'net is secure in no small part to his efforts and that of the rest of the OpenBSD team."
OpenSSH might get credit due to massive use. Good example. Past that, what else does most of the net on client side (mainly Windows & Mac) or server-side (mainly Win, FreeBSD, and Linux) depend on from OpenBSD developers?
OpenBSD led by example, being secure by default and at the expense of other considerations.
And yes, that wee piece of software that is the secure gateway of choice and has been for a great length of time; among a great many other innovations mentioned in the link in another reply.
Paradoxically, projects on github flourish because contributors and users by in large ignore the licenses. Granted, licenses are extremely important to protect intellectual property but nothing kills contributions to open source more than bureaucracy.
I won't bother contributing to a project if I have to jump through hoops. The Github ecosystem removes these hoops. The license is a secondary concern for in-house software.
I still don't see what you mean by this. All of the top projects on github have pretty clear licenses which are automatically accepted by you (the contributor).
In fact if you choose not to specify a license your work counts as copyrighted (as per github licensing documentation). So Github doesn't really remove any "hoops".
Reproducing the text because the site is under too much load and Coral Cache can't resolve it:
List: openbsd-misc
Subject: Re: LLVM license change
From: "Theo de Raadt" <deraadt () openbsd ! org>
Date: 2016-09-28 4:27:44
Message-ID: 91077.1475036864 () cvs ! openbsd ! org
[Download message RAW]
> And that is because corporate "contributor-wannabes" put pressure on the
> LLVM foundation.
> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html
>
> It does say "this is an RFC" but that was last year. We are now in this
> year:
> http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html
>
> What I particularly do not like is the "IANAL but let's do it anyway"
> drift emanating from a lot of high profile developers there.
Well, I hope they do it.
And then -- I hope a year or two later, some author of a component
(especially one from Europe where the moral rights of an author still
carries substantial weight) submarines the new licence, surfacing to
indicate that they never signed off on the additional terms applied to
them as a significant author, and will accept no cash to solve the
problem.
Then they are dead in the water.
A cataclysm like CSRG went through.
Then a fork of code on the original license can flourish. A fork
based upon the last free version -- but let's remember that is the
history of another piece of important software...
So this problem could be fixed, if enough people care.
In this situation, I suspect a few people are being paid a lot of
wages to act as agents permitting theft from their co-contributors.
They worked with others but now they are ready to steal from them. A
list of all contributers (and every single one of them must agree) has
not been published, so it is really likely this is a well-financed
effort being performed by paralegals. Meanwhile day by day that list
of contributors operating under the existing model is growing..
Someone is hoping they can get away with copyright theft.
Want to have fun? Submit a major diff, which (seperately) in the
submission says you'll never agree. Eventually most large projects
find their inner Xfree86, I'm afraid to say.
It's hard to have any idea what that means without the preceding context:
> > > What does the OpenBSD community think about the LLVM proposal to move
> > > to the Apache license?
> > >
> > > http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html
> >
> > If LLVM would move to the Apache 2 license, we would become unable
> > to use versions released after that change, and would be stuck with
> > version released before the change, just like we are stuck with
> > pre-GPLv3 gcc now. So it would be very bad for us.
> >
> > See http://www.openbsd.org/policy.html :
> >
> > Apache
> > The original Apache license was similar to the Berkeley license,
> > but source code published under version 2 of the Apache license
> > is subject to additional restrictions and cannot be included
> > into OpenBSD.
> >
> > In a nutshell, OpenBSD does not consider software released under
> > Apache 2 to be free software. At least not free enough for us
It might be, but this isn't one. There could have been 100 other reasons for not wanting a specific license on their project besides corporate dislike for it.
The Apache 2.0 provides a patent grant, and the whole reason they were looking for a new license was to add a patent grant. So if Apple wants to sue anyone who uses LLVM for patent infringement, why are they spending so much money on lawyers to figure out how to switch to a license with a patent grant?
The Apache 2.0 provides an uneven patent grant. Specifically, it's directed from users to the developers. The GPLv3 makes the patent grants much more copyleft in style to ensure that users cannot be attacked by patents from developers as well.
> each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted.
GPLv3:
> Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.
The two licenses are definitely not identical on patents, but both are pretty clear that they provide protection to users from developers, insofar as the original code and any modifications downstream were licensed under the Apache 2.0 license. You're right that there's no copyleft, but that doesn't reverse the direction of the patent grant.
The GPLv3 has several paragraphs on patents. Here are some parts you did not mention:
> If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.
> If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.
> A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.
There's no doubt that the GPLv3 provides broader patent protection for users, but both licenses put the "protect users from developer's patent claims" first.
To be honest if you're hostile to software patents in general (which I am, and the GPL sure as hell is), the part of the Apache 2.0 license's patent clause that prevents users from flipping around the patent claims seems like a non-issue.
All companies who ship Samba in products use GPLv3. There are a lot of companies shipping Samba (one went out with a successful IPO this week). Thus your FUD is disproved.
The old version from pre-GPLv3 times is Samba 3.0.x. It's over nine years old.
No vendor ships that version anymore. I don't think modern Windows clients will even connect to it now (no working NTLMv2).
The ones who didn't want the GPLv3 (Apple) either wrote their own or purchased a proprietary third party server such as Likewise and were left holding a flaming bag of shit when EMC purchased the Likewise codebase and cancelled all existing support contracts. You'd think people would learn, but there are still vendors out there gambling on using proprietary third party SMB3 servers (hoping the same won't happen to them :-).
Well as a practical example, I checked the latest firmware of Asus RT-AC88U (HW seems to have shipped in Q4/2015) and the strings in /usr/bin/smbd (binwalk can directly extract the Asus .trx files) point to some derived version of 3.0.37.
It doesn't really meet any of the goals for relicensing. For example, one goal was to not need CLA's. Apache has a built in CLA, GPLv3 does not.
Another is that llvm has no desire to require signing keys for represent or source reproduction of private backend, etc.
Using gplv3 as a base would have required an even longer list of exceptions, and the end result would be gutting most of gplv3
GNU General Public License, GPL, LGPL, copyleft, etc.
The GNU Public License and licenses modeled on it impose the restriction that source code must be distributed or made available for all works that are derivatives of the GNU copyrighted code.
While this may superficially look like a noble strategy, it is a condition that is typically unacceptable for commercial use of software. So in practice, it usually ends up hindering free sharing and reuse of code and ideas rather than encouraging it. As a consequence, no additional software bound by the GPL terms will be considered for inclusion into the OpenBSD base system.
For historical reasons, the OpenBSD base system still includes the following GPL-licensed components: the GNU compiler collection (GCC) with supporting binutils and libraries, GNU CVS, GNU texinfo, the mkhybrid file system creation tool, and the readline library. Replacement by equivalent, more freely licensed tools is a long-term desideratum.
[edit] removed extra spaces to avoid HN's auto-formatter
Have read it too, but the question was what's wrong with GPL3 that isn't wrong with GPL2. Am I again the only one to notice? :)
I'll give you folks a hint: the specific quote dleslie responded to says that OpenBSD stuck with GPL2 version of GCC to avoid GPL3.
But, of course, this place being HN, people have attention span of an infant and forget the context by the time they catch something they'd like to respond to :p
Painting the situation as "corporate contributer-wannabes" and "IANAL but let's do it anyway" is loaded language that seems intended to bring up negative tropes. The first is sneering at the host of potential contributors, because the host is willing to pay the salary of the contributors. The second is not remotely backed up by the facts.
They've hired lawyers, and consulted the community. The community's predominant concern was whether the new license (Apache2) would be compatible with GPLv2.
In the "We are now in this year" link, it's explicated how they consulted a gaggle of open source lawyers, determined the predominant belief was the new license was compatible with GPLv2. But they didn't stop there – they had a lawyer draft an addendum to really ensure that!
Not a good look. Fever swamp paranoia, and wishing ill on a series of people clearly trying to do well and address every concern.
> Painting the situation as "corporate contributer-wannabes" and "IANAL but let's do it anyway" is loaded language that seems intended to bring up negative tropes.
I don't see where refulgentis claims Theo did. Clearly, those are quotes from the person Theo is replying to.
Theo seems to agree with that person though, and "wishing ill on a series of people clearly trying to do well" certainly could apply to both parties in the email.
I apologize, I didn't intend to give the impression my post was limited to addressing Theo. I expressly avoided addressing an individual, but clearly that wasn't enough.
Highly doubt a fork will 'flourish' so easily. LLVM is largely backed by Apple, the founder himself (Chris Lattner) works there. It won't be abandoned in the near future, however the license changes.
LLVM wants to switch from a BSD-style license to Apache 2.0, with a few exceptions, one allowing use with GPLv2 code, another allowing the bits of compiler-rt and other components that get built into binaries to be redistributed without restriction.
The main benefit of Apache 2.0 is that it includes a patent grant as well. Right now, LLVM relies on a custom "developer agreement" for anyone who contributes code that includes a grant of patent rights, but it's kind of vague and fuzzy and so makes it hard for some people to contribute, and the license itself doesn't actually mention patents at all:
Theo objects to any license that applies more restrictions than the original BSD license. OpenBSD makes an exception for GPLv2 licensed utilities that have been traditionally shipped with BSDs that there's not a good replacement for, but has stopped upgrading things that have moved to GPLv3 and apparently objects to the Apache license as well.
The existing patent agreements seem to make the current license not comparable BSD but instead comparable to an awkward or even apparently extreme Apache 2.0, so isn't this about in practice removing restrictions, not adding restrictions? (This thought process is backed up by their stated reasoning and the kinds of contributors that are supposedly complaining.)
"Additional restrictions" can be funny. You may recall the FSF's position that the app store EULA placed "additional restrictions" on the GPL, a position that was and remains controversial.
In this case, it is a little harder to understand OpenBSD's interpretation of additional restrictions because they haven't listed their objections in any centralized place, but from reading around, they seem to believe:
* "You must cause any modified files to carry prominent notices stating that You changed the files" is an additional restriction
* "any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License" is an additional restriction
* The sheer length and complexity of the Apache license suggests to them there are other additional restrictions buried in there somewhere
> You may recall the FSF's position that the app store EULA placed "additional restrictions" on the GPL, a position that was and remains controversial.
I don't think that the position was contraversial, I just think that people took it the wrong way. The Apple EULA objectively has clauses in it that state that users must follow the "acceptable usage policy" and it is enforced regardless of any external agreements -- this would mean that Apple would be violating the GPL if they distribute any GPL software in their store.
You can add additional terms that permit distribution in the Apple store (as Signal has done), but the stock GPL does not permit distribution in the Apple store because the "acceptable use policy" is one of the things the GPL was made to fight against (the idea that users must act in an "acceptable" way to Apple when running software on their own computing devices).
> The Apple EULA objectively has clauses in it that state that users must follow the "acceptable usage policy" and it is enforced regardless of any external agreements -- this would mean that Apple would be violating the GPL if they distribute any GPL software in their store.
And Red Hat EULA objectively has clauses in it that you may not redistribute RHEL.
There is a slippery slope here, the FSF has decided for whatever reason that RHEL's restrictions "weren’t really restrictive, because they were so easy to comply with" [0] but there is really nothing "objective" about that determination.
You're being a tad disingenuous here. RHEL's EULA[1] is basically the same as SLE's, openSUSE's, Ubuntu's and so on. It only states that you are not allowed to use the RedHat trademarks when you redistribute RHEL -- and since RHEL (and the other distributions I mentioned) puts all of their trademarked components in a single "branding" package then it is not practically restrictive to make such a requirement. RHEL has no requirement that you cannot distribute some software (in fact, the distribution is under GPLv2 much like openSUSE and SLE).
Apple's EULA restricts users to only being able to use software they distribute under their "acceptable use policy". This is simply a violation of the GPL, with no wiggle room for discussion.
The existing patent agreements are a contributor agreement, not part of the license. So, they restrict people from contributing, but don't actually provide any guaranteed protection for downstream users, as far as I can tell.
However, I'm not a lawyer and not involved, was just trying to summarize as well as I could, so I could be wrong.
LLVM is considering switching to the Apache 2.0 License.
As a matter of policy, OpenBSD does not ship software that uses the Apache 2.0 License.
It's not entirely clear why that is their policy, but it seems to come down to some combination of the patent clause and the additional complexity of the license.
> It's not entirely clear why that is their policy
> The original Apache license was similar to the Berkeley license, but source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD. (http://www.openbsd.org/policy.html)
According to the link I posted their goal is to publish OpenBSD under the terms of the original BSD license (so 2-Clause BSD, 3-Clause BSD, MIT, ISC, etc. are all fine).
The Apache license v2 is more restrictive than BSD-style licenses so they can't include code licensed under it.
In the sense that it would be perfectly legal for them to include Apache v2 licensed code? What in the world would restrict them from doing so? They can include Apache v2 code, GPLed code, proprietary code, any code they want, really. Their goal however is to build an OS that can be used under the terms of a BSD-style license similar to Debian's goal to build an OS that is "free."
then again, we don't pat people on the back for holding on to their odd views, we congratulate them for coming to new realizations and acting on those. So... no, not really. It's not even hypocritical. It's just someone who is currently raising a perfectly valid argument, and his arguments in previous debates have literally nothing to do with the current, legally constrained, discussion around events that appear to have been put in place and moved forward without buying from all parties involved.
I might very well be wrong, but I believed that the licensing of the IPFilter code, and the clarification of the attached license was part of the reason that OpenBSD, and Theo, is so much against complex licenses.
While better than the GPL, version 2 and 3, in the sense that it's shorter, the Apache 2 license is still much more complex than the ISC or the BSD/MIT licenses. Another part of the issue, for some developers at least, is that the Apache 2 license sort of acknowledges that software patents are a thing. So if you disagree that companies should be allowed to patent software, mathematics and processes, you might not pick a license that validates the existence of those patents.
So if you disagree that companies should be allowed to patent software, mathematics and processes, you might not pick a license that validates the existence of those patents.
This sounds absurd to me. Software patents don't go away because one stops believing in them. Either the courts enforce them or not.
Sure, but I see the idea as a kind of boycott/protest. I disagree with patents, mainly software patents, consequently I will never use a license that consider patents.
But a boycott is supposed to help the cause, no? All you're doing is preventing a lot of people from using your code from fear that you'll sue them - some of which who might end up using an alternative from a company that holds and supports patents.
That's not how laws work. At all. Even the GPLv3 (authored by one of the biggest activists against software patents) has clauses relating to software patents -- because they are a legitimate threat to software freedom and need to be addressed. Just because you don't like patents doesn't make the problem go away -- in fact by ignoring it you're making the problem worse because then your code's license has no protection for your users.
How does the "ipfilter debacle" relate to "copyright theft" in your mind? Darren Reed changed the license text on his ipfilter software to clarify that modified versions were not permitted, and so his software was removed from OpenBSD.
Darren Reed's original license didnt grant the right to make derivative works, the modification just clarified that. Theo spent a lot of time arguing that OpenBSD's derivative work was still fair use and / or covered by the section of copyright law allowing you to copy a program you own into ram and modify it. Both of those arguments were total BS, and just used as justification for shipping the modified code even after they had been notified of the license violation.
It's common for open source projects to change licenses. To be honest, I'm pretty sure that most projects have set the bar much higher than it legally is. In other words, I think de Raadt's fantasy isn't going to happen, and if it did, the fallout would likely be that many projects would lose the ability to enforce their licenses.
Usually, when a project changes its license, it either tries to get permission from each contributor; or it makes an announcement that if any contributor objects, they will remove that person's contributions on request. But US law doesn't actually require that. In the US ( http://copyright.universityofcalifornia.edu/ownership/joint-... ):
"Each joint author has the right to exercise any or all of the exclusive rights inherent in the joint work. Each author may:
"• Grant third parties permission to use the work on a nonexclusive basis without the consent of other joint authors
"• Transfer his or her entire ownership interest to another person without the other joint authors' consent".
In other words, unless you have some kind of enforceable agreement between all contributors, anycontributor can relicense the work, without the consent of the other contributors. I'm not sure whether the GPL qualifies as the kind of agreement that could prevent this; the FSF has spent years saying the GPL doesn't meet all the standard requirements of a contract because it doesn't need to be a contract. The FSF famously requires contributors to transfer their copyright interest to the FSF because Stallman says an attorney told him that makes it easier to enforce the GPL. Or, as Eben Moglen says ( https://www.gnu.org/licenses/why-assign.en.html ):
"If there are multiple authors of a copyrighted work, successful enforcement depends on having the cooperation of all authors.
"... [I]n order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer's employer."
Many open source licenses other than the GPL don't have any chance of qualifying as the kind of agreement that could prevent a single contributor from relicensing the project on a whim.
Also note that "contributor" doesn't necessarily mean to "contributor to the parent project." I haven't been able to find any legal reason somebody can't fork a project (following the license), make enough changes to become a joint copyright owner as far as their fork is concerned, and then relicense the fork. I guess the original contributors would also be joint copyright holders as far as the fork is concerned, and could relicense the fork as well. I'm not sure where that would end; and I'm glad that so far nobody's been creative enough to start such a battle.
So, back to LLVM: Apple is, without question, a joint copyright holder and can relicense the code as desired. De Raadt's idea is that a European could say "well, the relicensing was OK under US law, but not under European law." But I don't see how moral rights would prevent relicensing. The Berne Convention establishes moral rights as ( https://en.wikipedia.org/wiki/Moral_rights ):
"Independent of the author's economic rights, and even after the transfer of the said rights, the author shall have the right to claim authorship of the work and to object to any distortion, modification of, or other derogatory action in relation to the said work, which would b...
"I would predict the outcome would be a court opinion that any contributor has the right to change the license"
You think Microsoft, who has put tens of thousands of lines into Linux, has a right to change the license of Linux away from GPL? Is that really what you're positing?
I'm saying that I don't see a legal obstacle to Microsoft doing that. There are other potential obstacles, such as reputation damage.
So far, open source projects act like copyright either requires unanimous agreement among the copyright owners to make changes, or each contributor has copyright only in their specific contribution (so, in practice, you need unanimous agreement). That's simply wrong for joint works, and joint works are defined as works meant to be combined together to make one work (the alternative being a collective work, where the parts are simply combined into a collection, does follow the "each contributor has copyright in just their contribution" model).
Copyright law is based on certain assumptions, like "if the co-authors get into an argument, it will be about how to divvy up royalties, and there will be a contract involved." Another is "co-authors work together at the same time, and know each other." Those assumptions are wrong for open source projects.
A party can become a joint author, and then they can change the license on the entire work. The part "joint copyright holders can distribute the entire work under any conditions they feel like, even without agreement from any other joint copyright owner" is well established. You may not believe me, but it is the law (I already linked to the University of California, and Eben Motown's statement that to enforce a licence you need the cooperation of each copyright holder, acknowledging that a single dissenting copyright holder can kill an enforcement action; but here's a link to Stanford: http://fairuse.stanford.edu/overview/faqs/copyright-ownershi...).
The FSF avoids this problem by requiring copyright assignment. To be honest, I'm not sure that's enough, but I think they're hoping for a sympathetic judge. Most projects have never looked at what the law actually says regarding joint work, and think it works the way they would write the law. I know what the outcome of that will be.
I don't think that your claim has been tested in court when it comes to code. This might be true for some kind of music or something, but I find it hard to believe that a court would agree that two people who have never met and have only communicated over the internet would have formed an implict contract allowing relicensing of a work several orders of magnitude larger than the contribution of the relicenser.
It's like claiming that someone shouting outside of a recording studio has the right to relicense the music created inside the recording studio. While it might be true, I'd want to see an actual legal case before claiming things that are that outlandish.
Not to mention that the GPL has been tested in court and has held. So there's that.
It's not a question about contract. It's about how joint copyright works.
I know what the arguments would be, but I'm not sure how the court would rule. The hypothetical depends on legally making a fork, and the GPL (as an example) only gives permission to fork if you agree that any distribution will be under the terms of the GPL. If you violate those terms, you've committed copyright infringement. But can a joint copyright owner be guilty of infringing his own work?
I remember Eric Raymond discussing a commercial copyright infringement case where a contractor was hired to update a program, and started distributing the updated program without permission. This was his argument.
However, he hadn't made significant changes to the program. Using your words, the program was several orders of magnitude larger than what the contractor added. The court got creative, and declared the contractor only had a collective copyright -- like somebody who has copyright on a single article in an encyclopedia -- and not a joint copyright -- even though his changes were meant to be combined with the original work to create a single work and not a collection of works. A collective copyright owner only has copyright in his contribution.
You are right that courts would be reluctant to allow the tail to wag the dog, but there is some threshold where the contributor has made enough changes that he has joint copyright, and at that point he can do what the law says a joint copyright holder can do.
How about the FSF suing Microsoft for copyright infringement? That would be a fun one.
Every individual contributor could also potentially sue Microsoft in that case. The FSF wouldn't even have to lift a finger, and the contributors could get a nice class-action lawsuit going.
All the comments here seem to focus on Theo, the Apache license vs. the BSD one, and for some reason the OpenBSD policy.
But my understanding of that email is about the irregularity of a unilateral change of license. The contributors own their work and licensed it under one license, and the project wants to change it without doing the Herculean job of getting permission from all.
I think Theo is correct there saying that there is a risk that one of those contributors will then come out of the woods and wreak havoc, risking a forced fork from the relicense point.
IANAL, but "you don't change the license" is one of the few things I was taught.
What provision of the MIT license prevents it? My understanding is that MIT -> GPL is legal as long as the required notice is kept for MIT compliance, since MIT is a subset of GPL.
MIT is not copyleft. If you can sublicense MIT to be proprietary (which is what most people consider to be a "benefit" of the MIT license) then you can also sublicense it to be under the GPL[1]. The GPL does not strictly provide more rights than the MIT license.
We don't change the license on the original code when we include it in proprietary software. I cannot just take a piece of MIT licensed code and change the license to what I want. I can add code of a different license.
You can't make the original code not-MIT-licensed, since the author already released it as such (and even they cannot make it not-MIT-licensed). But you can release it (with or without modifications) under another license as long as it lets you follow the MIT license's only restriction (reproduction of the copyright notice).
What do you think being GPL-compatible (for example) means other than that? The GPL requires you to release all parts of the derived work under the GPL, not just a compatible license.
Actually you are saying different things. Even thought the original code will still be forever available under MIT, you can, for example, sell it under a proprietary license (without changing a line of code) to whoever is willing to pay for that.
Yes you do (well change is the wrong word, you're sublicensing your copy of the code). Otherwise the software would not be proprietary. Windows for example used to ship BSD licensed code, and it would have been a violation of Windows' license to modify that code (even though the original code was under a free software license).
I don't understand which part of this is confusing you -- the MIT license explicitly states that sublicensing is permitted. If you didn't sublicense the code, then users would be allowed to have all the freedoms that come with the MIT license. This would make it impossible to have a proprietary version of an MIT licensed project -- which is something that we objectively know is possible because it happens all the time.
You cannot change the license on someone else's copyrighted work.
> Windows for example used to ship BSD licensed code, and it would have been a violation of Windows' license to modify that code (even though the original code was under a free software license).
Microsoft didn't include source and if I had obtained the BSD licensed source, I could certainly modify it and distribute it (but not the code written by Microsoft). Also, the BSD doesn't have a sublicense clause which is problematic for your first sentence.
Again, the project is not planning on doing it this way.
Chris even says this:
"
Once we reach an agreement on the path to take, we can start talking about logistics of how to get there."
Both of the licenses used in LLVM contain the following clause:
> Permission is hereby granted... to deal with the Software without restriction, including... the rights to... sublicense
The effect of this clause is that all LLVM contributors have already consented to a chance in license, whether that change is done by you, me, Debian, or the Pope.
The only question is whether the LLVM organization wishes to exercise this authority itself. It's clear that the majority of the key contributors are in favor of it, so it seems like a foregone conclusion at this point.
Well to cite an actual IP attorney [0], yes. A sublicense means that you (the licensee / sublicensor) grant somebody else (the sublicensee) the right to use the software, and you can do it under any terms you are permitted by the grant of sublicense.
The MIT/NCSA do place some restrictions on sublicenses ("subject to the following conditions") but I don't see any reason why the Apache license would present a problem as the choice of sublicense.
I am not a lawyer, I am not your lawyer, this is not legal advice.
The whole reason that this license change is coming up is that some people in the project (and I assume Apple as well) want to provide some level of protection from patent infringement cases for the users of LLVM. The ability to sublicense doesn't help here because the patent clause in the Apache 2.0 license would only apply to the patents owned by you, the one who is doing the sub-licensing. They want these protections to apply to the patents of any of the authors of LLVM, which of course cannot be done without their consent.
There is debate about to what extent patent protection is already extant in the current licenses. One example, the MIT has
> to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software
The word "patent" does not appear here, but the words "use" and "distribute" seem to imply the granting of rights necessary to achieve those ends (of which a limited patent license would be one), and the phrase "deal in the software without restriction" is a statement so broad that it seems difficult to argue a patent license (and perhaps many future IP innovations unknown to us today) was not granted by the rules of equitable estoppel.
The reason for this license change is to resolve the ambiguity that arises because the word "patent" does not appear as a word in this clause. It was found that the GPLv2 did not grant patent rights because it was not mentioned in that license [0], although the circumstances of that case and the text of the MIT are far apart.
As a result of all this LLVM may go around and get people to sign off on the Apache grant but it is likely to be under the banner of "clarifying" an implied patent grant rather than establishing a new one. Depending on how worried the lawyers are about the legal meaning of "deal in the Software without restriction" they may not be worried about the contributors they are unable to track down.
> The contributors own their work and licensed it under one license, and the project wants to change it without doing the Herculean job of getting permission from all.
And how Theo figured that the plan isn't to get approval for the license change from all contributors?
Everybody enjoys free (as in "freedom") software. Turns out, even quality-wise free software is often much better than non-free, closed-source software. On the other hand, it may be hard to really understand the rationale behind it. The idea goes against the principles of capitalism (based on property rights). Also, if it is completely OK for hardware design to be proprietary, why should it not be OK for software? What is so special about it? The arguments put forward by proponents of free software do not seem very convincing, and sometimes their personalities do not help attracting people to their cause. Often, this ideal becomes a nuisance even in the world of open source. If you want to use Debian, for instance, you are pretty much forced to use "non-free" repositories (or a "non-free" Debian re-distribution) for your setup to be useful.
What principle of capitalism is being violated? If anything, the freedom to set a price, even $0 if you so choose, sounds like the free market at work.
Property rights. The "free software" principle proclaims that software (possibly, among other things) should be "freed" from the possibility of being anyone's private property. (This also somehow gets mixed with this odd idea that software should be considered a form of "free speech".)
Free software still maintains copyright, if that's what your referring to. However, you're mixing (as is common these days) property rights and other rights (such as copyright). Specifically, you probably intended to use the confusing term "intellectual property".
Software is not a physical thing, so it's not clear who is the "owner" of the work. If you buy a book, you are the owner of the book but are not the copyright holder. In a similar fashion, if you buy (or download) some software, you are the owner of the software but are not the copyright holder. So free software does not proclaim that ownership is evil, it just states that all users should have rights that people have had throughout history when it comes to similar intstructional works such as recipies.
Also the idea that software is a form of "free speech" does not come from the free software movement. I think you're getting confused, and would recommend reading the GNU website[1] to better understand precisely what free software refers to.
Otherwise known as "copyleft", which means that everyone has the right to copy; it, moreover, demands that this right to copy may not be infringed upon by alteration of the software. There is no trace of the originally intended meaning of the word "copyright" in there; if anything, it's just its opposite.
Not all free software licences are copyleft licenses. While the GNU GPL is a very well known and widely used example, it is by far not the only free software licence. The Apache 2.0, MIT, BSD and other commonly used licenses are free software licenses because they provide the recipient the four essential freedoms. Copyleft is not mentioned in the free software definition[1]. It's mentioned as an optional way to license free software works.
In addition, even with copyleft every contributor has copyright over their changes. The crucial part of the copyleft hack is that it requires that distributing derived software must be done under the same license. You may choose to not distribute the software, and then the GNU GPL doesn't require you to do anything.
Property is a system for allocating rivalrous[1] resources. Applying property to freely copyable elements makes no sense. Supporting capitalism in no way requires defending the creation of government-granted monopolies under the cover of property rights.
Private property in the traditional sense is certainly a critical component of capitalism, but "intellectual property" rights are something quite different.
I don't think there is a conflict between support of capitalism and criticism of intellectual "property" rights and the associated legal constructs.
>Turns out, even quality-wise free software is often much better than non-free, closed-source software.
This is only true in the very narrow segment of 'tools for geeks by geeks', 'tools that big software companies need but don't provide a competitive edge/need to be OSS for adoption so they opensource' (Apple, Google, Microsoft) and companies that sell support for OSS (RedHat, Novell, Canonical, etc.)
As soon as you move from IT infrastructure/dev tools there is no contest between OSS and commercial packages or they only cover small a niche. Compare GIMP vs Photoshop, Blender vs Maya/3DSMax/ZBrush, Cycles/Yafaray vs VRay/Renderman/Lux, OSS CAD tools, LibreOffice vs Office, etc. They aren't in the same league most of the time in both quality and functionality supported.
Your point is valid, but also incredibly narrow, the type of tunnel vision that seems to affect all computer using professional artists, who somehow started thinking they were the majority of computer users. Not only is that not the case, but you're such a tiny minority that Apple didn't shy away from dropping you all, dropping software like Aperture, simplifying Final Cut and orienting it toward hobbyists and slashing its price down to a measly $300, and all those moves are coming from the company that used to be known as the friendliest toward artists. Your kind keeps harping about "ah, my firewire port" and so and so and Apple literally doesn't care. You're not the target audience anymore, you represent nothing.
The quality of open source software is, by far, when you consider most needs, more than adequate and often superior to closed source.
Most of the examples you give aren't even close to being evidence of a superiority of closed source in a debate of closed vs open, they are examples of the superiority of a few specific graphic powerhouses like Adobe. Is there anything like Photoshop in the world of closed source software? It is the only one. Closed source doesn't magically make things better. There are plenty of closed source competitors to Photoshop that aren't even close to what GIMP achieves, even more so with that plugin :
http://gmic.eu/
Which replicates almost all the most important functions of modern Photoshop. What GIMP misses, is not power, but productivity, by missing non destructive editing. On the other hand, with something like gmic, gimp is far, far more powerful than ANY other piece of software that isn't called Photoshop. Considering the extremely small amount of people who are actively working on GIMP and its plugins and that none of their are paid for it, I'd say they do an incredible job.
Everything you can do in Photoshop, you absolutely can do with GIMP, for eg things like these :
http://blog.patdavid.net/2014/02/getting-around-in-gimp-gmic...
Work just as good. If you're not a professional working on deadline who truly needs a productivity boost through constant modification of something you're commissioned to produce (which is where Non Destructive Editing shines best), you don't really need anything other than the GIMP.
So I'll quote your first paragraph and throw it back at you:
>>This is only true in the very narrow segment of 'tools for geeks by geeks', 'tools that big software companies need but don't provide a competitive edge/need to be OSS for adoption so they opensource'
Your views are only true in the very narrow segment of 'tools for artists that cost big bucks which represent exactly 0.01% of the software used in the entire world'. If most people don't have a use for the things you mention, like code editors and compilers, they don't have a use for things like Photoshop either.
And if we're going by % of software in use, there are far more web servers out there running open source programs that there will ever be photoshop installations. Much less packages like Maya which fill an even much smaller niche. Niche, a word you seem fond of using for talking about OSS. What is more niche between a web browser and maya?
Browsers fall in to the 'things we need to ship but the source being closed isn't a competitive advantage' of huge software corps (Mozilla being an outlier).
I listed artist tools because that's the thing I have first-hand experience with and I'm sure others here do as well but it's faaar from being limited to that.
List superior OSS alternatives to things like SAP/Dynamics/Salesforce or CAD like SolidWorks/AutoCAD. Where are all the OSS banking systems ? Every industry I've seen has their own specialized tools that cost big $ and has stuff that took years to purpose build, the sort of thing that just isn't viable under OSS model. Industrial control applications, and let's not even go to heavily regulated stuff used in medical devices and such.
I'm not the one who's tunneling here, there's more software out there than dev tools, browsers and server OSes, very little of it is OSS, even less can compete on quality.
The point of the free software movement is not quality, it's user freedom. Would you prefer having an electronic heart implant that is proprietary and is "totally safe trust me", or is free software but isn't the best thing in the world to interface with. I know which I'd pick, and the same logic applies to everything else I rely on in my daily life.
The parent comment was making a statement about quality to which I responded.
And if the proprietary software has been an industry standard and deployed in millions of cases before I would have no problem taking the closed source variant. It would be nice to have the source but in most cases I wouldn't know what to do with it anyway as it requires specialist knowledge, so I'd be relying on the community vetting it vs. legal requirements for approval by the regulatory agencies, I mean it would still be better to have the source but I could live without it.
Anyway my point isn't even related to preference, I'm just saying that the conditions for successful OSS software are limited to one of the models under which it makes sense commercially for the companies using it (most often IT giants), some sort of commercial support/free software deal or in rare cases it's a labor of love for geeks. Most of the software written out there doesn't fall nicely in to those categories and so OSS is not viable in those areas.
> Also, if it is completely OK for hardware design to be proprietary, why should it not be OK for software?
Personally I also have an issue with hardware designs being proprietary, but because we still have issues with software I prefer to spend my energy on the issue we've had better traction on.
> What is so special about it?
The big difference between hardware and software is that software can be in principle changed, modified and updated by the end user without too much hassle. Hardware cannot be practically modified (have you ever tried to modify a chip?). And hardware designs are useless to most users, because they'd need to have someone fab the components for them. However, every user has someone they know who knows how to program, and thus they can practically take advantage of the freedoms that they ought to have a right to.
> If you want to use Debian, for instance, you are pretty much forced to use "non-free" repositories (or a "non-free" Debian re-distribution) for your setup to be useful.
This is simply untrue. I use openSUSE Tumbleweed and have no issues with the proprietary repositories removed. I cannot comment on Debian, but I know a few people who use Debian without the universe repositories enabled. What precisely is "forcing" you to use non-free software? Maybe you should reconsider who you're blaming for that, and maybe try removing that proprietary garbage from your life.
But the distinction between the hardware design and software is blurry. What about microcode? What about designs targeting FPGAs? A basic idea in modern systems design, in fact, is that there is no preconceived notion about where hardware should end and software should begin.
The FSF draws a line that I find interesting (if not necessarily my own): whether it can be updated with a new version. If not, then it's equivalent to a circuit, and it's not as important that it be Free (though it must be non-malicious).
Perhaps I assumed too much context. Through my use of significantly outdated slang I was hoping to communicate something along the lines of "almost the entirety of the internet functions simply because almost all people ignore the legal make-believe that is intellectual property", and my comment was an attempt at a tongue-in-cheek reminder of this.
Regardless, I won't comment further. Message received.
"The LLVM project does not require copyright assignments, which means that the copyright for the code in the project is held by its respective contributors who have each agreed to release their contributed code under the terms of the LLVM License.
An implication of this is that the LLVM license is unlikely to ever change: changing it would require tracking down all the contributors to LLVM and getting them to agree that a license change is acceptable for their contribution. Since there are no plans to change the license, this is not a cause for concern.
As a contributor to the project, this means that you (or your company) retain ownership of the code you contribute, that it cannot be used in a way that contradicts the license (which is a liberal BSD-style license), and that the license for your contributions won’t change without your approval in the future."
The LLVM license (the UofI/NCSA license) is permissive, and thus compatible with just about everything, including the Apache 2.0 license. All the existing code can stay under the old license unless someone agrees to the new one. New contributions can go under the new license. The effective license of the codebase will become Apache 2.0, with some pieces still available under the previous permissive license.
This is considered a dick move for a project to make, often this means any non-trivial changes to existing code will be under the more restrictive licence, with no backward compatibility, preventing such changes from being incorporated by the original authors or anyone perusing a fork of the originally permissive codebase.
A common example of this kind of behaviour is GPL proponents forking BSD or other similiarly licensed software, and exclusively wrapping their contributions to it under the GPLv3.
A license change certainly shouldn't happen lightly, or without consulting the community. In this case, it looks like an extensively considered decision with substantial community feedback.
And patent lawsuits hurt, so as reasons to change licenses go, that seems like a pretty good one.
It only applies to further work done on the project. By licensing your work under a BSD/MIT/etc. style license you explicitly gave anyone permission to use the work in nearly any way they wanted, including as part of a Apache, GPL3, or even completely proprietary closed-source project.
If everyone else on a project decides to use a different license than you picked for their future hard work, that's their choice, not yours.
> A common example of this kind of behaviour is GPL proponents forking BSD or other similiarly licensed software, and exclusively wrapping their contributions to it under the GPLv3.
A much more common example is a proprietary software vendor taking a lax licensed project and creating a proprietary fork of it. Of course, BSD proponents don't mention the far more common case (because it wouldn't help the narrative that GPL proponents only spend their time relicensing code).
Why you don't have a problem with proprietary forks but do have a problem with copyleft forks is beyond me. Especially since sometimes copyleft forks are created because the developers made so many changes that it stands in its own right as a separate project (and the developers feel that user freedom trumps upstreamability).
The proprietary "forks" are often not distributed as source, they're either internal forks, or simply part of a larger product. The difference is that proprietary forks of permissive code is often kept in sync with upstream and you only ever learn of its existence when they decide to contribute back patches. They typically have the courtesy of making those available under the original license terms for everyone to benefit from.
> The difference is that proprietary forks of permissive code is often kept in sync and you only learn of its existence if they decide to contribute back patches. They typically have the generosity of making those available under the original permissive licence.
This sounds like cherry-picking to me. "If they decide to contribute back patches" is something that is not up to you -- and the same logic applies to copyleft forks just as much as it applies to proprietary forks (the quotes are not necessary, proprietary forks of lax licensed software are forks like any other kind of fork). Just because someone has used a license that gives users freedom should not be construed as it being a contribution to you.
> They typically have the generosity of making those available under the original permissive licence.
They also typically have the "generosity" of not providing source code to users, meaning that the users have no freedom when using the software. But hey, at least you got some marginally useful patches that probably aren't all that great. Yay.
Also, please note that some projects do dual-license their changes. I don't understand why you're so salty on this topic.
In fact, licenses that do not permit private copies of the modified software are not considered free software according to the FSF[1] (which I agree with).
> Especially since sometimes copyleft forks are created because the developers made so many changes that it stands in its own right as a separate project (and the developers feel that user freedom trumps upstreamability).
That "user freedom" you mention, which you had when you forked the original permissive codebase to GPLv3, is now lost on those new users you have wanting to make a similar change. It was certainly free enough for you then. It's a dick move ideological statement to push the notion of GPL "user freedom".
The freedom to relicense software is not under the free software definition, so the users have lost no freedoms. The only people that have lost some freedom are distributors of software, which are not the group of people the GPL is trying to protect.
This is all quite funny, because usually lax license advocates say "if you like the GPL then just relicense it because we give you that freedom" but then turn around and say "it's a dick move to relicense our code". If you didn't want people to relicense your code, don't use a license that permits it -- simple as that.
People throw around the phrase "cognitive dissonance" lot, too loosely probably. But BSD folks who constantly tout the virtues of their license for the things that it allows downstream developers to do and then complain when someone actually exercises those options are the single best real world example of cognitive dissonance that I've ever encountered.
That's like saying that you can't be mad about someone not repaying you a loan because you haven't written up a legal contract defining the conditions. Or like saying it's hypocritical to defend free speech and criticize someone for what they've said.
Just because you don't agree with an action doesn't mean you must find it ethical to use the Force of Law to punish it.
The whole point of the switch to Apache 2.0 was the patent grant. The old code will not be effectively under the Apache 2.0 license as far as this clause is concerned because the patent grant is a restriction on the copyright holder, not the user. You can't just take the fact that the authors of some parts of the code agreed not to sue you for patents they implemented in their respective contributions and then force everybody else not to sue you for their own patents.
I'm not suggesting that it's perfect. I'm just suggesting that from a legal point of view, the current license grants enough permissions that they don't have to have unanimous agreement from every copyright holder; the scenario painted in the linked email couldn't happen as written.
(They may still want unanimous agreement, either to have more code under the new license or to confirm community consensus.)
Nothing this says is wrong.
Nobody is changing the license without approval.
Random openbsd developers who don't work on the project opining otherwise is just random internet kibitzing
I'm not sure why anyone thinks there will not be a real license change process. There will.
This is just the stage of settling the question of what the license should be.
Everyone is quite aware of the work it will take to actually change the license (I've managed the process for a number of large projects before) and random commentary from Theo that it will just be unilaterally changed is simply wrong.
Chris's email even says this "
Once we reach an agreement on the path to take, we can start talking about logistics of how to get there."
As for the corporate wannabes comment, the truth is that folks have gone out of their way to talk to both users and contributors, at the developer conference and elsewhere (and in fact, we've spent a year trying to come up with licensing solutions to ensure we don't cause problems for various one off users, whereas most projects who have relicensed usually just told them tough luck).
Past that, I'll be honest:I'm pretty uninterested in what a bunch of random people on an unrelated mailing list, who don't participate in the community at all, want to think. Especially when they have pretty much no data and have never bothered to simply ask questions on the llvm mailing list in the thread (or at the developer conference, or...), like others did.
If they have real concerns, they are welcome to raise them in any of the normal ways.
I'm confused. The post he's responding to is just saying that they want to move to the Apache 2.0 license if possible. Chris certainly doesn't seem to be assuming they can just flick a switch and make it happen, considering he talks about "logistics" and is pretty clear it is still in the discussion stage.
Is it a dick move just to ask the contributors if they're willing to provide the code under the Apache 2.0 license so people can use LLVM without worrying about being sued for patent infringement? This looks to me like Apple and other corporate contributors with large patent portfolios giving users without such bargaining chips some protections from litigation.
I find it hard to see that as a bad thing, unless they were in fact deciding to pretend they own the copyright of the whole project and dare contributors to sue them. Thus far I see no evidence of that.
The anti-patent protections Apache provides don't work if the patent holder has the option to use the license without those protections instead. I believe this is why it's common for projects to dual-license under Apache and GPLv3 - both licenses have anti-patent provisions.
But it's not the patent holder that uses the license at all. It's the downstream user. Any downstream user would be protected by the patent clause as long as they're using the Apache 2.0 license regardless of what the patent holder wishes.
OpenBSD's been around for a long time, it would be unwise to dismiss these concerns, especially considering they've demonstrated this has happened before.
LLVM/clang was recently imported into OpenBSD and is being brought into shape to potentially replace GCC, having OpenBSD developers eyes on a codebase has also historically been a good thing.. I think a future without their input will be bleak.
164 comments
[ 4.0 ms ] story [ 220 ms ] threadThere is no possible way my code in any way could be mistaken for gcc.
There is no danger they can change their code to do fraud against me.
It's really obvious to any programmer.
Frasier is just a monkey-nigger flinging his shit.
> Theo de Raadt (/ˈθiː.oʊ dɛˈrɔːt/; Dutch: [ˈteː.o dɛˈraːt]; born May 19, 1968) is a software engineer who lives in Calgary, Alberta, Canada. He is the founder and leader of the OpenBSD and OpenSSH projects, and was also a founding member of the NetBSD project.
I'm open to specific examples if you have them of widespread changes in INFOSEC or massive adoption of better tech due to Theo de Raadt.
EDIT: I'm aware of many good apps they've made. To clarify, my comment is addressing this broad claim:
"The 'net is secure in no small part to his efforts and that of the rest of the OpenBSD team."
OpenSSH might get credit due to massive use. Good example. Past that, what else does most of the net on client side (mainly Windows & Mac) or server-side (mainly Win, FreeBSD, and Linux) depend on from OpenBSD developers?
And yes, that wee piece of software that is the secure gateway of choice and has been for a great length of time; among a great many other innovations mentioned in the link in another reply.
Paradoxically, projects on github flourish because contributors and users by in large ignore the licenses. Granted, licenses are extremely important to protect intellectual property but nothing kills contributions to open source more than bureaucracy.
In fact if you choose not to specify a license your work counts as copyrighted (as per github licensing documentation). So Github doesn't really remove any "hoops".
> each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted.
GPLv3:
> Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.
The two licenses are definitely not identical on patents, but both are pretty clear that they provide protection to users from developers, insofar as the original code and any modifications downstream were licensed under the Apache 2.0 license. You're right that there's no copyleft, but that doesn't reverse the direction of the patent grant.
> If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.
> If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.
> A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.
To be honest if you're hostile to software patents in general (which I am, and the GPL sure as hell is), the part of the Apache 2.0 license's patent clause that prevents users from flipping around the patent claims seems like a non-issue.
(Because the way you phrased it implies this only holds for patent trolls).
No vendor ships that version anymore. I don't think modern Windows clients will even connect to it now (no working NTLMv2).
The ones who didn't want the GPLv3 (Apple) either wrote their own or purchased a proprietary third party server such as Likewise and were left holding a flaming bag of shit when EMC purchased the Likewise codebase and cancelled all existing support contracts. You'd think people would learn, but there are still vendors out there gambling on using proprietary third party SMB3 servers (hoping the same won't happen to them :-).
GNU General Public License, GPL, LGPL, copyleft, etc.
The GNU Public License and licenses modeled on it impose the restriction that source code must be distributed or made available for all works that are derivatives of the GNU copyrighted code.
While this may superficially look like a noble strategy, it is a condition that is typically unacceptable for commercial use of software. So in practice, it usually ends up hindering free sharing and reuse of code and ideas rather than encouraging it. As a consequence, no additional software bound by the GPL terms will be considered for inclusion into the OpenBSD base system.
For historical reasons, the OpenBSD base system still includes the following GPL-licensed components: the GNU compiler collection (GCC) with supporting binutils and libraries, GNU CVS, GNU texinfo, the mkhybrid file system creation tool, and the readline library. Replacement by equivalent, more freely licensed tools is a long-term desideratum.
[edit] removed extra spaces to avoid HN's auto-formatter
I'll give you folks a hint: the specific quote dleslie responded to says that OpenBSD stuck with GPL2 version of GCC to avoid GPL3.
But, of course, this place being HN, people have attention span of an infant and forget the context by the time they catch something they'd like to respond to :p
They've hired lawyers, and consulted the community. The community's predominant concern was whether the new license (Apache2) would be compatible with GPLv2.
In the "We are now in this year" link, it's explicated how they consulted a gaggle of open source lawyers, determined the predominant belief was the new license was compatible with GPLv2. But they didn't stop there – they had a lawyer draft an addendum to really ensure that!
Not a good look. Fever swamp paranoia, and wishing ill on a series of people clearly trying to do well and address every concern.
Theo de Raadt said neither phrase.
Theo seems to agree with that person though, and "wishing ill on a series of people clearly trying to do well" certainly could apply to both parties in the email.
The main benefit of Apache 2.0 is that it includes a patent grant as well. Right now, LLVM relies on a custom "developer agreement" for anyone who contributes code that includes a grant of patent rights, but it's kind of vague and fuzzy and so makes it hard for some people to contribute, and the license itself doesn't actually mention patents at all:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536...
Theo objects to any license that applies more restrictions than the original BSD license. OpenBSD makes an exception for GPLv2 licensed utilities that have been traditionally shipped with BSDs that there's not a good replacement for, but has stopped upgrading things that have moved to GPLv3 and apparently objects to the Apache license as well.
In this case, it is a little harder to understand OpenBSD's interpretation of additional restrictions because they haven't listed their objections in any centralized place, but from reading around, they seem to believe:
* "You must cause any modified files to carry prominent notices stating that You changed the files" is an additional restriction * "any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License" is an additional restriction * The sheer length and complexity of the Apache license suggests to them there are other additional restrictions buried in there somewhere
I don't think that the position was contraversial, I just think that people took it the wrong way. The Apple EULA objectively has clauses in it that state that users must follow the "acceptable usage policy" and it is enforced regardless of any external agreements -- this would mean that Apple would be violating the GPL if they distribute any GPL software in their store.
You can add additional terms that permit distribution in the Apple store (as Signal has done), but the stock GPL does not permit distribution in the Apple store because the "acceptable use policy" is one of the things the GPL was made to fight against (the idea that users must act in an "acceptable" way to Apple when running software on their own computing devices).
And Red Hat EULA objectively has clauses in it that you may not redistribute RHEL.
There is a slippery slope here, the FSF has decided for whatever reason that RHEL's restrictions "weren’t really restrictive, because they were so easy to comply with" [0] but there is really nothing "objective" about that determination.
[0] https://www.gnu.org/licenses/quick-guide-gplv3.html
Apple's EULA restricts users to only being able to use software they distribute under their "acceptable use policy". This is simply a violation of the GPL, with no wiggle room for discussion.
[1]: https://www.redhat.com/en/about/red-hat-end-user-license-agr...
However, I'm not a lawyer and not involved, was just trying to summarize as well as I could, so I could be wrong.
As a matter of policy, OpenBSD does not ship software that uses the Apache 2.0 License.
It's not entirely clear why that is their policy, but it seems to come down to some combination of the patent clause and the additional complexity of the license.
> The original Apache license was similar to the Berkeley license, but source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD. (http://www.openbsd.org/policy.html)
The Apache license v2 is more restrictive than BSD-style licenses so they can't include code licensed under it.
While better than the GPL, version 2 and 3, in the sense that it's shorter, the Apache 2 license is still much more complex than the ISC or the BSD/MIT licenses. Another part of the issue, for some developers at least, is that the Apache 2 license sort of acknowledges that software patents are a thing. So if you disagree that companies should be allowed to patent software, mathematics and processes, you might not pick a license that validates the existence of those patents.
This sounds absurd to me. Software patents don't go away because one stops believing in them. Either the courts enforce them or not.
Usually, when a project changes its license, it either tries to get permission from each contributor; or it makes an announcement that if any contributor objects, they will remove that person's contributions on request. But US law doesn't actually require that. In the US ( http://copyright.universityofcalifornia.edu/ownership/joint-... ):
"Each joint author has the right to exercise any or all of the exclusive rights inherent in the joint work. Each author may:
"• Grant third parties permission to use the work on a nonexclusive basis without the consent of other joint authors
"• Transfer his or her entire ownership interest to another person without the other joint authors' consent".
In other words, unless you have some kind of enforceable agreement between all contributors, any contributor can relicense the work, without the consent of the other contributors. I'm not sure whether the GPL qualifies as the kind of agreement that could prevent this; the FSF has spent years saying the GPL doesn't meet all the standard requirements of a contract because it doesn't need to be a contract. The FSF famously requires contributors to transfer their copyright interest to the FSF because Stallman says an attorney told him that makes it easier to enforce the GPL. Or, as Eben Moglen says ( https://www.gnu.org/licenses/why-assign.en.html ):
"If there are multiple authors of a copyrighted work, successful enforcement depends on having the cooperation of all authors.
"... [I]n order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer's employer."
Many open source licenses other than the GPL don't have any chance of qualifying as the kind of agreement that could prevent a single contributor from relicensing the project on a whim.
Also note that "contributor" doesn't necessarily mean to "contributor to the parent project." I haven't been able to find any legal reason somebody can't fork a project (following the license), make enough changes to become a joint copyright owner as far as their fork is concerned, and then relicense the fork. I guess the original contributors would also be joint copyright holders as far as the fork is concerned, and could relicense the fork as well. I'm not sure where that would end; and I'm glad that so far nobody's been creative enough to start such a battle.
So, back to LLVM: Apple is, without question, a joint copyright holder and can relicense the code as desired. De Raadt's idea is that a European could say "well, the relicensing was OK under US law, but not under European law." But I don't see how moral rights would prevent relicensing. The Berne Convention establishes moral rights as ( https://en.wikipedia.org/wiki/Moral_rights ):
"Independent of the author's economic rights, and even after the transfer of the said rights, the author shall have the right to claim authorship of the work and to object to any distortion, modification of, or other derogatory action in relation to the said work, which would b...
You think Microsoft, who has put tens of thousands of lines into Linux, has a right to change the license of Linux away from GPL? Is that really what you're positing?
So far, open source projects act like copyright either requires unanimous agreement among the copyright owners to make changes, or each contributor has copyright only in their specific contribution (so, in practice, you need unanimous agreement). That's simply wrong for joint works, and joint works are defined as works meant to be combined together to make one work (the alternative being a collective work, where the parts are simply combined into a collection, does follow the "each contributor has copyright in just their contribution" model).
Copyright law is based on certain assumptions, like "if the co-authors get into an argument, it will be about how to divvy up royalties, and there will be a contract involved." Another is "co-authors work together at the same time, and know each other." Those assumptions are wrong for open source projects.
A party simply can't change the license for code that they did not write. They can only change the license for their own work.
The FSF avoids this problem by requiring copyright assignment. To be honest, I'm not sure that's enough, but I think they're hoping for a sympathetic judge. Most projects have never looked at what the law actually says regarding joint work, and think it works the way they would write the law. I know what the outcome of that will be.
It's like claiming that someone shouting outside of a recording studio has the right to relicense the music created inside the recording studio. While it might be true, I'd want to see an actual legal case before claiming things that are that outlandish.
Not to mention that the GPL has been tested in court and has held. So there's that.
I know what the arguments would be, but I'm not sure how the court would rule. The hypothetical depends on legally making a fork, and the GPL (as an example) only gives permission to fork if you agree that any distribution will be under the terms of the GPL. If you violate those terms, you've committed copyright infringement. But can a joint copyright owner be guilty of infringing his own work?
I remember Eric Raymond discussing a commercial copyright infringement case where a contractor was hired to update a program, and started distributing the updated program without permission. This was his argument.
However, he hadn't made significant changes to the program. Using your words, the program was several orders of magnitude larger than what the contractor added. The court got creative, and declared the contractor only had a collective copyright -- like somebody who has copyright on a single article in an encyclopedia -- and not a joint copyright -- even though his changes were meant to be combined with the original work to create a single work and not a collection of works. A collective copyright owner only has copyright in his contribution.
You are right that courts would be reluctant to allow the tail to wag the dog, but there is some threshold where the contributor has made enough changes that he has joint copyright, and at that point he can do what the law says a joint copyright holder can do.
Every individual contributor could also potentially sue Microsoft in that case. The FSF wouldn't even have to lift a finger, and the contributors could get a nice class-action lawsuit going.
But my understanding of that email is about the irregularity of a unilateral change of license. The contributors own their work and licensed it under one license, and the project wants to change it without doing the Herculean job of getting permission from all.
I think Theo is correct there saying that there is a risk that one of those contributors will then come out of the woods and wreak havoc, risking a forced fork from the relicense point.
IANAL, but "you don't change the license" is one of the few things I was taught.
Wine changed from the MIT license to LGPL without all of the developer's support.
[1]: http://danashultz.com/blog/2010/10/19/what-is-a-sublicense-a...
What do you think being GPL-compatible (for example) means other than that? The GPL requires you to release all parts of the derived work under the GPL, not just a compatible license.
Yes, that's what I was saying.
I don't understand which part of this is confusing you -- the MIT license explicitly states that sublicensing is permitted. If you didn't sublicense the code, then users would be allowed to have all the freedoms that come with the MIT license. This would make it impossible to have a proprietary version of an MIT licensed project -- which is something that we objectively know is possible because it happens all the time.
> Windows for example used to ship BSD licensed code, and it would have been a violation of Windows' license to modify that code (even though the original code was under a free software license).
Microsoft didn't include source and if I had obtained the BSD licensed source, I could certainly modify it and distribute it (but not the code written by Microsoft). Also, the BSD doesn't have a sublicense clause which is problematic for your first sentence.
The grandparent already said that "changing" is not the thing being discussed here, but "sublicensing", so this is a strawman.
> Permission is hereby granted... to deal with the Software without restriction, including... the rights to... sublicense
The effect of this clause is that all LLVM contributors have already consented to a chance in license, whether that change is done by you, me, Debian, or the Pope.
The only question is whether the LLVM organization wishes to exercise this authority itself. It's clear that the majority of the key contributors are in favor of it, so it seems like a foregone conclusion at this point.
The MIT/NCSA do place some restrictions on sublicenses ("subject to the following conditions") but I don't see any reason why the Apache license would present a problem as the choice of sublicense.
I am not a lawyer, I am not your lawyer, this is not legal advice.
[0] http://danashultz.com/blog/2010/10/19/what-is-a-sublicense-a...
> to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software
The word "patent" does not appear here, but the words "use" and "distribute" seem to imply the granting of rights necessary to achieve those ends (of which a limited patent license would be one), and the phrase "deal in the software without restriction" is a statement so broad that it seems difficult to argue a patent license (and perhaps many future IP innovations unknown to us today) was not granted by the rules of equitable estoppel.
The reason for this license change is to resolve the ambiguity that arises because the word "patent" does not appear as a word in this clause. It was found that the GPLv2 did not grant patent rights because it was not mentioned in that license [0], although the circumstances of that case and the text of the MIT are far apart.
As a result of all this LLVM may go around and get people to sign off on the Apache grant but it is likely to be under the banner of "clarifying" an implied patent grant rather than establishing a new one. Depending on how worried the lawyers are about the legal meaning of "deal in the Software without restriction" they may not be worried about the contributors they are unable to track down.
[0] See https://www.fenwick.com/FenwickDocuments/potential_defenses.... for an analysis of the GPLv2 situation
And how Theo figured that the plan isn't to get approval for the license change from all contributors?
Software is not a physical thing, so it's not clear who is the "owner" of the work. If you buy a book, you are the owner of the book but are not the copyright holder. In a similar fashion, if you buy (or download) some software, you are the owner of the software but are not the copyright holder. So free software does not proclaim that ownership is evil, it just states that all users should have rights that people have had throughout history when it comes to similar intstructional works such as recipies.
Also the idea that software is a form of "free speech" does not come from the free software movement. I think you're getting confused, and would recommend reading the GNU website[1] to better understand precisely what free software refers to.
[1]: https://www.gnu.org/philosophy/free-sw.en.html
Otherwise known as "copyleft", which means that everyone has the right to copy; it, moreover, demands that this right to copy may not be infringed upon by alteration of the software. There is no trace of the originally intended meaning of the word "copyright" in there; if anything, it's just its opposite.
In addition, even with copyleft every contributor has copyright over their changes. The crucial part of the copyleft hack is that it requires that distributing derived software must be done under the same license. You may choose to not distribute the software, and then the GNU GPL doesn't require you to do anything.
[1]: https://www.gnu.org/philosophy/free-sw.en.html
[1] https://en.wikipedia.org/wiki/Rivalry_(economics)
I don't think there is a conflict between support of capitalism and criticism of intellectual "property" rights and the associated legal constructs.
This is only true in the very narrow segment of 'tools for geeks by geeks', 'tools that big software companies need but don't provide a competitive edge/need to be OSS for adoption so they opensource' (Apple, Google, Microsoft) and companies that sell support for OSS (RedHat, Novell, Canonical, etc.)
As soon as you move from IT infrastructure/dev tools there is no contest between OSS and commercial packages or they only cover small a niche. Compare GIMP vs Photoshop, Blender vs Maya/3DSMax/ZBrush, Cycles/Yafaray vs VRay/Renderman/Lux, OSS CAD tools, LibreOffice vs Office, etc. They aren't in the same league most of the time in both quality and functionality supported.
Most of the examples you give aren't even close to being evidence of a superiority of closed source in a debate of closed vs open, they are examples of the superiority of a few specific graphic powerhouses like Adobe. Is there anything like Photoshop in the world of closed source software? It is the only one. Closed source doesn't magically make things better. There are plenty of closed source competitors to Photoshop that aren't even close to what GIMP achieves, even more so with that plugin : http://gmic.eu/ Which replicates almost all the most important functions of modern Photoshop. What GIMP misses, is not power, but productivity, by missing non destructive editing. On the other hand, with something like gmic, gimp is far, far more powerful than ANY other piece of software that isn't called Photoshop. Considering the extremely small amount of people who are actively working on GIMP and its plugins and that none of their are paid for it, I'd say they do an incredible job. Everything you can do in Photoshop, you absolutely can do with GIMP, for eg things like these : http://blog.patdavid.net/2014/02/getting-around-in-gimp-gmic... Work just as good. If you're not a professional working on deadline who truly needs a productivity boost through constant modification of something you're commissioned to produce (which is where Non Destructive Editing shines best), you don't really need anything other than the GIMP.
So I'll quote your first paragraph and throw it back at you:
>>This is only true in the very narrow segment of 'tools for geeks by geeks', 'tools that big software companies need but don't provide a competitive edge/need to be OSS for adoption so they opensource'
Your views are only true in the very narrow segment of 'tools for artists that cost big bucks which represent exactly 0.01% of the software used in the entire world'. If most people don't have a use for the things you mention, like code editors and compilers, they don't have a use for things like Photoshop either. And if we're going by % of software in use, there are far more web servers out there running open source programs that there will ever be photoshop installations. Much less packages like Maya which fill an even much smaller niche. Niche, a word you seem fond of using for talking about OSS. What is more niche between a web browser and maya?
I listed artist tools because that's the thing I have first-hand experience with and I'm sure others here do as well but it's faaar from being limited to that.
List superior OSS alternatives to things like SAP/Dynamics/Salesforce or CAD like SolidWorks/AutoCAD. Where are all the OSS banking systems ? Every industry I've seen has their own specialized tools that cost big $ and has stuff that took years to purpose build, the sort of thing that just isn't viable under OSS model. Industrial control applications, and let's not even go to heavily regulated stuff used in medical devices and such.
I'm not the one who's tunneling here, there's more software out there than dev tools, browsers and server OSes, very little of it is OSS, even less can compete on quality.
We've been making good money moving companies from SAP to Odoo.
And if the proprietary software has been an industry standard and deployed in millions of cases before I would have no problem taking the closed source variant. It would be nice to have the source but in most cases I wouldn't know what to do with it anyway as it requires specialist knowledge, so I'd be relying on the community vetting it vs. legal requirements for approval by the regulatory agencies, I mean it would still be better to have the source but I could live without it.
Anyway my point isn't even related to preference, I'm just saying that the conditions for successful OSS software are limited to one of the models under which it makes sense commercially for the companies using it (most often IT giants), some sort of commercial support/free software deal or in rare cases it's a labor of love for geeks. Most of the software written out there doesn't fall nicely in to those categories and so OSS is not viable in those areas.
> Also, if it is completely OK for hardware design to be proprietary, why should it not be OK for software?
Personally I also have an issue with hardware designs being proprietary, but because we still have issues with software I prefer to spend my energy on the issue we've had better traction on.
> What is so special about it?
The big difference between hardware and software is that software can be in principle changed, modified and updated by the end user without too much hassle. Hardware cannot be practically modified (have you ever tried to modify a chip?). And hardware designs are useless to most users, because they'd need to have someone fab the components for them. However, every user has someone they know who knows how to program, and thus they can practically take advantage of the freedoms that they ought to have a right to.
> If you want to use Debian, for instance, you are pretty much forced to use "non-free" repositories (or a "non-free" Debian re-distribution) for your setup to be useful.
This is simply untrue. I use openSUSE Tumbleweed and have no issues with the proprietary repositories removed. I cannot comment on Debian, but I know a few people who use Debian without the universe repositories enabled. What precisely is "forcing" you to use non-free software? Maybe you should reconsider who you're blaming for that, and maybe try removing that proprietary garbage from your life.
Perhaps I assumed too much context. Through my use of significantly outdated slang I was hoping to communicate something along the lines of "almost the entirety of the internet functions simply because almost all people ignore the legal make-believe that is intellectual property", and my comment was an attempt at a tongue-in-cheek reminder of this.
Regardless, I won't comment further. Message received.
"The LLVM project does not require copyright assignments, which means that the copyright for the code in the project is held by its respective contributors who have each agreed to release their contributed code under the terms of the LLVM License.
An implication of this is that the LLVM license is unlikely to ever change: changing it would require tracking down all the contributors to LLVM and getting them to agree that a license change is acceptable for their contribution. Since there are no plans to change the license, this is not a cause for concern.
As a contributor to the project, this means that you (or your company) retain ownership of the code you contribute, that it cannot be used in a way that contradicts the license (which is a liberal BSD-style license), and that the license for your contributions won’t change without your approval in the future."
OOPS.
A common example of this kind of behaviour is GPL proponents forking BSD or other similiarly licensed software, and exclusively wrapping their contributions to it under the GPLv3.
And patent lawsuits hurt, so as reasons to change licenses go, that seems like a pretty good one.
It only applies to further work done on the project. By licensing your work under a BSD/MIT/etc. style license you explicitly gave anyone permission to use the work in nearly any way they wanted, including as part of a Apache, GPL3, or even completely proprietary closed-source project.
If everyone else on a project decides to use a different license than you picked for their future hard work, that's their choice, not yours.
A much more common example is a proprietary software vendor taking a lax licensed project and creating a proprietary fork of it. Of course, BSD proponents don't mention the far more common case (because it wouldn't help the narrative that GPL proponents only spend their time relicensing code).
Why you don't have a problem with proprietary forks but do have a problem with copyleft forks is beyond me. Especially since sometimes copyleft forks are created because the developers made so many changes that it stands in its own right as a separate project (and the developers feel that user freedom trumps upstreamability).
This sounds like cherry-picking to me. "If they decide to contribute back patches" is something that is not up to you -- and the same logic applies to copyleft forks just as much as it applies to proprietary forks (the quotes are not necessary, proprietary forks of lax licensed software are forks like any other kind of fork). Just because someone has used a license that gives users freedom should not be construed as it being a contribution to you.
> They typically have the generosity of making those available under the original permissive licence.
They also typically have the "generosity" of not providing source code to users, meaning that the users have no freedom when using the software. But hey, at least you got some marginally useful patches that probably aren't all that great. Yay.
Also, please note that some projects do dual-license their changes. I don't understand why you're so salty on this topic.
[1]: https://www.gnu.org/licenses/license-list.en.html#NonFreeSof...
That "user freedom" you mention, which you had when you forked the original permissive codebase to GPLv3, is now lost on those new users you have wanting to make a similar change. It was certainly free enough for you then. It's a dick move ideological statement to push the notion of GPL "user freedom".
This is all quite funny, because usually lax license advocates say "if you like the GPL then just relicense it because we give you that freedom" but then turn around and say "it's a dick move to relicense our code". If you didn't want people to relicense your code, don't use a license that permits it -- simple as that.
Just because you don't agree with an action doesn't mean you must find it ethical to use the Force of Law to punish it.
(They may still want unanimous agreement, either to have more code under the new license or to confirm community consensus.)
Chris's email even says this " Once we reach an agreement on the path to take, we can start talking about logistics of how to get there."
As for the corporate wannabes comment, the truth is that folks have gone out of their way to talk to both users and contributors, at the developer conference and elsewhere (and in fact, we've spent a year trying to come up with licensing solutions to ensure we don't cause problems for various one off users, whereas most projects who have relicensed usually just told them tough luck).
Past that, I'll be honest:I'm pretty uninterested in what a bunch of random people on an unrelated mailing list, who don't participate in the community at all, want to think. Especially when they have pretty much no data and have never bothered to simply ask questions on the llvm mailing list in the thread (or at the developer conference, or...), like others did. If they have real concerns, they are welcome to raise them in any of the normal ways.
Is it a dick move just to ask the contributors if they're willing to provide the code under the Apache 2.0 license so people can use LLVM without worrying about being sued for patent infringement? This looks to me like Apple and other corporate contributors with large patent portfolios giving users without such bargaining chips some protections from litigation.
I find it hard to see that as a bad thing, unless they were in fact deciding to pretend they own the copyright of the whole project and dare contributors to sue them. Thus far I see no evidence of that.
The anti-patent protections Apache provides don't work if the patent holder has the option to use the license without those protections instead. I believe this is why it's common for projects to dual-license under Apache and GPLv3 - both licenses have anti-patent provisions.
LLVM/clang was recently imported into OpenBSD and is being brought into shape to potentially replace GCC, having OpenBSD developers eyes on a codebase has also historically been a good thing.. I think a future without their input will be bleak.