Theo de Raadt on LLVM license change
marc.info
marc.info
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.
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. > > > 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> 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.
> 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".
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?
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.
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.
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.
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.
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.
"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.)
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.
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 be prejudicial to the author's honor or reputation."
Note, (1) that is "independent of an author's economic rights" and (2) the contributor has the ability to object to any modification, mutilation, distortion, etc., of the work; not of the terms the work is distributed under. Countries can establish their own idea of moral rights, but I'm pretty sure they will follow the Berne Convention's definition pretty closely.
So I would predict the outcome would be a court opinion that any contributor has the right to change the license, and that moral rights aren't the right tool to stop a relicensing. And if anybody can fork, become a contributor in the fork, and relicense the fork, I don't see how anyone can enforce any license restrictions.
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.
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.
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.
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.