| |||||||||||||
WOW! Community soap opera - and then some!WOW! Community soap opera - and then some!Posted Oct 3, 2006 5:57 UTC (Tue) by eru (subscriber, #2753)In reply to: WOW! Community soap opera - and then some! by bojan Parent article: Busy busy busybox 1. Can GPLv3 really stop DRM in numbers that matter? Easy one. The answer is No. If GPL'ed software had a Microsoft-like market share, then it might have some effect, but as things now stand, those that want to create systems with DRM capabilities will simply base their designs on non-GPL3 software, of which there is no lack of. 2. Would staying with GPLv2 accelerate DRM adoption or not? It would have no effect. I think the only thing that really can stop DRM is consumer reaction against it. As long as there is demand for DRM technology, there is no shortage of software writers willing to help provide it. 3. Are we about to witness a huge FOSS licensing split? I hope there is still time to find common ground, otherwise this will be the biggest setback to F/OSS to ever happen.
(Log in to post comments)
WOW! Community soap opera - and then some! Posted Oct 3, 2006 15:33 UTC (Tue) by mingo (subscriber, #31122) [Link] 3. Are we about to witness a huge FOSS licensing split? I hope there is still time to find common ground, otherwise this will be the biggest setback to F/OSS to ever happen. I agree, and i hope so too. For example the patent language looks quite OK to me - patents are the "source code of ideas", so an extension of the Quid Pro Quo to that space looks obviously correct and are within the spirit of the GPLv2. One problem spot is the DRM provisions which depart from the spirit of the GPLv2 by trying to control certain works created independently from our codebase - for example certain types of hardware. This "controlling of other works" is achieved by the GPLv3 by adding certain types of "keys" to the definition of "Source Code" - and hence forcing the release of them [or the ceasing of distribution] via the distribution clauses. (with tons of qualifications and exceptions all around to avoid known collateral damage. It's a real mess, and by far my biggest problem with the GPLv3 - and also the main worry of other kernel developers who have expressed negative opinion. See other posts in this thread for more details and for a rather lively discussion of this topic.) The other problem spot is the 'extra permissions and restrictions' language. It is purportedly there to allow the integration of code with different license structures, but this integration is not done on an equal basis: "pure GPLv3" code is treated in an assymetrically beneficial way, which some people fear will lead to the assimilation of "non-pure" GPLv3 code. It also departs from the fundamental contribution symmetry spirit promised by the GPLv2: "code others take from you and modify you can take back and put into your project". With the currently proposed GPLv3, taking "pure GPLv3" code (that was taken from your project and modified) and putting those modifications into your "GPLv3 + permissions" project might silently "upgrade" your project's licensing status to "pure GPLv3" - at which point, if your licensing difference from the GPLv3 was on moral or religious grounds it's not "your project" anymore. So my suggestion would be to not "silence" critics with the promise of extra permissions allowed, but with the addressing of the worries of the critics.
|
|||||||||||||