Re: EPL and GPL incompatibility
On 10/09/16 16:45, George Bateman wrote: Also, if upstream are wrong, is the mechanism described at https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs sufficient to resolve the problem? Yes, they should granting an additional permission to link with libraries covered by the Eclipse Public License. Granting that shouldn't be a problem since they already think it's allowed. The only nitpick is that all copyright holders (of the GPL code linking with incompatible libs) would need to agree on this, not just eg. the main developer.
Re: Can "rockyou" wordlist be packaged in Debian?
On 21/09/16 01:46, Ben Finney wrote: Thanks for raising this question. Eriberto Mota writes: Well, the quoted event resulted in a file with 14 million passwords, distributed by Kali Linux. Do you have any reference to the discussions those people had over their license to distribute that information? I would expect such a discussion to get into the issue of whether a single password is subject to copyright restrictions, and further whether a compiled collection of such works is itself subject to copyright restriction. I would want to see such a discussion with clear, solid support for the freedom to redistribute that work under a free license, before proposing its distribution in Debian. IMHO, the passwords themselves are unlikely to pass the threshold of originality. Looking at the longer entries, there are a few passphrases,¹ but not much that could be considered copyrightable. In addition, the fact that passwords appeared multiple times is also an indicator that there was little to no originality involved. Another question would be if the database itself could be copyrighted, but given that there was no compiling effort at all from rockyou, that won't be the case.² Plus, it was a US company, where there are no database rights. However, I wonder if the fact that it was stolen would be a problem. Best ¹ and a lot of waste. In some cases they were probably inserted from spambots which confused it with a comment field. ² Ok, they might claim that their only goal creating the rockyou website was getting such password list from their users, but that would equal admitting an ever bigger misdemeanor.
Re: C-FSL: a new license for software from elstel.org
Some general feedback: On 21/01/16 22:49, Elmar Stellnberger wrote: CONVERTIBLE FREE SOFTWARE LICENSE Version 0.8, 2016-01-21 , *** This is just a draft *** copyright 2016, by Elmar Stellnberger Everyone is permitted to copy and distribute verbatim copies of this license document. You must not modify the license itself. This license applies to any software containing a notice by the copyright holder saying that it may be used under the terms of the Convertible Free Software License. If a specific version number is mentioned then usage rights include this version as well as any newer version which will always be similar in spirit to this license. The term Convertible Free Software license may be abbreviated as C-FSL. 1. Any work under this license comes completely without any warranty or any kind of liability such as lost revenues, profits, harm or damage of any kind even if the authors should have been advised of the possibility of such harm or damage. It may be seen as research work and does not claim for fitness to any particular usage purpose. 2. The term 'source code' applies to the preferred form that is used to develop or apply changes to a work under this license referred to herein as 'the work'. You are allowed to modify or change the source code if you accept that the resulting changed work will become subject to this license. As soon as you apply any change this is an implicit consent to fully comply with this license and a consent that the work may be used under this license. 3. It is your obligation that the changed version of your sources will be available to the public for free. Available for free means that there will be no undue hinderance in obtaining the given item like a registration of the person who wants to download or obtain the given item. Available for free also means that you must not charge for the given item itself apart from the possibility to require a reasonable charge for the physical reproduction of the data. You pretty much are forcing that each time the text editor contents are changed, a commit with that revision is immediatly published on the internet. 4. You are allowed to issue an 'automatic derivation process' on the source code which will result in so called 'object code'. As soon as you wanna share the object code with other people you are oblidged to make all utilities and data necessary to obtain the object code either availabel under C-FSL or any other open source license approved by opensource.org. The given data and utilities need to be available to the public for free. This means a propietary compiler cannot be used with these programs (even if the source code are eg. standard C89). 5. When appyling changes to the source code you need to leave your name, your email address and the date of your modifications so that other people may contact you. We suggest to list all changes by contributors either in a separate changelog file or in the header of the changed file. You should allow anonymous contributions, or contributing under a pen name. See also https://en.wikipedia.org/wiki/Nymwars Also IMHO it should allow collapsing several entries of the same author, or even summarising the whole changelog (if the original authors only mentioned author names, for instance). Furthermore you need to give your changed version a 'marker' which may be used to distinguish it from the upstream version when being distributed to other people. The distributed product needs to be of the form upstream name - dash upstream version - dash your marker optionally followed by a version number under your control. The marker needs to be unique, at least two letters in size. We suggest it to reflect the name of your company or distribution. What about the fork of a fork of a fork? IMHO it should be possible to replace the marker of the intermediate company, without having to append to the version or use different name. 6. You may choose to create a fork of a work under C-FSL by giving it a completely different name. However you need to assert that people will know that your fork is based on the original work. If your program has a graphical user interface the whole C-FSL license as well as in case of a fork a complete reference to the base product including email address and web presence must be accesssible via the GUI. Otherwise a plain text copy of this license as well as the aformentioned reference to the base product where applicable need to be given and packed alongside the distributed product. If your program has a comprehensive help, a manual or info page and is a fork the base product needs to be fully referred to there including a contact email and web presence. It does not apply to quick or short command line help output as long as a more comprehensive help page is also available. What if the original author prefers a simple: «This file is licensed under C-FSL, see http://c-fsl.license/legal»?
Re: C-FSL: a new license for software from elstel.org
On 21/01/16 22:33, jonathon wrote: 5. When applying changes to the source code you need to leave your name, your email address and the date of your modifications so that other people may contact you. Fails the Desert Island Test jonathon Maybe not. a) The guy could have an email address created before getting stranded b) Else he could use an email address @localhost It would fail for new generations born in that island that only programmed in paper, though :)
Re: debian status on using the PHP license for pear/pecl extensions
If the current FAQ entry related to PHP hasn't changed since http://web.archive.org/web/20051016231155/http://ftp-master.debian.org/REJECT-FAQ.html, I don't think the entry, and most importantly the phrase « That license, up to the 3.x which is actually out, is not really usable for anything else than PHP itself» can be applied to license v3.01 released *after* that. IMHO the ftp masters shouldn't be applying such FAQ entry and have to reevaluate the new license instead. (I should note that someone slightly edited it in the meantime, adding a comma and changing its → it's; so maybe they *did* review 3.01 and found nothing else worth changing) Best
Re: non free broadcom-sta-dkms_6.30.223.248-3_all.deb for wireless driver bmc4313
On 30/10/15 01:05, Gabriel Tachtatzis wrote: First time use non-free.I do not know nothing how must used.I can use this driver bcm4313 Sorry. I tray install driver wireless bcm4313. I install in easy in ubuntu 15.10 but have problem with debian. The non-free do no understand if i can use. The non-free repository is called that way because its contents are not free software, not because it is illegal to use them (generally: it may not be so in your country, or sometimes a piece of hardware is needed). That said, you must be more careful with their licenses, since you can't assume the goodness DFSG-vetted licenses have. You can read the license of this package on http://metadata.ftp-master.debian.org/changelogs//non-free/b/broadcom-sta/broadcom-sta_6.30.223.248-3_copyright How to install a program from the non-free repository is out of scope for this list, but I suspect you didn't add the repository, and/or you didn't refresh the package list before attempting to install. Best regards
Re: Is mpage DFSG compatible?
On 18/10/15 23:27, Eriberto wrote: Thanks Riley and Ángel! Ángel, The copyright notices in headers should be considered as priority over licenses inside generical files. So, the upstream intents provided by generical copyright files shouldn't be considered when packaging and if the files have headers. I understood your words, but the main license is non-DFSG (IMHO). Thanks a lot for your help! Regards, Eriberto Sure. I was considering that they probably *intended* it to be available under (L)GPL, and would thus be sympatetic to (properly) license under them. Not that Debian should solely rely on those files when there is more specific copyright information. Kudos to Ben for noticing that old Changelog entry.
Re: Is mpage DFSG compatible?
I have to agree with the interpretations of the given text. However, in addition to the license in the README file, it also comes with COPYING and COPYING.LESSER files with the text of GPL and LGPL, which seems to imply they wanted to allow distributing the program under (L)GPL. Seems worth a clarification by the copyright owner, those may be old copyright notices, and they are probably willing to relicense. That may not be possible for Contrib/mfix/test.ps, but that file could be stripped.
Re: Source files
On 15/10/15 00:50, Riley Baird wrote: On Wed, 14 Oct 2015 23:47:02 +0200 Francesco Poli wrote: The alternatives you propose are vague at best. For further details on what I think about the definition of source, anyone interested may read my essay: http://www.inventati.org/frx/essays/softfrdm/whatissource.html That's a good essay! Hopefully, something like that will become the reference that Debian actually uses in the future. Yes, good work, Francesco. I have some concerns, though: The preferred form of a work for making modifications to it. This fails to address the issues raised earlier in this thread: What about CVS headers? Well, the file with the CVS headers is probably what you would use for making modifications. What about patches created using quilt? quilt is a version control system (in form of patches). IMHO it doesn't affect for the definition of source. You don't edit the file using quilt, you use vi, emacs, notepad… and store the changes using quilt, but you could as well be using tar(1). The source is the file that you edit. It may be distributed as original file + a number of patch files, but that's orthogonal. The person whose preference should be taken into account is the one who last modified the version of the work under consideration. If he/she prefers to modify the work in a given form, then that form is the source code for the work. Company A writes a program A* in C++ and gives binaries away under a free license to Person B. Person B has excellent knowledge of how to edit binary executables and changes it to create program B*. It would follow that the binary executable is source. Yes. The source for B* is the binary. The source for A* is the C++ files. (I added the names above for clarification) However, that shouldn't lead to the that compiling a program and changing two bytes with an hex editor makes the original files no longer be “source”. In most cases, we should also look at the source of A* when working with B*, at least if B* is expected to be free software. One completely different thing is when nobody has some form of the work any longer. That form cannot be preferred for making modifications, since it no longer exists. In this case, the actual source is the preferred form for making modifications, among the existing ones. I write a program in C++ and release the binaries under a free license. The binaries are not the source form. But five years later, when I lose the USB which contained the only copy of the C++ code, the binaries become source. I'm most worried about authors falsely claiming «I lost the source» as an excuse for not disclosing them. I'm also not too keen on the last part about space-inefficient form for audiovisual works. Which once more shows that software licenses are not the best suited license for media files :)
Re: Expat + exception = DFSG-compatible?
El 13/10/15 21:53, Ben Finney escribió: Dmitry Smirnov writes: But my question really is whether it can be re-phrased to blacklist/mention known offender(s) in a DFSG-compatible manner and how... The goal of excluding specific people, or groups of people, is not compatible with software freedom. It's also not compatible with the DFSG. Such a goal cannot be met in a free software license. So, the resolution would entail getting at *why* They want to exclude certain people, and see whether that underlying goal can be met. That's the real point. I guess something similar to what you wanted could be achieved by a wording like: «This license does not provide any new rights to LitWare Inc. over the code for which they were terminated pursuing GPL §8 after they failed to comply with the license terms after being repeatedly notified since 2005.» which is quite different than: «The company Coho Winery cannot use this work, since when the founder filed for divorce [from me], it said very nasty things» or «Blue Yonder Airlines is not allowed to use this software, since planes are dangerous and nobody should operate them» "some people just don't deserve free work to be made available to them." could mean anything.
Re: Consensus about the Academic Free License ("AFL") v3.0
On 13/06/15 06:36, Walter Landry wrote: Ángel González wrote: On 12/06/15 23:22, Walter Landry wrote: I would strongly disagree here. Requiring documentation of any sort in addition to the source code is a big step. This is not a minor thing. I don't think requiring that some documentation is provided with the source code, makes it unfree. Of course it does. Mandating a minimum quality before releasing things may be good software practice, but it is decidely unfree. This license prevents a certain class of modifications that, in the original author's eyes, makes things worse. But later people may disagree in good faith. For example, suppose that there is documentation, but it is out of date to the point where it is misleading. This license prevents removing that misleading documentation. Even if you write new documentation, you have to distribute the old documentation as well. Cheers, Walter Landry I very carefully talked about requiring *some* documentation, as something opposed it to "all available documentation", which is what AFL requires and makes it problematic. Ironically, the most free program wrt this clause is one with no documentation at all. -- 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/557cc075.2020...@gmail.com
Re: Is libav's current packaging scheme OK for Debian?
(CCing Bálint again, see previous mail in https://lists.debian.org/557459e3.6090...@debian.org) On 07/06/15 16:49, Simon McVittie: On 07/06/15 14:19, Bálint Réczey wrote: The question now is how we should interpret DFSG with regard to Live DVD-s. Should we stop packaging Libav (and later FFmpeg) in the current scheme because it allows preinstalling hedgewars (GPLv2 only) with libavcodec-extra-56 making the DVD violating the license of the packages or let this be a concern for Live DVD creators? The thing that is not allowed is either distributing a derivative work of hedgewars source code with additional restrictions beyond those of the GPL-2, or distributing a derivative work of libav source code with additional restrictions beyond those of either GPL-2 or GPL-3. The hedgewars binary is clearly a derivative work of hedgewars source and, if you believe the FSF's assertions about dynamic linking, libav source (via the libavcodec56 GPL-2+ binaries, to which it links). I find it hard to justify how the hedgewars binary could possibly be a derivative work of libavcodec-extra-56, given that libavcodec-extra-56 was not involved anywhere in the preparation of the hedgewars binary, which (presumably) only uses published interfaces from libavcodec56. Those interfaces happen to be compatible with those found in libavcodec-extra-56. You don't need the library source either for linking to a GPL library with dlopen(3). Still, the final program is considered [by the FSF] a derivative work of the library. This looks very similar to libreadline issues, see http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL On the other hand, building with libavcodec56 but running with libavcodec-extra-56 would be similar to the psql libreadline workaround (bug 603599), currently used in Debian. -- 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/557b8680.8020...@gmail.com
Re: Consensus about the Academic Free License ("AFL") v3.0
On 12/06/15 23:22, Walter Landry wrote: Charles Plessy wrote: Here are a few comments about the license. - point 3) is poorly worded, but assuming it is well-intented, it is Free. I would strongly disagree here. Requiring documentation of any sort in addition to the source code is a big step. This is not a minor thing. I don't think requiring that some documentation is provided with the source code, makes it unfree. However, it could be intended to mean anything from "Please don't strip comments from the code" or "Keep the doc/ folder from the repository when producing a src tarball" to "Include any documentation ever written related to modifying the original work" (a patch howto, an emacs manual?). If the licensor has a copy of Knuth's TAOCP (ie. it's "available documentation"), and it describes something on-topic for modifying the original work (eg. the work uses linked lists, described in Chapter 2) then the Licensor agrees to provide a machine-readable copy of TAOCP. ∎ -- 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/557b7d1c.8070...@gmail.com
Re: GPL "+" question
On 31/05/15 00:10, Riley Baird wrote: On Sat, 30 May 2015 23:24:53 +0200 Ángel González wrote: IMHO you would be the one responsible for enforcing the license... Exactly. So, if a work is originally licensed under GPL-2+ and Person A makes a copy and gives it to Person B under GPL-3. Now consider that Person B gives a copy to Person C under GPL-2+. Person A can't enforce the original copyright holder's copyrights. I find it difficult to believe that the original copyright holder would enforce Person A's license. unless you also granted (delegated?) the right of enforcing the work license to someone else. I'm not sure that you can grant the right of enforcing the license to someone else, Copyright collecting societies do so. otherwise why wouldn't copyleft authors just let give everyone the right to enforce their license? I suspect that for legal litigation you may need to represent the copyright owner. Also note that if authors gave that power to everyone, anyone attempting to exercise that right would still need the author in order to prove that the author didn't also provide a propietary license to the infringer,¹ so it wouldn't be that useful. Usually, copyright collecting societies are the only ones entitled to license that author's work, and their position when detecting infringement is thus quite different. ¹ unless they also gave up the right to ever license it under different terms, perhaps. A very bad idea IMHO. -- 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/556a50c1.2070...@gmail.com
Re: GPL "+" question
On 30/05/15 03:30, Riley Baird wrote: Only the copyright holder can change what a *work* is licensed as. Unless the copyright holder grants the permission to do so, I would say... Let's say I hold copyright on a work, and I grant someone else permission to change the license of a work. Who would enforce the second license? Only a copyright holder can enforce their copyrights. IMHO you would be the one responsible for enforcing the license... unless you also granted (delegated?) the right of enforcing the work license to someone else. -- 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/556a2aa5.90...@gmail.com
Re: Bug#779377: Dual licensed LGPL2.1/GPL3 linking to GPL3 with OpenSSL exception
On 01/03/15 00:05, Riley Baird wrote: Or they could keep the files from Nokia under LGPL2.1, and use GPL3+openssl exception for the rest of the files. Given that they have proper headers, I don't see a problem with that, although I would mention that in the readme. But what license would the work as a whole be distributed as, then? I see your problem now. Silly conflicts between opensource licenses. Maybe LGPL2.1 can be "upgraded" to GPL3+openssl exception? It fits the spirit of those licenses, but I don't know if that'd actually be possible from a legal POV. A LGPL2.1 library can be used in a binary under GPL3+openssl exception since section 6 states: «you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications» but I don't think you can apply GPL + openssl exception terms to a LGPL work since IMHO that would no longer be the " ordinary GNU General Public License". Another option would be to relicense the program adding a LGPL linking exception, too. If upstream doesn't mind relicensing under LGPL (per #25), I would recommend doing so, as that will be much clearer. About Lenin photograph: Don't concern about imaginary countries. Copyright is sufficiently complex with the existing ones :) It's over 50 years pma which seems to be the copyright duration in Russia. And for US, which is not following the shorter term rule of the Berne Convention, it's also PD for being published before 1923. I don't think it would be a problem, but IAANAL. -- 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/54f2634b.1020...@gmail.com
Re: Dual licensed LGPL2.1/GPL3 linking to GPL3 with OpenSSL exception
On 28/02/15 02:31, Riley Baird wrote: Hi -legal! I was reviewing a package "classified-ads" for Debian, and I noticed a potential problem in the process. Namely, the author of the program has decided to use GPL3 with the OpenSSL exception. However, they have taken some files from Nokia which are dual licensed under either LGPL2.1 or GPL3. I think that since Nokia did not make the OpenSSL exception, Debian cannot legally distribute the result. However, I assume that it would be okay if the maintainer decided to change their license to LGPL2.1. Can someone confirm whether all of this is correct? The project is here: https://github.com/operatornormal/classified_ads/ and the Nokia-licensed files are here: https://github.com/operatornormal/classified_ads/tree/master/textedit Yours thankfully, Riley Baird Or they could keep the files from Nokia under LGPL2.1, and use GPL3+openssl exception for the rest of the files. Given that they have proper headers, I don't see a problem with that, although I would mention that in the readme. PS: I don't see the OpenSSL exception anywhere there. -- 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/54f1e526.3060...@gmail.com
Re: Does logo under CC BY SA makes entire project SA
Simon pointed out the key question: if it is a derivative work or just an aggregation of two works (code + logo, or logo + text). I don't think it would be considered a derivative but IANAL. Also note that even if the executable was a derivative work of the logo (and thus subject to the CC-BY-SA), the source code is not. You could remove/replace the logo and use the result following just the MIT license. Independently of being loaded at runtime or hardcoded. It's even more clear for the documentation. Suppose you have a pdf with the logo on the first page, and CC-BY text in the rest. I could strip the first page and release the result under CC-BY, even if the full pdf could only be used under CC-BY-SA (which may or may not be the case). IANAL, for legal issues consult with a lawyer, etc. -- 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/54ee1fe3.4080...@gmail.com
Re: Some questions about trademark, copyright and dfsg
2) As a way to get funding and money. If a commercial company wants to support an open source project by becoming sponsor and include their logo in the software (for instance in an about menu or in the map of a game). Their logo and name are obviously trademarked and copyrighted. If I include this logo will my project be considered as dfsg friendly ? Considering the whole package except the logo and sponsors part are open and free for modifications. There is no way a company will "openly" allow their logo to be modified. In fact even debian protect its own logo. https://www.debian.org/trademark Does that mean open source and free software project can't include sponsor logo and company name ? There's no problem in including the company name. Including the sponsor logo would make the application slightly unfree. Also note that some logos are so simple there's no copyright on them. 3) if a debian packager modify my software for any reason. Will they warn me about modifications ? Will they change the name to avoid any confusion between my original project and the "fork" made by debian ? Will they remove sponsor logo for instance without warning us ? The main reason for removing a logo would precisely be in order to allow it into Debian. The name could be changed, although IMHO it's not a reason strong enough for requiring that. Regards PS: I think you are looking at these things from the wrong perspective,. but it's good you asked. -- 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/54e59c87.8080...@gmail.com
Re: Standard implementation of constant, copyright or not ?
On 15/01/15 23:39, Guilherme Brondani Torri wrote: Thank you Walter. Perhaps I should be more specific about the usage of the headers. The included headers are distributed verbatim. The headers are included verbatim (stored as a constant string) into the binary. The headers provide physical constants and physical concepts to a model compiler. In case the user does not have a set of headers of his own, the binary spits out the verbatim copy to allow the model to be processed. In other words, the user has rights over the LGPL portion and can bypass the non-LGPL pass if he/she wishes to. (...) So it seems it is not an integral part of the compiler, just a handy hardcoded value. I would change the compiler (preferably at upstream) to read those entries from individual files at /usr/share/ if not provided by the user. Put a package with just those files in non-free. If the compiler AND the user didn't provide those AND those default files don't exist (non-free pkg not installed), abort with a message explaining what they need. If not I will think about ways not to anger and frustrate the users offering a tool that does not work out of the box. As I understand it, the compiler _could_ work without those headers (assuming the unlikely case that the user had them himself). Otherwise, it can live in contrib and depend on the non-free package.
Re: Python library under permissive GPL-compatible license optionally using GPL library
Yaroslav Halchenko wrote: 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 If the distributor were a distro like Debian IMHO: - package X can be licensed under Expat - package Y is licensed under GPL (I would probably add a warning on the description) As package X already meets GPL requeriments that's not really a problem. However, let's call X' to X + GPL-incompatible changes. Then X' and Y couldn't be used together. I suppose that if X' distributor actively encourage its users to use Y with its incompatible X', he could be deemed liable for encouraging those copyright violations. (this is quite different from simply allowing generic modules to be loaded) You may be interested in the linking-with-libreadline story. For your case I would simply document it (on a license page, when listing modules for download… it will depend on your website structure) -- 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/548b7dc0.7010...@gmail.com
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
Thorsten Glaser wrote: Ángel González dixit: On 30/07/14 22:00, Stas Malyshev wrote: You could not distribute other derived products bearing the name of PHP - but distributing PHP itself is fine, since it's not a "product derived from PHP" but the actual PHP. If Debian OTOH decides to make their own The actual PHP is still normally patched in a distribution. + 4B= On the other hand, minor patches to products already containing Absolutely no! That would make the situation much worse. This is very vague language, which will not help but add insecurities. I understand that's what the PHP developers are trying to express with the PHP License (although it's not explictely named as such). You may prefer a term like "substantially modified" but it's the same thing. There is some ambiguity on what is a B+minor patchB;, but I feel it's better to leave that to the courts should a lawsuit really arise (which would be a The very idea of a distribution doing licence review is to avoid things that could possibly, ever, go to court. There are clear cases of minor changes (eg. it applies some three-line patches), clear cases of major changes (suppose that the php engine was changed to run javascript instead!) and cases where it's not that clear (and should thus be avoided without a package rename). You can see Scratch_Trademark_Policy for an example of lawyer-written text using similar terms. http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code#Scratch_Trademark_Policy Please remember that we are just talking about changes that Debian itself may want to perform (so it doesn't require a renaming which would be bad both for PHP and Debian users). or later. Use Common Sense for determining if it's a minor patch. That does not work in a legal environment, unfortunately. That tried to explain the . Yet some dumb could that their javascript-running engine can be named php-foo because he has a series of three-line patches converting one into the other. This is why the OSI (and many others) say to please leave writing licences (code for the scripting language called legalese) to experts (lawyers), just as we’d not want the lawyers to write C code. This was just a proposal that could serve as starting point. I wouldn't expect that PHP blindly accepted it without consulting a lawyer! Would this change have the blessing of Debian and the approval of PHP? I highly doubt it. The current php5 source package in Debian has 49 patches… on top of a 5.6 release candidate. Things like porting to new platforms, etc. are not minor. One is named “hack-phpdbg-to-explicitly-link-with-libedit.patch”. You could say that every distribution makes a fork. Even with that funny name, it only changes PHPDBG_EXTRA_LIBS="$PHP_READLINE_LIBS" to PHPDBG_EXTRA_LIBS="-ledit -ltermcap". I have reviewed them. Most are trivial-minor at first sight, often chanes to m4s. Some fpm patches do define new functions and may deserve a second look (but are still simple, specially when compared to the full codebase). use_embedded_timezonedb.patch does , although . You raise a good point about porting, although it doesn't seem so bad. Those should be small changes (perhaps problems would appear if you needed to include a lot of patches copying libc functions not available natively… but instead of copyng them on each program, they should be a library). At the end of the day, php is substantially the same software on Linux or Hurd (where ptrace(2) doesn't work so Debian patched it), using date.timezone or getting it from /etc/localtime Changes to the build system seem specially clear as “not changing too much” the program itself. Looking at a BSD… there are 34 patches in MirPorts for PHP as well, I count only 20 :S (all minor things, some that should have been done at PHP) (As an aside, it's sad in general to check package patches, since most of them should really be at upstream…) though the licence information there is set to say that binaries may not be redistributed. You are creating the patches with a license not allowing binary redistribution?? You leave me speechless. Another option would be to simply rename PHP to… Icescriptinglanguage? ;-) Well, that would be bad for Debian users just due to not fixing the license to say what they mean. Quite similar to the problem a few years back of djb programs (considered uncopyrightable by himself) which could not be considered PD due to lack of an explicit license. Thanks for your insights, Thorsten PS: The cvs daemon at anoncvs.mirbsd.org doesn't seem to be listening on its IPv4 interface (81.169.181.30).
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
On 30/07/14 22:00, Stas Malyshev wrote: On the other hand, my own reading of the PHP Licence is that we may not, in fact, distribute (binaries of) modified versions of PHP software (the interpreter as well as everything else under that licence), period - but You could not distribute other derived products bearing the name of PHP - but distributing PHP itself is fine, since it's not a "product derived from PHP" but the actual PHP. If Debian OTOH decides to make their own fork of PHP, they can distribute it still, but not under the name of "PHP". I don't think Debian even claimed that the thing they distribute under the name of PHP is anything but the original product, so I don't see a problem here. I'm not sure why there's an effort to seek maximally contorted interpretation of the rules that would appear to disallow Debian to do something that Debian is already doing, has been doing for years, and nobody ever objected to Debian doing and nobody ever intends to object. To me this effort does not seem to be constructive, and not leading to any improvement of anything, but only to more inconvenience and annoyance to everybody involved. They have a point. A buggy php version with an added patch that avoids that it crashes when run on even dates could be considered -from a legal POV- a «derivative product of PHP». Legal-speak is quite different than common sense. Trying to keep the spirit of the PHP License and at the same time solve that strict interpretation, I propose the following change to the PHP License 3.01, which will hopefully please both parties: --- 3_01.txt2014-07-30 22:58:13.682449866 +0200 +++ 3_02.txt2014-07-30 23:20:07.332445907 +0200 @@ -24,6 +24,13 @@ from gr...@php.net. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo" + + 4½ On the other hand, minor patches to products already containing + the "PHP" label, including without exception those fixing its + security and/or functionality, are not considered a new product + and do not require any additional permission. Nonetheless their + version string should be modified in order to clearly differenciate + them from the official versions published by the original author(s). 5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a Notes: There is some ambiguity on what is a «minor patch», but I feel it's better to leave that to the courts should a lawsuit really arise (which would be a non-clear case) than attempting to set an arbitrary limit on number of diff lines or an appropiate ratio with the original code, which would fail sooner or later. Use Common Sense for determining if it's a minor patch. Still, bugfixes are explicitely listed as minor, given that they will be the most common case and the one which concerns Debian modifications. The result of those small modifications of PHP-labeled products is that requisites of §3 and §4 are waived, which IMHO is in the spirit of the PHP License as asserted by the current usage. The mention for modifying the version string was inspired by Thorsten email, and is related to the clause present on other licenses that a Modified work should be presented as such. A variant would be changing the "should" into "shall". I chose the former version to allow waiving the requirement for trivial changes or those without a clear version string (think on builds from git or from proposed patches). The term “original author(s)” was preferred over “The PHP Group” for including works by third parties. PS: 4½ is just a placeholder for discussion, the final version would need renumbering. Would this change have the blessing of Debian and the approval of PHP? -- 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/53d969ef.7090...@gmail.com
