On Feb 3, 2008 11:27 PM, bruno randolf <[EMAIL PROTECTED]> wrote: > > On Monday 04 February 2008 13:13:03 Felix Fietkau wrote: > > Luis R. Rodriguez wrote: > > > On Jan 9, 2008 10:27 PM, bruno randolf <[EMAIL PROTECTED]> wrote: > > >> hi! > > >> > > >> manually maintaining the Changes-licensed-under tags for every commit is > > >> boring, so i created the following script which you can paste > > >> into .git/hooks/commit-msg (don't forget to make it executable too) to > > >> automatically add a Changes-licensed-under tag with the same license as > > >> the touched files: > > > > > > This was really cool, thanks! I've added my own, which is a bit > > > different than yours, produces results as those from my latest > > > patches. You can find the script here: > > > > Erm... why exactly do we need the Changes-licensed-under, if > > Documentation/SubmittingPatches contains this bit of information about the > > Developer's Certificate of Origin: > > > > > > (a) The contribution was created in whole or in part by me and I > > have the right to submit it under the open source license > > indicated in the file; or > > > > (b) The contribution is based upon previous work that, to the best > > of my knowledge, is covered under an appropriate open source > > license and I have the right under that license to submit that > > work with modifications, whether created in whole or in part > > by me, under the same open source license (unless I am > > permitted to submit under a different license), as indicated > > in the file; or [...] > > > > Note the "under the open source license indicated in the file" and the last > > part. > > > > Shouldn't this part already make it the default to keep the same license > > that is mentioned in the file?
Warning: IANAL, but these comments are based on experiences and talks with SFLC. I have CC'd Bradley (who is not a lawyer either) and Karen (who is lawyer) from SFLC in case they have time and would like to jump in to clarify some of these items or to poke at me if i have erred. IIRC we actually reviewed these *very same lines* with the SFLC and the recommendation was that this was not sufficient to ensure we can help the BSD camp reap benefit from our changes. The main reason being that although *some* developers and maybe in fact you can argue *most* developers would abide by this, a few developers might be making contributions to non-GPL files thinking they actually are making GPL changes. > i also would like to get rid of having to use Changes-licensed-under tags, as > you said it seems unnecessary in most cases. This is not a requirement at all but simply *one technique* I proposed to see if it would suffice legal requirements and it just so happens that it did. Any other alternative that clearly indicates the desired license for the changes issued would suffice. Its not something we should enforce but simply recommend to help ensuring the BSD camp can use some of the code we produce, from a legal point of view. We went to *great lengths* to just ensure we could keep the ISC license, it seems to me a small cost to pay to try to keep helping them out. On the other hand if a developer wants to make GPLv2 changes to some 3-Clause-BSD/ISC files, then its going to be very difficult at that point to distinguish GPLv2 changes from ISC/3-Clause-BSD. IIRC at that point we could have BSD developers be able to use some of the code we produce only if individual patches are specified as licensed under a 3-Clause-BSD/ISC license. The file as a whole at that point would be GPL though. Fortunately git allows for a easy way to see individual contributions and with the current practice people would still technically be able to distinguish 3-Clause-BSD/ISC changes from GPL. I believe the technically painful part here would be that some aspects of the file would be GPL and some others won't so it would be pretty painful for a developer to figure out what parts of the file were in GPL-state or non-GPL state. Because of this I'd say that if a developer issues changes to some of our 3-Clause-BSD/ISC files and re-licenses our files as Bruno did with debug.[ch] (following SFLC's advice on how to properly accomplish this if you want to) we can just give up on this practice and assume GPL from there forward. What we can then expect the BSD community to reap benefit from our work would probably just be as documentation -- which is probably what they use our code for anyway as last I checked their codebase was still pretty different. Essentially we're doing this while we can, and we're going out of our way, sometimes even testing the patience of some kernel maintainers, to help the BSD camp. > i guess the problem comes in when the source file is dual licensed (e.g. > BSD/GPL as ath5k/base.c for example) and we are doing it now per SFLC > recommendation to make it explicitly clear. Actually this is not the reason why this was put forth but while we're at it let me say there is severe misconceptions about dual licensing GPL/BSD, a practice which hopefully will die. Dual licensing GPL with a-GPL-compatible license is functionally and legally equivalent to licensing under the more permissive license. For example when people dual license GPL with 3-Clause-BSD its functionally and legally equivalent to just licensing under the 3-Clause-BSD license -- which is the more permissive license. Basically its pointless, but I'm sure this is a practice used with good intentions. If you want to help both the BSD and GPL camps issue your code under a BSD license. AFAICT dual licensing is a practice which can be used to license code under GPL and *non-GPL-compatible* licenses. Besides all this, from a legal point of view the "Alternatively" language used for dual licensing in our specific files (base.[ch]) makes it a little vague what the intention was behind the license -- was it an "also" or was it "one or the other" clause. Let me open another can of worms while we're at it to demonstrate the problem with the vagueness of the "Alternatively" language. Historically changes under ath5k's base.[ch] files may have included contributions from patch authors (MadWifi for example) who intended the changes to be made simply under the GPLv2. When we send patches for those files we clarify our changes are under the 3-Clause-BSD to try to side with what Sam probably originally intended -- which was to help the BSD and GPL communities out. I think technically one could also argue that *perhaps* one author made changes with the GPLv2 license in mind. This is true, however, fortunately MadWifi had as whole was known to be Dual licensed type of project from a while back. In fact there are even guidelines specific for patches in which "Signed-off-by" practice was explained for and promoted [1]. > but also in this case i think it > would be safe to assume that the changes have the same license as the source > file (in this case dual). I think this is a safe bet for most developers but its certainly something we cannot assume for everyone unless we can somehow ensure all developer contributing are very aware of this practice. The other issue here is the Linux kernel's license is the GPLv2, contrary to MadWifi project, for example, so you could expect a few people who would think when contributing to Linux they would always be contributing changes under the GPLv2. This is why, for example, we asked Linux wireless developers to subscribe the submitting patches guidelines [2] on linuxwireless.org wiki. When changes are made people get e-mails with diffs of the changes made. [1] http://madwifi.org/wiki/DevDocs/SigningPatches [2] http://linuxwireless.org/en/developers/Documentation/SubmittingPatches Luis _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
