| |||||||||||||
GPLv3 & additional permissions/restrictionsGPLv3 & additional permissions/restrictionsPosted Sep 26, 2006 11:39 UTC (Tue) by robilad (guest, #27163)In reply to: GPLv3 & additional permissions/restrictions by mingo Parent article: Some GPLv3 clarifications from the FSF
GPLv3 just codifies existing practice in this area, where large projects with many stake holders like gcc, or the Linux kernel have used their specific exceptions to the GPL to make sure recepients of the code receive additional permissions that are not in the GPLv2, per se, or clarify the recepients obligations.
That has been going on since 1992, or so.
(Log in to post comments)
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 11:49 UTC (Tue) by mingo (subscriber, #31122) [Link] GPLv3 just codifies existing practice in this area, where large projects with many stake holders like gcc, or the Linux kernel have used their specific exceptions to the GPL to make sure recepients of the code receive additional permissions that are not in the GPLv2, per se, or clarify the recepients obligations.Would you mind to elaborate on what kind of additional permission there is in the Linux kernel's license? I'm not aware of any, and i'm a copyright holder of the Linux kernel.
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 12:05 UTC (Tue) by robilad (guest, #27163) [Link] Thanks for the correction, Ingo.
I may be completely off base here, but I was under the impression that the kernel had a clarification/permission for exported interfaces facing glibc that their use does not consititute a derivative work of the GPLd kernel?
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 12:21 UTC (Tue) by robilad (guest, #27163) [Link] I meant the text
NOTE! This copyright does *not* cover user programs that use kernel
on top of GPLv2 in the file COPYING in the Linus kernel. I think it serves to clarify the licensing status of the kernel regarding works using it by normal means through an addition to the GPL.
I would argue that such a permission in the kernel has not led to dire consequences that balkanisation predicts. I am unaware of any Linux forks without such an addition to the GPL.
I would argue that's for a simple reason: removing freedoms that have been granted before by yourself and other generous contributors to the kernel would only leads to a less useful code base, and serve to shut out existing stake holders. As such, the forked code base would be less useful than the existing project, so no such forks would be as successful.
I'd furthermore argue that a similar argument would hold for any tightening of licensing conditions by removing additional permissions from GPLv2/v3 licensed code.
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 12:27 UTC (Tue) by mingo (subscriber, #31122) [Link] that was never meant to be an additional permission. See: this collection of emails from Linus.What constitutes derived work isnt Linus' job to determine: it's a matter of law. (the GPLv2 is pretty silent on the issue so what controls is copyright law)
GPLv3 & additional permissions/restrictions Posted Sep 26, 2006 13:21 UTC (Tue) by robilad (guest, #27163) [Link] Oh, I fully agree with that, I'm just pointing out that the kernel itself has an additional note on top of the GPLv2 regarding the desired interpretation of the permissions in the license. There is nothing wrong in that, and I don't mean to nitpick whether it's a mere clarification, or an additional permission, or something else.
My point above was that some large projects find it useful to clarify or extend the permissions contained in their GPLv2-based licensing terms through such additions to the GPLv2. That practice has so far not had the negative consequences alluded to in gregkh's piece, despite going on for a long time.
Open Source seems quite alive, actually. :)
|
|||||||||||||