[arch-dev-public] License updates (was: rebuilding the whole core repo)
On 10/22/07, Travis Willard <travisw@wmpub.ca> wrote:
On Mon, 22 Oct 2007 15:00:59 +0200, Damir Perisa wrote
Sunday 21 October 2007, Travis Willard wrote: | If we're feeling REALLY ambitious, this would be a great time to | fix all the licenses in our packages - we still have over 1000 bad | licenses in extra - attached file shows packages that need work.
good idea... regarding your list i have some items:
* we should have the MIT licence in our common licences folder
* we should add all possible CC licences in our common licences folder ... maybe informing creative commons that we support their full scheme of licencing in our licence handling (public relations, networking *g*)
Regarding the above two, I'm all for adding common licenses (MIT, CC) to the licenses package, provided we can - I remember some licenses that are pretty common actually differ in their text from package to package (ie. the devs of the software need to add their own info for copyrights or something) - we can't really provide a common license for those.
For BSD, MIT, etc. the difference is that the license text changes based on the package, unlike the GPL which has the same text always. I know for BSD we are supposed to (according to the wiki page) list the license as 'BSD' but still include the text of the license. I would think the same applies for MIT and anything else where the text differs. I've kind of taken ownership of the licenses package, so feel free to shoot me suggestions as to what should be included and I'll gladly update it.
* LGPL2 = LGPL2.1 ? and if some pkg uses 2.0? our LGPL2 is indeed the 2.1 version
How significant are the differences between 2.0 and 2.1? Isn't our GPL2 license 2.1 as well?
I would say yes, they are in fact equivalent.
* some pkgs have licence-formatting issues (Apache instead of APACHE or gpl instead of GPL ... we change the formating? licences are all-caps always?)
It seems the precident is for common licenses, list them as all caps- of course, this makes sense for things that are abbreviations such as the GPL but not so much for APACHE. I'd be up for change, but we *really* need to document this. Our wiki article should have hard and fast guidelines for things like this.
The script I used to generate that list checked, for each license in licenses, is it "custom"? If not, then does a folder structure exist at /usr/share/licenses/common/${license}? If no, then it's invalid. Since the folders in /usr/share/licenses/common are capitalized, I think the entries in the license array should be as well.
Looking at it this way, caps seems stupid for licenses unless it is intended to be that way (e.g. GPL, BSD). There are a few other sticky issues, such as whether BSD/MIT should be listed as 'BSD' or 'custom:BSD' (I know I've read somewhere that we should use the former, which I agree with- it is a standard license, but the text differs between packages). -Dan
* some pkgs have licence-formatting issues (Apache instead of APACHE or gpl instead of GPL ... we change the formating? licences are all-caps always?)
It seems the precident is for common licenses, list them as all caps- of course, this makes sense for things that are abbreviations such as the GPL but not so much for APACHE. I'd be up for change, but we *really* need to document this. Our wiki article should have hard and fast guidelines for things like this.
It made much more sense when it was APL, but apparently people didn't know what the Apache Public License was...
The script I used to generate that list checked, for each license in licenses, is it "custom"? If not, then does a folder structure exist at /usr/share/licenses/common/${license}? If no, then it's invalid. Since the folders in /usr/share/licenses/common are capitalized, I think the entries in the license array should be as well.
Looking at it this way, caps seems stupid for licenses unless it is intended to be that way (e.g. GPL, BSD).
I do like the licenses being all caps. That's how I think of licenses. Either way, how would you case apache to make it more proper? Apache? Jason
On 10/22/07, Jason Chu <jason@archlinux.org> wrote:
Looking at it this way, caps seems stupid for licenses unless it is intended to be that way (e.g. GPL, BSD).
I do like the licenses being all caps. That's how I think of licenses.
Either way, how would you case apache to make it more proper? Apache?
I would say that it shouldn't matter. We should do case insensitive matching here. I mean, really, do we want Apache, APAche, and aPACHe to mean different licenses? I doubt it.
Monday 22 October 2007, Aaron Griffin wrote: | On 10/22/07, Jason Chu <jason@archlinux.org> wrote: | > > Looking at it this way, caps seems stupid for licenses unless | > > it is intended to be that way (e.g. GPL, BSD). | > | > I do like the licenses being all caps. That's how I think of | > licenses. | > | > Either way, how would you case apache to make it more proper? | > Apache? | | I would say that it shouldn't matter. We should do case | insensitive matching here. I mean, really, do we want Apache, | APAche, and aPACHe to mean different licenses? I doubt it. exactly my point, but reading your aPaCHE derivates, i almost spilled my tea... lol... maybe aPACHe is more restrictive than APache? LOL - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
On Mon, Oct 22, 2007 at 10:41:55AM -0500, Aaron Griffin wrote:
On 10/22/07, Jason Chu <jason@archlinux.org> wrote:
Looking at it this way, caps seems stupid for licenses unless it is intended to be that way (e.g. GPL, BSD).
I do like the licenses being all caps. That's how I think of licenses.
Either way, how would you case apache to make it more proper? Apache?
I would say that it shouldn't matter. We should do case insensitive matching here. I mean, really, do we want Apache, APAche, and aPACHe to mean different licenses? I doubt it.
Ok, that's fair enough. I'll change the namcap license rule to be case-insensitive. Jason
participants (4)
-
Aaron Griffin
-
Damir Perisa
-
Dan McGee
-
Jason Chu