Re: Request for Permission to Use Logo for Merchandise
Rodrigo Vega Cruz writes: > Hi! > > So, just to make it clear and clarify that I have understood > correctly, I just have to include in my webpage Legal/Terms of Service > that the products using the Debian logo follow the CC BY-SA 3.0 DEED > Attribution-ShareAlike 3.0 Unported, right? According to https://www.debian.org/trademark it looks like you can get a definitive answer by emailing tradem...@debian.org Cheers, Walter Landry
Re: Request for Permission to Use Logo for Merchandise
Rodrigo Vega Cruz writes: > Dear Debian Team, > I hope this message finds you well. My name is Rodrigo, and I am writing to > seek your permission to use the Debian logo on a > series of themed merchandise, specifically t-shirts. These products are > intended for sale and will feature both your iconic > logo and related community memes. > > Our goal is to celebrate and promote Debian within the community through > these t-shirts. We believe that this merchandise > will not only raise awareness of your distribution but also foster a stronger > connection among its users and enthusiasts. > > I would like to assure you that these products are intended for commercial > purposes, and we plan to conduct this initiative > with the utmost respect for your brand and its values. Additionally, should > this venture generate significant profits, we are > committed to contributing a portion of these earnings back to your project to > support and further its development. > > Please let me know the steps we need to follow to obtain your permission, or > if there are any specific conditions or licensing > agreements required for using the logo in this manner. > > Thank you for considering our request. I look forward to your positive > response and hopefully collaborating closely to make > this project beneficial for both parties. > > Best regards, > > Rodrigo Vega Cruz > Instagram: @danklinuxmemes The policy on logo use is spelled out here. https://www.debian.org/logos/ Hope that helps, Walter Landry
Re: hard linking libboost copyright files
Andreas Metzler writes: > On 2024-02-04 Muhammad Yaaseen wrote: >> The question is once we install the libboost .deb packages into a >> system, the copyright file for each libboost package is stored >> separately in /usr/shared/doc/packages folder. I'm think of >> hardlinking these copyright files so that we same some memory. Is this >> legally allowed. > [...] > > The canonical solution would be to add libboost-commonx.xx containing > what is currently found in /usr/share/doc/libboost-foox.xx and symlink > the whole directory. You'll probably need to make libboost-commonx.xx > arch all to be binNMU compatible. Another solution would be to add the Boost license to /usr/share/common-licenses. Running ls /usr/share/doc/*/copyright | xargs -n 100 grep "Boost Software License" | wc -l on my bookworm system finds it in 225 packages, of which 160 are not a libboost* package. Cheers, Walter Landry
Re: TrueType/OpenType and anti-circumvention laws
Paul Wise writes: > On Fri, 2024-02-02 at 20:16 -0500, P. J. McDermott wrote: >> Ping? Any thoughts on whether a font DRM modification tool would be >> legal to distribute and use in Debian given that the DRM is a simple bit >> field rather than an "effective" TPM such as scrambling or encryption? > > Probably best to consult a lawyer there, but ISTR even trivial things > are supposed to count under the DMCA. This feels similar to pdf viewers that do not honor DRM bits like 'do not print', which Debian distributes. Here is an old email exchange. https://lists.debian.org/debian-legal/2005/03/msg00308.html and a bug ticket that implemented DRM stripping. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298584 Running pdftohtml --help on my bookworm system includes the option -nodrm: override document DRM settings Cheers, Walter Landry
Re: SWIFTStandards IPR Policy
Mathias Behrle writes: > 2. License > SWIFT hereby grants you a world-wide, royalty-free, non-exclusive license to > use or promote SWIFTStandards (i) for information transmission purposes in or > outside the context of SWIFT messaging services and/or (ii) to develop > software, products or services which support transmission of information in > accordance with SWIFTStandards. This feels funny. It does not allow users to use SWIFTStandards to advocate against SWIFTStandards. As written, you can not even use it to improve the standard. Users also can not use it in unexpected ways, such as an art piece. > 3. Limitations > You may not directly or indirectly sell SWIFTStandards. You may not modify > SWIFTStandards while maintaining “SWIFTStandards” as a reference for the > modified standard. This License Agreement does not grant you a license to use > any of SWIFT’s trademarks, except the trademark “SWIFTStandards” for the use > as > defined in Section 2. I think this would preclude putting SWIFTStandards on a DVD and selling it. It is not directly selling SWIFTStandards, but it is indirectly selling it. So I do not think it passes the DFSG. It would be suitable for non-free. IANADD. IANAL. YMMV. Cheers, Walter Landry
Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?
Samuel Henrique writes: > Nmap has just released its version 7.93, and it comes with a new > license, similar to what it used to be, but it raised people's > attention so the license got more scrutiny than ever and that resulted > in long threads with no broad consensus. For the record, here is the complete text of the NPSL from https://svn.nmap.org/nmap/LICENSE Cheers, Walter - Nmap Public Source License Version 0.94 For more information on this license, see https://nmap.org/npsl/ 0. Preamble The intent of this license is to establish freedom to share and change the software regulated by this license under the open source model. It also includes a Contributor Agreement and disclaims any warranty on Covered Software. Companies wishing to use or incorporate Covered Software within their own products may find that our Nmap OEM product (https://nmap.org/oem/) better suits their needs. Open source developers who wish to incorporate parts of Covered Software into free software with conflicting licenses may write Licensor to request a waiver of terms. If the Nmap Project (directly or through one of its commercial licensing customers) has granted you additional rights to Nmap or Nmap OEM, those additional rights take precedence where they conflict with the terms of this license agreement. This License represents the complete agreement concerning subject matter hereof. It contains the license terms themselves, but not the reasoning behind them or detailed explanations. For further information about this License, see https://nmap.org/npsl/ . That page makes a good faith attempt to explain this License, but it does not and can not modify its governing terms in any way. 1. Definitions * "Contribution" means any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, web sites, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." * "Contributor" means Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. * "Covered Software" means the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work * "Derivative Work" or "Collective Work" means any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. It includes software as described in Section 3 of this License. * "Executable" means Covered Software in any form other than Source Code. * "Externally Deploy" means to Deploy the Covered Software in any way that may be accessed or used by anyone other than You, used to provide any services to anyone other than You, or used in any way to deliver any content to anyone other than You, whether the Covered Software is distributed to those parties, made available as an application intended for use over a computer network, or used to provide services or otherwise deliver content to anyone other than You. * "GPL" means the GNU General Public License Version 2, as published by the Free Software Foundation and provided in Exhibit A. * "Legal Entity" means the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. * "License" means this document, including Exhibits. * "Licensor" means Nmap Software LLC and its successors and assigns. * "Main License Body" means all of the terms of this document, excluding Exhibits. * "You" (or "Your") means an individual or Legal Entity exercising permissions granted by this License. 2. General Terms Covered Software is licensed to you under the terms of the GPL (Exhibit A), with all the exceptions, clarifications, and
Re: Is the APSL 2.0 DFSG-compliant?
Ben Westover writes: > On August 5, 2022 1:03:18 AM EDT, Walter Landry wrote: >>As someone who participated in that original exchange in 2004, APSL 2.0 >>still looks impossible to follow. If Debian suddenly goes off-line, >>Debian is not in compliance with the license. > > How exactly does Debian "go off-line", with so many mirrors and other > forms of redundancy? The long arm of the law can make that happen. Whatever problems Debian may have with the law, that does not excuse its obligations under the license. But that is just if Debian wanted to distribute the code in non-free. For the main archive, the DFSG is a guarantee for the users. I know that if I, as an individual, get code from main and distribute changes, at most I will have to publish the corresponding source at the same time. The APSL requires me, personally, to make the corresponding source available for 12 months. I can not just take down my website and work on a farm. >>For all of the other >>licenses, offering the source at the same time is sufficient. For APSL >>2.0, Debian has to keep the source archive up for at least 12 months >>since it last published a modification. > > Doesn't the GPL2 mandate three years of distribution for non-personal > modifications? No. If you distribute the corresponding source at the same time, that is enough. Cheers, Walter Landry
Re: Is the APSL 2.0 DFSG-compliant?
Ben Westover writes: > Hello, > > On 8/4/22 8:30 PM, Paul Wise wrote: >> What would have changed since the 2004 review of APSL 2.0? > > Here's a quote from that 2020 challenge of the APSL-1.2 being considered > non-free in 2001: > >> For the APSL-1.2, it seems that the only clause that makes the >> license non-DFSG-compliant is this one: >> >>> (c) You must make Source Code of all Your Deployed Modifications >>> publicly available under the terms of this License, including >>> the license grants set forth in Section 3 below, for as long as >>> you Deploy the Covered Code or twelve (12) months from the date >>> of initial Deployment, whichever is longer. You should >>> preferably distribute the Source Code of Your Deployed >>> Modifications electronically (e.g. download from a web site); >> >> It was claimed in [6] that this clause makes the APSL-1.2 >> non-DFSG-compliant as it's not possible for Debian to keep every >> single modification around for at least 12 months. >> >> This claim may have been valid in 2001, but I think it does not hold >> up for 2020 since source code to packaging in Debian is usually >> maintained in Salsa or Github and therefore keeping all modifications >> available for 12 months and longer, plus there is Debian Snapshots [7] >> which keeps a older versions of a package around as well - including >> source code. > > Things like this make me question whether the 2004 decision to consider > the APSL 2.0 non-DFSG-compliant is still valid in 2022. In fact, after > reading through the thread [1] the wiki references making the APSL 2.0 > incompatible with the DFSG, I'm not so sure it does that. IANAL, but > from what I could understand it seemed that there was a good argument > that the alleged non-DFSG clauses actually *did* comply with the DFSG, > and that argument wasn't fully refuted. The wiki references one other > thread, but that thread is specifically about the APSL 1.2, which the > APSL 2.0 fixes the issues of according to the FSF. That thread was > finished about two years before the APSL 2.0 came into existence. As someone who participated in that original exchange in 2004, APSL 2.0 still looks impossible to follow. If Debian suddenly goes off-line, Debian is not in compliance with the license. For all of the other licenses, offering the source at the same time is sufficient. For APSL 2.0, Debian has to keep the source archive up for at least 12 months since it last published a modification. Cheers, Walter Landry
Re: Binary file inside fruit package
Marcos Talau writes: > The fruit package [1] comes with a binary file named `book_small.bin'. This > binary file does not have a source code. > > Reading the documentation and checking the source code of the package, the > binary file appears to contain chess openings, and I believe it is used by > default by the program. How was book_small.bin generated? More concretely, if I wanted to add chess openings, would I start from book_small.bin? Or is there some other file that I would modify and then generate book_small.bin? Cheers, Walter Landry
Re: Question about Debian redistribution
Navtej Bhatti writes: > Am I allowed to redistribute an iso file containing the Debian rootfs, > but with only free packages added (including the debian > "firmware-linux-free") and some configuration files changed? The heart > of my software is my specialized vmlinuz flashed to another partition > of the USB. Debian certainly encourages this kind of modification. Debian's trademark rules are here https://www.debian.org/trademark As for your specific case, it sounds like you are essentially offering a specialized installer with a different kernel, but otherwise it is stock Debian? I think that makes you a Debian derivative https://www.debian.org/derivatives/ There are some detailed guidelines here https://wiki.debian.org/Derivatives/Guidelines I think any required changes would be minimal. However, I am just some guy on the internet, and I can not speak with authority. If those guidelines are not sufficient and you need a more definitive answer, then you probably need to speak to the Debian Project Leader. Cheers, Walter Landry
Re: Fwd: RNNoise's model and DFSG
Nicholas Guriev writes: > I still have suspicions about RNNoise and its probable non-free model. > I'm curious in context of my package libtgowt where I got to cut the > library out. What is the current consensus on this library in Debian > community? I already asked on debian-ai@ but nobody answered ever since. As I understand it, the standard that Debian uses in a case like this is whether something is the "preferred form for modification". If the person who created RNNoise wanted to improve it, what would they start from? If that is the finalized model, then that is enough for Debian. If there is some intermediate form, then that would be the preferred form. This sort of thing comes up with art assets. Would the creator generally re-render from scratch, or would they take the output and do further modifications? Sometimes, these intermediate forms can be much, much larger than the final form. So practical concerns can cause problems. Cheers, Walter Landry
Re: Export Compliance/Customs Information about Debian Software
. Cubik65536 writes: > In the legal information of some Linux Distribution, I have seen an Export > Compliance/Customs Information like this: > >> Export Compliance/Customs Information >> >> By downloading XXX Linux software, you acknowledge that you >> understand all of the following: >> >> XXX Linux software and technical information may be subject to the >> U.S. Export Administration Regulations (the “EAR”) and other U.S. and >> foreign laws and may not be exported, re-exported or transferred (a) >> to a prohibited destination country under the EAR or U.S. sanctions >> regulations (currently Cuba, Iran, North Korea, Sudan, Syria, and the >> Crimea Region of Ukraine, subject to change as posted by the United >> States government); (b) to any prohibited destination or to any end >> user who has been prohibited from participating in U.S. export >> transactions by any federal agency of the U.S. government; or (c) for >> use in connection with the design, development or production of >> nuclear, chemical or biological weapons, or rocket systems, space >> launch vehicles, or sounding rockets, or unmanned air vehicle >> systems. >> >> You may not download XXX Linux software or technical information if >> you are located in one of these countries or otherwise subject to >> these restrictions. You may not provide XXX Linux software or >> technical information to individuals or entities located in one of >> these countries or otherwise subject to these restrictions. You are >> also responsible for compliance with foreign law requirements >> applicable to the import, export and use of XXX Linux software and >> technical information. XXX Linux software in source code and binary >> code form are publicly available and are not subject to the EAR in >> accordance with §742.15(b). > > > Which tells us that the software and technical information were > subject to the U.S. Export Administration Regulations (the “EAR”). But > the open-sourced source code and binary code are not. But I cannot > find this kind of information on Debian website and wiki. I understand > that the Debian source code is not subject to the EAR, but is the > software (as I understand, it’s the packaged version of the software, > for example, ISOs) distributed on the website (debian.org) subject to > the regulations? I read some documents on the wiki > (https://wiki.debian.org/USExportControl, > https://www.debian.org/legal/cryptoinmain, and > https://www.debian.org/legal/notificationforarchive), but they did not > answer directly on the question. > > If I have anything that I misunderstood, please tell me. What exactly is and is not export controlled is something that changes over time. I am pretty sure that everyone on both sides agreed that exporting a printed book is OK. Anything beyond that becomes an exercise in parsing Supreme Court opinions and governmental regulations. So I do not think that we can give you a definitive answer. We can only tell you what Debian did, which is send a letter to BXA. I think Debian used to send letters every time crypto software was updated, but BXA asked them to stop. Cheers, Walter Landry
Re: Advice on licenses with "funny" amendments
Hi Nik, JSON has a license with similar problems. It has the addendum The Software shall be used for Good, not Evil. Debian takes the author at their word, and so it goes into non-free. https://wiki.debian.org/qa.debian.org/jsonevil I think that would have to be the case here as well. Cheers, Walter Landry Dominik George writes: > Hi, > > some times, we (the AlekSIS team) stumble upon upstream maintainers > who consider it funny to add amendments to licenses, or make up fun > licenses on their own. Here are two examples: > > https://github.com/codeedu/select2-materialize > > This project is MIT-licensed, but has a note saying: > > "BUT if you become a millionaire using this code, please bought >me a new brand luxury sailboat." > > Probably meant as a joke, a lawyer might see that > differently. Actually, I am somewhat curious if by adding this package > to Debian, and with that forcing it into Ubuntu, we could see Mark > Shuttleworth buy a luxury sailboat for that guy i nexchange for their > 30 lines of CSS ;). > > https://github.com/iconify/collections-json/issues/12 > > Not pointing directly to the project in question, but to this > elaborate thread on the issue. > > License here: https://icons8.com/good-boy-license > > "Please do whatever your mom would approve of. No tattoos, >No touching food with unwashed hands, No exchanging for drugs" > > Taken literally, that is a restriction on use, and as such non-free. > > > Now, it seems that the intention of these upstreams is not to really > prohibit use. In fact, for the second example, upstream provided a > nexpress statement that they dual-license under MIT license as > well. In the first case, I could not successfully contact the authors > yet. > > What does debian-legal say? Could I package the first example for > Debian, and trust that the amendment is a joke? > > Thanks, > Nik
Re: List of journal
Bastien ROUCARIES writes: > Could you do a review of https://github.com/JabRef/abbrv.jabref.org/ ? > > I do not know the legal status of this kind of database According to https://github.com/JabRef/abbrv.jabref.org/blob/master/LICENSE.md it is covered by CC0, which is fine for Debian. Cheers, Walter Landry
Re: Acceptability of a documentation license for Debian
J.B. Nicholson writes: > Jeffrey H. Johnson wrote: >> Redistribution and use in ‘source’ [...] and ‘compiled’ forms [...] in whole >> or in >> part, for any purpose, including commercial applications, with or without >> modification, in any medium, is hereby permitted, without fee or royalty, >> provided >> that the following conditions are met: > > Prohibiting distribution for a fee is non-free is a clear violation of > DFSG 1 (per https://www.debian.org/social_contract#guidelines). Also, > prohibiting distribution for a fee while allowing redistribution in > "commercial applications" is confusing. The license looks to me like it is saying that anyone distributing the work does not have to pay a fee to the original author. It does not prohibit the distributor from imposing fees on end recipients. Otherwise, the blurb about 'commercial applications' would be contradictory. As a whole, I could not find anything wrong with the license, though I did not look too carefully. The definition of 'source' and 'compiled' forms is a bit sloppy. I certainly would not recommend it. This looks equivalent to CC-BY https://creativecommons.org/licenses/by/4.0/ so I would use that instead. Cheers, Walter Landry
Re: Concern about a Sun license
Pierre Gruet writes:
> Hello,
>
> When working on igv (which is currently in non-free), I stumbled upon
> the license [0] including the following:
>
> Sun grants you ("Licensee") a non-exclusive, royalty free, license to
> use, and redistribute this software graphics artwork, as individual
> graphics or as a collection, as part of software code or programs that
> you develop, provided that i) this copyright notice and license
> accompany the software graphics artwork; and ii) you do not utilize
> the software graphics artwork in a manner which is disparaging to
> Sun. Unless enforcement is prohibited by applicable law, you may not
> modify the graphics, and must use them true to color and unmodified in
> every way.
>
> I feel that the "disparaging to Sun" part is a blocker for including
> the software in the main section. Do you agree?
> And what about the last sentence?
This license has come up before.
https://lists.debian.org/debian-legal/2005/08/msg00099.html
https://lists.debian.org/debian-legal/2006/01/msg00631.html
So, not free.
> I am a bit concerned because a check in sources.debian.org shows some
> software currently in main embed files with the "disparaging to Sun"
> part.
>
> [0]
> https://sources.debian.org/src/igv/2.6.3+dfsg-3/src/main/resources-jlfgr-1_0/LICENSE/
That sounds like a bug.
Cheers,
Walter Landry
Re: Dúvida sobre licenciamento CRM Public License Version 1.0
Guilherme Xavier writes: > License Website: > https://www.vtiger.com/open-source-crm/vtiger-public-license/ It kind of reminds me of the IBM Common Public License. I am not so worried about your specific concerns. Yes, people can write non-free things that include this code. The patent lawsuit stuff is just a way for people to formalize different ways of ending a patent lawsuit. It does not preclude the usual way, which is to win or lose the lawsuit. In any event, Here are some other parts that jumped out to me. In Part 2.1 (d) Notwithstanding Section 2.1(b) above, no patent license is granted: 1) for code that You delete from the Original Code; 2) separate from the Original Code; What does 'separate from the Original Code' mean? Does that mean that if I gradually delete everything else but the patented code (a la Ship of Theseus), can I suddenly no longer use the code? This may not matter, since Debian, as a rule, does not worry about patent licenses unless there are real patents being actively enforced. In Section 3.1, it says that you can distribute modifications via an 'Electronic Distribution Mechanism', but you have to keep it up for at least 6 months. Debian does not guarantee that. Mirrors, for example, may only have the latest version. Section 3.4 has some weirdness about updating legal notices and telling everyone about it (including sending mail to mailing lists). It feels weird, but I do not have a concrete objection yet. Section 8 has a bunch of stuff about terminating in case of patent lawsuits. I do not remember what the current policy is regarding those types of terms. Section 10 tries to define the code as 'commercial computer software', regardless of reality. This is probably ignorable. Section 11 specifies Indian law (probably OK) and 'jurisdiction of the Courts in Chennai, with venue lying in Tamil Nadu State, India'. That does not seem so OK. What if neither of the litigants are in India? So I think the one thing that is really a deal-breaker for Debian is Section 3.1. Section 11 also gives me pause. The rest I am uncertain. Cheers, Walter
Re: Bug#974678: ITP: openh264 -- H.264 encoding and decoding
Bastian Germann writes: > Am 02.06.21 um 17:33 schrieb Tobias Frost: >> Is this RFS package now a downloader or the library itself? > > It's both. The -dev package is created from the source files and > resides in main. The library package contains the downloader as a > postinst script, which checks the known SHA256 hashes. > There are some example userspace tools available in the package which > could potentially be packaged in an additional package. I left this > for a later version. > > There is also a chance that reproducible build might be implemented: > https://github.com/cisco/openh264/issues/893 > When that works, the package could build the lib, verify the resulting > hashes, and throw away the built binary. That way we could be sure not > to have any additions to the downloaded library that are not available > as source. > > I think, as Cisco provides the patent license, having the downloader > in contrib (for some architectures) is better than having the built > library in main (for all compiling architectures). We could also > provide both. Any thoughts? As I understand Debian Policy, downloading anything during postinst is discouraged, if not banned. So it would be best to avoid it. In terms of the patent license, I do not think that x264 has any special dispensation. So just directly building and packaging openh264 should not open Debian to any significant additional liability. But as always, the FTP masters will be the final arbiter of that. Cheers, Walter
Re: Rust trademark policy
Bone Baboon writes: > * The "Uses that require explicit approval" section says "Distributing a > modified version of the Rust programming language or the Cargo package > manager and calling it Rust or Cargo requires explicit, written > permission from the Rust core team.". This appears to interfere with > "The freedom to distribute copies of your modified versions to others > (freedom 3).". This is more or less the same exact problem that caused Debian to rename Firefox to Iceweasel. Eventually, Debian convinced Mozilla to allow Debian to use Firefox to refer to the modified versions that Debian distributes. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006 Ideally, Debian would get a similar dispensation for Rust. Cheers, Walter
Re: LGPLv2+ depending on (LGPLv3+ or GPLv2+) = (LGPLv3+ or GPLv2+)?
Andreas Metzler writes: > GnuTLS is pondering a license switch from LGPLv2+ to LGPLv3+/GPLv2+ dual > license. GnuTLS itself links dynamically against GMP which is already > LGPLv3+/GPLv2+ dual licensed. So afaict this should not make a difference, > gnutls rdeps already need a license which compatible with LGPLv3+ or > GPLv2+. I think this is OK for Debian. The only tricky clause is Section 4 of LGPL 3. GMP would already make this apply to all of the programs that use GnuTLS. I think the difference, if any, would be what exactly is required if someone wanted to modify GnuTLS. That is not an issue for Debian, since Debian releases source code for everything. As always, I can only guess. FTP master is the final authority for all this. Cheers, Walter Landry
Re: whitakers-words_0.2020.10.27-1_multi.changes REJECTED
calumlikesapple...@gmail.com writes: >> In all of that they miss something important - you are not allowed to >> modify. > > I interpret the fact that it lets you use the source code for "whatever > purpose" to mean that you can modify, compile, and distribute it. After > all, source code doesn't have much of a use on its own, and a modification > is a use. There are plenty of people in the world who are happy to have their work distributed, but not modified. So this is not a safe assumption. Cheers, Walter Landry
Re: Are ASN.1 modules code or specification?
Andreas Metzler writes: > Hello, > > Do we consider ASN.1 modules (e.g. the specification of > AttCertValidityPeriod in rfc 3281) to be code or specification? The general rule is that everything that Debian ships, including documentation, standards, pictures, etc., must be freely modifiable in a manner consistent with the DFSG. If it would go on a Debian DVD, then all of the bits on that DVD must DFSG-free. Otherwise, it may or may not be able to be hosted on non-free or contrib. Cheers, Walter Landry
Re: Font-Awesome 5 no build system DFSG compatibility
Simon McVittie writes: >> Considering DFSG #2: >> > The program must include source code, and must allow distribution in >> > source code as well as compiled form. > > The "program" (package, module) includes source code: [x] > > The license allows distribution of that source code: [x] You may or may not consider this dispositive, but the definition of source code from GPL v3 is The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. So a makefile or equivalent is required. On a more practical level, Debian has to be able to rebuild all of the binaries from source. If you can not do that, then that would be an RC bug. Cheers, Walter Landry
Re: Unclear license information regarding copyleft
Sven Bartscher <kritzef...@debian.org> writes: > Hi, > > Am 15.05.2018 um 20:04 schrieb Walter Landry: >> Sven Bartscher <sven.bartsc...@weltraumschlangen.de> writes: >>> As there are some problems[1] with the compiled shared library as >>> distributed by upstream (and because compiling things ourselves is >>> always nicer) I would like to rebuild the library when building the >>> Debian package, though I'm not sure if it is clear in the given >>> situation that it is legal to recompile the library and distribute the >>> resulting shared library. But maybe someone smarter than me can >>> enlighten me. >> >> I think you have to ask upstream about this (i.e. Tarn Adams). Absent >> any other information, I would think that you could not recompile the >> source into a new binary. It is probably just an oversight on the part >> of the Dwarf Fortress developers. > > I already tried to do that, but haven't received an answer in 4 months. > Sorry, I forgot to mention that in my previous post. I think you have to bother them again. Tarn Adams has probably forgotten about your request. You just have to be persistent. Cheers, Walter Landry
Re: Unclear license information regarding copyleft
Sven Bartscher <sven.bartsc...@weltraumschlangen.de> writes: > Greetings, > > (Please excuse if the below analysis is partly or even completely wrong, > reading about licensing and copyright issues often makes me quite confused) > > I'm the maintainer of the package dwarf-fortress in non-free. The > package as a whole is clearly non-free as the license states that „you > may redistribute the *unmodified* binary and accompanying files“ and the > source code to the contained executable is not provided. > > The package also contains a shared library called libgraphics.so and the > corresponding source code. The library links to (among others) SDL and > GTK which are licensed under the LGPL-2.1, AIUI this means that > libgraphics.so and its source code have to licensed under the LGPL. (due > to condition 2, correct?) As I understand it, libgraphics.so is not modifying SDL. In general, the LGPL only requires that you not get rid of the ability to dynamically link in a new version of SDL. So this is probably OK. > I could not find an explicit statement in the upstream tarball that > clarifies what license applies to the library in question. There is a > file called 'sdl license.txt' that contains a copy of the LGPL-2.1, > which hints that the author is aware that their work is in some way > affected by this license. > > As there are some problems[1] with the compiled shared library as > distributed by upstream (and because compiling things ourselves is > always nicer) I would like to rebuild the library when building the > Debian package, though I'm not sure if it is clear in the given > situation that it is legal to recompile the library and distribute the > resulting shared library. But maybe someone smarter than me can > enlighten me. I think you have to ask upstream about this (i.e. Tarn Adams). Absent any other information, I would think that you could not recompile the source into a new binary. It is probably just an oversight on the part of the Dwarf Fortress developers. I would phrase it as asking what license that part is under. There are a few obvious choices: LGPL 2.1 or later (to match SDL), MIT, or Apache. Please do not suggest a custom license. Cheers, Walter Landry
Re: systemd-resolved violates The Debian Free Software Guidelines
Martin Hanson <greencopperm...@yandex.com> writes: > I have posted this bug report > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896806 that has been > rejected by the maintainer. > > Maybe I have misunderstood the issue completely, but I do have some > experience with legal issues and AFAIK, there IS a problem here. > > I am posting this to the mailing list in order to get "more eyes on > the issue". This is equivalent to providing a default search engine in Firefox or Chromium. If the software required the use of these external services in order to provide basic functionality, then you might have an argument that the software should go into contrib. But that is not the case. Especially for this bug report, there are many options, packaged by Debian, for running your own DNS server. Those will be selected by default if you set up your network correctly. So I am not seeing the problem here. Cheers, Walter Landry
Re: JPL Planetary Ephemeris DE405
Ben Finney <bign...@debian.org> writes: > Dave Hibberd <d...@vehibberd.com> writes: > >> […] >> See especially sections on Kernels Distribution and Kernels >> Redistribution. The intent is to allow anyone to use or redistribute >> as long as the files/kernels are not modified." > > That intent explicitly does not permit distribution of modified works. > That permission is needed if the work is to be free software. You are right. I missed that. Walter Landry
Re: JPL Planetary Ephemeris DE405
Hi Dave, The FTP masters are the final judge, but it looks fine to me. It is basically free distribution with a requirement to change attributions if modified. Cheers, Walter Landry Dave Hibberd <d...@vehibberd.com> writes: > Walter, > > Thanks for the response - I got in touch with Mr Folkner, and I received the > following response: > > "We consider the ascii and binary ephemeris files the same SPICE > kernels that have exactly the same information just in a different > format. The ephemeris data are then released for public use under the > following conditions; > > https://naif.jpl.nasa.gov/naif/rules.html > > See especially sections on Kernels Distribution and Kernels > Redistribution. The intent is to allow anyone to use or redistribute > as long as the files/kernels are not modified." > > Under my reading of their terms, it feels like a free license we can > distribute the files under - they permit use, redistribution and > modification as the user sees fit, and are only looking to limit their > liability for support of any modified code. > > Can anyone confirm or suggest why I may be wrong in this interpretation? > > Thanks in advance! > DH > > -- > Hibby > d...@vehibberd.com > > On Fri, 23 Feb 2018, at 12:26 AM, Walter Landry wrote: >> Hibby <d...@vehibberd.com> writes: >> > What I'm here to clarify is that I can't see a license for the ascii >> > files - I'm not sure if this fileset is something that anyone in >> > debian-legal have come across, or have any advice on what license they >> > may have been released under? I can't see anything on the JPL FTP server >> > outside of the CD Notes from the original release [5]. The contact >> > detailed on them worked at JPL 21 years ago, and I don't reckon the >> > email address is still active. >> >> There is contact information at the bottom of >> >> https://ssd.jpl.nasa.gov/?planet_eph_export >> >> It references William Folkner. He published a paper in 2014, so he may >> still be around. >> >> Cheer, >> Walter Landry
Re: IUPAC/InChI-Trust Licence DFSG-Compliant ?
Alex Mestiashvili <ames...@rsh2.donotuse.de> writes: > Hi, > > could you please clarify if the license below can be considered > DFSG-compatible ? > > Section 2 doesn't sound very good, but section 3 says that GPL-2+ may be > applied. > Will it be fine to simply state that it is licensed under GPL-2+ and > also include the original license in d/copyright ? It looks a like the LGPL-2. In any event, this license is fine as is. If anyone wants to make modifications that are not allowed by the existing text, then they can modify it under GPL-2+ terms. There are other examples in the archive of this (e.g. CECILL). Cheers, Walter Landry
Re: JPL Planetary Ephemeris DE405
Hibby <d...@vehibberd.com> writes: > What I'm here to clarify is that I can't see a license for the ascii > files - I'm not sure if this fileset is something that anyone in > debian-legal have come across, or have any advice on what license they > may have been released under? I can't see anything on the JPL FTP server > outside of the CD Notes from the original release [5]. The contact > detailed on them worked at JPL 21 years ago, and I don't reckon the > email address is still active. There is contact information at the bottom of https://ssd.jpl.nasa.gov/?planet_eph_export It references William Folkner. He published a paper in 2014, so he may still be around. Cheer, Walter Landry
Re: EULA vs BSL,EULA vs BSL
IOhannes m zmölnig (Debian/GNU) <umlae...@debian.org> wrote: > (please CC me, as i'm not subscribed to the list) > > On 2017-11-20 22:20, Walter Landry wrote: >>> >>> now i wonder, are these header files licensed under the EULA or under >>> the BSL? >> >> Are the headers sufficient for development, or does it require some >> compiled libraries? If so, it does not matter if the headers are >> free, since the libraries will be required for any development anyway. >> > > good point, with another fun answer: > in order to successfully use the entire thing, indeed a non-free shared > library is required. > the fun part is, that this library is *not* part of the SDK. > the library is part of another piece of non-free software. however, this > other piece (including the library) is not protected by the same EULA, > and it doesn't forbid the distribution (it doesn't explicitely allow it > either; so i might need to check that with upstream as well). I think you are just going to have to check with upstream. The licensing is inconsistent. Walter Landry
Re: EULA vs BSL,EULA vs BSL
IOhannes m zmölnig (Debian/GNU) <umlae...@debian.org> wrote: > hi, > > i was playing with the idea about packaging the Decklink SDK by > Blackmagic (this is an SDK to access digital video grabbing cards). > the SDK consists of a dozen or so header files, and some example code, > including pre-compiled binaries. > there's also a 200 pages manual on how to use the SDK. > > now they have a very strange licensing policy: > > you can only download the SDK by agreeing to a very restrictive EULA > (attached; henceforth "the EULA"), which explicitly forbids to > re-distribute "the software". > so far so bad. > > however, once you have obtained the SDK, it all becomes a bit blurry for me. > there is no license file included in the package. > however, each and every header file (that is: the entire public API of > the SDK), contains a verbatim license of the BSL (attached). > > now i wonder, are these header files licensed under the EULA or under > the BSL? Are the headers sufficient for development, or does it require some compiled libraries? If so, it does not matter if the headers are free, since the libraries will be required for any development anyway. Cheers, Walter Landry
Re: I am the RD of ASUS, want to confirm the Debian license
刘欢 <appleeatwo...@gmail.com> wrote: > Dears, > > Sorry to use a private email,The company's mailbox can not send mail to @ > list.debian.org > > We are developing a laptop test software, hoping to use Debian as the > operating environment, and pre-installed in the user's computer. > According to Debian lisence, we do not have to pay for it, just open the > Debian source code we use. > But whether we need open source our test software.I did not find the > relevant instructions on the official website. > We do not want to open source our software, because it will involve the > interests of some third-party vendors. If you are using any packages from the 'non-free' or 'contrib' repositories, then you are going to have to look at the licenses of all of those packages. They can have all sorts of restrictions on what you can do. If you are using only packages from the 'main' repository, then Debian makes a good faith effort to make sure that everything in that repository complies with the Debian Free Software Guidelines. https://www.debian.org/social_contract This includes the clause 9. License Must Not Contaminate Other Software That will often cover the kind of use I think you are envisioning. Please note that Debian is largely a volunteer effort and does not guarantee that they did a good job vetting the licenses. With that said, it also somewhat depends on how your test software is written. For example, if your software links with GPL-licensed software, then you may be required to give out the source of your test software to anyone who gets the binaries. So what you want to do is at least plausible. What you need to do now is sit down with a lawyer and get answers specific to your situation. Because I am definitely not a lawyer. Hope that helps, Walter Landry wlan...@caltech.edu
Re: tss2: Is it DFSG compatible
Breno Leitao <lei...@debian.org> wrote: > * The TCG grants to the user of the other parts of the specification > (other than the Source Code) the rights to reproduce, distribute, > display, and perform the specification solely for the purpose of > developing products based on such documents. > > Is this last paragraph a possible violation of DSFG, or, should it not > be taken in consideration since it seems to exempt the source code? That makes the source code free, but everything else non-free. Does the package contain the non-source bits? Cheers, Walter Landry
Re: Do i need to purchase any License
ardavan izadi <ardavanizadi...@gmail.com> wrote: > Hi, > > I would like to use Debian on a single board computer for commercial use. > We’re going to produce an IoT gadget and eventually sell to the market. > > What we need to do is to: > > 1. Change the log screen during booting and display our logo > 2. Run our custom software (written in Python & C) instead of OS desktop > environment > > I’m not sure about Debian licensing and don’t understand very well as it’s > long and confusing to me. > > Do I need to purchase any license for my product from Debian? > Please assist me. One thing I can say for certain is that Debian does not sell licenses. For your other questions, this page may be helpful. https://www.debian.org/doc/manuals/debian-faq/ch-redistrib.en.html Cheers, Walter Landry
Re: Cisco EIGRP patent licence and the GPLv2 licence
Paul Jakma <p...@jakma.org> wrote: > On Tue, 4 Jul 2017, Walter Landry wrote: >> With that said, the usual approach that Debian follows is that if the >> patent is not being actively enforced, Debian does not worry about >> them. Otherwise, Debian would not be able to ship anything. Since >> you claim later > > It's hard to know. Cisco do have a history of initiating patent > enforcement actions though. E.g.: > > > https://blogs.cisco.com/news/protecting-innovation-itc-945-initial-determination > > How much that would concern one would depend on one's situation. > > Personally, I don't have an issue with that style of licence cause it > only limits those who want to sue over patents. Which seems fine to > me. IBM also has a history of suing everyone. If they are not suing over a particular patent, then it is not all that productive to worry about it. > (On whether concerns are founded: The brief informal legal advice I've > had seemed to suggest maybe - your reply above seems to too; what I > can't get clarity on is that issue of the reasonable degree of > caution, and the appropriate balance between different interests). I do not think I can give you any more clarity. Almost every non-trivial piece of software infringes patents, so objecting to the GPL because of an unenforced patent license would make almost all GPL software undistributable. I do not know how much mischief could be caused by bad actors. I can not imagine very much, but I might not be very imaginative ;) Cheers, Walter Landry
Re: Cisco EIGRP patent licence and the GPLv2 licence
Paul Jakma <p...@jakma.org> wrote: > Hi, > > I have a question I have not been able to get a conclusion to, > regarding the compatibility of the licence Cisco have given to their > EIGRP patents, by way of their declaration under the IETF "IPR" > process. That declaration being: > > https://datatracker.ietf.org/ipr/2236/ > > The relevant grant/licence text being: > > "For any claims of any Cisco patents that are necessary for practicing > the Enhanced Interior Gateway Routing Protocol specification > , any party will have the right to use any such > patent claims under reasonable, non-discriminatory terms, with > reciprocity, to implement and fully comply with the specification. This means that Cisco's patent grant only applies if you are implementing EIGRP. So that feels incompatibile. With that said, the usual approach that Debian follows is that if the patent is not being actively enforced, Debian does not worry about them. Otherwise, Debian would not be able to ship anything. Since you claim later > What I've gotten from those exchanges suggests there is little reason > to be concerned about the Cisco patent or the licence. then it would be fine for Debian. Note that I am not the decider. The Debian FTP masters are the final arbiters. They are extremely busy, so they rely on this list to sort out the easy cases. The only way to get a definitive ruling from the FTP masters is to create and submit a package. I am a random person who has been following the debian-legal mailing list for some time, so I think I have a sense of what the FTP masters are thinking. YMMV. Cheers, Walter Landry wlan...@caltech.edu
Re: System libraries and the GPLv2
Florian Weimer <f...@deneb.enyo.de> wrote: >> #5 Declare GMP to be a system library. >> > (snip) > >> #5 was how Fedora looked at the OpenSSL library issue. Since Debian >> has another viewpoint on OpenSSL I somehow doubt we would use it for >> GMP. > > I would like to suggest to treat more libraries as eligible for the > system library exception within Debian. The traditional interpretation as I understand it is that nothing Debian ships qualifies for the the system exception. This is because Debian ships everything together, and the system exception only applies for components that do not accompany the executable. Cheers, Walter Landry
Re: Are golang-github-facebookgo-* DFSG compliant?
Jeff Epler <jep...@unpythonic.net> wrote: > The license granted hereunder will terminate, automatically and without > notice, > if you (or any of your subsidiaries, corporate affiliates or agents) initiate > directly or indirectly, or take a direct financial interest in, any Patent > Assertion: (i) against Facebook or any of its subsidiaries or corporate > affiliates, (ii) against any party if such Patent Assertion arises in whole or > in part from any software, technology, product or service of Facebook or any > of > its subsidiaries or corporate affiliates, or (iii) against any party relating > to the Software. Interesting. If any S 5000 company sues Facebook, then anyone with retirement in a US equities fund will lose access to the patent. I understand the reasoning behind the clause, but that does cover a lot of people. > ISTM that since "patent" contains is an "additional grant" (i.e., the plain > language implies that it in no way restricts the rights granted in "license"), > it can be ignored for the purposes of analyzing whether the package's license > is DFSG-free. I think Debian's usual course of action is to only worry about actively enforced patents. If Facebook is not actually going around filing suits based on these patents, then Debian usually does not care about patent issues. So I agree. Cheers, Walter Landry
Re: Inclusion of PDF with CC Attr 3.0 license
Ian Jackson <ijack...@chiark.greenend.org.uk> wrote: > My personal view is that there would be no problem shipping the PDF, > even though Debian's users would have no practical ability to modify > this PDF. Making a modified version of a scientific paper like this > one is neither useful, nor, unless especial care is taken, ethical. As someone who reads and writes papers, this is not true. Reusing figures for talks and other papers is immensely useful. Copying the LaTeX for an equation can also be quite helpful. This paper has both of these elements. It is not like it is hard to add the attribution required by the license. Cheers, Walter Landry
Re: EADL license
Florian Weimer <f...@deneb.enyo.de> wrote: > * Walter Landry: > >> The EADL data was created by US Government employees (Lawrence >> Livermore). So there is no copyright in the US. Also, in the US, >> there is no copyright in a set of facts. However, as a courtesy, you >> should preserve the credits. > > Debian is also available in Europe, where the U.S. government is not > barred by U.S. law from obtaining and enforcing copyright of its > works. Europeanl law also has copyright-like protections for certain > collections of facts. In practice, Debian already distributes these kinds of works. http://metadata.ftp-master.debian.org/changelogs//main/o/openjpeg/openjpeg_1.5.2-3_copyright See the entry for applications/mj2/meta_out.* So I think it is fine in this case as well. > Frederic-Emmanuel, the license you quoted does not seem to give > permission to make modifications (and redistribute them). Only > permission of unmodified copies seems to be allowed. True. I do not think it matters. Cheers, Walter Landry
Re: EADL license
PICCA Frederic-Emmanuel <frederic-emmanuel.pi...@synchrotron-soleil.fr> wrote: > Hello still exploring my package > > I found this. > > Is it DFSG-free ? > > #F EADL97_MShellConstants.dat > #U00 This file is a conversion to specfile format of > #U01 directly extracted EADL97 Shell constants. > #U02 to simplify its use with the fisx and PyMca software packages. > #U03 > #U04 Neither those packages or their author(s) claim any ownership of > #U05 the data and they do not warrant the integrity of the data > following > #U07 the conversion process. > #U06 > #U07 EADL itself can be found at: > #U08 http://www-nds.iaea.org/epdl97/libsall.htm > #U09 The code used to generate this file has been: > #U10 GenerateEADLShellConstants.py > #U11 > #U12 The proper way to quote these data is: > #U13 D.E. Cullen, et al., "Tables and Graphs of Atomic Subshell and > #U14 Relaxation Data Derived from the LLNL Evaluated Atomic Data Library > #U15 (EADL), Z = 1 - 100," Lawrence Livermore National Laboratory, > UCRL-50400, > #U16 Vol. 30, October 1991 > #U17 The author of this data, D.E. Cullen, has stated that > redistribution of this > #U18 data is permitted provided the previous credits are maintained. > #U19 > > just for informations, these DATA are scientific fact (it is important right > ?) The EADL data was created by US Government employees (Lawrence Livermore). So there is no copyright in the US. Also, in the US, there is no copyright in a set of facts. However, as a courtesy, you should preserve the credits. Cheers, Walter Landry
Re: detail about license in duc package
Herbert Fortes (hpfn) <h...@ig.com.br> wrote: > Hi, > > On version 1.4.0 of the duc package a new file > became part of the software. At a first read > I thought it was free. But now I have doubts. > > First paragraph: > > "Permission is hereby granted, free of charge, to any person obtaining a > copy of this software and/or associated documentation files (the > "Materials"), to deal in the Materials without restriction, including > without limitation the rights to use, copy, modify, merge, publish, > distribute, sublicense, and/or sell copies of the Materials, and to > permit persons to whom the Materials are furnished to do so, subject to > the following conditions:" > > It is define "Materials" as the documentation files only ? The most natural reading is for Materials to mean "software and/or associated documentation". So I think this package is fine. Cheers, Walter Landry
Re: Questions about libntru license/ntru patent status
Zhu-Zhu Chin <zchin...@yandex.com> wrote: > 25.02.2016, 06:31, "Walter Landry" <wlan...@caltech.edu>: > >> Tor itself would not have to switch. Distributors would have to >> be careful when distributing binaries, which is something that Tor >> may or may not care about. > > Tor wouldn't have to switch even though they provide binaries at > torproject.org? Tor would have to provide source with their binaries, which is something that they already do. The code that the Tor project writes could still be BSD licensed. So if someone wants to make a pure BSD version, all they would have to do is take out the NTRU parts. > > If that is a problem, it might be a better idea to use the > > BSD-licensed implementation of NTRU [2] instead. It has the added > > benefit of being more efficient. > > If it is faster, you could fold it into the official > GPL-licensed version and enjoy performance and patent > protection. > > Are you saying other implementations than the official one are not > patent protected, or is it non-GPL'd implementations? As I understand it, the GPL'd NTRU implementation is distributed by the patent holders. The GPL implicitly grants a patent license. The BSD licensed version does not have this patent license. Cheers, Walter Landry
Re: Questions about libntru license/ntru patent status
Paul Wise <p...@debian.org> wrote: > On Thu, 2016-02-25 at 06:53 +0900, William Whyte wrote: >> I'll get our legal people to have a look at what that's meant to mean >> and see if we can get clarification. > > Great, thanks. > > My first thought was that Tor couldn't link with other GPLed software too. My impression is that the FOSS license exemption is only for works licensed under terms that would otherwise be incompatible with the GPL. Tor is BSD, so it does not have to make use of the exemption. This clause, then, just operates as a warning that ntru-crypto can not change the license of other GPL'd works. Cheers, Walter Landry
Re: Questions about libntru license/ntru patent status
Zhu-Zhu Chin <zchin...@yandex.com> wrote: > I'm no legal expert but Tor is BSD-licensed, so if you incorporated > GPL'd code [1], all of Tor would have to switch to the GPL. Tor itself would not have to switch. Distributors would have to be careful when distributing binaries, which is something that Tor may or may not care about. > If that is a problem, it might be a better idea to use the > BSD-licensed implementation of NTRU [2] instead. It has the added > benefit of being more efficient. If it is faster, you could fold it into the official GPL-licensed version and enjoy performance and patent protection. Cheers, Walter Landry
Re: Questions about libntru license/ntru patent status
Nick Mathewson <ni...@torproject.org> wrote: > Would there be any issues with including one or more of the NTRU > libraries in Debian, with the patent licenses in [4] below? It looks like if the license for Tor is compatible with the GPL, then you are fine. If the license for Tor is incompatible, but is one of the 28 licenses they list, then it is also fine. Looking at the copyright file for the latest version of Tor in Debian http://metadata.ftp-master.debian.org/changelogs/main/t/tor/tor_0.2.7.6-1_copyright it all looks compatible with the GPL. > If there are no issues, great! How should we move forward? Are there > more steps we should follow? I think you are OK. There is nothing more to do. Cheers, Walter Landry
Re: Are these copyright notices compatible with GPLv2+?
Riley Baird <bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch> wrote: >> > //3. Users agree to obey all government restrictions governing >> > //redistribution or export of the software. >> >> This is an additional restriction on top of what is allowed by GPLv2+. >> That, unfortunately, makes it incompatible. > > That sounds sensible, but are you sure?. Red Hat includes such a notice > with Fedora, so I'm tempted to think that we're interpreting this > wrongly. > > https://fedoraproject.org/wiki/Legal:Export I read that as requiring you to acknowledge that the law exists. It does not feel like Fedora would have an independent claim against you for breaking the law. > Regardless, the below clause is a non-commercial clause, which isn't > compatible with the GPLv2: >> //1. The users agree not to charge for the model owner code itself but may >> //charge for additions, extensions, or support. I do not think this is not a problem in practice. If you add a trivial addition to the code, then you are allowed to charge for the code. Cheers, Walter Landry
Re: Are these copyright notices compatible with GPLv2+?
Guilherme Brondani Torri <guito...@gmail.com> wrote: > //2. In any product based on the software, the users agree to acknowledge > //Michael Schroter that developed the model and software. This > //acknowledgment shall appear in the product documentation. This essentially boils down to a copyright notice. So I think it is OK. > //3. Users agree to obey all government restrictions governing > //redistribution or export of the software. This is an additional restriction on top of what is allowed by GPLv2+. That, unfortunately, makes it incompatible. > //4. The Users agree to reproduce any copyright notice which appears on > //the software and documentation on any copy or modification of such > //made available to others. > === END === > > One concern was raised about the request on paragraph 2, related to > acknowledgment of the author in the documentation. Does the word "shall" > implies something mandatory? If not, is there any other potential issue? > > The second file has this copyright notice: > > === BEGIN === > © 2005-2014 FBH. Permission to make copies, either paper or electronic, of > these files for personal or classroom use is granted without fee provided > that the copies are not made or distributed for profit or commercial > advantage and that the copies are complete and unmodified. Other > distributing, publishing, or posting on servers requires prior written > permission by FBH. By downloading these files, you agree that FBH shall not > be held to any liability with respect to any claim by you or from any third > party arising from or on account of the use of these files, regardless of > the form of action, including negligence. In no event will FBH be liable > for consequential or incidental damages of any nature whatsoever. > === END === > > Requesting permission from FBH would be enough? > In case they give us permission to distribute, should we make their > permission visible to others? How this is usually done? This does not allow modification, so it is definitely incompatible with GPLv2+. It also restricts how you can use it. In addition, Debian will not distribute it in main, since Debian guarantees that people can do things like sell installer DVD's with the contents of main. If you want to distribute this software linked to a GPLv2+ project, you will have to ask for a new license from FBH. Cheers, Walter Landry
Re: Establishing dialogue between the Debian project and OGC regarding Document & Software Notice terms
Sebastiaan Couwenberg <sebas...@xs4all.nl> wrote: > Because I've been unable to get feedback from Thorsten Alteholz or any > of the other FTP masters about this issue, I'm now directing this to > debian-legal in the hope we can get a dialog going between the Debian > project and the OGC (Open Geospatial Consortium). I'm getting the > impression that the FTP masters are unwilling to discuss this issue > because it might constitute legal advise which is problematic in the US, > or because they only enforce the DFSG and not set the terms of its > interpretation. debian-legal does not dispense official Debian advice. It is just a bunch of people with experience in how Debian looks at legal issues. So we can not give you an sort of official advice. This applies even to this email. I am not empowered to give official Debian advice. With that said, the people behind ftp-master are very busy and do not have time for lengthy discussions of legal minutiae. They rely on discussions in debian-legal to sort out the issues and fix obvious problems. So in this kind of situation, the usual procedure is to convince debian-legal that you have fixed the license. Then software with that new license get's submitted. ftp-master then decides whether they like the end result. This has the unfortunate possibility that ftp-master may disagree with debian-legal. In practice, debian-legal has been more conservative than ftp-master. So if you get it through debian-legal, it should be fine with ftp-master. As for the specifics of this license, the original rejection for TinyOWS http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2014-January/017300.html is, I think, clear about what the problem is. You have to allow modifications. Thorsten's further rejection at http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2014-January/017321.html also mentions the ability to freely modify. The "Proposed Text" at http://wiki.osgeo.org/wiki/OGC_XML_Schemas_and_FOSS4G_Software_Distribution might work, but only if it is a request, not a binding requirement. That is not clear to me. Cheers, Walter Landry wlan...@caltech.edu
Re: Establishing dialogue between the Debian project and OGC regarding Document & Software Notice terms
Sebastiaan Couwenberg <sebas...@xs4all.nl> wrote: > In the PyCSW discussion a good argument was made about the OGC Software > Notice terms not being problematic for Debian, because its terms are > identical to the W3C licenses and we have files licensed under those > terms in main: > > http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2014-November/027146.html > https://lists.osgeo.org/pipermail/standards/2015-February/000845.html > > Are the terms of the 'W3C Software and Document Notice and License' DFSG > complaint? If so, wouldn't it be sufficient to unambiguously license the > OGC CITE tests and XSD schemas under those terms to be DFSG compliant too? The Software license looks fine. It is the Document license which is problematic. The first link above claims that there are many files already in Debian already under the W3C document license. I could not find any with a cursory search. Do you have specific examples of files that Debian ships that are covered by the W3C Document license? Regards, Walter Landry wlan...@caltech.edu
Re: TPP 14.17
Glenn McGrath <glenn.l.mcgr...@gmail.com> wrote: > Hi all; > > The TPP has a clause that seems to me to be a direct attack on copyleft > licences. > > Hoping someone can tell me i am wrong, and everything will be ok. > > Article 14.17: Source Code > 1. No Party shall require the transfer of, or access to, source code > of software owned by a person of another Party, as a condition for > the import, distribution, sale or use of such software, or of > products containing such software, in its territory. It does not cover modification or copying. You can still require source code if you want to modify and/or copy. So I think it is fine. Cheers, Walter Landry
Re: Source files
Ole Streicher <oleb...@debian.org> wrote: > Walter Landry <wlan...@caltech.edu> writes: >> Ole Streicher <oleb...@debian.org> wrote: >>> What are the general guidelines here? Somewhere in written form? The >>> DFSG does not contain a hint here. >> >> The rule of thumb that I have seen applied is that 'source' is the >> preferred form of modification for the people making modifications. >> If a person really prefers editing 1400 character lines, then that is >> the source. However, you can not just state that you prefer that. > > I'd prefer just to ignore the line: it is a comment line that is not > needed for the functionality, so I see no reason to touch it at all. The > only reason to touch it for me would be to delete it. Sorry, I had not noticed that it was a comment. I am confused as to why it is there. Do you know why? Could you get upstream to delete this seemingly useless line? That would solve your immediate problem and clean up the code. Cheers, Walter Landry
Re: Source files
Ole Streicher <oleb...@debian.org> wrote: > What are the general guidelines here? Somewhere in written form? The > DFSG does not contain a hint here. The rule of thumb that I have seen applied is that 'source' is the preferred form of modification for the people making modifications. If a person really prefers editing 1400 character lines, then that is the source. However, you can not just state that you prefer that. We reserve the right to not believe you. Otherwise, proprietary software vendors could state the the binary is the 'source'. So if a file is generated mechanically, whatever scripts that generate the file are the 'source'. However, if someone actually edited the 1400 character line, then it could become 'source'. I have not seen the example of CVS status lines before. I think Debian generally ignores that kind of technical violation because 1) CVS is free software 2) Those lines are not critical to functionality. 3) The lines are very short and not difficult to modify. Cheers, Walter Landry
Re: DFSG status of petsc
Drew Parsons <dpars...@debian.org> wrote: > What is Debian policy on pdf documentation in upstream source? > > > dolfin needs an updated petsc to run optimally (multiple processors). > And dolfin is cool, so I'll update petsc (the latest version at > http://www.mcs.anl.gov/petsc is 3.6.1). > > We've been using a dfsg version of petsc. The dfsg impact is minimal: > > (1) a windows executable and dll in bin/win32fe/ > > (2) pdf manuals (manual.pdf, tao_manual.pdf, developers.pdf in docs/) > > These two sets of files are only dfsg because the source code is not > available to generate them. I gather we'd be free to modify the files > and distribute modifications if we wanted to. Isn't this the source for win32fe? https://bitbucket.org/petsc/win32fe Though you should probably just delete it from the tarball. In my 5 minute search, I could not find the source for the documentation. But I am absolutely certain someone on petsc-maint could point you to it. Cheers, Walter Landry
Re: How to free US governmental code
Ole Streicher oleb...@debian.org wrote: Hi, In one of the packages I am currently working on (idlastro [1]), some files have the following license [2]: | Copyright 1992, The Regents of the University of California. This | software was produced under U.S. Government contract (W-7405-ENG-36) | by Los Alamos National Laboratory, which is operated by the University | of California for the U.S. Department of Energy. The U.S. Government | is licensed to use, reproduce, and distribute this software. Neither | the Government nor the University makes any warranty, express or | implied, or assumes any liability or responsibility for the use of | this software. Surely, this makes the code non-free. However, I have no idea whom to ask to change to license to something DFGS-compatible. What are the experiences with this kind of copyright: are there any chances to make it free? Looking around the ftp site http://idlastro.gsfc.nasa.gov/ftp/ there is a top level file LICENSE dated 2014 that looks like a simple BSD license for Wayne Landsman. Since Wayne is also listed as a contributor to eqpole_grid.pro, he should be sympathetic to relicensing. A Google search for Wayne Landsman Astronomy turns up a likely contact at GSFC. You should ask Wayne directly. He would then contact the legal department at UC, though that would involve some work on his end. Also, are you planning on distributing http://idlastro.gsfc.nasa.gov/ftp/pro/misc/blkshift.pro That and a few other files have a non-commercial use license. Cheers, Walter Landry -- 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/20150629.070201.414466700400025959.wlan...@caltech.edu
Re: How to free US governmental code
James Cloos cl...@jhcloos.com wrote: OS == Ole Streicher oleb...@debian.org writes: OS In one of the packages I am currently working on (idlastro [1]), some OS files have the following license [2]: OS | Copyright 1992, The Regents of the University of California. ... Since the copyright is The Regents of the University of California, one wonders whether the their relicensing statement, where they dropped the 4th clause retoactively, covers this, too. I can't find the instance of that statement which I saved, nor via goog, so I cannot be sure whether it limited the relicensing to software which was released under the original BSD license, or coverred all software copyrighted by the Regents. I found something here ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change I do not think it applies in this case. Cheers, Walter Landry -- 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/20150629.110515.1437842410455001293.wlan...@caltech.edu
Re: Consensus about the Academic Free License (AFL) v3.0
Charles Plessy ple...@debian.org 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. - The Attribution Notice sounds a bit like an invariant section, but it is also very similar to the NOTICE file from the Apache License, which is Free. It is somewhat different. The Apache license only requires you to preserve attribution notices from the NOTICE file. AFL requires preserving any descriptive text identified therein as an Attribution Notice. There is no requirement that the text actually be an attribution notice. So maybe it is OK as long as there are only attributions in the Attribution Notice. Cheers, Walter Landry -- 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/20150612.142252.589075240808081958.wlan...@caltech.edu
Re: Consensus about the Academic Free License (AFL) v3.0
Ángel González keis...@gmail.com wrote: On 12/06/15 23:22, Walter Landry wrote: Charles Plessyple...@debian.org 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. 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
Re: Free as in speech, but not as in beer
Paul van der Vlis p...@vandervlis.nl wrote: Hello Miriam, Op 24-03-15 om 21:05 schreef Miriam Ruiz: 2015-03-24 20:04 GMT+01:00 Paul van der Vlis p...@vandervlis.nl: Op 24-03-15 om 18:38 schreef Paul R. Tagliamonte: Unless it allows modification and redistribution of this (and we do so), What when the DD who packages it, would package it with the 5 user limitation? If the 5 user limitation is a requirement, then the license is definitely not DFSG-free (and, also, they would have to figure out how to manage the contradiction between this limitation and the AGPL). Depending on the license, it might go to non-free, though. The 5 user limitation is something in the software, but because it's AGPL it's not forbidden to remove it. But I think the developer would ask friendly to remove a version without the limitation from Debian. If anyone actually used the software, I think the limitation would be quickly removed. As a historical example, xpdf, as distributed by the developer, prevented copy and paste from documents that were marked read-only. The Debian maintainer removed that feature. Cheers, Walter Landry -- 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/20150324.142756.427512270065426951.wlan...@caltech.edu
Re: How to open-source a program?
Ole Streicher debian-de...@liska.ath.cx wrote: Has anyone already went through such an exercise and could assist me in writing a nice E-mail? Or are there better ways to proceed? I have assisted people in doing this sort of thing a few times. It sounds like the author is on board with releasing the code, which is crucial. It would be best if the author started the ball rolling, but lets see what we can do. Looking at http://www3.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/en/community/STETSON/daospec/agreement.txt it looks like Greg Fahlman would be the person to contact. Fahlman may forward you to someone else. I have attached a sample letter. Use as much or as little as you like. You need to let Peter Stetson look at your letter before you send it. Without his complete support you are unlikely to succeed. Cheers, Walter Landry Subject: Distributing Daophot through Debian Dear Dr. Fahlman, I am a developer for Debian, a free Linux distribution. Debian includes more than 37500 packages, precompiled software bundled up in a nice format that makes it easy to install. I would like to distribute a copy of the Daophot software through Debian. Daophot is an important piece of software, used by astronomers around the world. http://adsabs.harvard.edu/abs/1987PASP...99..191S Currently, to obtain Daophot, users must sign a non-disclosure agreement that prohibits further redistribution. http://www3.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/en/community/STETSON/daospec/agreement.txt I have contacted Peter Stetson, the author of Daophot. He said that, while he is willing to distribute Daophot under more permissive terms, he is obligated to follow any restrictions set down by the National Research Council of Canada. So this is why I am sending a letter to you. Ideally, Daophot would be distributed under a free or open source license. The National Research Council of Canada, through the Canadian Astronomy Data Centre, already distributes a number of pieces of astronomical software freely. https://code.google.com/p/opencadc/ https://code.google.com/p/caom/ https://github.com/canfar/vos Please let me know if it will be possible to modify the distribution terms for Daophot. If you are not the right person to contact, I would appreciate it if you could direct me to the right person. Thank you, Ole Streicher -- 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/20150208.231112.901590335374856807.wlan...@caltech.edu
Re: Standard implementation of constant, copyright or not ?
Guilherme Brondani Torri guito...@gmail.com wrote: I am currently maintaining the ADMS package (LGPL 2.1). The package is now hosted at: https://github.com/Qucs/ADMS The two headers that are causing us trouble are these: https://github.com/Qucs/ADMS/blob/master/admsXml/constants.vams https://github.com/Qucs/ADMS/blob/master/admsXml/disciplines.vams We received a request to update to the latest version of the headers. See: https://sourceforge.net/p/mot-adms/patches/4/ The new headers from LRM 2.4.0 (May 2014), annex D. have the following copyright notice: // Copyright(c) 2009-2014 Accellera Systems Initiative Inc. // 1370 Trancas Street #163, Napa, CA 94558, USA. // // The material in disciplines.vams is an essential part of the Accellera Systems // Initiative (Accellera) Verilog-AMS Language Standard. Verbatim copies of // the material in this Annex may be used and distributed without restriction. // All other uses require permission from Accellera IP Committee // (ipr-ch...@lists.accellera.org). // All other rights reserved. // // Version 2.4.0 How ADMS stand on this context? Can distribute at all the new headers? Does the new headers change anything with respect to Debian package inclusion policy? The license for the new headers is not a free license. I think it could go into non-free. You could, in principle, extract the constants from NIST yourself. The disciplines.vams file is more complicated, because it is not just constants. It looks like a number of tolerances that have been chosen somewhat arbitrarily. Maybe you could ask Accellera for a better license? IETF RFC's have the same problem, and cause recurring problems for Debian. https://wiki.debian.org/NonFreeIETFDocuments Cheers, Walter Landry
Re: Non-freeness of the AFL v3.0
Ian Jackson ijack...@chiark.greenend.org.uk wrote: If we want to distribute AFL3.0 code whose copyrightholder is not Larry Rosen, we should probably send the copyrightholder an email pointing to this interpretation, just so that they have the opportunity to disagree now rather than later. (And include that email and any reply in the copyright file.) This is the case we have today with svn_load_dirs. Are you saying that we should not distribute svn_load_dirs until we get this clarification? I also must say that I am not convinced by Larry Rosen's explanation. Rosen's comment However, there isn't a soul in the software world who doesn't know that Debian software is open source and that the actual software licenses are posted in all the appropriate places somewhere. is manifestly not true. Lots of people in the software world have no idea what Debian is. Will I get into trouble if I sell someone a live CD without getting them to assent to the AFL? Sony is not the most benevolent of companies. Also, reading the license, I would expect it to require Debian to do what Sony, the current copyright holder, does in all of their own installers: require explicit assent via a clickwrap. Even judges would be familiar with that mechanism and not think it odd to require it. Finally, this comment That's because you are diligent and careful in what you distribute. makes it sound like if Debian starts getting sloppy in other areas then Debian will get in trouble. That feels wrong. Cheers, Walter Landry wlan...@caltech.edu -- 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/20141104.164837.1940264495017064422.wlan...@caltech.edu
Re: openjdk-8 upstream limits source distribution?
Steven Chamberlain ste...@pyro.eu.org wrote: Hi, This is an odd statement for GPLv2 code: http://download.java.net/openjdk/jdk8/ : International Use Restrictions Due to limited intellectual property protection and enforcement in certain countries, the JDK source code may only be distributed to an authorized list of countries. You will not be able to access the source code if you are downloading from a country that is not on this list. We are continuously reviewing this list for addition of other countries. This is just Oracle saying that they will not offer downloads to people in embargoed countries (e.g. Cuba). Debian does a similar thing. This does not prevent anyone from taking that download and giving it to a Cuban. Cheers, Walter Landry -- 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/20140901.164029.770625889527809981.wlan...@caltech.edu
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
Ángel González keis...@gmail.com wrote: 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: Stop. Please just stop. Please pick an existing, well known license so that we do not have to argue *again* over whether this really solves all of the problems. Thanks, Walter Landry
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
Stas Malyshev smalys...@sugarcrm.com wrote: Would you change the licence to something more usual, like MIT/X style? No, this is completely infeasible That is not correct. It is very easy to change the license because the license has an upgrade clause (condition #5). Cheers, Walter Landry -- 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/20140730.175410.333118138785423294.wlan...@caltech.edu
Re: [PHP-QA] Debian and the PHP license
Ferenc Kovacs tyr...@gmail.com wrote: I've find it a bit disturbing, that ftpmasters can make a decision on legal grounds(which is the probably the highest priority for debian as far as I'm concerned), without any backing from debian-legal debian-legal has no authority to decide anything. It is just a mailing list. We can discuss things here day and night and ftp-masters can ignore it. With that said, debian-legal can be useful when issues are clear-cut. For example, if someone asks if the Apache 2.0 license is compatible with the GPL (no for GPL 2.0, yes for GPL 3.0). Think of debian-legal as the secretary for ftp-masters. We can sometimes divine what they are thinking, but the final word belongs to ftp-masters. In any case, in the interest of making this email constructive, my take on the PHP license is that it does need to be fixed. From ftp-masters REJECT-FAQ, they also think so. So my advice would be to just use a well known, existing license and be done with it. Judging from the existing PHP license, the closest thing would be the 3 clause BSD license http://opensource.org/licenses/BSD-3-Clause Apache 2.0 would also be a good choice. Now, I understand that changing licenses is a huge chore, and the benefits can sometimes be intangible. The main benefit is that you will never have to deal with us again ;) Cheers, Walter Landry wlan...@caltech.edu -- 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/20140729.121653.1175255053010754152.wlan...@caltech.edu
Re: Perforce distribution license
Vincent Bernat ber...@debian.org wrote: ❦ 9 mai 2014 11:26 -0700, Walter Landry wlan...@caltech.edu : I do not see any permission to redistribute. Many organizations want to be the sole source of their software, so redistribution is not something you should assume. So this license will not work. You could ask Perforce to give Debian permission to distribute. Or anyone since redistribution must be allowed for anyone to be in non-free. I do not think that is required for non-free. I think that there are other packages in non-free which only have permission for Debian and it's mirrors to distribute. That is why it is called non-free ;) Cheers, Walter Landry
Re: Perforce distribution license
Lukas Anzinger l.anzin...@gmail.com wrote: Hi, it'd be interesting to have Perforce (p4) properly packaged in Debian in section non-free. The terms under which Perforce is distributed are available here: http://www.perforce.com/downloads/terms-use It seems to me that redistribution of binaries is not a problem as long as they are not modified so I believe that p4 could be uploaded to non-free. Is there anyone who would object? (I'm not a Debian developer/maintainer [yet] so I'm merely just asking out of curiosity.) I do not see any permission to redistribute. Many organizations want to be the sole source of their software, so redistribution is not something you should assume. So this license will not work. You could ask Perforce to give Debian permission to distribute. Another troublesome part is the line about export controls You shall not permit, directly or indirectly, use of any Perforce technology in or by any U.S. embargoed country or otherwise in violation of any U.S. export control laws and regulations. I think Debian just has to treat it like crypto software. Also, regarding the indemnification, Perforce does not require indemnification for people you distribute to, only for your own use. So if p4 eats your neighbor's cat, you have to indemnify Perforce against your neighbor's lawsuit. Debian does not actually run p4, so I do not think this is an issue for non-free. For future reference, I am attaching the license. It is pretty much the usual icky commercial license. Cheers, Walter Landry Terms of Use You acknowledge and agree that you are downloading and using the software at your own risk, and that you did not rely upon any skill or judgment of Perforce Software, Inc. (Perforce) in such choice or decision. PERFORCE PROVIDES NO WARRANTY WHATSOEVER ON ANY SOFTWARE HEREUNDER, EXPRESS, IMPLIED OR OTHERWISE. PERFORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, WARRANTIES WITH RESPECT TO THE SOFTWARE, AND ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. You acknowledge and agree that you have no ownership rights in the software, and that Perforce has and retains all right, title, interest and ownership in and to the software, and in any copies or updates of the software. You may not sell, transfer, assign, delegate, or subcontract the software. You may use software downloaded from Perforce for your own direct internal business purposes, for as long as you wish, provided you do not make any modifications to the software. You may not decompile, disassemble, or reverse engineer the software. The software constitutes proprietary information and trade secrets of Perforce, whether or not any portion of the software is or may be the subject of a valid copyright or patent. You may not alter or remove any proprietary markings on the software, including copyright, trademark, trade secret, and patent legends. You will indemnify and hold harmless Perforce, and all its successors in interest, subsidiaries, affiliates, and their officers, employees and agents, from all liability arising from use of the software by you or any of your successors. This product is subject to U.S. export control laws and regulations including, but not limited to, the U.S. Export Administration Regulations, the International Traffic in Arms Regulation requirements, and all applicable end-use, end-user and destination restrictions. You shall not permit, directly or indirectly, use of any Perforce technology in or by any U.S. embargoed country or otherwise in violation of any U.S. export control laws and regulations. IN NO EVENT WILL PERFORCE BE LIABLE FOR ANY DAMAGES, INCLUDING WITHOUT RESTRICTION ANY LOST PROFITS, LOST SAVINGS OR OTHER INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE SOFTWARE EVEN IF PERFORCE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY ANY OTHER PARTY. PERFORCE’S LIABILITY FOR DAMAGES HEREUNDER SHALL IN NO EVENT EXCEED THE AMOUNT PAID FOR THE SOFTWARE UNDER THE TERMS AND CONDITIONS OF THIS AGREEMENT.
Re: copyright years in the copyright file
Osamu Aoki osamu_aoki_h...@nifty.com wrote: Hi, On Fri, Apr 25, 2014 at 01:56:21AM +0200, Vincent Lefevre wrote: The copyright years in /usr/share/doc/getmail4/copyright are incorrect (not up-to-date). I have reported bug 743161[*] about that, but it has been closed because upstream doesn't care. This means that some time in the future, people could think that some code has fallen into the public domain, while this is actually not true. One may also wonder whether new code is distributed in the same license (one could interpret the lack of copyright notice update as unspecified license for the new code). Upstream considers this is good enough and 1 year is nothing to fuss about. See http://marc.info/?l=getmailm=131805611901165w=2 | Neither. I update that when I happen to notice another year has gone by | (getmail is more than a decade old at this point) -- but it's not | important to keep it current. Having that year out-of-date has no legal | effect under the Berne copyright convention. Thus, I do not think this is a bug. The information is still misleading to end-users. This makes it a minor bug. But it is still a bug. Since upstream is not willing to fix it, Debian can. If Vincent is willing to do all of the work of preparing a correct patch, I do not see a good reason to refuse to apply the patch. Cheers, Walter Landry wlan...@caltech.edu -- 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/20140427.013940.888054049895997375.wlan...@caltech.edu
Re: Unteralterbach visual novel
Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Bas Wijnen wij...@debian.org writes: I am going to start with trying to package Bernd und das Rätsel um Unteralterbach - a visual novel set in present-day bavaria containing (optional) erotic content The erotic content is not optional, AFAICS. Only the abuse is optional. The first time you get to a point where you can see it, you have to click a button that says I'm mentally ill and want to see this. Given that these are (drawn) images of child abuse, I think they are actually criminal to possess in many countries (including mine, the Netherlands, so I have already deleted the game). I'm pretty sure we cannot distribute them in Debian, not even in non-free. So for the rest of the post, I'm assuming that those images are not in the game. As far as I understand it, in Germany, for a text / recording / drawing to be a criminal matter, it must depict actual abuse – meaning a child has to be abused for the document to be created. Off-topic: Does this mean that the stereotypical hentai comics that commonly depict rape, child abuse, dismemberment etc. are not legal to posess in NL as well? Quote: http://www.zeit.de/politik/deutschland/2013-06/kinderpornographie The US seems to be more strict. A man was convicted in 2010 for sending Hentai comics through the mail. http://www.escapistmagazine.com/forums/read/7.175488-Hentai-Collector-Sentenced-to-Jail-Over-Obscene-Material Cheers, Walter Landry wlan...@caltech.edu
Re: OpenJDK 7.0 license question
Mathieu Malaterre ma...@debian.org wrote: [CC me please] Hi there, Could someone please clarify why OpenJDK 7.0 went to main with the following license: http://openjdk.java.net/legal/ - http://openjdk.java.net/legal/OpenJDK-TCK_SE7_27Dec2011.pdf Looking at /usr/share/doc/openjdk-7-jre/copyright it does not mention that license. I do not think that Debian ships the TCK. Looking at http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html it looks like they do not give out the TCK to everyone. Cheers, Walter Landry -- 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/20130904.103524.1589744090062387635.wlan...@caltech.edu
Re: [php-maint] Bug#692613: php5: non-free files in upstream tarball (The Software shall be used for Good, not Evil)
Thijs Kinkhorst th...@debian.org wrote: On Mon, May 13, 2013 13:01, Ondrej Sury wrote: OK, it's very much annoying (since the tarball is huge and the updated module won't hit PHP 5.5), but I will comply. This seems like a paper exercise which I doubt is worth our efforts. I seems extremely unlikely that the author of the software could have a legally valid case where a judge would positively decide that a use case is objectively Evil and in violation of this license. I don't see a practical risk to anyones freedom being in jeopardy here. Surely it's an annoying license, so when removing it is opportune we should do it, but in this case the potential gains (if any?) do not seem to outweigh the cost. The problem is not whether Debian can distribute the software. The problem is that the tarball that Debian distributes to users must not contain non-free bits. This is hardly the first time that this has come up [1]. Yes, it is annoying for the packager. But it is useful for the user to know that, whatever is in the tarball, they will not have to do any forensic analysis before using the tarball. Cheers, Walter Landry wlan...@caltech.edu [1] For example, http://lists.debian.org/debian-legal/2008/11/msg00083.html http://lists.debian.org/debian-legal/2007/11/msg00280.html http://lists.debian.org/debian-legal/2006/07/msg00043.html -- 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/20130513.063112.1924456364084710209.wlan...@caltech.edu
Re: Open-source library proxying to a closed-source library (ITP #679504)
Francesco Poli invernom...@paranoici.org wrote: On Sat, 7 Jul 2012 18:48:47 +0200 Christophe-Marie Duquesne wrote: [...] On Sat, Jul 7, 2012 at 5:03 PM, Francesco Poli It could *maybe* qualify for the contrib archive [2], as long as it is determined to be (legally redistributable and) Who would determine whether it is legally redistributable? The ultimate decision on what will or will not be distributed by Debian is up to the FTP Masters (possibly after consultation with other bodies, including the Debian-legal mailing list). I think that your use of the header files to extract function information is covered by fair use. In general, I think the code as a whole can go into main, because it works fine with GLPK. If there were separate packages for the proprietary solvers, then those would have to go into contrib. But IANAL and I am not an FTP Master. (even though I see that it is licensed under the terms of the EPL, a license that I personally dislike...). The EPL is the license recommended by coin-or [2] where I intend to submit my project. I would be happy to relicense my work differently as long as the new license is approved by the open source initiative (coin-or requirement) and as it makes it possible to link Osi with it. [1]: http://scip.zib.de/ [2]: http://www.coin-or.org/contributions.html I would personally recommend a simpler license, such as the Expat license: http://www.jclark.com/xml/copying.txt also known as the MIT license: http://www.opensource.org/licenses/MIT I noticed that parts of the code are licensed under GPL 3+, and other parts are EPL 1+. These are incompatible licenses, meaning that Debian could not distribute binaries. One solution would be to put everything under Expat or MIT. Alternately, you could dual license everything under GPL 3+ and EPL 1+. Cheers, Walter Landry wlan...@caltech.edu -- 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/20120707.202220.57768713094072007.wlan...@caltech.edu
Re: public domain no modification
Steve Langasek vor...@debian.org wrote: On Tue, Apr 10, 2012 at 12:01:45AM +0200, Francesco Poli wrote: On Sat, Apr 07, 2012 at 05:05:27PM +0200, Mathieu Malaterre wrote: Clearly §2 is meant to distinguish derived work from original work. However in our case, this means this package will have to have its name change whenever we need to patch the source code (eg. fix a compilation error). This appears to be entirely consistent with the requirements of DFSG #4. That's not my understanding of the issue under consideration: more details are included in my own analysis [1]. Yes, because as usual your analysis is way out in left field. Lets try to keep to the facts. My impression is that clause 2 introduces odd restrictions on how modified versions are packaged package is synonymous with name in this case. DFSG#4 says free works may require a name change when modified. In this case, it affects the API. It forbids creating a drop-in replacement. I remember a large discussion on this topic when discussing the Latex Project Public License. My recollection was that the consensus was that drop-in replacements must be allowed. In any case, the modified files must be put into Java files. What if the modification is to port it to C/Python/C#/C++/Ruby/Lisp? This alone should disqualify it from main. and insists that modifications be documented in comments (which, depending on how it is interpreted, may be a very strong restriction). You mean like this restriction? a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. You know, the one in the GPLv2? Your claims that this may be non-free are absurd. Not all file types have comments. The GPL is more flexible. For example, you can modify an image and put the required notices in the image itself. Cheers, Walter Landry wlan...@caltech.edu -- 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/20120409.172156.1755585307805512271.wal...@geodynamics.org
Re: Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
I am Cc'ing the DPL for clarification. Christofer C. Bell christofer.c.b...@gmail.com wrote: On Tue, Mar 27, 2012 at 6:46 PM, Lennart Weller l...@ring0.de wrote: Am 28.03.2012 01:01, schrieb Ben Hutchings: Since you've accepted as fact that this software infringes those patents, it looks like you're about to violate item 1 of the Debian patent policy. Ben. S3TC is not actively enforced by S3. And I took this thread [1] as a reference to create the ITP anyway. According to this thread from 2010 there are at least three other projects already using the S3TC algorithms. And there is more than one project which depends on this package. e.g. 0ad and wine [1] http://lists.debian.org/debian-legal/2010/12/msg00062.html I think Ben's point is that the Debian Patent Policy[1] was published on February 19, 2012, and therefore would supersede any previous consensus regarding the inclusion of patent encumbered software where the included patents are not being actively enforced. Personally, I agree with the posters in the thread you cited[2]. If this is going to be the project's official position, it may as well close shop. I must have missed this policy when it was announced. Who wrote that policy? It changes long standing traditions in Debian. The first item Debian will not knowingly distribute software encumbered by patents is impossible. Debian would have to stop distributing almost anything. I am sure gcc is encumbered by unenforced patents. Also, the third item, AKA The first rule of Patents is that we do not talk about Patents, is too broad. If someone posts publicly, then no one would be surprised to see it quoted far and wide. Attorneys can subpoena your private records, but they could do that regardless of whether you posted something publicly. Was the intention of that point that you should not discuss anything in private except with an attorney? So do not post anything to debian-private expecting it not to get subpoenaed? That would be more sensible advice. The other points are good, but those two really made me scratch my head. In contrast, the patent FAQ at http://www.debian.org/reports/patent-faq is good. So, who, in particular, wrote the patent policy at http://www.debian.org/legal/patent Regards, Walter Landry wlan...@caltech.edu -- 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/20120328.023206.1893294338866990004.wal...@geodynamics.org
Re: custom license (package: bwctl)
Clark C. Evans c...@clarkevans.com wrote: Raoul, This looks like a non-symmetric copyleft-like attempt: then you thereby grant Internet2, its contributors, and its members for that reason, I don't think it's free I am not so sure. It is not required to give them back the changes. It is just the default. It seems like, if you modify a file, you could add a copyright notice like Modifications Copyright (c) 2012, J. Random see license.mit for terms then the modifications would be under the MIT license. Or you could reuse the bwctl license and replace Internet2 with J. Random. Cheers, Walter Landry wlan...@caltech.edu -- 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/20120203.115647.1906689101038995781.wal...@geodynamics.org
Re: Qt Eclipse integration license (discriminating against group of users)
Jakub Adam jakub.a...@ktknet.cz wrote: Hi, I'm working on a package for Eclipse Qt Integration [1]. Some of the source files come with following license: / ** ** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies). ** All rights reserved. ** Contact: Nokia Corporation (qt-i...@nokia.com) ** ** This file is part of the Qt Designer of the Qt Toolkit. ** ** Windows(R) users may use this file under the terms of the Qt Eclipse ** Plug In License Agreement Version 1.0 as attached in the LICENSE.TXT ** [2] file. My brief analysis of this license is that it is non-free. It only allows using the file in conjunction with Qt on Windows machines. It looks like a fairly standard proprietary license. This is probably here to reassure developers of proprietary software. ** Linux(R) users may use this file under the terms of the GNU Lesser ** General Public License Agreement version 2.1 as shown in the LGPL-2_1.TXT file. ** / This license in itself is discriminating against users, so it has to go in non-free. But there is a potential loop-hole in this license via the LGPL-2.1. A Linux user could choose the LGPL-2.1 offer (the file has no extra restrictions) and via the terms of the LGPL-2.1 distribute the sources under a LGPL-2.1. The only issue is there is no definition of a Linux user (as far as I can tell), so I am not sure it is a safe work around. What is your opinion? Are we allowed to redistribute these files under terms of LGPL-2.1 only, or must this license be considered non-free? You should contact upstream and clarify what they really want to do. In particular, ask them if it is ok for you to do what you asking. If it is not ok, then the code is not really licensed under the LGPL, and it would be good to know that. Ideally, they would remove that restriction in the license so that it would read something like ** You may use this file under the terms of the GNU Lesser ** General Public License Agreement version 2.1 as shown in the LGPL-2_1.TXT file. ** ** Alternately, Windows(R) users may use this file under the terms of the Qt Eclipse ** Plug In License Agreement Version 1.0 as attached in the LICENSE.TXT ** file. Cheers, Walter Landry wlan...@caltech.edu -- 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/20120202.123118.1584880682135202000.wal...@geodynamics.org
Re: need help with openscad's license
chrysn chr...@fsfe.org wrote:
* technical solution
if the modifications could be split out from OGL_helper.h by means of
c++, we would still link against the qpl version statically, but we
wouldn't have to ship qpl source code in openscad and could rely on it
being provided by the non-free build dependency.
if it was trivial, the openscad authors would already have done it,
and my c++ fu is not strong enough for such a task.
My C++ fu felt strong. I am attaching a new version of
CGAL_renderer.h that seems to work with the version of cgal bundled
with Debian.
The only essential difference between openscad's and cgal's
OGL_helper.h header was that some member variables were made private.
So I used a C++ trick to make them accessible. There were also some
typedefs that I just spelled out manually.
This also has the benefit of not assuming that the layout of a class
stays the same when adding private: or protected: decorations.
Cheers,
Walter Landry
wlan...@caltech.edu
/*
* OpenSCAD (www.openscad.org)
* Copyright (C) 2009-2011 Clifford Wolf cliff...@clifford.at and
* Marius Kintel mar...@kintel.net
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* As a special exception, you have permission to link this program
* with the CGAL library and distribute executables, as long as you
* follow the requirements of the GNU GPL in regard to all of the
* software in the executable aside from CGAL.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
*/
#ifndef CGAL_RENDERER_H
#define CGAL_RENDERER_H
#include CGAL/Nef_3/OGL_helper.h
#undef CGAL_NEF3_MARKED_VERTEX_COLOR
#undef CGAL_NEF3_MARKED_EDGE_COLOR
#undef CGAL_NEF3_MARKED_FACET_COLOR
#undef CGAL_NEF3_UNMARKED_VERTEX_COLOR
#undef CGAL_NEF3_UNMARKED_EDGE_COLOR
#undef CGAL_NEF3_UNMARKED_FACET_COLOR
using CGAL::OGL::SNC_BOUNDARY;
using CGAL::OGL::SNC_SKELETON;
// Originally from https://gist.github.com/1528856
// Modified to allow access two rather than one private member.
// This is needed because CGAL::OGL::Polyhedron has private members
// that we need access to.
// Generate a static data member of type Tag::type in which to store
// the address of a private member. It is crucial that Tag does not
// depend on the /value/ of the the stored address in any way so that
// we can access it from ordinary code without directly touching
// private data.
template class Tag
struct stowed
{
static typename Tag::style_type style;
static typename Tag::object_list_type object_list_;
};
template class Tag
typename Tag::style_type stowedTag::style;
template class Tag
typename Tag::object_list_type stowedTag::object_list_;
// Generate a static data member whose constructor initializes
// stowedTag::value. This type will only be named in an explicit
// instantiation, where it is legal to pass the address of a private
// member.
template class Tag, typename Tag::style_type Style, typename
Tag::object_list_type Object_list_
struct stow_private
{
stow_private()
{
stowedTag::style = Style;
stowedTag::object_list_ = Object_list_;
}
static stow_private instance;
};
template class Tag, typename Tag::style_type Style, typename
Tag::object_list_type Object_list_
stow_privateTag,Style,Object_list_
stow_privateTag,Style,Object_list_::instance;
struct Polyhedron_private
{
typedef int(CGAL::OGL::Polyhedron::*style_type);
typedef GLuint(CGAL::OGL::Polyhedron::*object_list_type);
};
// Explicit instantiation; the only place where it is legal to pass
// the address of a private member. Generates the static ::instance
// that in turn initializes stowedTag::value.
template class stow_privatePolyhedron_private,CGAL::OGL::Polyhedron::style,
CGAL::OGL::Polyhedron::object_list_;
class Polyhedron : public CGAL::OGL::Polyhedron
{
public:
enum RenderColor {
CGAL_NEF3_MARKED_VERTEX_COLOR,
CGAL_NEF3_MARKED_EDGE_COLOR,
CGAL_NEF3_MARKED_FACET_COLOR,
CGAL_NEF3_UNMARKED_VERTEX_COLOR,
CGAL_NEF3_UNMARKED_EDGE_COLOR,
CGAL_NEF3_UNMARKED_FACET_COLOR,
NUM_COLORS
};
Polyhedron() {
setColor(CGAL_NEF3_MARKED_VERTEX_COLOR,0xb7,0xe8,0x5c);
setColor(CGAL_NEF3_MARKED_EDGE_COLOR,0xab,0xd8,0x56
Re: XNAT license terms... any chance for main?
Yaroslav Halchenko deb...@onerussian.com wrote: 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 only a request, not a requirement. So it is fine. Everything else looks fine to me. Cheers, Walter Landry wlan...@caltech.edu -- 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/20110603.133427.1547628357412441210.wal...@geodynamics.org
Re: Question about GPL and DFSG Compatibility of a Proposed Amendment to the W3C Document Licence
Lachlan Hunt lachlan.h...@lachy.id.au wrote: Hi, The W3C and the HTML WG are currently negotiating a new copyright licence for the HTML specifications, and I would like to get some clarification about whether or not the proposed licence is compatible with the GPL and the Debian Free Software Guidelines. The proposed licence is Option 3, listed here. http://www.w3.org/2011/03/html-license-options.html#option3 For posterity, I am attaching the complete copy of the three options. In a followup email I will analyze them. Cheers, Walter Landry wlan...@caltech.edu Option 1 Copyright © 2011 W3C® (MIT, ERCIM, Keio). W3C liability and trademark rules apply. As a whole, this document may be used according to the terms of the W3C Document License. In addition: * To facilitate implementation of the technical specifications set forth in this document, anyone may prepare and distribute derivative works and portions of this document in software, in supporting materials accompanying software, and in documentation of software, PROVIDED that all such works include the notice below. HOWEVER, the publication of derivative works of this document for use as a technical specification is expressly prohibited. * Furthermore, all code, pseudo-code, schema, data tables, cascading style sheets, and interface definition language is licensed under the W3C Software License, LGPL 2.1, and MPL 1.1. The notice is: Copyright © 2011 W3C® (MIT, ERCIM, Keio). This software or document includes material copied from or derived from [title and URI of the W3C document]. Option 2 Copyright © 2011 W3C ® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability and trademark rules apply. The W3C Document License applies to this document as a whole; however, to facilitate implementation of the technical specifications set forth in this document you may: 1. copy and modify, without limitation, any code, pseudo-code, schema, data tables, cascading style sheets, interface definition language, and header text in this document in source code for implementation of the technical specifications, and 2. copy and modify reasonable portions of this document for inclusion in software such as, for example, in source code comments, commit messages, documentation of software, test materials, user-interface messages, and supporting materials accompanying software, all in accordance with good software engineering practices, and 3. include reasonable portions of this document in research materials and publications. You may distribute, under any license, the portions used, copied, or modified in accordance with the terms set forth above. Copying, republication, or distribution of any portion of this document must include the following notice: Copyright © 2011 W3C ® (MIT, ERCIM, Keio). Includes material copied from or derived from [title and URI of the W3C document]. Option 3 Copyright © 2011 W3C® (MIT, ERCIM, Keio). W3C liability and trademark rules apply. As a whole, this document may be used according to the terms of the W3C Document License. In addition: * To facilitate implementation of the technical specifications set forth in this document, anyone may prepare and distribute derivative works and portions of this document in software, in supporting materials accompanying software, and in documentation of software, PROVIDED that all such works include the notice below. * Furthermore, all code, pseudo-code, schema, data tables, cascading style sheets, and interface definition language is licensed under the W3C Software License, LGPL 2.1, and MPL 1.1. The notice is: Copyright © 2011 W3C® (MIT, ERCIM, Keio). This software or document includes material copied from or derived from [title and URI of the W3C document]. -- 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/20110428.065044.318830237410758434.wal...@geodynamics.org
Re: Question about GPL and DFSG Compatibility of a Proposed Amendment to the W3C Document Licence
Walter Landry wlan...@caltech.edu wrote: Option 1 As noted, the clause HOWEVER, the publication of derivative works of this document for use as a technical specification is expressly prohibited. makes the license incompatible with the DFSG, so I will not spend any time on any other parts. Option 2 Copyright © 2011 W3C ® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability and trademark rules apply. The W3C Document License applies to this document as a whole; however, to facilitate implementation of the technical specifications set forth in this document you may: 1. copy and modify, without limitation, any code, pseudo-code, schema, data tables, cascading style sheets, interface definition language, and header text in this document in source code for implementation of the technical specifications, and 2. copy and modify reasonable portions of this document for inclusion in software such as, for example, in source code comments, commit messages, documentation of software, test materials, user-interface messages, and supporting materials accompanying software, all in accordance with good software engineering practices, and 3. include reasonable portions of this document in research materials and publications. I would say that this option fails the DFSG because it only allows copying and modification of reasonable amounts. It would also be incompatible with the GPL, so I do not understand why Eben Moglen would say that it is compatible. Option 3 Copyright © 2011 W3C® (MIT, ERCIM, Keio). W3C liability and trademark rules apply. As a whole, this document may be used according to the terms of the W3C Document License. In addition: * To facilitate implementation of the technical specifications set forth in this document, anyone may prepare and distribute derivative works and portions of this document in software, in supporting materials accompanying software, and in documentation of software, PROVIDED that all such works include the notice below. * Furthermore, all code, pseudo-code, schema, data tables, cascading style sheets, and interface definition language is licensed under the W3C Software License, LGPL 2.1, and MPL 1.1. So what if I want to make derivative works that do not facilitate implementation of the specifications? What if Neal Stephenson writes a GPL-licensed book that includes the standard but modified by an evil megacorp for nefarious purposes? If that is allowed, then I have no problem with this license. Also, I noticed on the page you referenced the summary Summary With this as background, the three licenses can be summarized as follows: * Option 1 Broad reuse in software and software documentation to implement the specification, with an explicit field of use restriction. * Option 2 Reuse of reasonable portions in software and software documentation to implement the specification consistent with good engineering practices, with no field of use restriction thereafter. * Option 3 Broad reuse in software and software documentation to implement the specification, with an implicit field of use restriction. If they believe that, then Option 3 is incompatible with the DFSG and the GPL. Cheers, Walter Landry wlan...@caltech.edu -- 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/20110428.072728.1952855615795842695.wal...@geodynamics.org
Re: Question about GPL and DFSG Compatibility of a Proposed Amendment to the W3C Document Licence
Francesco Poli invernom...@paranoici.org wrote: On Thu, 28 Apr 2011 07:27:28 -0700 (PDT) Walter Landry wrote: Option 2 [...] I would say that this option fails the DFSG because it only allows copying and modification of reasonable amounts. Agreed, again. It would also be incompatible with the GPL, I think it is indeed GPL-incompatible, as you say, but... so I do not understand why Eben Moglen would say that it is compatible. ...as far as I understand, Eben Moglen believes Option *3* to be GPL-compatible (see the message that started this thread). Now we are talking about Option 2. Actually, in the referenced web page http://www.w3.org/2011/03/html-license-options.html there is the claim Views within the PSIG differ on how each license satisfies each use cases. The primary sources of disagreement relate to one's view of the following: * the GPL-compatibility of a license. Note: Eben Moglen has stated that he considers Options 2 and 3 to be GPL-compatible. Cheers, Walter Landry wlan...@caltech.edu -- 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/20110428.103336.2267662035371215801.wal...@geodynamics.org
Re: NASA Open Source Agreement
Paul Wise p...@debian.org wrote: Firstly, it would be much better if they used an existing, well-understood free license rather than reinventing the legal wheel. Indeed. I believe the French government standardized on CECILL, which can be trivially converted to GPL. Secondly, I was under the impression that all US Government works are supposed to be public domain, under what circumstances is this license used? The US Government often acquires copyrighted code from contractors. There is actually some verbiage in this license about that (Section 3B). As for the license, the only troublesome section I found is the one mentioned (3G) G. Each Contributor represents that that its Modification is believed to be Contributor’s original creation and does not violate any existing agreements, regulations, statutes or rules, and further that Contributor has sufficient rights to grant the rights conveyed by this Agreement. There is an interesting interaction with a different section 3I I. A Recipient may create a Larger Work by combining Subject Software with separate software not governed by the terms of this agreement and distribute the Larger Work as a single product. In such case, the Recipient must make sure Subject Software, or portions thereof, included in the Larger Work is subject to this Agreement. So if you combine things together, then it does not have to be an original creation. It seems that the only time that 3G comes into play is if you modify existing code. So if your friend makes a modification, you can not pass off that modification as your own. Essentially, copyright notices have to be correct. However, it is awfully confusing, and I am not certain that my analysis would be compelling in court. I worry a bit more about the words does not violate any existing agreements, regulations, statutes or rules which means that you can not do anything against the law. So dissidents in Cuba could not modify NOSA code to get around the censorship. I would think that the US Government would not want to give Cuba more tools for oppression. As for Debian, I do not remember what decision the Debian FTP masters made about these types of clauses. In any case, it would be a million times better for NASA to reuse an existing license. Cheers, Walter Landry wlan...@caltech.edu
Re: Providing source for .iso files downloaded using bittorrent
Marcelo E. Magallon mmaga...@debian.org wrote: Now, back to the Debian case, Bradley seems to think that providing a method to download the source (e.g. apt-get source) is not enough. If I understand it correctly, he's saying we must do something extra to comply with GPLv2§3: a) provide the source *in* the .iso; b) provide a written offer and all that; or c) show that we have a written offer from upstream. a) is not going to happen, we don't have c) in the general case so b) it is (from his point of view). I do not think that Debian, itself, has any problems. The GPL says If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. Debian distributes both the source and binaries from its worldwide mirrors. Even though it may be technically more difficult to get the source, Debian is still distributing the source from the same place (Debian mirrors). The case for the Bittorrent users, on the other hand, is less clear. Since the users are dependent on the Debian tracker, you could argue that they are merely acting as agents of Debian. Anyone setting up their own tracker would have to distribute both binary and source. Cheers, Walter Landry wlan...@caltech.edu -- 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/20110424.175408.534319940737453550.wal...@geodynamics.org
Re: scientific paper in package only in postscript form non-free?
MJ Ray m...@phonecoop.coop wrote: Francesco Poli wrote: [...] It's true that there's no clear definition of the term source code in the DFSG text, but the most accepted definition of source in the context of Free Software has been the one found in the GNU GPL, for quite a long time. Are you sure it's the most accepted? I didn't find numbers on it. I have been on this list for a decade, and I have not seen any other definitions that have any significant support. Perhaps other forums have different makeups, but on debian-legal I have not seen any other cohesive approaches. I have seen plenty of people say things like it is POSSIBLE to modify it, therefore it is source. But that makes the source requirement a no-op. This is in contrast to, for example, which licenses people prefer. Some people prefer GPL, some prefer MIT, some prefer BSD, etc. Cheers, Walter Landry wlan...@caltech.edu -- 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/20110316.091951.170313769160757168.wal...@geodynamics.org
Re: Bug#570621: Parsing output = derivative work?
Miriam Ruiz mir...@debian.org wrote: In general, I wouldn't consider parsing the output of another program to de a derivative work. In general, I do agree with Miriam that parsing the output of another program does not make a derivative work. But just to give an example of where it does happen, git is largely comprised of many small utilities that communicate over pipes and command-line arguments. Cheers, Walter Landry wlan...@caltech.edu -- 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/20110308.092322.148477719412830956.wal...@geodynamics.org
Re: Ubuntu trademark non-free?
Jordan Metzmeier titan8...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I had been looking at this bug for a few days now as well the the Ubuntu Trademark Policy [1]. I am not a legal person, so I would like to bring it to the attention of people who are, to see if this policy makes the application non-free in its current state. The statements that stands out to me are: We reserve the right to review all usage within the open source community, and to object to any usage that appears to overstep the bounds of discussion and good-faith non-commercial development. and Restricted use that requires a trademark licence Permission from us is necessary to use any of the Trademarks under any circumstances other than those specifically permitted above. These include: - - Any commercial use. This makes it clearly non-free. It is best to just replace anything trademarked by Ubuntu. Cheers, Walter Landry wlan...@caltech.edu -- 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/20100810.135059.487047624931241340.wal...@geodynamics.org
Re: About the licensing of URW Garamond No. 8
Rogério Brito rbr...@ime.usp.br wrote: Hi, Walter and other people. On Apr 13 2010, Walter Landry wrote: Re: Software Licence for URW Garamond Fonts To whom it may concern, I am a software developer associated with the Debian project [1], an association of individuals who work together to create a free operating system. I am interested in including the URW Garamond fonts in Debian. Including them in Debian would make them easily available on multiple mirror worldwide, showcasing the excellent work you have done Just a question: is mirror in multiple mirror worldwide be written in singular or in plural form? Sorry. My mistake. It should be multiple mirrors worldwide. Cheers, Walter Landry wlan...@caltech.edu -- 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/20100421.062617.497362439094414722.wal...@geodynamics.org
Re: [Pkg-fonts-devel] About the licensing of URW Garamond No. 8
Khaled Hosny khaledho...@eglug.org wrote: On Thu, Apr 15, 2010 at 07:20:30PM -0700, Walter Landry wrote: Nicolas Spalinger nicolas_spalin...@sil.org wrote: BTW one of the goals we have in the Debian fonts team is to work to reduce the big duplication of fonts in various packages in our archive: there is no absolute need for every single piece of software to ship with its very own set of fonts... Sometimes it does but from a Debian perspective IMHO a dependency is much nicer. There is a lintian check for this too. I do agree that GPL-compatibility is great and very desirable but fonts have a different set of requirements corresponding to their special status and usage scenarios. Somehow, everyone thinks that they are special and therefore they deserve annoying license terms. We had this debate on debian-legal before with the LPPL. I am sure we will have it again. I still have zero sympathy for this view. Certainly, there are special cases that GPL can't cover, no matter how I like GPL, it isn't the cure of every issue. If the special case is that you want to add annoying clauses, then, yes, the GPL can not help you. Generally, though, one of GPL, LGPL, or MIT/Expat usually fits with people's desires. Sometimes, you have to add exceptions to the GPL, but you never have to add restrictions. and of course the trouble with defining what font sources are and how to properly satisfy the GPL requirement in this context. There has been ample discussion on this topic on debian-legal for years. This is not actually difficult to figure out. For some reason, people think it is, but it is not. If you do not want a source requirement in the license, then you do not really want a copyleft license. Otherwise, the copyleft becomes almost, but not entirely, useless. The issue is, what to be consider as source for fonts? One working with FontLab would consider the FontLab file as source, but it is a proprietary binary format of no use without FontLab, actually the generated fonts is much more usable as source than it. If changes to the font are made by modifying the FontLab file, then the FontLab file is the source. Just because FontLab is proprietary does not mean that the source is not FontLab. If the fonts are changed by editing the generated fonts, then the source is the generated fonts. See. That was not so hard. Cheers, Walter Landry wlan...@caltech.edu -- 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/20100416.072314.579529036175573661.wal...@geodynamics.org
Re: [Pkg-fonts-devel] About the licensing of URW Garamond No. 8
Nicolas Spalinger nicolas_spalin...@sil.org wrote: Walter Landry wrote: Nicolas Spalinger nicolas_spalin...@sil.org wrote: Hi Walter, There are obviously varying needs and preferences (prejudices?) along the licensing spectrum but IMHO your reply is very reductive. At the end of the day upstreams make up their own mind about how they license their own creation but allow me to explain the reasoning of the OFL model a bit more: I understand that many font designers want to put in annoying license terms. I really do understand that. In fact, there are many regular software developers who want to put in annoying license terms for their programs. Debian does not encourage these annoying terms for programs, and Debian should not encourage annoying terms for fonts either. IMHO you are misunderstanding what I was trying to say: this was more of a general comment to describe our own views not just that of some particular upstreams: there is a spectrum of community-validated licenses (I mean DFSG/FSF/OSD compliant ones) and people have different preferences for various parts of the spectrum and it's fine. One license does not fit every single need or approach otherwise we'd all be using the same which is obviously not the case. How people interact with upstream and make relicensing recommendations reflects that is all I'm saying. This whole discussion is about what license should be suggested to upstream. You want to suggest a license with annoying terms. I want to suggest a license without these annoying terms. Regardless of what license is suggested, if upstream decides to use OFL, then it can go into Debian. This is not ideal, in the same way that someone choosing the Q license is not ideal. The years of OFL research and community review have given birth to a nexus between the needs of two very different communities: type designers and the FLOSS communities. We have also pushed back on various unreasonable expectations from font designers to find an acceptable middle ground which the FSF, the Debian ftp-masters and OSI have validated. Having a common community-reviewed-and-validated license designed especially for fonts and to which the actual font design community has given input and now recognizes greatly helps in reducing licensing proliferation. Personally I am also very much in favour of Debian and other major community projects pushing back on software developers who put unreasonable requests on their licensing terms to the detriment of users. Believe it or not but some designers actually want to do the right thing by contributing and benefiting from a libre software approach, there's just such a huge cultural gap to cross and a maze of crazy licenses full of programmer jargon that they very rarely get anywhere. A font-specific license helps tremendously. Compare the variety and quality of libre/open fonts now available to what we had a few years ago... Just because a lot of people have agreed on an annoying license does not mean that Debian should encourage it. For the GPL imcompatibility, fonts are much more useful aggregated to rather than merged with existing software, possible incompatibility with existing software licenses is not a problem. See http://www.gnu.org/licenses/license-list.html#Fonts I was using the rendered fonts as art. In the US, rendered fonts are not copyrightable (as far as I understand). Elsewhere, the situation is unclear. So how does the rendered art stand wrt. the GPL requirements? It is output or aggregation? The GPL GNU Bison exception discussion all over again? As Khaled has rightly pointed out, the situation is not as unclear as you paint it to be. Especially for jurisdictions where fonts are clearly recognized as software and copyright or case laws have explicit mentions of their special status. Khaled's reply just confirms that there are differing laws in different jurisdictions. That is why it is better to have a good license for the fonts so that I do not have to depend on what a jurisdiction thinks about rendered fonts. You say you needed a GPL-compatible font but what does that mean? I assume you needed a font to bundle with when distributing a piece of software under GPL, right? OFL-ed fonts explicitely allow anyone to bundle. (even with restricted software). OTOH you probably want to recommend an external open font instead by adding a package dependency. You have it backwards. It is the GPL which does not allow incorporating OFL-ed fonts. Not sure I see what you mean here. What about aggregation? I am not aggregating things. It is an integral part of the program. Without the art, the program would not run as surely as if I were missing libc. BTW one of the goals we have in the Debian fonts team is to work to reduce the big duplication of fonts in various packages in our archive: there is no absolute need for every single piece of software to ship with its very
Re: [Pkg-fonts-devel] About the licensing of URW Garamond No. 8
bad. Making a good copyleft license is hard. There are legions of people who have made flawed copyleft licenses. The solution is not to make a new license that is incompatible with everything else. For this particular concern, I fail to see how the GPL font exception could be any clearer. The last sentence of OFL's section 5 is pretty equivalent. And that from a designer perspective there are no name collision protection, no reputation protection, no explicit declaration to derive artwork from the outlines, These are all annoying restrictions that regular software programmers sometimes ask for. They may not conflict with the DFSG, but Debian does not recommend them for regular programs, and Debian should not recommend them for anything else in the archive. and of course the trouble with defining what font sources are and how to properly satisfy the GPL requirement in this context. There has been ample discussion on this topic on debian-legal for years. This is not actually difficult to figure out. For some reason, people think it is, but it is not. If you do not want a source requirement in the license, then you do not really want a copyleft license. Otherwise, the copyleft becomes almost, but not entirely, useless. Also v2 and v3 react differently. The patent clauses could be misunderstood and scare away font designers when they mistake it with design patents... Again, an education issue. The font exception was written way back with not a huge of amount of discussion with font designers and the FSF is still looking for feedback. IHMO using the exception is really an exception considering the increasing body of libre/open fonts we now enjoy. I am still having a hard time finding a GPL-compatible monospaced font... There's plenty of discussions on the open font library mailing-list for example. If you want to contribute to getting this fixed, I recommend you talk to Dave Crossland who has been proposing to tackle this for years... Getting what fixed? I still do not see the real problems with GPL+font exception. Cheers, Walter Landry wlan...@caltech.edu -- 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/20100415.192030.1023635395894569686.wal...@geodynamics.org
Re: ms-sys contains MBRs which are copyrighted by Microsoft
Gunnar Wolf gw...@gwolf.org wrote: leorolla dijo [Thu, Apr 01, 2010 at 06:23:59AM -0700]: For security reasons it could perform a checksum verification to protect the user from a corrupt or virus-infected backup file. So the simple changes in the source would be: * remove the problematic file from the source code * change the source code to -look for a 446-byte file with a specific filename -if absent, produce error message explaining what the user is supposed to do and exit -perform the checksum verification -if fails, produce appropriate error message and exit -copy the file to the mbr (Is it also be copyright violation to distribute checksums along with the program? In this case, add look for the presence of a checksum file with a given name etc; if absent, produce an error message telling the user to copy it from a trusted source etc and exit.) Humm... and given the search space is just giant (and not mindboggingly huge), you could even add a loop that generates a random 446-byte-long content until it matches the md5sum and the sha1sum for said file? The math does not work. The search space is still too unfeasibly large. There are 2^(8*448) different combinations. You will find a collision in md5sum first, though the sun would have burned out long before the loop completed. Cheers, Walter Landry wal...@geodynamics.org -- 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/20100414.163703.914206309142954568.wal...@geodynamics.org
Re: About the licensing of URW Garamond No. 8
Rogério Brito rbr...@ime.usp.br wrote: P.S.: Please, as I am not a native speaker of English, feel free to correct my grammar, style or anything that would improve the text. Here you go. Feel free to ignore any or all of my suggestions. Cheers, Walter Landry Re: Software Licence for URW Garamond Fonts To whom it may concern, I am a software developer associated with the Debian project [1], an association of individuals who work together to create a free operating system. I am interested in including the URW Garamond fonts in Debian. Including them in Debian would make them easily available on multiple mirror worldwide, showcasing the excellent work you have done with your fonts. Part of the criteria for including the fonts in Debian is that they conform to a specific set of guidelines: the Debian Free Software Guidelines [2]. The URW Garamond fonts are currently available under the Aladdin Free Public License (AFPL) [3]. Unfortunately, works licensed under the AFPL do not conform to the DFSG, a fact alluded to in the introduction of the AFPL. Despite that, people have been using, redistributing, and modifying them. Motivated by a desire to create a complete set of high quality fonts for Debian and others, I built upon your work and their work by creating a public repository where I can integrate their changes and create a complete set of fonts [4]. As the project diverges from the original fonts as released by (URW)++, it would be convenient if the fonts could be made available under a license that is compatible with the DFSG. This would make it easier to attract contributions and distribute the result. We can, of course, make the fonts available under a different name and fully acknowledge that the initial work was done by (URW)++. We can also refer people to your commercial fonts, make it clear that the project has only been based on your initial release, and that it does not reflect the designs of (URW)++. As a suggestion, it would be simplest if you chose a new license that is already widely used and understood. If you want to release it with minimal restrictions, then the most straightforward license would be the MIT license [5]. If you would like all modified versions of the font to remain free, then using the GNU GPL with a font exception would be preferred [6]. If you have any questions, please do not hesitate to contact me. Thank you, Rogério Theodoro de Brito Debian Project Maintainer, Member of the Fonts Packaging Team Instructor of Computer Science, Univ. Mackenzie, São Paulo, Brazil [1] http://www.debian.org [2] http://www.debian.org/social_contract#guidelines [3] http://www.artifex.com/downloads/doc/Public.htm [4] http://git.debian.org/?p=users/rbrito-guest/urw-garamond.git [5] http://en.wikipedia.org/wiki/Expat_License [6] http://www.gnu.org/copyleft/gpl.html http://www.gnu.org/licenses/gpl-faq.html#FontException -- 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/20100413.224608.629041793913682650.wal...@geodynamics.org
Re: Does this license meet DSFG?
Ben Finney ben+deb...@benfinney.id.au wrote: Dererk der...@debian.org.ar writes: 4. You may use, modify, and redistribute the software under a modified version of the GPL version 3 (or, at your option, a modified version of any higher-numbered version of the GPL) The GPL explicitly forbids modification of the license terms: Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. So I think it's misleading to refer to “modified versions of the GPL”, since modified versions aren't the GPL any more. If you want to permit an action in a license text, it would be best to be clear on what action it is you're permitting. Not quite. You just have to take out the preamble and modify the instructions for use. http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL You can still call it a modified version of the GPL. Cheers, Walter Landry wlan...@caltech.edu -- 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/20100409.202825.38538952185178.wal...@geodynamics.org
Re: Distribution of media content together with GPLv2 code in one package?
Steve Langasek vor...@debian.org wrote: On Mon, Apr 05, 2010 at 12:22:53AM +0200, Francesco Poli wrote: However, it is my opinion that works with unavailable source do not comply with DFSG#2, regardless of the license. Your opinion is not relevant. The text of the DFSG is what's relevant, and the text says that *programs* must include source code, not arbitrary non-program works distributed in Debian. That was voted on 2004 and Debian decided that you are incorrect. It is time to move on. Cheers, Walter Landry wlan...@caltech.edu -- 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/20100404.201126.1081618717981130828.wal...@geodynamics.org
Re: Distributing Debian derivative
David Given d...@cowlark.com wrote: On 2010-03-22 15:14, Paul Wise wrote: In any case, some of the software you are distributing will be GPL, so you'll need to also distribute source code. How do Debian derivatives such as Knoppix or Elive do it? AFAIK, they don't distribute the source code for unmodified packages themselves, instead referring people to the Debian servers. Is this legal or is it just that nobody's complained yet? 7 years ago, Klaus Knopper posted to this list [1] Klaus Knopper le...@knopper.net wrote: May I quote from the written offer, that is included on every Knoppix-CD in the KNOPPIX directory: Since this is a genuine open source project, subject to the GNU General Public License, the source code for the KNOPPIX-specific packages is available via the Internet at http://www.knopper.net/knoppix/sources/. You may find the sources for the installed Debian packages on the various Debian mirrors. Additionally, you can order the sources directly from Knopper.Net for the cost of material, copying, packaging and postage. This offer is valid for 3 years, counting from the build date of this CD-Rom. Regards -Klaus Knopper I do not know anything about Elive. Cheers, Walter Landry wlan...@caltech.edu [1] http://lists.debian.org/debian-legal/2003/04/msg00402.html -- 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/20100322.090658.579529027719855103.wal...@geodynamics.org
Re: EPL + LGPL compatiblity?
Pablo Duboue pablo.dub...@gmail.com wrote: Hi, We seek some advice regarding #572982 [1] (azureus, a well-known torrent client, combines source licensed under incompatible licenses). From Niels quoted sources, there is no doubt about the incompatibility of GPL and EPL. But LGPL and EPL might be a different matter and Google has proved quite unfriendly on this regard. I think that the LGPL v3 is compatible with the EPL. The LGPL allows you to convey combined works as long as you can recompile the LGPL parts. Since we have the source for everything, this is not a problem. Cheers, Walter Landry wlan...@caltech.edu -- 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/20100309.043452.761058721790309809.wal...@geodynamics.org
Re: ISDA CDS Standard Model Public Licence v0.1
Convention on Contracts for the International Sale of Goods is expressly excluded. Any law or regulation which provides that the language of a contract shall be construed against the drafter shall not apply to this License. Choice of law and venue. Yucky. The QPL has it (see, for example, deal.ii), so ftpmasters must think it is ok. I do not know of any analogous loser pays provisions in any licenses in main. Cheers, Walter Landry wlan...@caltech.edu -- 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/20100214.000843.912413905944212857.wal...@geodynamics.org
Re: opencascade license in squeeze
cristian paul peñaranda rojas p...@kristianpaul.org wrote: Hello, I was checking opencascade in lenny was in non-free, but in queeze is in main-free now :D So i guess the new license is okay with debian legal and free sofware, but can anyone in shorts word explainme why please :) From the changelog at http://packages.qa.debian.org/o/opencascade/news/20090307T154958Z.html * Upstream replaced Triangle by a free implementation, thus external-triangle.patch is removed as well as dependencies against libtriangle-dev. * Remove ros/src/FontMFT/*.mft files, these font files have no sources. (As a side effect, closes: #487116) * All non-free bits have thus been removed, and opencascade is moved from non-free into main. The license was never really an issue. There was an explanatory note which contradicted the license and seemed to add non-free terms, but that is not the license. Cheers, Walter Landry wlan...@caltech.edu -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
