Re: would this custom license considered DFSG-free/GPL-compatible
On Tue, 04 Oct 2016, Paul Wise wrote: > On Tue, Oct 4, 2016 at 8:56 PM, Yaroslav Halchenko wrote: > > // 4. If anything other than configuration, indentation or comments have > > been > > //altered in the code, the modified code must be made accessible to the > > //original author(s). > This is impossible to comply with for those who do not have Internet > access so I think it would fail DFSG item 5; No Discrimination Against > Persons or Groups. ok -- playing devil's advocate (just a phrase, I am not of that opinion about the upstream ;)) -- nothing there states about connectivity (Internet) or media (digitized, printed) how they must be made accessible. Could be via mail, bottle in the ocean, ... -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
would this custom license considered DFSG-free/GPL-compatible
Dear Debian IANALs, Would you consider this short custom license DFSG-free and compatible for reuse/integration within projects under more permissive (MIT/BSD) or copyleft licenses such as GPL. (do not want to burden/prime you with my analysis). // This software is published under the terms of KeyJ's Research License, // version 0.3. Usage of this software is subject to the following conditions: // 0. There's no warranty whatsoever. The author(s) of this software can not //be held liable for any damages that result from existence or use of this //software. // 1. This software may be used freely for both non-commercial and commercial //purposes. // 2. This software may be redistributed freely, paid or unpaid, in source or //binary form, standalone or as part of a larger work, as long as this //license information is included. // 3. This software may be modified freely except for this license information, //which must not be changed in any way. // 4. If anything other than configuration, indentation or comments have been //altered in the code, the modified code must be made accessible to the //original author(s). Thank you very much in advance for your time/input! P.S. Please keep me and Martin CCed. Thank you very much -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Does logo under CC BY SA makes entire project SA
Dear IANALs, I am in a dialog about a license for a logo I once envisioned and then some proper designed helped to design but because naive me didn't disclose upfront the terms of the logo release -- got problematic. Now at least we agreed that logo could be released under CC BY SA (share-alike) license but I wondered: if I have a software project which is under more permissive license (MIT or BSD-3) and then includes that logo a) in the code b) in the documentation. Does it obligates share alike (thus copyleft) licensing of the entire project, i.e. it would not be available for close-source derivatives? or would be ok as long as logo itself, if modified, is exposed in original form (.ai or .svg) Thanks for your views on this P.S. I would appreciate being CCed in replies -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150225155532.gx7...@onerussian.com
Re: Does logo under CC BY SA makes entire project SA
On Wed, 25 Feb 2015, Simon McVittie wrote: share alike (thus copyleft) licensing of the entire project, i.e. it would not be available for close-source derivatives? The important question is, is the code or documentation legally a derivative work of the logo, or have they just been put alongside each other? (This is really a question for a lawyer - it's a question about copyright law, not about CC licenses.) Thank you Simon -- that was a nice view / thought exercise! -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150225172113.gr7...@onerussian.com
is swirl a known trademark? or just swirl with word 'Debian'?
NB moving this to debian-legal with hope for better closure before making more noise on -project On Mon, 12 Jan 2015, Josselin Mouette wrote: Yaroslav Halchenko wrote: I don't think so: http://tmsearch.uspto.gov/bin/showfield?f=docstate=4803:q33o33.2.1 The mark consists of a spiral formed with the style of a paintbrush stroke with the word debian written. And there are much simpler trademarks out there. The logo of a famous clothing company consists in a blue square with three characters written in white, in a given font. i.e. swirl on its own is not trademarked, thus could be freely used for other projects The swirl is a trademark, regardless of your uninformed opinion on that topic. just for my own education -- could you please support your statement with references? in my case I have cited the official USPTO description of the Debian trademark. As in your example black square without three letters wouldn't be considered a trademark of that closing company -- why then Debian swirl (released under the most open license and not explicitly trademarked) is officially (not just hypothetically) an existing trademark? I do not remember the case when we (Debian/SPI) followed up on cases where nearly exactly the same swirl was used, making swirl is a trademark even weaker (without exercise, there is no strength ;) ). Or there were? Cheers, -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150112170242.gv7...@onerussian.com
Python library under permissive GPL-compatible license optionally using GPL library
Dear fellas who know much more about licensing than me. I might have even asked before (since we are in a similar situation with PyMVPA/shogun) but forgot what was the summary: If we have a library X in Python, released under some GPL-compatible license (e.g. BSD-3 or Expat) and then using (optionally) some GPL code (at run time) provided by another library Y -- what are the implications? Am I wrong on any of the following statements - the project X codebase doesn't have to be relicensed to GPL - the project X can use project Y (since under GPL compatible license) - It is only at 'run time' when actual linking to the library Y happens, so project must comply with GPL but whose responsibility it is then and what needs to be enforced? - original distributor of X must have provided all the sources with modifications? But it was user's decision to use GPL'ed library - or user must somehow make sure he has the sources... (sounds dubious) - is mere ability to be used with GPL licensed library Y makes distributors of code of X required to comply with GPL? (e.g. provide modified sources) Thanks in advance for your feedback [1] http://mail.scipy.org/pipermail/nipy-devel/2014-December/010707.html -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212170741.gb7...@onerussian.com
GLF Library custom license -- DFSG-compliant?
Hi NALs and ALs, While working on a next package I ran into the GLF library code, which was once released under following license | GLF Library | Version 1.0 (Release) | | Author: Roman Podobedov | Email: ro...@ut.ee | WEB: www.ut.ee/~romka | Date: 17 August 2000 | | Copyright (C) 2000, Romka Graphics | This library is freely distributable without any license or permissions. | You can use this library in any program (commercial, educational | or individual), but in each program, where You use this library, You | should to keep this header (author name and coordinates)! and wondered what would be your take on it (do not want to bias you with my concerns)? could it be considered DFSG-compliant and GPL-compatible? FWIW, subsequent version of the library was released under a somewhat modified license explicitly forbidding commercial use and is distributed within non-free within mgltools-pyglf package here is the text of that license: This library is freely distributable without any license or permissions for non-commercial usage. You can use this library in any non-commercial program. In each program, where You use this library You should keep this header (author name and coordinates)! Thank you in advance for your feedback! FWIW -- I did try to reach Roman to inquire about the license and possibility to re-release it under some standard FOSS license, but all emails I could find were obsolete now. So if anyone is stronger in google-foo, feel welcome to reach out ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140427022402.ga3...@onerussian.com
ODC-By license -- DFSG-compliant?
), and this License will continue in full force and effect unless terminated as stated above. ### 10.0 General 10.1 If any provision of this License is held to be invalid or unenforceable, that must not affect the validity or enforceability of the remainder of the terms and conditions of this License and each remaining provision of this License shall be valid and enforced to the fullest extent permitted by law. 10.2 This License is the entire agreement between the parties with respect to the rights granted here over the Database. It replaces any earlier understandings, agreements or representations with respect to the Database. 10.3 If You are in breach of the terms of this License, You will not be entitled to rely on the terms of this License or to complain of any breach by the Licensor. 10.4 Choice of law. This License takes effect in and will be governed by the laws of the relevant jurisdiction in which the License terms are sought to be enforced. If the standard suite of rights granted under applicable copyright law and Database Rights in the relevant jurisdiction includes additional rights not granted under this License, these additional rights are granted in this License in order to meet the terms of this License. -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130912163359.gz27...@onerussian.com
use of openlogo in derivative logo for a Debian sub-project
Dear IANALs, ANALs and Zack, not out of boredom but just out of enthusiastic inspiration I thought to come up with a logo to use for our Python-In-Debian efforts. All variants are available at http://www.onerussian.com/tmp/pydebian-red_tuned/ Unfortunately PSF (Python Software Foundation) has forbidden us to use the modified and tiled Python logo, thus killing 1-5 variants. And we are left with 6 or 7 (last two). Now the question: would use of (slightly modified) openlogo (without word Debian ATM) in logo behind Python-In-Debian projects, be ok with the Debian trademark policy? Thank you in advance for clarifications, -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic signature.asc Description: Digital signature
Re: Are ‘UniProt’ records complying with the DFSG ?
eh, I feel your pain... e.g. now I was thinking to re-upload pystatsmodels which was already once rejected due to my omission of mentioning copyright with restrictive license on some quite factual DB. unfortunately IMHO we (Debian) are not in position to provide such legal service to the community as to claim that something is not copyrightable (e.g., are you sure it is not in all jurisdictions?) in contradiction to the author's original copyright/license claim. We can only contact upstream and try clarifying/changing various license issues (in my case above the author is already R.I.P... heh), strip such questionable materials or complement them by shipping in non-free... I see no other way around. Cheers, On Wed, 20 Jul 2011, Charles Plessy wrote: To me, the contents of the records above look factual. Can I conclude that, being non-copyrightable, the file is not non-free despite its license statement ? Have a nice day, -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110720025015.gl26...@onerussian.com
XNAT license terms... any chance for main?
Hi Comrades, We are considering packaging XNAT [1]. Its license terms [2] look like an apache 1.1 like license with additional disclaimers (not for clinical use), and requests. Could you please advise either those of particular concern forbidding XNAT entering main? Here is the full list of terms with my takes on their main appropriateness 1. Redistribution and use, with or without modification, must retain the author's(s') copyright notice(s) as documented in the source code. Redistributions in binary code must reproduce the author's(s') copyright notice(s) as documented in the source code. This list of conditions, the disclaimer in the documentation and/or other materials provided with the distribution must also be retained or reproduced. ok 2. None of the names, logos, or trademarks of Harvard, HHMI, Washington University, any Licensor or any of Licensor's affiliates or any of the Contributors may be used to endorse or promote products produced in whole or in part by operation of the software or derived from or based on the software without specific prior written permission from the applicable party. ok 3. The acknowledgment This product includes XNAT, developed by Randy Buckner at Harvard University and the Neuroinformatics Research Group at Washington University School of Medicine shall apply to all copies of complete or substantial portions of the software, including without limitation all source and executable forms, and on any user documentation. ok 4. The software has been designed for research purposes only and has not been approved for clinical use. It has not been reviewed or approved by the Food and Drug Administration or by any other agency. You acknowledge and agree that clinical applications are neither recommended nor advised. Since it seems to be just an advisory, I think it should be ok 5. You are responsible for purchasing any external software that may be required for the proper running of this software. You also agree that you are solely responsible for informing your sublicensees, including without limitation your end-users, of their obligations to secure any such required permissions. You further agree that you are solely responsible for determining and divulging the viral nature of any code included in the software. ok 6. We request that you acknowledge the support of XNAT in publications that utilize the software such as by This product includes XNAT, developed by Randy Buckner at Harvard University and the Neuroinformatics Research Group at Washington University School of Medicine and/or by direct citation. I guess that is the biggest concern. It is common for scientific software to request citations for works using the software. And I consider it acceptable since * it seems to not violate any of the freedoms and DFSG tests * we do consider CC BY-SA 3.0 possibly requiring attribution in form of citation as DFSG compliant So, should this be license terms acceptable for inclusion of XNAT into main? Thanks in advance for feedback [1] http://www.xnat.org [2] http://www.xnat.org/about/license.html -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic signature.asc Description: Digital signature
data copyright or not -- what is Debian's take?
Hi Debian Legal Experts, N.B. yes -- I use 'experts', and you do not have to be certified, nor a diplomaed attorney. Since everything is relative, you might just have an expertise I am lacking, thus being experts for my sake. Enjoy the title ;-) In the light of my veiled (never said here that it to be applied to data) question about appropriateness of custom attribution with CC BY-SA 3.0 license, and further communications on cc-community list: http://lists.ibiblio.org/pipermail/cc-community/2011-January/005825.html I wonder now what actually to recommend people willing to share data, so later on it could be uploaded to the Debian archives without problem (I already had 1 package rejected due to missing copyright statements for the included datasets). Should I advise to blindly attach a copyright statement and license, possibly copyrighting non-copyrightable, thus committing Copyfraud in some jurisdictions? What would be the take of Debian ftpmasters whenever they receive a package shipping data without clean copyright/license statement and something like this instead: This data has been collected 2010 by Author1, Author2. Please recognise the substantial effort that went into the collection of this data by attributing the authors. Attribute by citing the original publication: Author1, Author2, Title of the paper, where published, 2010, URL: http:// Or should I advise to use the text of MIT license, verbally and explicitly describing possible uses and disclaiming any warranty? but once again without any copyright statement. Thanks in advance for your feedback, -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124154434.ga30...@onerussian.com
Re: Re: please advise on how to attribute correctly using CC BY-SA 3.0
Bug-Forwarded: http://lists.ibiblio.org/pipermail/cc-community/2011-January/005825.html interestingly enough, data might not be copyrightable at all (depending on jurisdiction)... I should get back to one of the packages which was rejected from Debian some time ago due to absent copyrights on some data files ;-) Cheers -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110115030255.ga22...@onerussian.com
Re: Re: please advise on how to attribute correctly using CC BY-SA 3.0
Note, though, that the CC Attribution clauses make provision for the copyright holder to specify whatever manner of attribution they like. and that was exactly the reason for my question since I have not found online (nor in the urls you have provided, thanks!) any reasonable example exercising this provision with an attribution by referencing a publication. So, I came up with the custom one and still looking for an advice on possibly better phrasing: N.B. CC URL to the license terms could indeed be replaced with a custom URI pointing to a file within the distributed materials to guarantee persistence. Copyright (C) 2010, Author1, Author2 Distributed under the terms of the Creative Commons Attribution-Share Alike 3.0 license: http://creativecommons.org/licenses/by-sa/3.0/ . Attribute by referencing the original publication: Author1, Author2, Title of the paper, where published, 2010, URL: http:// Any comments are still welcomed ;-) -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic signature.asc Description: Digital signature
please advise on how to attribute correctly using CC BY-SA 3.0
Hi Legal Experts, In the realm of the mix of research and Debian activities we (NeuroDebian project) whenever applicable try to encourage researchers to share their data under some open terms. To avoid confusion, and to suggest a license which seems to be a better fit for data, we advise (and use ourselves) CC BY-SA 3.0, in particular because it was announced to be DFSG-compliant. Here follows the main question: what would be the correct composition of for the copyright/license notice to embed the desired attribution, in particular referencing a journal publication (which seems to be ok according to my treat of 4c of CC BY-SA license terms) e.g. Copyright (C) 2010, Author1, Author2 Distributed under the terms of the Creative Commons Attribution-Share Alike 3.0 license: http://creativecommons.org/licenses/by-sa/3.0/ Public use requires attribution of the original works published in Author1, Author2, Title of the paper, where published, 2010, URL: http:// Something like that? or am I stretching attribution idea of CC BY-SA too far? Please advise -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic signature.asc Description: Digital signature
Re: use of Python bindings to GPL library from within non-GPL Python toolkit
Thank you Anthony for a detailed explanation, but I am still lacking a clear view here since you are talking about mixing-in GPL code within non-GPLed project, and in our case it is not quite the case: ATM all code in our project is non-GPLed, including some code which makes use of external GPL library through python bindings. So, technically speaking we are not mixing the code, and we do not redistribute GPL code within our project (that dependency on GPLed library is optional). But if I get it right -- it doesn't really matter, since GPL doesn't allow external non-GPLed software to use GPLed library (for such scenarios there is LGPL), am I right? -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: use of Python bindings to GPL library from within non-GPL Python toolkit
Hi Guys, I am sorry that I am following up on this dead thread I started long ago [1], and which Francesco was kind to follow up to. Now I've got another project to package and got the same issue, and I am not clear if I have the right understanding of GPL-compatibility. AFAIK it means that you can use GPL-compatible licensed project within GPL-ed project, and not vise-versa! Am I correct? And actually if I am reading it right, wikipedia says the same: Many of the most common free software licenses, such as the original MIT/X license, the BSD license (in its current 3-clause form), and the LGPL, are GPL-compatible. That is, their code can be combined with a program under the GPL without conflict (the new combination would have the GPL applied to the whole). so -- combination has to be GPLed! If I am not right -- then Francesco is right and I can easily use GPLed project (and don't even ask for LGPL) from anything which is 'GPL-compatible'. If I am right -- then I guess we might have quite a few packages in debian already which would need a closer look. And what could be a possible work-around? double-licensing? search for exceptions from GPLed project authors (release it under LGPL for use in a specific project etc) Thanks in advance! [1] http://lists.debian.org/debian-legal/2008/04/msg5.html On Wed, 02 Apr 2008, Yaroslav Halchenko wrote: Dear Legal People, I am one of the developers of PyMVPA toolbox [1], which we currently distribute under MIT License. It is written in Python and is actually a framework either to create scripts for the analysis or just perform analysis interactively within python (ipython) shell environment. Recently we decided to make use of shogun library inside of PyMVPA, which has python bindings available. Shogun is distributed under GPL (not LGPL). IIRC Python itself, since it is simply a programming language, is not limited in licensing terms to what libraries are allowed to be used (not shipped) within Python, thus it is ok to use shogun within Python. But do we have to double-license PyMVPA for people to be legally able to use shogun functionality within PyMVPA? or since we don't explicitly link to shogun, neither bundle it together we are ok? We don't want to switch to GPL completely since we don't want to limit MIT-compatible licensed software to absorb/use our (non-GPLed) code. If we do have to release it under GPL as well, would it be ok to distribute entire PyMVPA in a single package and just mention that some parts of PyMVPA (which make use of GPL) cannot be distributed/used under MIT license and are distributed solely under GPL? Thank you in advance for clarifications [1] http://pkg-exppsy.alioth.debian.org/pymvpa/ -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] signature.asc Description: Digital signature
use of Python bindings to GPL library from within non-GPL Python toolkit
Dear Legal People, I am one of the developers of PyMVPA toolbox [1], which we currently distribute under MIT License. It is written in Python and is actually a framework either to create scripts for the analysis or just perform analysis interactively within python (ipython) shell environment. Recently we decided to make use of shogun library inside of PyMVPA, which has python bindings available. Shogun is distributed under GPL (not LGPL). IIRC Python itself, since it is simply a programming language, is not limited in licensing terms to what libraries are allowed to be used (not shipped) within Python, thus it is ok to use shogun within Python. But do we have to double-license PyMVPA for people to be legally able to use shogun functionality within PyMVPA? or since we don't explicitly link to shogun, neither bundle it together we are ok? We don't want to switch to GPL completely since we don't want to limit MIT-compatible licensed software to absorb/use our (non-GPLed) code. If we do have to release it under GPL as well, would it be ok to distribute entire PyMVPA in a single package and just mention that some parts of PyMVPA (which make use of GPL) cannot be distributed/used under MIT license and are distributed solely under GPL? Thank you in advance for clarifications [1] http://pkg-exppsy.alioth.debian.org/pymvpa/ -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik signature.asc Description: Digital signature
GPLizing BSD licensed sources
Dear Legal people, I am looking for a quick hint. lush project ships sources of modified version of libsvm which is released under BSD license. Since lush is GPLed, and they heavily modified those libsvm sources, they added a generic copyright + GPL excerpt on top above original BSD license. Please see http://pastebin.com/d7d42ea06 for an example. Although no clause of BSD license seems to be violated, I still have some unpleasant aftertaste. Am I right that technically it is ok? or may be file needs cleaner header which would state explicitly that only modifications since original version LIBSVM-2.5 are under GPL and copyrighted by lush authors? Thanks in advance for the clarifications -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debian/copyright and actual copyrights
Dear Legal People, I am sorry to drag your attention to such a primitive case but to don't waste too much time in debates on the subject I am not strong in, I decided to ask for clarification (and may be advice) from the list. Today I've filed a bugreport http://bugs.debian.org/451647 against wacom-tools package. Its copyright file imho violates the policy (I think I can cite it here since it is quite concise) ,--- | This package was created by Ron Lee [EMAIL PROTECTED] on | Thu, 4 Nov 2004 16:06:55 -0800. | | Parts of it were downloaded from http://linuxwacom.sf.net | | Copyright: GPL | | Some files in the linuxwacom distribution are now covered by the LGPL, | the individual files are marked accordingly. | | A copy of the GPL and LGPL can be found in /usr/share/common-licenses | on Debian systems. `--- I take debian policy statement ,--- | 12.5 Copyright information | | Every package must be accompanied by a verbatim copy of its copyright and | distribution license in `--- that it requires copyright file to list copyright holder(s) and corresponding licenses if the software is not in public domain and is distributed under copyleft license such as GPL or LGPL. Indeed people usually don't list copyrights and licenses for some build helpers (usually autogenerated) such as auto* tools. But I thought that we (DDs and Debian Maintainers) are required to list the copyright holders relevant to the distributed within package material. Otherwise copyright file has little sense and can be summarized by two fields in control file (such as License:, Homepage:) Unfortunately the maintainer of wacom-tools does not agree on that and his replies imho become more philosophical than practical. My questions to the list now: 1. Do we have to list all copyright holders + licenses per each piece of software distributed within a package? or it is more of should than must (which would be in strong disagreement with my previous state of mind)? 2. Is wacom-tools violating the debian policy? Thanks in advance -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik pgp3GQYCvAAWV.pgp Description: PGP signature
Re: GFDL with no invariants/covers, is ok?
suggested following terms (which btw were used in another package shipped in debian): You could have googled a bit: http://www.debian.org/vote/2006/vote_001 doh... indeed... sorry about that -- was too late at night I guess ;-) Thanks everyone for the information! -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GFDL with no invariants/covers, is ok?
Dear Legal People, I am in the process of making package for remake ready (which is a branch from make which allows improved debugging etc... ITP#411174) make package had stripped all of the documentation due to GFDL. remake's author doesn't mind bending licensing for his own .texi file (used for .info etc) specific for debugging facilities of remake. He suggested following terms (which btw were used in another package shipped in debian): ,--- | Permission is granted to copy, distribute and/or modify this document | under the terms of the GNU Free Documentation License, Version 1.1 or | any later version published by the Free Software Foundation; with no | Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. `--- Does it sound ok? If not - what would be the best DFSG-free alternative license I should suggest to release documentation under? P.S. Please CC me - I am not on the list. -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
Thanks everyone for help -- I've got the point now ;-) Well -- I postpone this ITP and will wait for source code release It's been mentioned are you complying with the GPL if you distribute obfuscated source?. I'd say yes, because you're distributing it unmodified as per what the original author gave you (I think that's legit as per the GPL - I think it says you can distribute the unmodified source without any further obligation). -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
Le mardi 30 janvier 2007 à 09:49 -0500, Yaroslav Halchenko a écrit Thanks everyone for help -- I've got the point now ;-) Well -- I postpone this ITP and will wait for source code release This is your choice, but most people here agreed that you don't need to. I just don't want to release it due to unreasonable/worrying refusal to provide source code, which make it harder for anyone to inspect/modify it. And IMHO every tentative Debian package has to go through at least basic inspection by the maintainer for the subject of malware/obvious insecurities, before being shipped as part of Debian. -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
I've ran into a problem: given firefox extension released under GPL as shipped (.xpi files) has obscured .js files -- all formatting was removed. I've asked the upstream to provide proper source code, but so far he effectively refused to do that, although it seems to be a very simple operation to perform. For our discussion see http://z9.invisionfree.com/foxyproxy/index.php?showtopic=250 If I understood GPL license correctly, upstream author simply can't release anything under GPL if he doesn't provide sources. Whenever I've asked on mozilla's addons IRC I've got reply as afaik he codes himself, and so if he writes on his page / in the package that it is gpl, you can use it under the gpl license but I think that he/she is incorrect in his/her understanding of GPL. Could anyone correct/confirm me? Is there anything I could do to gently force upstream to either provide the sources or rerelease his probably-full-of-spyware software under some non-FOSS license, so I don't even bother thinking about packaging/using it? ;-) P.S. Please CC me since I am not on debian-legal list -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
So, if I read your comments correctly, the .js files aren't intentionally obfuscated. Whitespace has just been removed in order to speed up download. It may be misguided, but it's also pretty common among JavaScript programmers. Except the javascript file is zipped in a .xpi file, making the space removing argument moot. That is exactly what I thought and stated in our discussion with the author on the support forum. .xpi is compressed, then chrome file is shipped within .jar which is also zip compressed. I don't think that spaces is of any concern for the size. They might contribute to few %s of the size. Also VC available from mozilla.org [1] got only space-stripped versions of the code -- no originals as well... I was able to run the JavaScript code through GNU indent (http://www.gnu.org/software/indent/ ) and get readable and modifiable I've done that (with astyle) but it still was really hard to comprehend the source. I don't think that this is a case where the user gets unmodifiable source. However, the GPL requires the prefered form for modification to be provided. And what the author uses to modify is definitely not the whitespace-free version. seconded. For now I just tagged ITP bug with wontfix and provided a description why not... [1] http://www.mozdev.org/source/browse/foxyproxy/ -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
