The FSF is slightly biased; they want to "lay their paws on" the BSD-licensed software out there.
They use the argument I debunked, as they don't see the difference between "an appropriate" and "a specific appropriate", as they lack experience doing embedded development with the collection of BSD licenses. I have that experience, and know how much of a pain license reproduction can be (not to mention license vetting by lawyers.)
Your primary argument seems to be "White is black, because I say so" - "Taking away freedom isn't taking away freedom because another way of taking away freedom isn't taking away freedom, because I refuse to entertain that freedom is a zone of shades of grey."
You are making ECONOMIC claims. Do you understand economics and game theory? For instance, do you understand why becoming irrational in anger is a rational advantage?
These are not rethorical questions, really - they are requirements for a sane debate. If you do not have this competence, you are not competent to have opinions in this area. If you want to have a decent opinion - if you want to contribute to understanding rather than noise - you need to make yourself qualified before arguing these points, as just arguing will lead to your opinion strengthening EVEN WHEN IT IS WRONG.
So, I ask if you are competent - and if you are not, if you're willing to ask questions about the topics and learn about them, rather than game around with words convincing yourself deeper and deeper of something without going the rational route.
I'm skipping further arguments until we get this stuff cleared out. I just have one comment about an additional misunderstanding of yours, WRT patch quality. You assume that there is only one dimension to development quality. There isn't. For FreeBSD, strict style guidelines are important, and throughout consistency in the codebase is important, including full documentation updates etc. For a number of the patch types we did, this was not relevant for our use; the code functionality was 100% for the customers, and the code quality was adequate for maintenance; the correct tradeoff was to stop development of some parts when they worked 100%. Doing them correctly for various subtle aspects of style (the obvious ones of formatting and naming were of course OK) would be significant extra work, work that was inappropriate for our mission yet with my FreeBSD hat on I saw it as inappropriate to commit them without fixing them.
As far as I can evaluate, the GPLv2 is NOT compatible with three-clause BSD. The three-clause BSD brings in an extra restriction: Reproduction of the 3-clause BSD license. This is an extra restriction. Think of having 2000 different variants of BSD style licenses in the same program, all requiring reproduction. This place a extra burden on anybody that want to distribute binary copies, and would otherwise just have to provide a copy of the GPL and an offer of providing source code - now they have to add about 1000 pages of print or a readable digital format.
It is common to try to argue that this fall under "an appropriate copyright notice and disclaimer of warranty" part of the GPL; however, as shown as above, it is clear that there is a significant difference between requiring "any appropriate copyright notice and disclaimer of warranty" and requiring "a specific copyright notice and disclaimer of warranty", especially as you scale up.
Following standards without messing with the standardization process (though participating in it as an ethical member), of course.
Or, barring that, sitting down and dying. If they can't be a responsible corporate citizen - which I'd prefer - they should die. Even if that requires that they just get shut down by the government.
The injunctive remedy is interesting and appropriate. Yes, it is interfering with business - but monopolies get to be interfered with, at least if we want a functioning market. And pricing Windows as a commodity would be good, overall.
No, the GPL has the problem of co-existing in the same app as CDDL.
Place blame where it belongs - GPL is the one bringing the heavy restrictions creating license incompatibility with EVERYTHING that cannot be converted directly to the GPL (including all BSD style licenses, if you do an exact reading of the GPL and BSD licenses.)
In the end, ZFS is the single point that tempts me in general about Solaris, but I'm not about to jump platforms when I know enough 'tricks' to get 'good enough' out of my existing platform. I hear and understand you.
However, understand that the purpose of the GPL is to encourage all code to be "free," ... by doing an attack on proprietary software, and the benefits that gives to those that want to pool their resources to solve a special problem (e.g, risk mitigation - the people can buy the product after all the risk has been taken.)
Note that I'm none too happy with proprietary software in general; I do, however, see an economic positive function for it in niches, especially when it can be built reasonably cheaply (by standing on the shoulders of giants - that is, free software).
The Slashdot translation says:
In a letter from Microsoft, our business partners were informed that they were "expected" to participate in the SIS meeting and vote yes. As a compensation they would get "market benefits" and extra support in terms of Microsoft resources. What is translated as "market benefits" is originally "marknadsbidrag" - which, assuming Swedish is the same as my native tongue Norwegian in this area - means marketing subsidies, which would as far as I know usually be in the form of Microsoft paying for their partner's advertising. This is more or less direct cash for the companies, and can be substantial amounts.
We may waive any right to complain about their morals, though we may complain about their lack of enlightened self-interest:) I'll also note that slapping the GPL on BSDed code is pragmatically more dangerous to the BSDed alternative than somebody slapping a proprietary license on the same, as the GPLed variant would to a larger degree compete for the same mindshare. As a such, if we allow shades of grey instead of black and white, it's morally "more wrong" to create a GPLed fork of a BSDed project and not feed changes back than to do a proprietary derivate, as the GPLed version both influence the access to developers more and it is more likely to be ideological rather than pragmatic, and as a such not contribute changes back.
For a proprietary fork, propagating changes upstream makes good "business sense" - you get somebody else to maintain the changes for you, and the changes will be taken into account for the decision of "official" changes, instead of you having to argue a weak case that that change will damage your proprietary derivate and maintain things yourself. You also get community goodwill and internal goodwill and a feeling among your employees of "doing the right thing". If you are to keep changes proprietary, the strategic value of keeping those changes proprietary have to exceed the tactical value you get from the above. That's seldom the case, yet when it is the case, it's important - and having the ability to do so if necessary has strategic value (removing risk) *even if the ability is never used and you give away all your changes to the community*.
WRT why people choose the GPL: The problem as I see it is that a lot of programmers choose the GPL for bad reasons - for instance (and this seems to be common) thinking that BSDs don't get any changes back (which it does) and that GPL code will get changes back from commercial companies that it otherwise wouldn't get (which it won't, since the commercial companies will choose to work on other codebases that they CAN keep proprietary). And once people have started choosing the GPL, they will naturally start feeling that this is for good reasons, and will look for reasons to behave that way (attitude adjustment due to behaviour is a basic social psychological phenomenon). So, I'm trying to get more people to know the difference, and choose the GPL when it is appropriate, after having looked through the direct impact of their licensing rather than just their feelings, and to also look at the alternative licenses and how it directly impact things.
Also, I try to make people look at goals. I work primarily for the twin goals of maximising the amount of free software, and maximising overall freedom for people through making the world more wealthy. For this goal, the use of the BSD style licenses is usually - in my opinon - the best choice. For the original goal of the GPL license - killing off proprietary software, no matter what the cost to free software - the GPL is excellent. The GPL is also good to use for dual-licensing, and in some cases for companies where they want to give away tech but don't want another company to start competing with them, for strategic reasons.
Overall, I want people to think about these things properly, and really follow their goals - logically, methodically, and efficiently.
I'm deeply familiar with the laws of "your country", having lived here myself some 33 years (which happen to be since birth);)
As for "not considering BSDed software free software", you can convert BSD license to copyleft by slapping an extra restriction on it, which you are allowed to do, and as long as the end user is using the BSD licensed version, they have the freedom to do this if they want to.*
Of course, it depends on what your overall goals are. Mine is to create a richer world, overall - one where people have more freedom, in all its variations. One of the important freedoms here is the ability to allocate risk, something that can require the ability to create restraints. To understand this properly requires that you are somewhat schooled in understanding economics, including why we want to pay off risk.
Whether this include the ability to get source is debatable; I personally think that it would be reasonable to require source access, though not to allow redistribution. For me, an optimal license would often be one that allowed public access after a reasonably short period - somewhere in the range of 3-5 years - and allowed the creation of derivates that was kept proprietary for that period. It strikes a balance between building a "creative commons" to build from and the ability to finance the risk of building products.
Eivind.
* I'll note that RMS and most of the rest of the community agree with me in considering BSD free software; the copylefter that disregard this seems to be a student invention, with PVV in the forefront.
As far as I can tell, you are arguing that the user should not have the freedom to get the change at a discounted cost (because the developer expects further work) by trading his freedom to have another developer do the work? Why? It sounds like some sort of "protect the user from himself" thing?
Apart from that, developers are the ones that create changes. Without developers, the difference between the GPL and the BSD license is moot. The question, to my mind, is primarily one of what creates the most free software? Assuming rational interaction, I see this as being the BSD license. The primary way that the GPL creates more software is by making the contributing developers feel "safe from exploitation" and "fighting against the machine" and "using the license that makes more free software", which in my are irrational, to a degree fueled by rms' excellent propaganda. The way to counter is with information and rationality, hopefully.
I'll reorder because there is a crucial and common misunderstanding here:
You can't later port new features added under the GPL back into your BSD-licensed system under a BSD license, which is exactly the same result as happens when someone cuts a closed, proprietary branch like MS with the IP stack.
That we do not get changes from proprietary derivates is a common belief. It's also dead wrong. The BSDs get a LOT of changes back from the proprietary derivates; the SCSI stack of FreeBSD and the Netgraph subsystem would be two large examples. From my own work I could mention NAT daemon firewall passthrough as a simple feature.
So, passing the code into a proprietary derivate is a large improvement from not having people do anything with the code. The derivate creates changes which have a likelihood of making it back; the non-use creates ZERO likelihood of having changes passed back.
It's a bit rich to deny people to keep their own changes proprietary, wouldn't you say?
Except that's what the GPL tries to do. It's removing freedom.
Sorry, I think your logic is broken here. If you (as a BSD developer) wish to grant complete freedom to all users of your code, including the right to cut a closed proprietary branch or fork - which is my fag-packet understanding of the BSD license - then isn't the GPL simply a special case of "proprietary"?
Yes, GPL is in my book a special form of proprietary, where the restriction created is different from the common ones, and created to protect emotions rather than to create profit.
The BSD license does not prohibit the mix with the GPL license; rather, the GPL prohibits the additional restrictions that the BSD license gives, even though they are fairly small.
It's a bit rich to deny people to keep their own changes proprietary, wouldn't you say?
(...)
We want our software to keep freedom. Including the freedom of future developers to keep their own changes private, or get paid for them.
(...)
As an example, we have Apples operating system, partially made on code I wrote. And I'm a very happy user of it, even though I (or rather, my employer) had to pay for the extra stuff Apple has added.
So please tell... how can I keep my changes to Apple's OS private, or get paid for them? Oh wait, I can't do that because I can't make any changes at all. It's a bit rich to deny the ability to make any changes at all on something made up mostly of "free" software, wouldn't you say? Actually, you can make changes to Darwin, which is the free software parts.
I never quite understand the BSD logic, because on the one hand you love the ability to create, buy and use proprietary derivates. Yet the freedom you want is anything but in that software. It's in some other software over there, which is pure BSD and comes with source code.
Maybe it's me that's wierd, but I care about the ability to improve the software I am using and not about the ability to improve software I'm not using. Like in this case, if I were an OS X user I'd care about the ability to improve OS X and not about the abiltiy to improve Free/Open/NetBSD. The more people use GPL software, the more people will improve it. The more people use proprietary derivates over pure BSD, the less people will improve it. Assuming the proprietary derivates do not submit changes back to the pure BSD branch. Which is a wrong assumption - many (most?) do. The rest of your argument rests on this wrong assumption (and a couple of other assumptions about how developer acquisition happens which are too simplified), so it's fairly much moot.
If you really valued freedom, you would give away your software under a license giving away complete freedoms - that is, as public domain.
Placing a work in the public domain does not work toward freedom.
If you do not grant others the rights you yourself enjoy, and indeed instead seek to have additional power over them, that is not freedom.
The rights you have: To license it how you see fit, make modifications to it that you can license how you see fit, and to present yourself as the author of the work. Those rights are the rights you give away with placement into the public domain.
As far as I can tell, you seek to have additional powers over people beyond that. You seek to dictate their actions based on some type of morality, done by removing their freedoms.
Oh, you noticed that this was word games, too?
No, it's not "word games", it's simply incorrect to refer to public domain as "a license giving away complete freedoms". Public domain and BSD style licences allow for the authoritarian use of content - "I used work X freely to create my work Y, but if anyone tries to use work Y freely to create their own work Z, I will use the might of the federal government to stop them!" This not freedom. Freedom implies equality, while what the author of work Y demands here is submission.
But this wasn't a question of whether the author of Y gave freedom. It was a question of whether the author of X gave freedom. You are arguing that the author of X should not give freedom, because of the potential of an Y not giving freedom.
As the author of work X, I want to protect the freedoms of potential authors of work Z.
In this, the different licenses are mere tools, and the actual activity around the software - writing it, copying it, modifying it, with people doing it for love or for money or a combination, with money ultimately providing the possibility (as people have to live) - are the things to analyse.
Of course the actions are what is significant, the licenses tools. And of course people must make a living.
That doesn't mean that it is right to make a living by actions which degrade the freedoms of others.
Let me come with a concrete example of "restricting freedom" creating greater freedoms here: I used to work for a company that made ISDN router/mail/proxy boxes based on FreeBSD. This included a variety of kernel patches and a bunch of system patches, the totality of this sold as a product to about a hundred customers (more were planned, but it didn't turn out that way.)
The product would not have been made without the ability to have discretion in what patches to give away and which to keep. We ended up giving back about 90% of the patches, keeping the rest proprietary because they were either too low quality to push upstream, or they were totally specific tuning mods that were not appropriate upstream.
Now, the customers gained the freedom to have a box that did what they needed. This is a freedom they would not have had if we hadn't created the box, so not gaining the additional right to create more boxes themselves can't be seen as "degrading" (and we wouldn't have been able to give them the additional freedom we did without the ability to give the freedoms separately.)
Incidentally, the FreeBSD community gained the freedom of using those of the patches that were appropriate for them, patches that would not be available otherwise.
If you see any "degrading of freedom" in this, please detail. As far as I can see, the overall freedom level went up for everybody, by giving them more and better choices, including creating more free software.
I totally agree that there are different kinds of freedoms in different part of the system; my point was to highlight a different freedom, and show a different perspective. If you misunderstood that, maybe I should have been more explicit about playing up one side - I thought it was obvious.
I disagree with your definitions of how a BSD developer versus a GPL developer thinks, though. In my experience, it is usually a case of a BSD developer saying "I want freedom for the people that use the software I write. I don't want to restrict what they can do with it, including making their own software from it and doing whatever they want with that. The software I write will be out there by direct distribution, so anybody that want to will be able to use that particular software - selling any derivative of it is only possible when the derivative is enough better that people are willing to pay for the improvements, and then the cost is based on the value of those improvements."
The GPL user says "I want to force the people that use the software I write to do a particular thing with any software they develop that incorporate it: I want to force them to give away the changes." The rationale, when I've forced most GPLers to go into it, is that they are afraid of "feeling exploited". So, they remove freedom to avoid the risk of a feeling. Then they often go on to rationalize it as "software freedom" - but - when confronted face to face - they end up with "I would feel so bad if somebody else made something useful from my software and I didn't get money, so I'll make it impossible for them to make something useful and make money from it," or he just applies the GPL by routine, or from a misunderstood belief that it creates more free software directly (because he subconsciously thinks that other developers are license agnostic, and that the changes that otherwise becomes proprietary magically is created and given to the public if the code is GPL licensed, rather than the fact that the changes won't be done at all.)
That's my primary experience with the different philosophies. There are variations, and there are people licensing different ways for different reasons.
The removal of the freedom of relicensing - which is what the GPL does - removes all the freedoms that results from relicensing.
Ownership of land is one example of "relicensing" of the free use of nature, which e.g. many Indians take/took exception to. Yet, ownership of land create a host of other freedoms - like the ability to have a private space you can rely on over time.
Trying to make the GPL into "It is only removing the ability to remove freedom and arguing that this in itself destroys freedoms is sophistry" is just the standard persuasive trick of using emotionally laden words to trick yourself and others into not looking at the underlying realities. In other words: Sophistry. Your accusation goes back on yourself.
Now, if you had decency, you would look over your words and apologize for your silly dance.
My experience makes this restriction much more obvious - I've had to reproduce about 70 licenses for a product, instead of just the two. Well over a hundred pages of licenses, instead of about 2 (with, for the GPL, a written offer of source code).
For a physical product, this adds a noticeable extra burden. One extra license is no big deal, yet multiply it by a bunch and it becomes obvious.
Just reproducing the license (without adding the restriction that the distributor HAS to reproduce the license), as in dual-licensing, would not add any extra restrictions. It would also only be possible for the original author, who can say whatever he wants about the license - including modifying the GPL by granting exceptions from it, such as the ability to license under another license. He could also add extra restrictions, as long as he actually only used his own code. (The only thing that could block that would be the license on the text of the GPL itself; as far as I remember that's a free distribution license with no right to create derivatives, which would be fine - as the author would not be modifying the GPL text.)
Giving an exception seems within the spirit of the GPL. Reproducing the copyrights/licenses is actually onerous in many cases, but it doesn't usually interfere much with the end user's ability to change and redistribute the code as source, which is what the GPL seems to mostly be concerned about.
Personally, I would probably add another GPL poison pill to whatever I released after that, though - to require people to actually contact me and have the code relicensed if they want to hack around with the GPL. And convincing me to relicense would include convincing me that they knew exactly what they were doing and had sound reasons for needing/wanting to use the GPL instead of sticking with a more free license; I see routine licensing under the GPL as damaging, and want to do my little bit against it.
Just like it would if the code was taken properitary.
It's a bit rich to deny people to keep their own changes proprietary, wouldn't you say?
Except that's what the GPL tries to do. It's removing freedom.
And that's what many of us BSDers are against. We want our software to keep freedom. Including the freedom of future developers to keep their own changes private, or get paid for them. Thereby, we also allow the end users the freedom to buy those changes - a freedom they wouldn't have if the code was GPLed, because the incentive to make the changes wouldn't be there.
As an example, we have Apples operating system, partially made on code I wrote. And I'm a very happy user of it, even though I (or rather, my employer) had to pay for the extra stuff Apple has added. The ability to do so is a freedom I have partially gotten from having released my software under the BSD license.
They use the argument I debunked, as they don't see the difference between "an appropriate" and "a specific appropriate", as they lack experience doing embedded development with the collection of BSD licenses. I have that experience, and know how much of a pain license reproduction can be (not to mention license vetting by lawyers.)
Eivind.
You are making ECONOMIC claims. Do you understand economics and game theory? For instance, do you understand why becoming irrational in anger is a rational advantage?
These are not rethorical questions, really - they are requirements for a sane debate. If you do not have this competence, you are not competent to have opinions in this area. If you want to have a decent opinion - if you want to contribute to understanding rather than noise - you need to make yourself qualified before arguing these points, as just arguing will lead to your opinion strengthening EVEN WHEN IT IS WRONG.
So, I ask if you are competent - and if you are not, if you're willing to ask questions about the topics and learn about them, rather than game around with words convincing yourself deeper and deeper of something without going the rational route.
I'm skipping further arguments until we get this stuff cleared out. I just have one comment about an additional misunderstanding of yours, WRT patch quality. You assume that there is only one dimension to development quality. There isn't. For FreeBSD, strict style guidelines are important, and throughout consistency in the codebase is important, including full documentation updates etc. For a number of the patch types we did, this was not relevant for our use; the code functionality was 100% for the customers, and the code quality was adequate for maintenance; the correct tradeoff was to stop development of some parts when they worked 100%. Doing them correctly for various subtle aspects of style (the obvious ones of formatting and naming were of course OK) would be significant extra work, work that was inappropriate for our mission yet with my FreeBSD hat on I saw it as inappropriate to commit them without fixing them.
Eivind.
It is common to try to argue that this fall under "an appropriate copyright notice and disclaimer of warranty" part of the GPL; however, as shown as above, it is clear that there is a significant difference between requiring "any appropriate copyright notice and disclaimer of warranty" and requiring "a specific copyright notice and disclaimer of warranty", especially as you scale up.
Eivind.
Or, barring that, sitting down and dying. If they can't be a responsible corporate citizen - which I'd prefer - they should die. Even if that requires that they just get shut down by the government.
Eivind.
Eivind.
Place blame where it belongs - GPL is the one bringing the heavy restrictions creating license incompatibility with EVERYTHING that cannot be converted directly to the GPL (including all BSD style licenses, if you do an exact reading of the GPL and BSD licenses.)
Eivind.
So does everybody that use Windows.
Eivind.
Very funny presentation!
Note that I'm none too happy with proprietary software in general; I do, however, see an economic positive function for it in niches, especially when it can be built reasonably cheaply (by standing on the shoulders of giants - that is, free software).
Eivind.
Eivind.
For a proprietary fork, propagating changes upstream makes good "business sense" - you get somebody else to maintain the changes for you, and the changes will be taken into account for the decision of "official" changes, instead of you having to argue a weak case that that change will damage your proprietary derivate and maintain things yourself. You also get community goodwill and internal goodwill and a feeling among your employees of "doing the right thing". If you are to keep changes proprietary, the strategic value of keeping those changes proprietary have to exceed the tactical value you get from the above. That's seldom the case, yet when it is the case, it's important - and having the ability to do so if necessary has strategic value (removing risk) *even if the ability is never used and you give away all your changes to the community*.
WRT why people choose the GPL: The problem as I see it is that a lot of programmers choose the GPL for bad reasons - for instance (and this seems to be common) thinking that BSDs don't get any changes back (which it does) and that GPL code will get changes back from commercial companies that it otherwise wouldn't get (which it won't, since the commercial companies will choose to work on other codebases that they CAN keep proprietary). And once people have started choosing the GPL, they will naturally start feeling that this is for good reasons, and will look for reasons to behave that way (attitude adjustment due to behaviour is a basic social psychological phenomenon). So, I'm trying to get more people to know the difference, and choose the GPL when it is appropriate, after having looked through the direct impact of their licensing rather than just their feelings, and to also look at the alternative licenses and how it directly impact things.
Also, I try to make people look at goals. I work primarily for the twin goals of maximising the amount of free software, and maximising overall freedom for people through making the world more wealthy. For this goal, the use of the BSD style licenses is usually - in my opinon - the best choice. For the original goal of the GPL license - killing off proprietary software, no matter what the cost to free software - the GPL is excellent. The GPL is also good to use for dual-licensing, and in some cases for companies where they want to give away tech but don't want another company to start competing with them, for strategic reasons.
Overall, I want people to think about these things properly, and really follow their goals - logically, methodically, and efficiently.
Eivind.
That's a good call...
Nuff said.
As for "not considering BSDed software free software", you can convert BSD license to copyleft by slapping an extra restriction on it, which you are allowed to do, and as long as the end user is using the BSD licensed version, they have the freedom to do this if they want to.*
Of course, it depends on what your overall goals are. Mine is to create a richer world, overall - one where people have more freedom, in all its variations. One of the important freedoms here is the ability to allocate risk, something that can require the ability to create restraints. To understand this properly requires that you are somewhat schooled in understanding economics, including why we want to pay off risk.
Whether this include the ability to get source is debatable; I personally think that it would be reasonable to require source access, though not to allow redistribution. For me, an optimal license would often be one that allowed public access after a reasonably short period - somewhere in the range of 3-5 years - and allowed the creation of derivates that was kept proprietary for that period. It strikes a balance between building a "creative commons" to build from and the ability to finance the risk of building products.
Eivind.
* I'll note that RMS and most of the rest of the community agree with me in considering BSD free software; the copylefter that disregard this seems to be a student invention, with PVV in the forefront.
Apart from that, developers are the ones that create changes. Without developers, the difference between the GPL and the BSD license is moot. The question, to my mind, is primarily one of what creates the most free software? Assuming rational interaction, I see this as being the BSD license. The primary way that the GPL creates more software is by making the contributing developers feel "safe from exploitation" and "fighting against the machine" and "using the license that makes more free software", which in my are irrational, to a degree fueled by rms' excellent propaganda. The way to counter is with information and rationality, hopefully.
Eivind.
You can't later port new features added under the GPL back into your BSD-licensed system under a BSD license, which is exactly the same result as happens when someone cuts a closed, proprietary branch like MS with the IP stack.
That we do not get changes from proprietary derivates is a common belief. It's also dead wrong. The BSDs get a LOT of changes back from the proprietary derivates; the SCSI stack of FreeBSD and the Netgraph subsystem would be two large examples. From my own work I could mention NAT daemon firewall passthrough as a simple feature.So, passing the code into a proprietary derivate is a large improvement from not having people do anything with the code. The derivate creates changes which have a likelihood of making it back; the non-use creates ZERO likelihood of having changes passed back.
Sorry, I think your logic is broken here. If you (as a BSD developer) wish to grant complete freedom to all users of your code, including the right to cut a closed proprietary branch or fork - which is my fag-packet understanding of the BSD license - then isn't the GPL simply a special case of "proprietary"?
Yes, GPL is in my book a special form of proprietary, where the restriction created is different from the common ones, and created to protect emotions rather than to create profit.The BSD license does not prohibit the mix with the GPL license; rather, the GPL prohibits the additional restrictions that the BSD license gives, even though they are fairly small.
Eivind.
(...)
We want our software to keep freedom. Including the freedom of future developers to keep their own changes private, or get paid for them.
(...)
As an example, we have Apples operating system, partially made on code I wrote. And I'm a very happy user of it, even though I (or rather, my employer) had to pay for the extra stuff Apple has added.
So please tell... how can I keep my changes to Apple's OS private, or get paid for them? Oh wait, I can't do that because I can't make any changes at all. It's a bit rich to deny the ability to make any changes at all on something made up mostly of "free" software, wouldn't you say? Actually, you can make changes to Darwin, which is the free software parts. I never quite understand the BSD logic, because on the one hand you love the ability to create, buy and use proprietary derivates. Yet the freedom you want is anything but in that software. It's in some other software over there, which is pure BSD and comes with source code.
Maybe it's me that's wierd, but I care about the ability to improve the software I am using and not about the ability to improve software I'm not using. Like in this case, if I were an OS X user I'd care about the ability to improve OS X and not about the abiltiy to improve Free/Open/NetBSD. The more people use GPL software, the more people will improve it. The more people use proprietary derivates over pure BSD, the less people will improve it. Assuming the proprietary derivates do not submit changes back to the pure BSD branch. Which is a wrong assumption - many (most?) do. The rest of your argument rests on this wrong assumption (and a couple of other assumptions about how developer acquisition happens which are too simplified), so it's fairly much moot.
Eivind.
Placing a work in the public domain does not work toward freedom.
If you do not grant others the rights you yourself enjoy, and indeed instead seek to have additional power over them, that is not freedom.
The rights you have: To license it how you see fit, make modifications to it that you can license how you see fit, and to present yourself as the author of the work. Those rights are the rights you give away with placement into the public domain.As far as I can tell, you seek to have additional powers over people beyond that. You seek to dictate their actions based on some type of morality, done by removing their freedoms.
No, it's not "word games", it's simply incorrect to refer to public domain as "a license giving away complete freedoms". Public domain and BSD style licences allow for the authoritarian use of content - "I used work X freely to create my work Y, but if anyone tries to use work Y freely to create their own work Z, I will use the might of the federal government to stop them!" This not freedom. Freedom implies equality, while what the author of work Y demands here is submission.
But this wasn't a question of whether the author of Y gave freedom. It was a question of whether the author of X gave freedom. You are arguing that the author of X should not give freedom, because of the potential of an Y not giving freedom.As the author of work X, I want to protect the freedoms of potential authors of work Z .
Of course the actions are what is significant, the licenses tools. And of course people must make a living.
That doesn't mean that it is right to make a living by actions which degrade the freedoms of others.
Let me come with a concrete example of "restricting freedom" creating greater freedoms here: I used to work for a company that made ISDN router/mail/proxy boxes based on FreeBSD. This included a variety of kernel patches and a bunch of system patches, the totality of this sold as a product to about a hundred customers (more were planned, but it didn't turn out that way.)The product would not have been made without the ability to have discretion in what patches to give away and which to keep. We ended up giving back about 90% of the patches, keeping the rest proprietary because they were either too low quality to push upstream, or they were totally specific tuning mods that were not appropriate upstream.
Now, the customers gained the freedom to have a box that did what they needed. This is a freedom they would not have had if we hadn't created the box, so not gaining the additional right to create more boxes themselves can't be seen as "degrading" (and we wouldn't have been able to give them the additional freedom we did without the ability to give the freedoms separately.)
Incidentally, the FreeBSD community gained the freedom of using those of the patches that were appropriate for them, patches that would not be available otherwise.
If you see any "degrading of freedom" in this, please detail. As far as I can see, the overall freedom level went up for everybody, by giving them more and better choices, including creating more free software.
Eivind.
I disagree with your definitions of how a BSD developer versus a GPL developer thinks, though. In my experience, it is usually a case of a BSD developer saying "I want freedom for the people that use the software I write. I don't want to restrict what they can do with it, including making their own software from it and doing whatever they want with that. The software I write will be out there by direct distribution, so anybody that want to will be able to use that particular software - selling any derivative of it is only possible when the derivative is enough better that people are willing to pay for the improvements, and then the cost is based on the value of those improvements."
The GPL user says "I want to force the people that use the software I write to do a particular thing with any software they develop that incorporate it: I want to force them to give away the changes." The rationale, when I've forced most GPLers to go into it, is that they are afraid of "feeling exploited". So, they remove freedom to avoid the risk of a feeling. Then they often go on to rationalize it as "software freedom" - but - when confronted face to face - they end up with "I would feel so bad if somebody else made something useful from my software and I didn't get money, so I'll make it impossible for them to make something useful and make money from it," or he just applies the GPL by routine, or from a misunderstood belief that it creates more free software directly (because he subconsciously thinks that other developers are license agnostic, and that the changes that otherwise becomes proprietary magically is created and given to the public if the code is GPL licensed, rather than the fact that the changes won't be done at all.)
That's my primary experience with the different philosophies. There are variations, and there are people licensing different ways for different reasons.
Eivind.
The removal of the freedom of relicensing - which is what the GPL does - removes all the freedoms that results from relicensing.
Ownership of land is one example of "relicensing" of the free use of nature, which e.g. many Indians take/took exception to. Yet, ownership of land create a host of other freedoms - like the ability to have a private space you can rely on over time.
Trying to make the GPL into "It is only removing the ability to remove freedom and arguing that this in itself destroys freedoms is sophistry" is just the standard persuasive trick of using emotionally laden words to trick yourself and others into not looking at the underlying realities. In other words: Sophistry. Your accusation goes back on yourself.
Now, if you had decency, you would look over your words and apologize for your silly dance.
Eivind.
Eivind.
For a physical product, this adds a noticeable extra burden. One extra license is no big deal, yet multiply it by a bunch and it becomes obvious.
Just reproducing the license (without adding the restriction that the distributor HAS to reproduce the license), as in dual-licensing, would not add any extra restrictions. It would also only be possible for the original author, who can say whatever he wants about the license - including modifying the GPL by granting exceptions from it, such as the ability to license under another license. He could also add extra restrictions, as long as he actually only used his own code. (The only thing that could block that would be the license on the text of the GPL itself; as far as I remember that's a free distribution license with no right to create derivatives, which would be fine - as the author would not be modifying the GPL text.)
Eivind.
Personally, I would probably add another GPL poison pill to whatever I released after that, though - to require people to actually contact me and have the code relicensed if they want to hack around with the GPL. And convincing me to relicense would include convincing me that they knew exactly what they were doing and had sound reasons for needing/wanting to use the GPL instead of sticking with a more free license; I see routine licensing under the GPL as damaging, and want to do my little bit against it.
Eivind.
The original BSD vaersion is still out there.
Just like it would if the code was taken properitary.It's a bit rich to deny people to keep their own changes proprietary, wouldn't you say?
Except that's what the GPL tries to do. It's removing freedom.
And that's what many of us BSDers are against. We want our software to keep freedom. Including the freedom of future developers to keep their own changes private, or get paid for them. Thereby, we also allow the end users the freedom to buy those changes - a freedom they wouldn't have if the code was GPLed, because the incentive to make the changes wouldn't be there.
As an example, we have Apples operating system, partially made on code I wrote. And I'm a very happy user of it, even though I (or rather, my employer) had to pay for the extra stuff Apple has added. The ability to do so is a freedom I have partially gotten from having released my software under the BSD license.
Eivind.