Dúvida sobre licenciamento CRM Public License Version 1.0
Hello, I am packaging the "Seclists" package from Kali ( https://pkg.kali.org/pkg/seclists) for Debian and I have a question about a license found in some of the upstream files. The license "CRM Public License Version 1.0" was found in files "Web-Shells/Vtiger/settings/actions/Gateway.php", "Web-Shells/Vtiger/modules/VtigerVulnPlugin/actions/Gateway.php" and "Web-Shells/Vtiger/modules/VtigerVulnPlugin/VtigerVulnPlugin.php" and I would like to check if this license is in accordance with the DFSG. I am in doubt whether this license complies with the DFSG even after reviewing it. I would like everyone's opinion to know about this license. The main points that left me in doubt about the compatibility of this license with the DFSG are: " 2. Source Code License. 2.1.The Initial Developer Grant. The Initial Developer hereby grants You a world-wide, royalty-free, non-exclusive license, subject to third party intellectual property claims: (a) under intellectual property rights (other than patent or trademark) Licensable by Initial Developer to use, reproduce, modify, display, perform, sublicense and distribute the Original Code (or portions thereof) with or without Modifications, and/or as part of a Larger Work; and (b) under Patents Claims infringed by the making, using or selling of Original Code, to make, have made, use, practice, sell, and offer for sale, and/or otherwise dispose of the Original Code (or portions thereof). " This paragraph gave me the impression that someone can claim something on top of a program that is in Debian, for example, aiming for some profit. " (a) such Participant's Contributor Version directly or indirectly infringes any patent, then any and all rights granted by such Participant to You under Sections 2.1 and/or 2.2 of this License shall, upon 60 days notice from Participant terminate prospectively, unless if within 60 days after receipt of notice You either: (i) agree in writing to pay Participant a mutually agreeable reasonable royalty for Your past and future use of Modifications made by such Participant, or (ii) withdraw Your litigation claim with respect to the Contributor Version against such Participant. If within 60 days of notice, a reasonable royalty and payment arrangement are not mutually agreed upon in writing by the parties or the litigation claim is not withdrawn, the rights granted by Participant to You under Sections 2.1 and/or 2.2 automatically terminate at the expiration of the 60 day notice period specified above. " In this item it seems to me that there is an imposition of royalty payment in case of any future problems that may happen to whoever uses the code. License Website: https://www.vtiger.com/open-source-crm/vtiger-public-license/ Regards, -- Guilherme Xavier 1808 D926 7486 3C2E 07B7 B08C 1B14 0644 976B 8AC9
Re: Hacking License
Le 06/12/2018 à 10:29, Giacomo Tesio a écrit : > Il giorno gio 6 dic 2018 alle ore 02:12 Ben Finney > ha scritto: >> Giacomo, I again ask you: please don't impose on the free software >> community the burden of yet another roll-your-own license text. > > Ben, I'm a hacker. And I'm Italian. > To me Freedom will NEVER mean permission to pick a product off the shelf. Hello, it seems to be a little conflict between what you want to do and the spirit of DFSG: - DFSG have been chosen in the spirit: using debian/main, you are free to do anything you want without having to look at each package (even if you sell hardware embedding it,...), but if you use non-free branch, you have to check each license to be sure you are granted to use this software - it seems you want to restrict this for your package usage, then non-free is the good branch to publish it >> We already have a minefield of difficult-to-predict interacting clauses >> just with the *existing* license conditions that are well known. > > Yet how many strong copyleft we have? > How many are really designed to maximise user freedom? > How many are designed with a distributed computing environment in mind? > >> Adding yet another set of conditions massively multiplies the potential >> set of combinations, making it that much harder to determine whether a >> given work is free software. Please realise that this is *not* a benefit >> to the community. > > This is a issue of existing international copyright regulation. > If you want to reform it, I'm totally with you. > No software should be allowed to be proprietary or secret. > > By turning users to hackers, the Hacking License is a step into this > direction. This is clearly in conflict with DFSG. "non-free" branch isn't there to blame projects but just to explain to users that they have to check license before using it. >>> Does this license match the DFSG? > [...] > > I really understand your concerns. > I carefully ponder your objections. > And I'm eager to know which lines makes the Hacking License look > non-free to your eyes: I will try to remove every ambiguity. > > But I'm not asking permission. > > The Hacking License exists as a response to the bad moves I see around > (and ultimately against) free software. > Since I can't trust anymore many existing actors, I'm hacking a solution > myself. > > >> -- >> \ “To have the choice between proprietary software packages, is | >> `\ being able to choose your master. Freedom means not having a | >> _o__)master.” —Richard M. Stallman, 2007-05-16 | > > To have the choice between "blessed free software licenses" is > being able to choose your master... and your users' master. > > I have no master. This is your choice and you are in your right. Thanks for contributing to free software. Cheers, Xavier
Re: Hacking License
Le 04/12/2018 à 11:17, Giacomo Tesio a écrit : > Hi Xavier actually, before writing to the debian-legal list, I > compared the license against the three tests > (I've found the "The tentacle of evil test" on the Wikipedia page > about DFSG, > https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines#debian-legal_tests_for_DFSG_compliance). > > Il giorno mar 4 dic 2018 alle ore 10:41 Xavier ha scritto: >> >> Le 04/12/2018 à 10:07, Giacomo Tesio a écrit : >>> If, on the other hand, no new copyleft license is allowed to enter >>> Debian, I'm fine with it, but I think this should be clearly stated >>> somewhere in the social contract. >> >> No Debian accepts any license that are DFSG compliant (DFSG is just a >> guidelines). You may use the 3 tests to understand what may be wrong : >> * https://wiki.debian.org/DesertIslandTest > > The Hacking License only requires to distribute sources of Derived > Works to the users of such Derived Work, so it passes this test. > >> * https://wiki.debian.org/DissidentTest > > Same as above. > >> * The tentacle of evil test (not found in wiki, why ?): >>"Imagine that the author is hired by a large evil corporation and, >>now in their thrall, attempts to do the worst to the users of the >>program: to make their lives miserable, to make them stop using the >>program, to expose them to legal liability, to make the program non- >>free, to discover their secrets, etc. The same can happen to a >>corporation bought out by a larger corporation bent on destroying >>free software in order to maintain its monopoly and extend its evil >>empire. To be free, the license cannot allow even the author to take >>away the required freedoms." > > To be honest this puzzled me a bit: is "the author" here > 1. the author of the software or > 2. the author of the license? The author of things covered by license > In case of 1, if the authors of the software violates the right of > users, his grants on any patch they received terminate, including the > copyright assignment that let them update the license. > In case of 2, if the author of the Hacking License get hired by a > large evil corporation (trust me, very unlikely in practice... > compared to me, Linus has been such a kind guy all these years... :-D) > I cannot change the license of any software licensed under the Hacking > License. > > To be honest, to my untrained eye the tentacle of evil test might be a > case against GNU License common use of "or (at your option) any later > version." because if a project moves to an _apparently_ good new > version of GPL and accept patches under it, and then turns out that > the upgrade had issues, they might have huge troubles to go back at a > previous version. No, the software you gave is usable with current license even if next version is more restrictive (you can then fork). "Tentacle of Evil test" forbids the author to restrict later what is covered now with the current license (see French difference between "gratuit" and "libre": both translated to "free").
Re: Hacking License
Le 04/12/2018 à 10:07, Giacomo Tesio a écrit : > Il December 4, 2018 6:04:59 AM UTC, Ben Finney ha > scritto: >> If you want to release a work of software compatible with Debian, please >> do everyone – yourself included – a huge favour and choose an existing, >> well-understood, known-by-copyright-experts-to-be-effective free >> license already used for many existing software works. > > Hi Ben thanks for your advice. I know you mean well. > > > It's not my intention to abuse the debian-legal mailing list, I was > really looking for compatibility issues between the Hacking License > and the DFSG in the hope to address them before the widespread > adoption of the software it cover and the license. > > While the copyright attribution embedded in the Hacking License is > designed to make updates to the license possible, I cannot be sure > that the changes that Debian would require would be compatible with > the rights granted to the users after the release, actually making the > software incompatible with Debian (the upstream copyright attribution > is terminated, like other grants, on violation of users rights). > > I appreciate the feedbacks shared so far by Debian Legal volunteers, > and integrated them in the new version of the license to this aim. > > > If no further incompatibility exists between the Hacking License and > the DFSG, I will not annoy the list anymore. > If, on the other hand, no new copyleft license is allowed to enter > Debian, I'm fine with it, but I think this should be clearly stated > somewhere in the social contract. No Debian accepts any license that are DFSG compliant (DFSG is just a guidelines). You may use the 3 tests to understand what may be wrong : * https://wiki.debian.org/DesertIslandTest * https://wiki.debian.org/DissidentTest * The tentacle of evil test (not found in wiki, why ?): "Imagine that the author is hired by a large evil corporation and, now in their thrall, attempts to do the worst to the users of the program: to make their lives miserable, to make them stop using the program, to expose them to legal liability, to make the program non- free, to discover their secrets, etc. The same can happen to a corporation bought out by a larger corporation bent on destroying free software in order to maintain its monopoly and extend its evil empire. To be free, the license cannot allow even the author to take away the required freedoms." > Same if this is a problem of license authorship (because I'm neither a > lawyer nor a committee) or affiliation. > > Ultimately, if "strongly discouraged" actually means "forbidden" I > just need to know it. > >> However, you are strongly seeking feedback not on the work of software, >> but on your new license text. > > No, let's be clear on this: I **welcome** all feedbacks about the > license's text, but here I'm **seeking** just for > _incompatibilities_with_DFSG_. > I didn't release the software yet because it's innovative by itself > and I need an appropriate license to more effectively protect the > users' freedom in a strongly distributed computing platform. > > Giacomo
Re: MongoDB Server Side Public License, Version 1 (SSPL v1)
Le 16/10/2018 à 22:44, Florian Weimer a écrit : > * Xavier: > >>> From: Eliot Horowitz >>> Date: Tue Oct 16 13:03:02 UTC 2018 >>> Subject: [License-review] Approval: Server Side Public License, >>> Version 1 (SSPL v1) >>> ... >>> “If you make the functionality of the Program or a modified version >>> available to third parties as a service, you must make the Service >>> Source Code available via network download to everyone at no charge, >>> under the terms of this License. Making the functionality of the >>> Program or modified version available to third parties as a service >>> includes, without limitation, enabling third parties to interact with >>> the functionality of the Program or modified version remotely through >>> a computer network, offering a service the value of which entirely or >>> primarily derives from the value of the Program or modified version, >>> or offering a service that accomplishes for users the primary purpose >>> of the Software or modified version. >> >> I feel this part fails against the dissident test but I could be wrong. > > I think you are right, but the test <https://wiki.debian.org/DissidentTest> > is not formally part of the Debian Free Software Guidelines. Right but as DFSG is just a guideline, my opinion is that: - formal success to DFSG is not enough (else we would have to change them more often, which would create detrimental instability), - if one of the 3 tests fails, we leave with an unfavorable opinion to start the discussion here. In this case, I feel that upstream team wants to limit freedom of their software while remaining just at the limit of the rules. So for now, my feeling is that it's not in the spirit of DFSG, while ~respecting the words.
Re: MongoDB Server Side Public License, Version 1 (SSPL v1)
Le 16/10/2018 à 22:44, Florian Weimer a écrit : > * Xavier: > >>> From: Eliot Horowitz >>> Date: Tue Oct 16 13:03:02 UTC 2018 >>> Subject: [License-review] Approval: Server Side Public License, >>> Version 1 (SSPL v1) >>> ... >>> “If you make the functionality of the Program or a modified version >>> available to third parties as a service, you must make the Service >>> Source Code available via network download to everyone at no charge, >>> under the terms of this License. Making the functionality of the >>> Program or modified version available to third parties as a service >>> includes, without limitation, enabling third parties to interact with >>> the functionality of the Program or modified version remotely through >>> a computer network, offering a service the value of which entirely or >>> primarily derives from the value of the Program or modified version, >>> or offering a service that accomplishes for users the primary purpose >>> of the Software or modified version. >> >> I feel this part fails against the dissident test but I could be wrong. > > I think you are right, but the test <https://wiki.debian.org/DissidentTest> > is not formally part of the Debian Free Software Guidelines. Right but as DFSG is just a guideline, my opinion is that: - formal success to DFSG is not enough (else we would have to change them more often, which would create detrimental instability), - if one of the 3 tests fails, we leave with an unfavorable opinion to start the discussion here. In this case, I feel that upstream team wants to limit freedom of their software while remaining just at the limit of the rules. So for now, my feeling is that it's not in the spirit of DFSG, while ~respecting the words.
Re: MongoDB Server Side Public License, Version 1 (SSPL v1)
Le 16/10/2018 à 16:03, Paul Wise a écrit : > Hi all, > > I noticed MongoDB are pushing a new license that tries to be like the > AGPL but more expansive in what software it covers and more expansive > in what activities trigger the clauses within it. > > They have posted to the OSI license review mailing list: > > http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003603.html > > For your convenience, I have included a full copy of the mail below, > which includes a justification section as well as full license terms. > > From: Eliot Horowitz > Date: Tue Oct 16 13:03:02 UTC 2018 > Subject: [License-review] Approval: Server Side Public License, Version 1 > (SSPL v1) > ... > “If you make the functionality of the Program or a modified version > available to third parties as a service, you must make the Service > Source Code available via network download to everyone at no charge, > under the terms of this License. Making the functionality of the > Program or modified version available to third parties as a service > includes, without limitation, enabling third parties to interact with > the functionality of the Program or modified version remotely through > a computer network, offering a service the value of which entirely or > primarily derives from the value of the Program or modified version, > or offering a service that accomplishes for users the primary purpose > of the Software or modified version. I feel this part fails against the dissident test but I could be wrong.
Re: DFSG-compatibility of X13-ARIMA-SEATS (U.S. federal govt. software)
Le 03/08/2018 à 11:44, Sébastien Villemot a écrit : > Dear fellow developers, > > I would like to package X13-ARIMA-SEATS¹, which is software developed > at the U.S. Department of Commerce. As such, it is not copyrighted in > the U.S., and rights to use, redistribute and modify are explicitly > granted outside the U.S. > > However, the last clause of the licence says that the “user agrees to > make a good faith effort to use the Software in a way that does not > cause damage, harm, or embarrassment to the United States/Commerce.” > This may be seen as a restriction on use (and therefore contrary to > DFSG§6), though it is unclear to me whether this is a significant- > enough restriction to make it non-free, and whether it is really > enforceable. > > Do you think that this license is DFSG-compatible? > > Thanks in advance for your insights, > > ¹ https://www.census.gov/srd/www/x13as/ Hello, the next sentence in the same paragraph says "The United States/Commerce expressly reserve all rights and remedies", so it could means that "good faith effort" is a real constraint, not just a wish My 2 cents… signature.asc Description: OpenPGP digital signature
French gov open license
Hi all, French government uses now lo/ol license to publish its open datas: https://www.etalab.gouv.fr/wp-content/uploads/2014/05/Open_Licence.pdf "To facilitate the re-use of the « Information », this licence has been designed to be compatible with any licence which requires at least the attribution of the « Information ». For instance, it is compatible with the « Open Government Licence » (OGL) of the United Kingdom, the « Creative Commons Attribution 2.0 » (CC-BY 2.0) licence of Creative Commons and the « Open Data Commons Attribution » (ODC-BY) licence of the Open Knowledge Foundation." Can it be recognize by DFSG ? Regards, Xavier
Re: music123
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Pierre Rosen a écrit : I don't know if it is an issue, but I noted that music123 might be a (TM), see http://www.music123.com/ Thanks Jean-Pierre for the information. In CANADIAN TRADE-MARK DATABASE music123.com is registered. In the US MUSIC123 and MUSIC123.COM are registered. I'm not a lawyer but it seems that our music123 doesn't enter in the Goods and Services description [1]. Is this enough ? I CC the debian-legal list for help/advices. xavier [1] http://tess2.uspto.gov/bin/showfield?f=docstate=4002:h7f25.2.1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuRBvAACgkQVIZi0A5BZF5FOQCgxLTRh/Q3dU7acwS0Un9GBmEf jUgAoKTtxHcFxdL/zYd7CTNFeNNlTdtK =C/Zc -END PGP SIGNATURE- -- 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/4b9106f0.6080...@ipno.in2p3.fr
Re: License of CORBA Interface Definition Files published by the Object Management Group
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ludovic Brenta a écrit : Selon xavier grave xavier.gr...@ipno.in2p3.fr: Can't we just use the testsuite apart from package building to be sure that our packaging is OK and then distribute a version without the .idl files ? Testing should be our duty and not for the buildd machines ? We will do that for sure but there are other .idl files required to build, not just test, the CORBA personality (see Thomas Quinot's email on polyorb-us...@lists.adacore.com). In the mean time, let's focus on the legal aspects on this list. Hi, Thanks for the reminder. I have probably miss Thomas's email during my holiday time. xavier -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqg4pIACgkQVIZi0A5BZF7a7wCcCl0dyBc290V5+aaS76//4QKM d1MAnRU4abPSyukO3Q4PrsvmKE2IwE8T =VcpC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License of CORBA Interface Definition Files published by the Object Management Group
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ludovic Brenta a écrit : Josselin Mouette j...@debian.org writes: Le mardi 25 août 2009 à 02:52 +0200, Ludovic Brenta a écrit : The source package orbit2_2.14.17.orig.tar.gz shipped by Debian contains the following files that concern me: src/idl/CORBA_PIDL/CORBA_Request.idl src/idl/CORBA_PIDL/pseudo_orb.idl [snip] The debian/copyright file in the package does not explicitly state a license for those files but implies that the license is the GPL. The package is in main. My opinion is that the headers themselves are not subject to copyright. They are just the formal description of a specification, there is nothing creative in them. However the comments are, so maybe we have to strip the comments from those files. Thanks. Since: - the spec specifically refers to the .idl files - the .idl files are derived works from the spec, I still think that the .idl files are copyrighted and subject to the same license as the spec. However, your interpretation is probably closer to the intended purpose of these files. The OMG failed to make their intentions clear. I don't think they understood copyright law themselves since they speak of using the specification and conforming software to the specification, neither of which are even concepts in copyright law, which concerns itself only with distribution, modification and derived works. So, the OMG's failure to clarify the license for the .idl files is not surprising. It seems to me that if the authors of a CORBA implementation choose to distribute .idl files (even though this is not a requirement of a conforming implementation), they can do so only if they are the authors of the .idl files; and if they are the authors of the .idl files then they can choose whatever license they want under the permission to use the specification which I understand as permission to derive works from the copyrighted specification. This may or may not be the case for the authors of orbit2 but the authors of PolyORB have already stated that they redistribute the OMG's .idl files (and they even pointed me to the OMG license). I think such redistribution is illegal. Any other opinion? Hi, I'm sorry I can't help on such problems. It is very far from my understanding. Can't we just use the testsuite apart from package building to be sure that our packaging is OK and then distribute a version without the .idl files ? Testing should be our duty and not for the buildd machines ? My two cents... xavier PS:any comment on my last changes (minors) ? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqffMMACgkQVIZi0A5BZF7+zQCgxCwGH2fKlCZGdeFyXhYF4tF5 ATsAn3j9aF86b9IS1Rd/80URBut0pNdx =et0p -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Le jeudi 07 avril 2005 10:32 +0200, Olivier Galibert a crit : On Thu, Apr 07, 2005 at 10:17:15AM +0200, Xavier Bestel wrote: Le jeudi 07 avril 2005 10:04 +0200, David Schmitt a crit : Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. VHDL is a hardware description language. You don't code firmware in VHDL. If the firmware, or part of it, is uploaded to a fpga you do (or Verilog instead of VHDL, same difference). Oh yes, I was dense. Xav
Re: DRAFT for a GR proposal concerning the Sarge release
On Wed, 28 Apr 2004, Stephen Frost wrote: Has anyone asked Linus what his feelings are regarding firmware? Good idea. And two interesting posts related tot his issue: (Wed, 10 Dec 2003 ) http://groups.google.fr/groups?selm=11gWH-4XN-1%40gated-at.bofh.itoe=UTF-8output=gplain And I think this argument is _especially_ strong for things like firmware etc, and I've been on record as saying that I think it's ok to upload standard firmware for a driver as long as you don't call it directly (ie it really lives on the hardware itself). (At this point I should probably point out that other people disagree, and there are people who feel strongly that the kernel cannot contain binary firmware. Whish is obviously part of the reason for having the firmware loader interfaces for drivers - adding an extra layer of separation). (Tue, 3 Feb 1998) http://groups.google.fr/groups?selm=199802032339.PAA11325%40dandelion.comoe=UTF-8output=gplain Linus and I discussed this at length regarding the Mylex/BusLogic FlashPoint SCSI Host Adapters. The FlashPoint SCCB Manager library code runs on the host CPU essentially in place of firmware running on an onboard processor as with the MultiMaster boards. Any software that runs on the host CPU is *required* to be in source form; binary is considered perfectly acceptable for firmware that is downloaded to a board, though obviously source for that would be nice too. One of the key conceptual differences here is that at least in theory, a driver in source form with downloaded binary firmware can execute on any hardware-compatible platform Linux runs on, or can be made to do so. The binary library module would have to be provided by your company for each Linux platform to be supported, and that does make a conceptual difference.
Non-free source package with downloadable parts
Hi folks, I am the author maintainer of the httrack package (currently in testing), an offline browser and mirroring utility. Among with html, javascript/java, and css parsers, an optional, standalone (loaded through a dlopen probe), external module allow to provide basic flash (swf) files parsing and link extraction. For that, I need two files from the macromedia SDK. Unfortunately, the SDK license is a bit restrictive (see http://www.macromedia.com/software/flash/download/search_engine/license2.html) : 3. Restrictions By using the licenses above, you agree to the following restrictions: a You will not make or distribute copies of the SDK, or electronically transfer the SDK outside your company. b You will not modify, sell, rent, transfer, resell for profit, distribute, or create derivative works based upon the SDK or any part thereof other than as set forth in Section 2. c You will not export or re-export, directly or indirectly, the SDK into any country prohibited by the United States Export Administration Act and the regulations thereunder. ... The point a is especially restrictive: I can't redistribute those stupid 2 files. (and other points confirm that the package can't be free) What I have made, is a script which, in debian/rules, does the following: - download (using httrack) the license html page (http://www.macromedia.com/software/flash/download/search_engine/license2.html) - transform to text and show the license to the user (using /bin/more) - ask the user if he agrees with the license, and if so, the user must enter I agree using the keyboard - the script, upon license check, downloads the SDK zip file, extracts the necessary parts, and continues the build process (the build process fails if the license was not confirmed) The script also copies the zip file in /var/tmp/httrack, and will reuse it without confirmation the next time (as the license agreement was accepted) Is it (legally) okay? The source package is libhttrack-swf, and can be checked here: http://debian.httrack.com/dists/unstable/main/source/ (libhttrack-swf is an external module to httrack, also in http://debian.httrack.com/dists/unstable/main/source/) Regards, --- Xavier Roche [EMAIL PROTECTED]
