Timing the addition of permissive licensing
There has been a lot of debate on the ethics of copycenter (permissive like BSD, MIT, or Apache) vs. copyleft (e.g., viral licenses like the GPL).
Of course, it's a matter of choice, as well explained, I think, in this article. (The article raises another separate question for me as to there were a nearly completely permissive license which allowed inclusion in closed source works, but which virally prohibited Digital Rights Management or being used on hardware restricting access to code--not sure if that makes sense...I'm also unclear on whether GPL3 prohibits use on machines that use DRM at all or only if the GPL3 code itself (and its derivatives) must be accessible. And while I'm posing questions, I also need to find out whether GPL3 as opposed to GPL2 allows requiring attribution in the original or derivative works--I'm personally not a fan of attribution in truly open projects, as it can become cumbersome ("How many people do I have to list here??") or effectively non-free (if you're a company) to have to do so. And if one contributes to an open-source project, to retain the copyright on one's own contributions, is it really necessary to list "copyright 2009", etc.? Ok, on with the post, Brett...)
Anyhow, strictly from an altruistic point of view, my current thoughts are as follows. (p.s. IANAL--I am not a lawyer, so nothing here constitutes legal advice)
If the project is such that a vendor could end up hijacking it, or if you feel it really needs contributions from vendors, then a viral license (including the lesser GPL) might work. But... unless you are philosophically opposed to closed source (which is not necessarily what those who use copyleft licenses automatically are), you might arguably be helping the development of society along if you released under a more permissive license--once your own project reached sufficient maturity.
For example, I'm thinking that if the PHP.JS had been under a copyleft license originally (it is under MIT), once the PHP.JS project manages to implement the bulk of the functions, although no doubt the implementations can continue to improve, it would be less of a concern that the project could be hijacked, and if code improvements needed to be made to the library itself by a closed source project, they could still do so.
Granted, you might argue that society would be better served if companies lost all incentives to close the source, due to viral licenses taking over, so, according to such a position, viral licenses are more helpful to society even if it means a company cannot bring a cool idea into fruition, since they might feel forced to find closed source incentives elsewhere. I think there may be a difference here as to whether we are talking about code which can turn into a whole infrastructure (e.g., Apple proved they could run with BSD, and if they had or would become a monopoly, it could cause trouble for others), or whether it is just part of the infrastructure.
For example, if toll roads were ubiquitous, that could really impact our freedom (though, it may be arguable that allowing some such roads (perhaps with a time limit on their exclusive rights--like copyright expiration) ensures they are better maintained and provide useful access routes, etc., and also don't burden tax payers who do not use such roads). However, it may be less clear in certain cases. For example, a browser also provides a kind of infrastructure, even though it is not as fundamental as the operating system. In any case, I think that closed file formats are worse for interoperability, no matter how critical (though I guess some might argue closed file formats are themselves potential innovations).
One possibility which I'm not sure has been raised (no doubt somewhere it has), is the approach of starting out with a copyleft license, and explicitly informing would-be contributors that the code can be dual-licensed at some future point (assuming the contributors hand over copyright, so other developers' contributions can indeed escape GPL viral issues in the future) under a more permissive license, assuming certain conditions were first met (e.g., that all functions would have some agreeable implementation). Perhaps the original developer could write an agreement indicating that they would not use the code given to them under any license besides the current copyleft one, until such time as they might feel the conditions were met to publish under the permissive license--at which point the original developer would need to fully publish all such contributions in order to himself/herself begin to freely use the contents of the permissive license which were based on others' submissions (and of course others could then use the contents of the permissively-licensed code as well).
I would think that the above approach might invite more contributions--and even more fast-paced contributions, at least among those who were serious to contribute. The closed-source developers would at least have SOME incentive to help out, as they might not if the code were in the beginning under a permissive license or if there was no indication that the license could ever be made permissive.
In any case, I think it is helpful to distinguish between different incentives and different approaches, to consider idealistic ethics or practical concerns, rather than lumping them together. However, I also agree with Bruce Perens' point (in the article cited above), that having too many choices can also be a burden (for the developer). Although the arguments about GPL3 dealing with later legal issues are persuasive (I'm still unclear on the DRM issue however, as per the question I posed above), I am concerned that the GPL itself (whose licenses are mutually incompatible) can cause a proliferation of licenses (if there can be a GPL3, then there may well be a mutually incompatible GPL4).
Heck, maybe the FSF should just make a version of GPL which states that it is an auto-updating license which automatically subjects itself to future versions of the GPL as soon as publicly available! If we all do start using the GPL3, it really can be a pain not to have access to all of the work done by others in GPL2. What if some company writes their code in some manner, that when exposed to air (as might happen when trying to open an embedded device), it vanishes. While the GPL3 does insist on "durable physical medium" when releasing the code by conveying "the object code in, or embodied in, a physical product", maybe "durable" can be twisted by the right lawyers. Anyways, this is just an example, but I don't think we can guarantee that GPL3 is the last license from FSF forever (assuming you think theirs is the best viral license). [Update: I see that this eventuality of a changing license was, as I should have imagined, already anticipated. Suggestions are given at http://www.gnu.org/licenses/rms-why-gplv3.html for releasing under "GPL version 3 or any later version" or assigning a proxy to be able to make decisions about later versions.]
Of course, it's a matter of choice, as well explained, I think, in this article. (The article raises another separate question for me as to there were a nearly completely permissive license which allowed inclusion in closed source works, but which virally prohibited Digital Rights Management or being used on hardware restricting access to code--not sure if that makes sense...I'm also unclear on whether GPL3 prohibits use on machines that use DRM at all or only if the GPL3 code itself (and its derivatives) must be accessible. And while I'm posing questions, I also need to find out whether GPL3 as opposed to GPL2 allows requiring attribution in the original or derivative works--I'm personally not a fan of attribution in truly open projects, as it can become cumbersome ("How many people do I have to list here??") or effectively non-free (if you're a company) to have to do so. And if one contributes to an open-source project, to retain the copyright on one's own contributions, is it really necessary to list "copyright 2009", etc.? Ok, on with the post, Brett...)
Anyhow, strictly from an altruistic point of view, my current thoughts are as follows. (p.s. IANAL--I am not a lawyer, so nothing here constitutes legal advice)
If the project is such that a vendor could end up hijacking it, or if you feel it really needs contributions from vendors, then a viral license (including the lesser GPL) might work. But... unless you are philosophically opposed to closed source (which is not necessarily what those who use copyleft licenses automatically are), you might arguably be helping the development of society along if you released under a more permissive license--once your own project reached sufficient maturity.
For example, I'm thinking that if the PHP.JS had been under a copyleft license originally (it is under MIT), once the PHP.JS project manages to implement the bulk of the functions, although no doubt the implementations can continue to improve, it would be less of a concern that the project could be hijacked, and if code improvements needed to be made to the library itself by a closed source project, they could still do so.
Granted, you might argue that society would be better served if companies lost all incentives to close the source, due to viral licenses taking over, so, according to such a position, viral licenses are more helpful to society even if it means a company cannot bring a cool idea into fruition, since they might feel forced to find closed source incentives elsewhere. I think there may be a difference here as to whether we are talking about code which can turn into a whole infrastructure (e.g., Apple proved they could run with BSD, and if they had or would become a monopoly, it could cause trouble for others), or whether it is just part of the infrastructure.
For example, if toll roads were ubiquitous, that could really impact our freedom (though, it may be arguable that allowing some such roads (perhaps with a time limit on their exclusive rights--like copyright expiration) ensures they are better maintained and provide useful access routes, etc., and also don't burden tax payers who do not use such roads). However, it may be less clear in certain cases. For example, a browser also provides a kind of infrastructure, even though it is not as fundamental as the operating system. In any case, I think that closed file formats are worse for interoperability, no matter how critical (though I guess some might argue closed file formats are themselves potential innovations).
One possibility which I'm not sure has been raised (no doubt somewhere it has), is the approach of starting out with a copyleft license, and explicitly informing would-be contributors that the code can be dual-licensed at some future point (assuming the contributors hand over copyright, so other developers' contributions can indeed escape GPL viral issues in the future) under a more permissive license, assuming certain conditions were first met (e.g., that all functions would have some agreeable implementation). Perhaps the original developer could write an agreement indicating that they would not use the code given to them under any license besides the current copyleft one, until such time as they might feel the conditions were met to publish under the permissive license--at which point the original developer would need to fully publish all such contributions in order to himself/herself begin to freely use the contents of the permissive license which were based on others' submissions (and of course others could then use the contents of the permissively-licensed code as well).
I would think that the above approach might invite more contributions--and even more fast-paced contributions, at least among those who were serious to contribute. The closed-source developers would at least have SOME incentive to help out, as they might not if the code were in the beginning under a permissive license or if there was no indication that the license could ever be made permissive.
In any case, I think it is helpful to distinguish between different incentives and different approaches, to consider idealistic ethics or practical concerns, rather than lumping them together. However, I also agree with Bruce Perens' point (in the article cited above), that having too many choices can also be a burden (for the developer). Although the arguments about GPL3 dealing with later legal issues are persuasive (I'm still unclear on the DRM issue however, as per the question I posed above), I am concerned that the GPL itself (whose licenses are mutually incompatible) can cause a proliferation of licenses (if there can be a GPL3, then there may well be a mutually incompatible GPL4).
Heck, maybe the FSF should just make a version of GPL which states that it is an auto-updating license which automatically subjects itself to future versions of the GPL as soon as publicly available! If we all do start using the GPL3, it really can be a pain not to have access to all of the work done by others in GPL2. What if some company writes their code in some manner, that when exposed to air (as might happen when trying to open an embedded device), it vanishes. While the GPL3 does insist on "durable physical medium" when releasing the code by conveying "the object code in, or embodied in, a physical product", maybe "durable" can be twisted by the right lawyers. Anyways, this is just an example, but I don't think we can guarantee that GPL3 is the last license from FSF forever (assuming you think theirs is the best viral license). [Update: I see that this eventuality of a changing license was, as I should have imagined, already anticipated. Suggestions are given at http://www.gnu.org/licenses/rms-why-gplv3.html for releasing under "GPL version 3 or any later version" or assigning a proxy to be able to make decisions about later versions.]
posted by Brett at
7:56 PM
0 Comments:
Post a Comment
<< Home