Re: License question about sf2 soundfont in Tuxguitar
>From my personal experience of 15+ years contacting with authors of thousands of "free" sound fonts: they are usually composed of sounds taken from random places, and nobody really knows who made them or what their license are. Many of them take samples from other "free" sound fonts, and chain gets larger and larger so the true origin is difficult to trace. The assemblers of the sound fonts just assume that, if they can't find a copyright notice attached to the samples, they must be in the public domain. And most likely they are not. Even if they were originally released under a permissive license, the license and authors should be maintained as a minimum. Of course, there are exceptions of sound font assemblers who correctly document their sources and licenses of each individual sample, but that's a lot of work, and most common case is just to ignore everything and assume that it will be fine. It's the true and sad state of most free sound sample libraries out there.
Re: Questions about spacet cadet reverse engineering
On Mon, 2 Jan 2023 at 08:36, Stephan Verbücheln wrote: > > They clearly state that they decompiled binaries from Windows XP. This > means it is a /fork/ and *not* a /clone/. > > Since I have not heard that Microsoft has put a permissive license on > those binaries, I would expect that the restrictions of the original > binary apply. > It may be worth asking Microsoft to release that software with an open-source license or at least the binaries with a permissive license that allows redistributing those files to the reversed-engineered compiled binary to use them. After all, they did not distribute with Windows anymore, so their profit over that software is currently zero and they have nothing to lose about it. Best regards, R-
Re: GeForce nvidia driver license for commerical use?
Il giorno lun 3 ott 2022 alle ore 21:50 Simon McVittie ha scritto: > > On Mon, 03 Oct 2022 at 21:12:50 +0200, Roberto A. Foglietta wrote: > > Are you referring to the special permission given by e-mail by Donald Randall > > in 2003? > > I think you're misreading the copyright file. Randall Donald is a Debian > contributor who asked Nvidia for permission to redistribute their driver, > and got a reply (which is quoted in the copyright file) from someone > named Andy. > Thanks Simon for this clarification but it is not enough yet and I will quickly explain to you why. Could you bring to our attention the original e-mail or the name/e-mail address of Andy working for nVidia, please? Because the e-mail address rdon...@debian.org does not exist anymore and he does not reply by Linkedin. I personally spoke with a USA nVidia manager about licensing in a video conference call and he assured me that the only way to legally receive the nVidia software is downloading from their website. Moreover, he was acknowledged that the aim was to use Debian. It might happen that everybody in the two teams was wrong but why not suggest to rely directly on Debian, then? It would have been great. Best, R- P.S.: forget the other email without the reply to the m-list, thanks.
Re: GeForce nvidia driver license for commerical use?
Il giorno lun 3 ott 2022 alle ore 20:42 Simon McVittie ha scritto: > On Mon, 03 Oct 2022 at 19:52:23 +0200, Roberto A. Foglietta wrote: > > reading this link here below, it seems that compilation and repackaging > the > > content is prohibited by their license. What's your opinion on this? > > Please note that the Debian maintainers of nvidia-graphics-drivers have > received special permission from Nvidia beyond what is allowed by the > license in the .run archive. Please see > > https://tracker.debian.org/media/packages/n/nvidia-graphics-drivers/copyright-510.85.02-2 > (or equivalent for other versions) for details. > > If you plan to repackage this driver outside Debian or distribute it > commercially, you will need to talk to Nvidia directly, or obtain your > own legal advice. > Thank you Simon for the prompt reply. Are you referring to the special permission given by e-mail by Donald Randall in 2003? Randall Donald http://www.khensu.org rdon...@debian.org https://www.linkedin.com/in/randalldonald/ On which Linkedin profile is reported a volunteer activity as external for NVIDIA Volunteering Debian Developer and Archive MaintainerDeveloper and Archive Maintainer Jan 2001 - Jan 2010 · 9 yrs 2 mosJan 2001 - Jan 2010 · 9 yrs 2 mos Science and Technology Debian developer most notably responsible for leading the NVIDIA packaging team. 2001 - 2010 Please, could you explain to me how a company external voluntary could have delivered a legally binding permission? Best regards, R-
GeForce nvidia driver license for commerical use?
Hi all, reading this link here below, it seems that compilation and repackaging the content is prohibited by their license. What's your opinion on this? https://opensource.stackexchange.com/questions/10082/geforce-nvidia-driver-license-for-commerical-use In fact, up today (515.76) the .run archive that contains the driver and the CUDA libraries is licenced in a way for which two essential operations are not permitted: §2.1.2 does not allow the compilation essential for deliver a binry driver §2.1.3 does not allow to repackage the .run content in many .deb packages The license could be found inside the .run archive downloadable from this url https://www.nvidia.com/en-us/drivers/unix Best regards, R-
Re: Hosting the original youtube-dl sources on salsa?
On Thu, Oct 29, 2020 at 11:15:34PM +0100, Dominik George wrote: > The RIAA seems to be targeting the most vulnerable and leat likely to > defend themselves, otherweise they would be targeting those who upload > content violating copyright laws instead on free software maintainers. > > (Also, there is YouTube Premium which allows for downloading any video > ypu like, so in the view of the RIAA, why is that acceptable?). I think that the issue is *not* about content uploaded to youtube without permission. Youtube has licensed music, for example try to search for any famous song, like Bohemian Rhapsody. There are official music videos and many unofficial ones uploaded by personal accounts, both of them are legally permitted because the music is licensed by YouTube. You can see that the unofficial videos also contain a notice in the description that says "Licensed to YouTube by ..." and a list of music publishers and copyright holders. YouTube is paying for those permissions, and the money comes from 1) ads on normal YouTube or 2) subscriptions on YouTube Premium. YouTube Premium users have permission to download the music as well (for their personal offline use) because they are paying to the music rights societies, in a similar way that other companies like Spotify are doing. RIAA sees youtube-dl as a software that allows people to access their licensed content with the same privileges as their paying users, but without paying. And that's why the DMCA enters here, because youtube-dl is seen as a software that allows "circumvention of technological barriers for using a digital good in certain ways which the rightsholders do not wish to allow" [1] [1] https://en.wikipedia.org/wiki/Anti-circumvention I personally was very upset about the takedown of youtube-dl, I just want to clarify a bit what is this issue about.
CC-BY 4.0
On Mon, Jun 15, 2020 at 10:13:30PM +0200, Francesco Poli wrote: > I asked the FSF to publish a reasoned analysis on this. > I did so back in 2015, but nothing has been disclosed yet (as far as I > know). :-( > > I am personally *not* convinced that CC-by v4.0 is GPL-compatible. I think that being picky about licensing issues is a good thing. In this particular case, it's going to require quite an effort to counterweight the common opinion when Debian FTP masters, the FSF and Creative Commons' lawyers say that there is no problem, but if you are reasonably convinced that something is not right, I would encourage you to continue writing to FSF for the detailed analysis. I'm using Creative Common licenses quite extensively on several projects, so the analysis will interest me a lot.
Re: Maxmind GeoIP/Geolite license change
On Mon, Jun 15, 2020 at 08:04:47PM +0200, Francesco Poli wrote: > The reason is that the one-way compatibility mechanism of CC-by-sa v4.0 > is not exceptionally clear, and, without that compatibility, the > CC-by-sa v4.0 license itself has a number of controversial clauses > (non-free, in my own personal opinion). CC-BY 4.0 (without SA) may be better than CC-BY-SA in that case, according to the FSF it's compatible and accepted as a free license (for content which is not a program).
Re: Stack Overflow and copyrightability of small snippets
I want to thank you for your research and bringing up this issue. From now I will start looking for those snippets in the software projects that I'm participating, as I find them worrysome in some particular cases, indeed.
Re: Transity: GPL-licensed but Free only for Non-Commercials
There was a similar case with LinuxSampler a few years ago, restricting *use* of the program in commercial applications. It was removed from Debian and it was concluded that its license is inconsistent, nobody can actually comply with it, because the GPL and the added restriction contradict each other. It was also rejected from non-free (undistributable software). https://lists.debian.org/debian-legal/2005/09/msg00271.html
Re: upstream changing from GPL-2+ to GPL-3+ without copyright holders permission
On Tue, Aug 06, 2019 at 09:18:23AM +0200, Florian Weimer wrote: > Many authors provide conflicting license statements. It's not > unusual. In the extreme case, it makes the software undistributable > and unsuitable for Debian. I know, conflicting statements are a serious problem. But that's a different issue. > > > If those unwritten exceptions are common, I've probably violated > > authors' whises a lot of times already :( > > I was mainly talking about written clarifications, not unvoiced > thoughts of the authors. Then I agree, written clarifications should be followed if possible. But, if those clarifications are not part of the license, and they are only suggestions, authors should be completely fine when they are ignored. If they are not, they must be part of the license, otherwise I consider it lying on the actual distribution terms, and it is unfair. Vim editor says: "Vim is Charityware. You can use and copy it as much as you like, but you are encouraged to make a donation for needy children in Uganda". It is not part of the license, so Vim is included in Debian. And it seems to me that very few users of Vim are actually doing that, but it should be fine since it's only a suggestion (I hope). There are religion-based statements in music software included in Debian, that I choose to not follow because it will be against my own convictions. I hope the author is fine with that, otherwise I will consider the program non-free and start writing bug reports for those programs to be removed from Debian.
Re: upstream changing from GPL-2+ to GPL-3+ without copyright holders permission
On Mon, Aug 05, 2019 at 11:37:22PM +0200, Florian Weimer wrote: > In general, I agree. But there might be cases that are less > clear-cut. For example, if the upgrade from GPLv2+ to GPLv3+ is used > to gain permission to combine the work with an AGPL work, especially > if this is done in an “open core” context. Or if the author clearly > intended that uploading the original (GPLv2+) work to someone else's > computer was distribution under the GPLv2 terms, and the GPLv3 upgrade > is used primarily to circumvent that. I don't understand that. If the author provides written permission to upgrade to a later version but he don't really want people to do that, it looks to me like lying. He should either clarify the cases where the upgrade is not wanted, or avoid writing those permissions at all. > I also think that in general, Debian should try to respect copyright > holders' wishes, even if the project is not required to do so. > Disregarding authors rarely leads to good outcomes. I would want to be respectful, of course, but how can I respect copyright holders' wishes when they say something and want something different instead? I can't read their minds. It's not feasible to ask all authors when there are hundreds (and I don't even consider it fair, it won't pass the desert island). If those unwritten exceptions are common, I've probably violated authors' whises a lot of times already :(
Re: FRR package in Debian violates the GPL licence
On Tue, Mar 19, 2019 at 02:22:08PM +, Paul Jakma wrote: > 3. People took the code of (2), and adapted that code - extensively and >explicitly - to make use of and rely upon the facilities of the code >of (1); facilities which were missing in the code of (2). > > The people involved in (3) - Linux Foundation, Cumulus Networks, 6WIND, Big > Switch Networks, etc. - refuse to acknowledge the legal reality that the > code of (3) is covered by the GPL licence of the code of (2), and refuse to > honour the conditions required by the GPL - see David Lamparter's mail. Well, that's more complicated than I've thought. Under my point of view, those companies are right, sorry to say that.
Re: FRR package in Debian violates the GPL licence
On Sun, Mar 17, 2019 at 02:08:38PM +0100, David Lamparter wrote: > The respective original authors have expressed and reaffirmed their > wishes for the code to remain under a permissive license. While we > could obviously just slap GPL on top, we have decided to try and honour > the original author's requests. Indeed, when including external libraries/files into a software project, I was always encouraged to contribute my changes under the same license of each individual part, for polite reasons. So, I am somewhat puzzled about this issue. On the other side, if I understood correctly, there are authors who want to contribute their code under GPL exclusively, and they feel that some of their changes got included into the bundled libraries (and are significant enough to be covered by copyright), so those libraries should be wrapped by the GPL as well. Maybe those external libraries should not be imported in the first place, to respect all authors' wishes seems imposible when they are mutually exclusive, and that's looks "murky" even if allowed by the license.
Re: JPL Planetary Ephemeris DE405
On Mon, Feb 26, 2018 at 10:16:49AM +0100, Ole Streicher wrote: > As far as I know, there is no extension agreement with the US. So, JPL as > the database maker cannot protect the database by article 7. > > Also, the protection in article 7 expires after 15 years (article > 10). The databases DE200 and DE405 are however created 1981 and 1998; so > they cannot be protected on this base. This is indeed a useful response that I was expecting, thanks.
Re: JPL Planetary Ephemeris DE405
On Mon, Feb 26, 2018 at 09:03:56AM +0100, Ole Streicher wrote: > The directive is about database protection, not (only) about > copyright. It mainly shows *two* independent possibilities how database > are protectable: > > 1. Copyright protection: By accounting the creativity to produce the > database; this is article 3, and this is done by applying a > copyright. The article actually *limits* the reasons why a database can > be copyright protected, by specifying an exhaustive list (selection and > arrangement). Every database that does not follow this rules is not > copyright protected according to the directive. > > 2. "Sui Generis Right": By accounting the investment to create the > database. The directive allows (resp. requests from the EU countries to > allow) to protect this investment. This protection is however *not* > copyright protection. A database that was created with substantial > investment but without creativity in selection or arrangement is still > not protected by copyright, even when the maker decides to protect it > under article 7. The Spanish LPI declaration included both in the copyright law. Well, actually is more complex than that, because if you read the article in BOE document, there is not a single reference to the word "copyright" there, instead, it refers to modifications to the LPI law. The LPI law is the document that defines how copyright protection works inside Spanish legal jurisdiction. Maybe they have a different interpretation, or they made a mistake including those terms there. In both cases, we would need more than good luck to convince government to change it, and currently, copyright it's beign used end enforced in all those cases, in spite of how much you disagree.
Re: JPL Planetary Ephemeris DE405
On Sun, Feb 25, 2018 at 01:47:51PM +0100, Ole Streicher wrote: > Your other argument (with article 7) has nothing do do with copyright: > even when this article applies to a database, it is still not > (necessarily) copyright protected. Article 7 just claims that the maker > of a database *may* protect his work; but as long as he does not do > this, there are no restrictions. This is the opposite to copyright, > where the default is restrictive and the copyright owner may grant you > rights. And it also is possible only for 15 years. I'm not sure if I'm not understanding what you mean correctly. The Directive is not a modification to copyright, but EU member countries modify their copyright laws to include those protections. Each country have its local laws. In Spain, the copyright law it's not even called "copyright", it is called the LPI, but the word "Copyright" is still recognised for compatibility with the Berne Convention. The declaration has many differencies with the US definition of copyright, for example, definition of "fair use" is not compatible, the "public domain" concept doen't even exist (though it is usually considered safe to import and use public domain works from countries which do define it), and thousands of other differences. So, it's easier to refer to the text of the Directive directly rather than to individual copyright declarations for each country under their own legal jurisdiction. I think that's what is confusing you into thinking that it is nothing to do with Copyright (or maybe I'm not understanding your point, I'm not sure). I hope it's more clear now. The modification of Spanish copyright declaration was published on "BOE", which is the official document that informs about those changes. It was recorded in BOE-A-1998-5568, it's in Spanish but if you feel interested you can search it online at http://www.boe.es/ and translate it (hopefully the translator don't mess too much with it, law articles are writen in a very specific form). All requirements of the database directive has been included into the Spanish copyright law. So well, I don't understand why you say that it has nothing to do with copyright, sure it does. If you read the Spanish LPI with its modifications, you'll see that a database or collection of things can now be copyrighted (and actually it is automatically copyrighted and protected like any other work). The copyright law is extended so it includes all those provisions required by the database directive, including the protection of collections of works that are factual, non-artistic, non-creative, when the creator of the colletion has invested time and/or effort in the validation process, etc... I personally think that the choosen wording provides even more than required by the database directive, which makes easier to claim copyright for trivial things wrapped into databases, unfortunately. Yes, there had been opposition, specially at first, but time has passed and the modified copyright law is still being used (and abused). It seems that you don't believe me when I say that I've seen databases of trivial things beign enforced, and that's fine, not trusting random persons over the Internet is OK. Writing in English takes a long time for me so please excuse me if I don't continue to explain how copyright works in my country. If you want to research and see it by yourself, you are welcome.
Re: JPL Planetary Ephemeris DE405
On Sat, Feb 24, 2018 at 10:51:55PM +0100, Ole Streicher wrote: > I read that article 7 that you cited as: the maker of a database has the > right to protect it -- which however needs him to be active (which is > not the case for the JPL). Okay, feel free to include databases of facts in Debian if you think it's safe, I'll feel free to blacklist those packages, and everyone is happy. In this particular case, it may be safe, I don't know the JPL database, and it seems that it cames from the US. My email was to disagree with your statement that a collection of facts can't be copyrighted. The Directive is a document that members of EU need to comply by modifying their local laws (usually by amending copyright laws), which, to make things more complicated, the exact terms vary between each EU member. If you are still convinced that it can't be copyrighted and they are safe, well, there is nothing more that I can say, go ahead and use them. For my part, I've seen a case of copyright sucesfully applied to a completely automated list of facts, and that's enough for me to be convinced of the opposite. I still think that recommending them for inclusion in Debian without properly analyzing each case and the author intents, It seems that you know the directives in EU (I though at first that you were not aware of them), and you still defend that they are safe, which is fine, you are free to have your opinion. I'm still thinking that not taking seriously the database laws, and including them in Debian without properly analyzing each case and author intents is quite unfortunate, though.
Re: JPL Planetary Ephemeris DE405
On Sat, Feb 24, 2018 at 02:03:44PM +0100, Ole Streicher wrote: > Sure; law is always open to be interpreted by the court. This is > generally true and not specific to this case. Yes but, what I want to say is that, in this particular case, I don't think it's safe to assume that a collection of facts can't have copyright, not even when it's entries are selected by objective criteria. Let's quote the Directive No. 96/9/EC: Article 7 Object of protection Member States shall provide for a right for the maker of a database which shows that there has been qualitatively and/or quantitatively a substantial investment in either the obtaining, verification or presentation of the contents to prevent extraction and/or re-utilization of the whole or of a substantial part, evaluated qualitatively and/or quantitatively, of the contents of that database. [...] Notice that database creators can argue that they have made a "substantian investment in verifying the contents" to justify their database protection. It's not needed to have made an effort in manually selecting entries (yes, that's another way to have a database protected, but not the only one). I'm worried that this is not taken seriously because it has been used plenty of times already, and the way the directive is written is quite biased toward creators of databases as far as I can tell in my opinion. The only exceptions given are those in the Article 6, in short: for private, scientific research, or non-commercial purposes.
Re: JPL Planetary Ephemeris DE405
On Fri, Feb 23, 2018 at 11:41:37PM +0100, Ole Streicher wrote: > That is generally not true for scientific databases: When the entries > are selected by objective criteria (which is the common case for such > databases), the database is not copyrightable. That's open to the interpretation of the judges. Search for previous cases and you'll be surprised. A company that I've worked for was one of such victims.
Re: JPL Planetary Ephemeris DE405
On Fri, Feb 23, 2018 at 09:14:32AM +0100, Ole Streicher wrote: > Then (and may be more important): These files are not copyrightable ad > all, since they are natural data; they describe *facts*. As one can't > copyright the distance to the moon, one can't copyright the details of > earth rotation. A collection of facts can have a copyright even if the facts themselves can not. This is known as the Directive 96/9/EC on the EU. http://www.esa.int/About_Us/Law_at_ESA/Intellectual_Property_Rights/Copyright_and_databases
Administracion y Control de Neumaticos - Maximice la seguridad
Maximice la seguridad para el operador, la carga o pasaje. Curso Básico de Administración y Control de Neumáticos Elija fecha y sede para participar: 22 de Marzo / Monterrey, N.L. 24 de Marzo / Guadalajara JAL. 29 de Marzo / Cd. de México Traemos para usted este seminario en el cual se le proporcionarán las herramientas para la adecuada administración y control de los neumáticos, su uso y cuidado, generando grandes beneficios para su empresa con los cuales mejorará las condiciones de seguridad, rendimiento de combustible, control de daños y optimización de costos. Para recibir nuestro temario responda con la clave Control y sus datos: Nombre: Empresa: Teléfono: Lic. Roberto Quijano, Ejecutivo de Comercial ¡Será un placer atenderle! Comuníquese al: 01.800.212.0746 Este mensaje le ha sido enviado como usuario o bien un usuario le refirió para recibirlo. Si no pertenece al sector y no desea recibir actualizaciones al respecto, debian-legal@lists.debian.org responda con el asunto 6DFVTG3R
Re: is igmpproxy dfsg compliant?
On Fri, Dec 02, 2016 at 06:20:24PM +0100, Pali Rohár wrote: > I'm already in contact with old/original maintainers of igmpproxy hosted > on sourceforge who maintained it until release of version 0.1. > > Those maintainers are not interested in maintaining igmpproxy anymore > and they agreed that I can take over whole igmpproxy project. Currently > I have new repository on github (on old sourceforge project is written > by original maintainers that project was moved to my github repository), > but there is no new released version. That looks better, if you are now the maintainer and previous authors are in contact, seems good. > > 1. As other have pointed, not all BSD licenses are compatible with > > the GPL, it should be examined before assuming it is, if you can > > please paste it to this list so other people can comment. > > Copyright © 2002 The Board of Trustees of the Leland Stanford Junior > University > Permission is hereby granted to STANFORD's rights, free of charge, to > any person obtaining a copy of this Software and associated > documentation files ( "MROUTED"), to deal in MROUTED without > restriction, including without limitation the rights to use, copy, > modify, merge, publish, distribute, sublicense, and/or sell copies of > MROUTED , and to permit persons to whom MROUTED is furnished to do so, > subject to the following conditions: > 1) The above copyright notice and this permission notice shall be > included in all copies or substantial portions of the MROUTED . > 2) Neither the STANFORD name nor the names of its contributors may > be used in any promotional advertising or other promotional materials to > be disseminated to the public or any portion thereof nor to use the name > of any STANFORD faculty member, employee, or student, or any trademark, > service mark, trade name, or symbol of STANFORD or Stanford Hospitals > and Clinics, nor any that is associated with any of them, without > STANFORD's prior written consent. Any use of STANFORD's name shall be > limited to statements of fact and shall not imply endorsement of any > products or services. > > 3) MROUTED IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. > IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY > CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, > TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH MROUTED OR > THE USE OR OTHER DEALINGS IN THE MROUTED . I'm not good at spotting incompatibilities so I hope that other people comment, to me it looks like a variation of the X11 license, AFAIK it is good.
Re: is igmpproxy dfsg compliant?
On Fri, Dec 02, 2016 at 03:53:53PM +, Ian Jackson wrote:
> Pali Rohár writes ("Re: is igmpproxy dfsg compliant?"):
> > On Thursday 24 November 2016 19:29:21 Roberto wrote:
> > > On Thu, Nov 24, 2016 at 06:36:53PM +0100, Pali Rohár wrote:
> > > > And can be included igmpproxy package into Debian?
> > >
> > > Probably asking the authors if they can please switch the license, it
> > > will benefit not only Debian but anyone who downloads from upstream
> > > source as well.
> >
> > So... it is enough if all authors and contributors of igmpproxy agree
> > that their changes can be redistributed under GPLv2+?
>
> Yes.
>
> > Or do they need to "relicense" their changes also under new BSD Stanford
> > too?
>
> No.
>
> Ian.
I would prefer that the upstream does the license transition by
examining the situation and fixing all headers and documentation. They
(hopefully) know better about who modified the files and what licenses
the changes are in each case. Otherwise, even if they give you
permission to switch those files into the new license, each time a new
version of the upstream source is packaged it should be cleaned again by
the debian maintainer, or a notice should be included within
debian/copyright file saying all the references to the non-free license
scattered in the source code are not valid anymore. Neither of those
solutions seem the correct thing.
Two more things to notice:
1. As other have pointed, not all BSD licenses are compatible with the
GPL, it should be examined before assuming it is, if you can please
paste it to this list so other people can comment.
2. Is the change of license of mrouted effective from a specific
version, or are all older versions placed under the new license too? And
in the first case, what version forked igmpproxy from? Can those sources
be upgraded to the first BSD-licensed version?
Again, I think this should be fixed by upstream and only trying fo fix
it in the debian package if upstream does not want to cooperate.
In my experience, when a fork from a program (or library) is included
into another, it can be sometimes very difficult to fix things when the
original project switch to another (possibly better) license. igmpproxy
seems to be easier, but it should be done the correct way anyways.
As an example, it happend when idsoftware gave permission to relicense
Doom source into GPL. I was very active by then trying to sort all
things, but it was painful, with thousands of emails to all people who
modified the original sources. Many engines based on Doom were unable to
make the switch (zDoom, one of the more populars, it is still maintained
under the old non-free license because it will conflict with many other
pieces of code submitted under the older license), and many authors will
actually refuse to switch to the new license or prefer the older (yes,
some people explicitly refused to give permission to relicense their
changes into the new license).
So please, when code is touched by many different people, NEVER assume
that people will agree to a license change, even if the new license
seems clearly better.
Re: is igmpproxy dfsg compliant?
On Sat, Nov 26, 2016 at 12:51:52PM +0100, Pali Rohár wrote: > Yes, but mrouted was release/relicensed under less restrictive BSD > license too. > > As wrote in one of first emails, here is link to text of new mrouted > license: > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/mrouted/LICENSE mrouted relicensed its code, but the igmpproxy fork did not, and they are not the same thing anymore. I've already answered to this in my first email in this thread, please read it again.
Re: is igmpproxy dfsg compliant?
On Sat, Nov 26, 2016 at 12:46:45PM +0100, Pali Rohár wrote: > On Thursday 24 November 2016 20:07:43 you wrote: > > > I do not know, but mrouted was relicensed to BSD in 2003 and > > > igmpproxy started in 2005 (according to year in source files). And > > > because BSD is compatible with GPL, you can relicense those parts > > > to GPL and adds your own GPL code to it. Then whole package can be > > > redistributed only under GPL... > > > > Of course, you can *not* do this. > > Why? I think you must redistribute whole program as GPL. Section 2. of > GPLv2 contains: > > === > But when you distribute the same sections as part of a whole which is a > work based on the Program, the distribution of the whole must be on the > terms of this License, whose permissions for other licensees extend to > the entire whole, and thus to each and every part regardless of who > wrote it. > === > > This does not mean that some parts cannot be still distributed under > other license (e.g. mrouted parts under Stanford or BSD), but from that > section I understood that whole igmpproxy can be distributed only under > GPLv2. That's not what the license says. I know that licensing can be confusing and tedious and I'm not very good at expressing myself in english... please read the official GPL FAQ, it is very good and it may help you to understand better the meaning of the GPL license: https://www.gnu.org/licenses/gpl-faq.html
Re: is igmpproxy dfsg compliant?
On Thu, Nov 24, 2016 at 07:29:21PM +0100, Roberto wrote: > On Thu, Nov 24, 2016 at 06:36:53PM +0100, Pali Rohár wrote: > > I'm not saying that it invalidates. Just that I understood that whole > > igmpproxy can be redistributed under GPLv2+ and some other parts, based > > on mrouted had original license Stanford.txt... and those and only those > > parts (without other GPL) can be redistributed also under Stanford > > license... This is how I understood it. > > OK, I think I understand it better now. We are basically saying the same > thing then, with only one difference. I reply myself... actually I think I have not understood your statements correctly, reading it again it seems that you think that the mrouted code is somewhat dual licensed with GPL or Stanford.txt and you can choose which one to apply. That's not the case, when combined into a GPL program both licenses are active and must be obeyed *at the same time* (supposing that they are compatible, which I doubt).
Re: is igmpproxy dfsg compliant?
On Thu, Nov 24, 2016 at 06:36:53PM +0100, Pali Rohár wrote: > I'm not saying that it invalidates. Just that I understood that whole > igmpproxy can be redistributed under GPLv2+ and some other parts, based > on mrouted had original license Stanford.txt... and those and only those > parts (without other GPL) can be redistributed also under Stanford > license... This is how I understood it. OK, I think I understand it better now. We are basically saying the same thing then, with only one difference. If the original code of mrouted was included bundled in a separate directory unmodified, or easily replaceable, then yes, you could replace it with the new BSD version and then "relicense" all Stanford code under BSD. But, as far as I know, it has been modified and mixed into other product, so in order to change the license of those parts, permission is needed from all of its authors and contributors (which now includes igmpproxy authors because the modifications are also copyrighted by them). That's why in my first email I say that nobody else can switch the license, even if mrouted switched long ago, the forked code is a different program now. Sorry if it was not clear. > So... question now is, can be whole igmpproxy (as one software package) > redistributed under GPLv2+? I think yes that yes. I disagree, I'm not even sure that the Standford license is compatible with the GPL, and even when all licenses are compatible, you should still include all of them in debian/copyright file and should pass the DFSG. That is only my opinion, I would like to read opinions from more people on this list. > Or... if you think that not, what is reason, and what needs to be done? > > And can be included igmpproxy package into Debian? Probably asking the authors if they can please switch the license, it will benefit not only Debian but anyone who downloads from upstream source as well.
Re: is igmpproxy dfsg compliant?
On Thu, Nov 24, 2016 at 05:36:57PM +0100, Pali Rohár wrote: > On Tuesday 22 November 2016 16:17:21 Roberto wrote: > > On Tue, Nov 22, 2016 at 02:42:34PM +0100, Pali Rohár wrote: > > The COPYING file that you linked says "Original license can be found > > in the Stanford.txt file". It says nothing about the BSD license. > > But this statement is under mrouted section in COPYING file. Under > igmpproxy section is written GPLv2+ license. I don't understand this phrase, do you mean that igmpproxy authors relicensed the mrouted source code under the GPLv2+ license? And how if would be possible > > The *.c files also point to the Standford.txt license. > > And again in *.c files is GPLv2+ license with information that igmpproxy > is based on smcroute (licensed under GPLv2) and mrouted which *original* > license was Stanford. And again I'm not sure that I'm correctly understanding you. If you are saying that the GPL somewhat invalidates other licenses and now the code has become GPL because it was mixed with other GPL code then I must disagree. In that case it would be very easy to change any license into the GPL. > Or why do you think that Stanford.txt applies to whole source code? From > COPYING I understood it differently, due to sections in files, and also > because on official webpage is written GPLv2+. No, I don't think that Stanford.txt applies to whole source code. It applies to *part* of the source code, that's what COPYING file says. It is very common for projects to be based on several other projects and combined from multiple licenses, and it is not a problem if licenses are compatible and DFSG-free.
Re: is igmpproxy dfsg compliant?
On Tue, Nov 22, 2016 at 02:42:34PM +0100, Pali Rohár wrote: [...] > Note that smcroute 0.92 was accepted into Debian [4]. > > Due to above GPL facts in igmpproxy files I think that everybody though > igmpproxy is licensed and distributed under GPL. If it was legal and I > correct I do not know... But since 2003 after mrouted got alternative BSD > license I think it is correct to redistribute smcroute 0.92 and so also > igmpproxy under GPL as states in [1], [2], [3]. > > And if Debian really had not problem to include smcroute 0.92 into > archives in 2006 [4] I guess there should not be problem to include also > derivate works from smcroute 0.92 licensed under GPL. The authors of smcroute maybe agreed to relicense the code, but that does not make any other programs based on mrouted automatically relicensed. The COPYING file that you linked says "Original license can be found in the Stanford.txt file". It says nothing about the BSD license. The *.c files also point to the Standford.txt license. There is nothing in the igmpproxy that makes me think that they switched to the BSD license. If you had been in contact with the authors and they gave you a special permission to make the license change, please include in debian/copyright the information or the emails in which they gave you permission to do so, and please don't do it without their full knowledge and approval. > ... Or do you have any other opinion which could cause problem in this > situation? I can't offer legal advice, just saying that according to the information given in the source code of igmpproxy, it seems clear to me that is still distributed under the GPL *and* the Standford license. The code included in igmpproxy has been largely modified and its subject to the copyright of mrouted *and* igmpproxy's contributors, so all of them must agree in order to change the license. (Whether the standford license is DFSG-free and/or compatible with the GPL is a different issue).
Re: is igmpproxy dfsg compliant?
On Sun, Nov 20, 2016 at 02:52:33PM +0100, Pali Rohár wrote: > Because igmpproxy is based on mrouted originally licensed under Stanford > and later relicensed under BSD, I would consider it DFSG compliant... For what is worth, my point of view follows: In general, when a program is relicensed, the new license is not applied automatically to forks and derivative versions. Imagine that I make a GPL program that the igmpproxy developers modify and include into igmpproxy. I later relicense my code to a license incompatible with the GPL; igmpproxy won't automatically switch to the new license unless everyone agree (and probably will never happen because they are fine with the GPL version). If the new license of mrouted is better, we can expect that all developers and contributors will be happy to switch, but it must be done by them, nobody else can switch the license in their behalf unless they give permission. According to the source repository of igmpproxy, it is stil using the Standford license.
Re: Freeware Public License (FPL)
On Fri, Nov 04, 2016 at 07:21:34PM +0100, Francesco Poli wrote: > Hi, > rather than commenting on the several misconceptions and plain false > statements included in the upstream author's answer, I will just > recommend you to reply him something similar to the following: That's an excellent advice, I'm sure that the intention of the author was good, but it will be a waste of time writing lots of emails trying to educate him about copyright laws, it seems much more productive a simple mesage like that, I may use it too as a template when needed.
Re: would this custom license considered DFSG-free/GPL-compatible
On Tue, Oct 04, 2016 at 08:56:22AM -0400, Yaroslav Halchenko wrote: > // 4. If anything other than configuration, indentation or comments have been > //altered in the code, the modified code must be made accessible to the > //original author(s). Fails the Desert Island Test: https://wiki.debian.org/DesertIslandTest
Re: "Use as you wish" license
On Tue, Jul 05, 2016 at 05:45:59PM +0100, Ian Jackson wrote: > This mailing list is purely advisory (if that, even), and has no > formal decisionmaking status. The actual decisions are made and > implemented by the ftpmasters. Some advisory is valuable for me just before I choose to include such files in my project. > If the ftpmasters have accepted this kind of permission statement > before, so many times, then I think we can draw the conclusion that > they are happy with it. I would like to accept that conclusion too, but from previous experience I know it's not always the case (ftpmasters are human too). People tend to blindly accept that everything is OK if entered Debian before, and hence mistakes are never fixed and takes a lot of work to stop the inertia, your answer is a clear example. I hope you did not feel cheated for my omision, but I would have missed your first answer which was truly useful. Next time I won't say that I've searched the source archive :P I have not found any previous discussion about those licenses so asking here seem to be the right thing to do, if that is not the case, can you please point me the correct steps, should I ask ftpmasters directly or there is another mailing list you think more appropiate?
Re: "Use as you wish" license
On Tue, Jul 05, 2016 at 12:50:55PM +0200, Johannes Schauer wrote:
> if the original author of the software really meant "do with it whatever you
> like - really, everything" when they wrote "Use as you wish", then I'm sure
> they will give you a positive reply when you ask them whether it would be
> possible for them to relicense their work under a very simple license like
> MIT/Expat. Just drop the author an email and ask. :)
Thanks, I think it would be the best way, I will do it for the second
case ("may be downloaded and used for any projects, without
restrictions"). There are several contributors and people who modified
things, it can be not easy, but I will try.
The first one ("use as you wish") is already on Debian. To be honest I
must say that I knew that, but I asked anyways to get independent
answers not influenced by the fact that it has been included before.
Some of those notices are really weird, specially the BeerWare one...
http://sources.debian.net/src/freeciv/2.5.4-1/common/scriptcore/tolua_common_a.pkg/?hl=178#L178
http://sources.debian.net/src/cecilia/5.2.1-1/Resources/CeciliaPlot.py/?hl=11#L11
http://sources.debian.net/src/pythoncard/0.8.2-5/debian/codeEditor/?hl=4#L4
http://sources.debian.net/src/libsmi/0.4.8%2Bdfsg2-11/debian/copyright/?hl=94#L94
http://sources.debian.net/src/dispcalgui/3.1.3.1-1/DisplayCAL/wxenhancedplot.py/?hl=10#L10
http://sources.debian.net/src/libsigc%2B%2B-2.0/2.8.0-1/tests/test_disconnect.cc/?hl=2#L2
http://sources.debian.net/src/dactyl/1.2%7Er20151231-1/plugins/aardvark.js/?hl=2#L2
http://sources.debian.net/src/gnuradio/3.7.9.2-4/gr-wxgui/python/wxgui/plot.py/?hl=10#L10
Re: "Use as you wish" license
On Tue, Jul 05, 2016 at 03:55:33PM +1000, Ben Finney wrote: > So I think it is too risky to accept such a license if there is no > explicit permission to all the freedoms needed for DFSG works. Thank you for your answers. It seems there are different views on this so it's probably better to avoid files under that license if I want a my program eventually included in Debian, I suppose.
"Use as you wish" license
I've encountered two simple notices, I wonder if they are acceptable for DFSG under your opinion. Is "Use as you wish" an acceptable license? And, a web page that says some of its content "may be downloaded and used for any projects, without restrictions". There is no explicit mention of redistribution of modified versions, though.
Question on QuickFIX license
[ I am not subscribed to debian-legal, please keep me in the CC; M-F-T set accordingly ] I have filed an ITP for QuickFIX (c.f. #642268). As I was looking over the license, I figured that it was just a standard BSD w/ advertising clause. When I looked a little closer, I saw 5 clauses instead of 4, which looked like the advertising clause had been split into two parts. However, the final clause left me scratching my head (the complete license is at the end of my email): 5. Products derived from this software may not be called QuickFIX, nor may QuickFIX appear in their name, without prior written permission of quickfixengine.org I am not really sure if this provision makes QuickFIX unsuitable for main. Is the Debian package a product derived from this software in the sense meant by the license? What do others think about this? I thought it might fall under integrity of the author's source code. But I am not so sure. Regards, -Roberto -8--Complete license text follows--8- The QuickFIX Software License, Version 1.0 Copyright (c) 2001-2010 quickfixengine.org All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: This product includes software developed by quickfixengine.org (http://www.quickfixengine.org/). Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names QuickFIX and quickfixengine.org must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact a...@quickfixengine.org 5. Products derived from this software may not be called QuickFIX, nor may QuickFIX appear in their name, without prior written permission of quickfixengine.org THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL QUICKFIXENGINE.ORG OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: geotrans license: asking for advice
Hi all... I send attached the copyright file of the package GEOTRANS I asked for advice here some days ago. I've renamed the package to GEOTRANZ, to fulfill the terms of use (do not use the original name in derived works) and I understand that we have permission to distribute derived works of geotrans because the authors say so in a mail sent to me (it is not clear in the terms of use). I asked them to rewrite the terms of use but they released a new version without doing it. I you agree I will upload the package to main soon. -- Regards, Roberto Lumbreras This package was Debianized by Roberto Lumbreras [EMAIL PROTECTED] on Sun, 02 Mar 2008 17:16:08 +0100 It was downloaded from http://earth-info.nga.mil/GandG/geotrans/ The package GEOTRANZ is derived from GEOTRANS: The product was developed using GEOTRANS, a product of the National Geospatial-Intelligence Agency (NGA) and U.S. Army Engineering Research and Development Center. Do not use the name GEOTRANS for any derived work. Debian modifications are the following: add makefiles to compile it with openjdk; modify some icons so they have a transparent background; use x-www-browser to lunch help instead of netscape; modify directory where help files are; add missing includes in C files to fix implicit declaration warnings. Debian package GEOTRANZ is DFSG free because: -Everyone is allowed to use and distribute the software (see terms of use). -Everyone is allowed to modify the software develop derivative works (see terms of use). -Everyone is allowed to make and distribute derived works if the GEOTRANS name is not used. (see terms of use and clarification mail from authors). -The package is compiled with and depends on free packages only (thanks to openjdk). GEOTRANS upstream author: National Geospatial Intelligence Agency (NGA) Department of Defense United States of America Point of Contact: Coordinate Systems Analysis Team phone (314) 263-4171, DSN 693-4171 [EMAIL PROTECTED] GEOTRANS Project Managers: Brian Akers (St. Louis) and Dan Mullaney (Bethesda) Please contact the JMTK Help Desk ([EMAIL PROTECTED], 1-888-549-JMTK) if you have any problems, questions, or comments. Copyright: (C) 1999-2008 National Geospatial Intelligence Agency (NGA) Although NGA makes no copyright claim under Title 17 U.S.C., NGA claims copyrights in the source code under other legal regimes. I wrote NGA asking for permission to distribute derived works of geotrans, and they sent me the following mail: -- From: Mullaney, Dan F. Daniel.F.Mullaney _at_ nga.mil To: roberto.lumbreras _at_ gmail.com Cc: Spaunhorst, Scott Scott.J.Spaunhorst _at_ nga.mil Subject: RE: geotrans license clarification Date: Wed, 1 Oct 2008 10:53:25 -0400 Sir, Please find an updated Terms of Use for GEOTRANS. Our position is that derivative works may be distributed, if they adhere to these Terms. A new version (GEOTRANS 2.4.2) will be made available shortly. Thank You, Dan Mullaney NGA/SNAC Coordinate System Analysis -- GEOTRANS Terms of Use: 1. The GEOTRANS source code (the software) is provided free of charge by the National Geospatial-Intelligence Agency (NGA) of the United States Department of Defense. Although NGA makes no copyright claim under Title 17 U.S.C., NGA claims copyrights in the source code under other legal regimes. NGA hereby grants to each user of the software a license to use and distribute the software, and develop derivative works. 2. NGA requests that products developed using the software credit the source of the software with the following statement, The product was developed using GEOTRANS, a product of the National Geospatial-Intelligence Agency (NGA) and U.S. Army Engineering Research and Development Center. Do not use the name GEOTRANS for any derived work. 3. Warranty Disclaimer: The software was developed to meet only the internal requirements of the National Geospatial-Intelligence Agency (NGA). The software is provided as is, and no warranty, express or implied, including but not limited to the implied warranties of merchantability and fitness for particular purpose or arising by statute or otherwise in law or from a course of dealing or usage in trade, is made by NGA as to the accuracy and functioning of the software. 4. NGA and its personnel are not required to provide technical support or general assistance with respect to public use of the software. Government customers may contact NGA. 5. Neither NGA nor its personnel will be liable for any claims, losses, or damages arising from or connected with the use of the software. The user agrees to hold harmless the United States National Geospatial-Intelligence Agency (NGA). The user's sole and exclusive remedy is to stop using the software. 6. Please be advised that pursuant to the United States Code, 10 U.S.C. 425, the name
geotrans license: asking for advice
Hi... I have packaged a nice software called geotrans (ITP #468918): http://earth-info.nga.mil/GandG/geotrans/ whose author is NGA (US National Geospatial-Intelligence Agency). You can find my work at http://rover.thehackers.org/geotrans/ The package provides a GUI written in java that is like a calculator, and a library providing functions to convert between coordinate systems, map projections and datums. The problem is that the license says: NGA hereby grants to each user of the software a license to use and distribute the software, and develop derivative works. Unfortunately, this doesn't explicitly permit the distribution of derivative works, so it is non-free and ftp-masters rejected my first upload. It is a shame I missed it, but I did it. In the license they say things like Although NGA makes no copyright claim under Title 17 U.S.C., NGA claims copyrights in the source code under other legal regimes., so it was clear for me that they were allowing distribution... but the magic words are missing in the license :( I've asked the authors to clarify this, and I recently got a mail saying: Please find an updated Terms of Use for GEOTRANS. Our position is that derivative works may be distributed, if they adhere to these Terms. A new version (GEOTRANS 2.4.2) will be made available shortly. I send you attached these new terms of use, that adds a new point (2) saying: 2. NGA requests that products developed using the software credit the source of the software with the following statement, The product was developed using GEOTRANS, a product of the National Geospatial-Intelligence Agency (NGA) and U.S. Army Engineering Research and Development Center. Do not use the name GEOTRANS for any derived work. But I can not find you can distribute derived works anywhere... maybe you can understand that you can because point 2 requests giving credit in products developed using the software (so you can distribute them, if you can't is useless to give credit)..., and also is the requirement that the name of geotrans can not be used in any derived work, so it is clear that: -you can do derivative works using a different name (maybe geotranz? ;-) -you must give credit them in derivative works, so... can you distribute them??? I have asked them again to clarify these points: Could you please change that sentence to: NGA hereby grants to each user of the software a license to use and distribute the software, develop and distribute derivative works. ? In point 2 it is clear that credit must be given to the software and that the name of geotrans can not be used in derivative works. But... fixing a bug in the source, or changing something is a derivative work? I had modified geotrans sources to adapt them to the Debian Operating System, that changes are only to compile (makefile changes) and build geotrans (missing import directives for my compiler) from the source, and some small changes to make the help work in Debian (netscape changed to x-www-browser and the directory where help files are). I have also modified the geotrans icon so it has a transparent background. All of that changes I understand they are not derivative works, so the name of geotrans can be used in the Debian distribution of geotrans. Do you agree? What should I do? What do you think? Regards, -- Roberto Lumbreras Debian developer GEOTRANS Terms of Use: 1. The GEOTRANS source code (the software) is provided free of charge by the National Geospatial-Intelligence Agency (NGA) of the United States Department of Defense. Although NGA makes no copyright claim under Title 17 U.S.C., NGA claims copyrights in the source code under other legal regimes. NGA hereby grants to each user of the software a license to use and distribute the software, and develop derivative works. 2. NGA requests that products developed using the software credit the source of the software with the following statement, The product was developed using GEOTRANS, a product of the National Geospatial-Intelligence Agency (NGA) and U.S. Army Engineering Research and Development Center. Do not use the name GEOTRANS for any derived work. 3. Warranty Disclaimer: The software was developed to meet only the internal requirements of the National Geospatial-Intelligence Agency (NGA). The software is provided as is, and no warranty, express or implied, including but not limited to the implied warranties of merchantability and fitness for particular purpose or arising by statute or otherwise in law or from a course of dealing or usage in trade, is made by NGA as to the accuracy and functioning of the software. 4. NGA and its personnel are not required to provide technical support or general assistance with respect to public use of the software. Government customers may contact NGA. 5. Neither NGA nor its personnel will be liable for any claims, losses, or damages arising from or connected with the use of the software. The user agrees to hold harmless
Documentation copyright/licensing
[Please keep me in the CC, as I am not subscribed to -legal] I am preparing an upload to tbb. With this upload, a new binary package will be introduced, called libtbb-doc. It will include HTML documentation files that were generated by Doxygen from the tbb program sources. Because of the new binary package, it will have to pass NEW processing again, which is why I am posting this message to the list. Now, each HTML file contains this comment: Generated by Doxygen 1.3.9.1 Each file also contains this footer: Copyright copy; 2005-2008 Intel Corporation. All Rights Reserved. When I inquired in #debian-devel, AzaThat indicated that the All Rights Reserved has little or no legal meaning anymore. I wanted to get some opinions on this list before I upload however. All of the program sources are clearly covered under GPL2. The documentation is mechanically generated from the sources. Does the footer statement on documentation pages conflict with that license. My initial inclination is that it does not. Any other opinions? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Review of license
On Mon, Apr 28, 2008 at 10:29:05PM +0200, Francesco Poli wrote: [I'm Cc:ing Roberto, who asked to be Cc:ed, but probably didn't see Joe's reply] Thanks Francesco. This is the type of messed up license obtained when a lawyer never looks over the license, and the drafter is not familar with license drafting. The license is indeed vague and messed up: as I already stated, I dislike it... Thanks for the review. While I agree that the license appears to be not very desirable, it seems to be acceptable for distribution in Debian. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Review of license
[ Please keep me in the CC since I am not subscribed to -legal ] I was recently asked to sponsor an upload of a package that carries the below license. Is this license acceptable for main? Regards, -Roberto -88-- Preamble The intent of this document is to state the conditions under which a Package may be copied, such that the Copyright Holder maintains some semblance of artistic control over the development of the package, while giving the users of the package the right to use and distribute the Package in a more-or-less customary fashion, plus the right to make reasonable modifications. Definitions: * Package refers to the collection of files distributed by the Copyright Holder, and derivatives of that collection of files created through textual modification. * Standard Version refers to such a Package if it has not been modified, or has been modified in accordance with the wishes of the Copyright Holder. * Copyright Holder is Christopher B. Powell, [EMAIL PROTECTED]. * You is you, if you're thinking about copying or distributing this Package. * Reasonable copying fee is whatever you can justify on the basis of media cost, duplication charges, time of people involved, and so on. (You will not be required to justify it to the Copyright Holder, but only to the computing community at large as a market that must bear the fee.) * Freely Available means that no fee is charged for the item itself, though there may be fees involved in handling the item. It also means that recipients of the item may redistribute it under the same conditions they received it. 1. You may make and give away verbatim copies of the source form of the Standard Version of this Package without restriction, provided that you duplicate all of the original copyright notices and associated disclaimers. 2. You may apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version. 3. You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following: a) place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as ftp.uu.net, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package. b) use the modified Package only within your corporation or organization. c) rename any non-standard executables so the names do not conflict with standard executables, which must also be provided, and provide a separate manual page for each non-standard executable that clearly documents how it differs from the Standard Version. d) make other distribution arrangements with the Copyright Holder. 4. You may distribute the programs of this Package in object code or executable form, provided that you do at least ONE of the following: a) distribute a Standard Version of the executables and library files, together with instructions (in the manual page or equivalent) on where to get the Standard Version. b) accompany the distribution with the machine-readable source of the Package with your modifications. c) accompany any non-standard executables with their corresponding Standard Version executables, giving the non-standard executables non-standard names, and clearly documenting the differences in manual pages (or equivalent), together with instructions on where to get the Standard Version. d) make other distribution arrangements with the Copyright Holder. 5. You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own. 6. The scripts and library files supplied as input to or produced as output from the programs of this Package do not automatically fall under the copyright of this Package, but belong to whomever generated them, and may be sold commercially, and may be aggregated with this Package. 7. C or perl subroutines supplied by you and linked into this Package shall not be considered part of this Package. 8. The name of the Copyright Holder may not be used to endorse or promote products derived
Re: Bug#445998: ITP: eaccelerator -- PHP accelerator, optimizer, and dynamic content cache
On Tue, Oct 09, 2007 at 09:24:14PM +0200, Tim Dijkstra wrote: On Tue, 09 Oct 2007 21:29:38 +0400 Alexander Gerasiov [EMAIL PROTECTED] wrote: Package: wnpp Severity: wishlist Owner: Alexander Gerasiov [EMAIL PROTECTED] * Package name: eaccelerator Version : 0.9.5.2 Upstream Author : eaccelerator team http://eaccelerator.net/wiki/Team * URL : http://eaccelerator.net * License : GPL Programming Lang: C Description : PHP accelerator, optimizer, and dynamic content cache Some dummy packages available for now in my repository at http://gq.net.ru/debian I'm going to upload it after fixing some packaging issues. Feel free to kick me by mail, if I'm too slow. Are the license issues finally solved then? Last time I checked binaries were not distributable, see for example: http://www.mailarchives.org/list/debian-devel/msg/2005/08164 grts Tim Also, in one of the many discussions about this piece of software it came out that original author of turck-mmcache (the software on which eaccelerator is based) now works for Zend. Zend produces a proprietary (and expensive) accelerator-sort of product for PHP. It is doubtful that they would enable the distribution of something that they would see as competing with their product. I seem to recall that the people who took over eaccelerator had it in mind to do a complete rewrite of the eccalerator code to break any link with turck-mmcache, allowing them to relicense eaccelerator. If that rewrite is complete, then the software may be distributable. However, I have not looked into it for quite a while. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Intel IA-32 EL License - ok for non-free?
On Mon, Apr 23, 2007 at 03:42:10PM -0600, dann frazier wrote: * Section 4: Updates requires commerically reasonable efforts to supply our customers with updates that Intel distributes. If this means we cannot say no to an update from Intel, that does not sound reasonable for non-free. But perhaps we are exempt from this since 1) non-free isn't officially part of Debian and 2) we are a non-commercial entity making commercially feasibility null? There is also the issue that Intel's update policy may not mesh well with the stable release update policy. What about a downloader that lives in contrib and just polls the Intel site (or whatever, it can be cron-based or only happen when the admin executes it) and downloads the whole thing, including any updates? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Java in Debian advice result
On Mon, Mar 05, 2007 at 01:10:33PM +, Andrew Saunders wrote: On 2/28/07, John Goerzen [EMAIL PROTECTED] wrote: to summarize the situation here. SPI's attorney has asked that his messages not be posted to public mailing lists for reasons of attorney-client privilege. Please could you elaborate on whom this secrecy is intended to protect, and in what way? I thought attorney-client privilege was a mechanism intended to protect sensitive information disclosed by the client to the attorney (facilitating honest and open communication without the client having to worry about information being leaked to enemies, competitors or the authorities). Assuming this is the case, it seems a bit strange that the request for secrecy should be coming from the *attorney*'s side... I could well be talking bollocks here, and I apologise in advance if that's the case, but I have to say that that's the inference I got. Clarification welcome. (Standard IANAL lawyer disclaimers apply) I thought that attorney-client privilege was something invoked (is that the right word?) by the client. The attorney can only invoke it if the information he is being asked to reveal somehow reveals some protected information of the client. I would think that since SPI is the client, they can unilaterally decide to make the information public. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Java in Debian advice result
On Mon, Mar 05, 2007 at 10:23:40AM -0800, Sean Kellogg wrote: So, from the lawyer's perspective, it is a matter of client-attorney privilege. SPI now has to make the decision that full disclosure to the public via d-l is worth the potential risk of losing that protection. My guess would be the lawyer has done the research on how one could bring suit against Debian/SPI/3rd party and disclosure would be like handing a roadmap to the enemy. You generally want to make the cost of bringing suit against you as high as possible to warred off long-shot litigation. OK. Makes perfect sense to me. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: What should be in debian/copyright when a gpl source now depends on openssl?
On Mon, Feb 26, 2007 at 05:04:24PM +0200, [EMAIL PROTECTED] wrote: I am not sure the subject accurately reflects the body of this message. Narcis Ilisei has the copyright to inadyn. He released it under the gpl. The source that he wrote is an http client of some sort Aand depends only on libc. Now opendns.com offers to download a modified version. Their version adds an https support. I couldn't see any copyright notice for their version. opendns's version depends on -lcurl -lssl -lcrypto -ldl -lz -lkrb5support , where ssl is provided by openssl. Can debian distributes opendns's version? Assuming that opendns wrote their modifications by themselves, What should be put in debian/copyright? Is the following appropriate as debian/copyright: Thu, 22 Feb 2007 06:15:15 -0700 Home page is http://inadyn.ina-tech.net . Upstream Author: Copyright (C) 2003-2005 Narcis Ilisei, [EMAIL PROTECTED] Copyright (C) 2006-2007 http://www.opendns.com License: Copyright (C) 2003-2005 Narcis Ilisei Copyright (C) 2006-2007 http://www.opendns.com 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. 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 On Debian systems, the full text of the GNU General Public License may be found in /usr/share/common-licenses/GPL. That won't work as there is no SSL excpetion for the GPL. You can check the copyright file for the httperf to see how I handled this same issue. There are others, but that is the only one I can think of off the top of my head. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: [OT] mailing list subjects
On Fri, Feb 09, 2007 at 10:32:43AM +0100, Daniele Micci wrote: Hi, just a suggestion. Why don't you (the ML admins) tag each email in the ML inserting in its subject some prefix (something like: [Debian-legal] subject of email)? This could help those of us who often read emails using a web interface. Thank you for reading, and forgive me for the OT. Because it waste's space? That's what server-side filtering is for. If you read mail in an 80 character wide terminal, then you will know that many subject lines already get truncated. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: creative commons
On Mon, Jan 08, 2007 at 10:08:19PM -0800, Jeff Carr wrote: On 01/08/07 18:43, Roberto C. Sanchez wrote: On Mon, Jan 08, 2007 at 09:02:02PM -0800, Jeff Carr wrote: That's good, I'm not convinced that CC in any form isn't DFSG. :) It seems to me the CC is written with the same kind of mentality and intentions that the DFSG was written. Well, any non-commercial variant of the CC is a clear violation of DFSG #6 (No Discrimination Against Fields of Endeavor). Yes, I understand that. As a guideline, the DFSG is for the purposes of advancing the free software movement. I don't know why the Creative Commons guys added that option, but perhaps there was some really good reason for when it needs to be used. All I'm saying is that it's use needs to be evaluated when someone might choose to use it. I agree that I can't think of a valid use, but I'm not comfortable saying that I've ruled out the possibility that some valid use exists. Jeff OK. I misread your statement as something akin to all CC variants are DFSG-compliant. On closer inspection, that is clearly not what you said :-) Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: creative commons
On Wed, Jan 10, 2007 at 01:34:53AM +0100, Francesco Poli wrote: Hence, I don't know what the lawyers are looking for, but a license that grants too few permissions is not OK to me, even if it does so in a legally perfect manner. It seems to me that you are looking at this as a sort of all or nothing situation. I don't think that is correct. A license that grants what you consider to be too few permissions might be too many for some. Now if we were to rely only standard copyright, then only the original creator would be permitted to distribute his work. Redistribution would be prohibited. Now, if the creator decides that he would like to permit free redistribution as long as the redistributor does not realize a commercial gain, then fine. That is an improvement, because before that the redistributor would not have been permitted to redistribute. Depending on the situation, the creator may have decided to create the work and give it away, as long others did likewise without making money. Now, is this situation perfect? No. I suppose the utopian ideal would be something like ST:TNG, where we all endeavor in a field of our choosing about which we are passionate solely for the purpose of self actualization. All knowledge is shared and there is no impediment to its exchange. Of course, as we live in the real world and are predominantly driven by money as a society, we really can't do as they do in ST:TNG. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Is this legal? [RFP: djohn -- Distributed password cracker]
On Thu, Jan 04, 2007 at 01:25:08AM -0400, Jose Luis Rivas Contreras wrote: Hi, I was checking some old RFP's and I find this one. Is a little program that distribute the job of cracking passwords using John the Ripper. I think this is not totally legal to be packaged officially for Debian. Some reason why you think it is illegal and *where* you think it is illegal would be important and probably also generate a more fruitful discussion than a simple claim of it's illegal with nothing else. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: PEAR / PHP License status
On Fri, Dec 08, 2006 at 10:05:52PM +0100, Sylvain Beucler wrote: Hi, What is the status of the discussion with PEAR (or PHP Group) about using the PHP license in some of the PEAR packages? [1][2] I'm currently in need of QuickForm (v3) in a GNU GPL'd application, but QuickForm is released under the PHP license, which is incompatible :/ If you are the author of said application, you could release under the MIT or BSD-type license. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Tue, Oct 17, 2006 at 11:42:14PM -0700, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote: The answer to the question in the subject is simple: NO. Thankyou for your opinion. I note you seemed to neglect to mention that you're not a lawyer. So, do you have anything to say about what Nathanael said? How does his not being a lawyer make his statement false? I don't think the point was that the statement is false, rather that it is unfounded. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Tue, Oct 17, 2006 at 07:07:00PM -0700, Don Armstrong wrote: On Tue, 17 Oct 2006, Roberto C. Sanchez wrote: So what? Distributing GPL works *with* sources is also not clear of legal liability. Those liabilities occur in either case, so they're not particularly interesting to discuss. Doing something that is against the letter and spirit of a software license is just not a position that we should put ourselves in. But they are interesting. The original argument was about sourceless firmware. Consider these two cases: 1. distributing firmware without corresponding sources 2. distributing packages and source code to a patented implementation of something In case 1, it depends on whether or not you consider (firmware == software) to be true. If yes, then it is against the letter and the spirit of the GPL. That may require an actual court case to figure out. If no, it is just against the spirit, but still legal. In case 2, there is no disputing that it is illegal, if software patents are indeed legal in $jurisdiction. Now, in such a case, it is agianst the spirit of the GPL, while still in complete compliance with the letter of the GPL and generally still illegal. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Wed, Oct 18, 2006 at 02:16:04AM -0700, Don Armstrong wrote: Regardless, that distribution in compliance with relevant licenses doesn't necessarily absolve you of all liabilities is well known, and not an issue I'm terribly intersted in discussing in the abstract. [And if for some reason it was readable into my initial response, that was definetly not the intention.] OK. I'll drop it then. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Tue, Oct 17, 2006 at 03:35:26PM -0700, Don Armstrong wrote: On Wed, 18 Oct 2006, Anthony Towns wrote: On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote: The answer to the question in the subject is simple: NO. Thankyou for your opinion. I note you seemed to neglect to mention that you're not a lawyer. That should be abundantly apparent to anyone who has been paying attention. Regardless, it doesn't dismiss the crux of the argument: baring competent legal advice to the contrary,[1] distributing sourceless GPLed works is not clear of legal liability. Doing otherwise may put ourselves and our mirror operators in peril. So what? Distributing GPL works *with* sources is also not clear of legal liability. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Offices have been closed permanently
, Find out how to make 1.5 - 3.5k a day from your home. 800.671.9007 Ring me at my number if you can return calls. Thanks, Roberto Kennedy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Are source packages required to be DFSG-free? (was: Re: New bugs filed regarding non-free IETF RFC/I-Ds)
On Tue, Oct 03, 2006 at 04:59:03PM +0200, Simon Josefsson wrote: There is some discussion in one of the bug reports: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390664 (please read it first) The problem is essentially, if I understood it correctly, whether Debian source packages [in main] must be DFSG-free or not, or whether it is sufficient that Debian binary packages [in main] must be DFSG-free and that the source package is legally distributable. I'm not sure what the policy is here. I thought the Debian Policy was that source packages must be DFSG-free too, but I can't find a precise quotation in the Debian Policy Manual and point to it. IIRC, the rule is that sources and binaries must be DFSG free. Otherwise, source CDs would fall under different rules than binary CDs. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: License review request: LinuxMagic FSCL
On Tue, Sep 26, 2006 at 10:04:28PM -0700, Ryan Finnie wrote: Greetings, I responded to an RFP[0] for packaging magic-smtpd[1], and need some help on the legal side. I see 3 issues here: 1. The license[2], also included below, has not been reviewed by the OSI, and is not used in any existing Debian package. The company itself considers it open source, but I feel I am not qualified to make a determination. 2. The software is designed to replace certain components of qmail, which is wholly non-free. Even if the license is clean, does this make the software part of the non-free archive as well? I guess theoretically you could write Free software that would interface with magic-smtpd... Maybe contrib. If it is deemed to be free and then depends on non-free software to be functional, it would go into contrib. 13.6 Dispute Resolution. Any litigation or other dispute resolution between You and THE WIZARDS relating to this License shall take place in the Province of British Columbia, and You and THE WIZARDS hereby consent to the personal jurisdiction of, and venue in, the state and federal courts within that Province with respect to this License. The application of the United Nations Convention on Contracts for the International Sale of Goods is expressly excluded. 13.7 Entire Agreement; Governing Law. This License constitutes the entire agreement between the parties with respect to the subject matter hereof. This License shall be governed by the laws of Canada and the Provncie of British Columbia, except that body of British Columbia law concerning conflicts of law. Where You are located in the province of Quebec, Canada, the following clause applies: The parties hereby confirm that they have requested that this License and all related documents be drafted in English. Les parties ont exigé que le présent contrat et tous les documents connexes soient rédigés en anglais. I'm no legal expert, but I seem to recall that these type of venue selection clauses make the licenses non-free. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: public domain, take ?$B!g
On Mon, Sep 25, 2006 at 10:56:27AM -0700, Daniel Gimpelevich wrote: Greetings! I'm fully aware that the opinions stated on this list have no bearing on anything, but I would still like to ask whether anyone here might have any ideas for improving the wording of the following license header: #!bin/bash # # Let this be known to all concerned: It is the specific intent of the # author of this script that any party who may have access to it always # treat it and its contents as though it were a work to which any and all # copyrights have expired. # I thought about s/author/sole author/ but decided against it as not generic enough. I can see how deciding against it may make it rather unclear as to whose intent is being expressed, but I think that would be rather moot anyway in the event of any dispute. I now cut the ribbon opening this to the free-for-all of opinions... What about: The author(s) of this script expressly place it into the public domain. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: selling web application access
On Wed, Sep 20, 2006 at 02:46:35PM +0200, Ottavio Campana wrote: Hi everybody, I'm writing here because I'm having a doubt on the GPL and I'd like to discuss it with you. Scenario: a software house develops a web application based on GPL software. It doesn't sell the application to customers, it sells the access to the application, which is installed, run and is maintained on the software house's server. Question: can the users ask for the application's source code? I mean, in the GPL only the case of software distribution is covered. But in this case the software isn't distributed, it remains in the software house's servers. Probably not under GPL 2 or earlier. Selling access to an application is the same as distributing the application? It is not the same thing. One is a product (the code), the other is a service (the access to it). This is supposed to be specifically addressed by GPL 3. Thank you for your answers. PS:I know it is not polite, but can you please CC: me? I did not subscribe the list. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Hypocrisy of Debian (was: Sorry, no more RC bugs for non-free data in main ...)
On 9/5/06, Andreas Barth [EMAIL PROTECTED] wrote: * Markus Laire ([EMAIL PROTECTED]) [060830 15:01]: This problem was mentioned in this list on _2004_ but cdrtools still hasn't been removed from Debian (see [2]). IMHO hypocrisy is perfect word to describe such behaviour. This list isn't the place where everybody needs to jump if someone sends a mail. If you want to make sure this issue is taken up, please file an RC bug (what happened in the meantime), if it is an release critical issue. I would prefer to not continue with this, but I need to reply. I've already mentioned in a previous mail, but I would want to present my apologies again for the strong, abrasive, and maybe offending parts of my responses. But there is something I do not understand. Why this list is not the place to put disagreements on the way legal issues are handled? I'm sorry for the strong way of saying things I've used on some of my mails. But, except the offensive wording which was a mistake for my part, I think I should be allowed to disagree, and to publicly expose my point of view, even when my point of view is negative. If this list is not the place, where is it? debian-private? As somebody filed an RC-bug against cdrtools for this reason, we knew that we have to fix that prior to release of etch. I prefer to not enter in the cdrtools issue, because I know almost nothing about this bug. In fact, I was not aware of this license incompatibility until now. My claims are for the bugs that are downgraded, silently ignored or allowed into the stable release because of several exceptions that I do not see. And that is what I would want to say. So, if you think something is an important issue, *you* need to make sure it is actually mentioned in the right places. And please don't cry because people are not jumping to conclusions, but take the proper time to create a proper solution. That is exactly I was trying to perform, searching for license problems, reporting them, and also trying to help to solve them whenever possible. I think that we all agree with this. The problem starts when we disagree on how much important a particular issue is, and a serious problem for myself is not serious for others. Every person has a different point of view, this is perfectly normal. But I think we have an important difference between Debian claims and reality, and I would prefer to have less beautiful claims more close to reality than ideal claims too far from reality. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hypocrisy of Debian
Well, I've been reading the responses and I'm sorry for starting all of this. I don't like this kind of discussions, they deeply depress me, but it just happens that lately I'm getting involved frequently on many of them. I want to say some things. I hereby say that, in my subjective point of view, current Debian Social Contract and policy are made of high quantities of hypocrisy. I know this word may hurt some people, but it is not intended as a insult. I acknowledge there are many people working hard to make fixes [1], and even people who disagree with the importance of those bugs appear to have their own reasons to do that. So, I don't think that the word hypocrisy should be directed to a person in particular; I just see that the result of Debian as a whole does not match with my desired level of purity, this is a fact in my point of view. Although clarified, I maintain my claims about hypocrisy. I absolutely don't want anybody to feel insulted, but in case anybody does, I can only say that I'm honestly sorry very much for hurting you, but my claims are maintained. I also want to present my apologies for being too strong in some of my messages. Some of my neurons got tickled, and they are the ones that carry my deep fundamental and basics ethics. Maybe I'm too serious about topics like copyright, laws, free software, DFSG... but I can't change my mind (and not sure if I want to). I can't see any exceptions in the current policy for free software, and neither I see particular cases where it should be relaxed [2]. That is the reason for myself being happy, until now, with Debian; the rigid position for non-free and free software just fits well into my mind. Certainly, I would prefer things to not follow this path, but if most people thinks that it is OK to get relaxed under certain circumstances, all I can say is that an official clarification for all those circumstances is much appreciated (like the one that it is currently for firmware). I'm not only referring to this particular bug. I've found one string on one file that appears to be sufficient for everybody to agree in the priority. More generally, I'm referring to any other case, like giving priority to release in time, license incompatibilities, how much time a package should be allowed in main with the bug unresolved, how serious is not give credit for data or to suspect about the procedence... all should be documented, please. This way, maybe I would not agree with the policy, but at least I would feel it is sincere, which is probably the main concern for myself in this moment. I know of at least 5 more packages under the situation that we can call unclear. I'm currently so much depressed to continue with the goals I've previously posted here [3], but other people can continue if they want, it is not hard to find those cases on packages that contain icons, textures or sounds. Notes: [1] There are many positive examples. This bug in particular looks very similar to the one I reported: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174456 [2] At least I have not found them, or I do not correctly interpreted them in case they exists. [3] http://lists.debian.org/debian-legal/2006/08/msg00124.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#385115: Sorry, no more RC bugs for non-free data in main (was: Bug#385115: chromium-data: Unclear license for some files)
On 8/30/06, Steve Langasek [EMAIL PROTECTED] wrote: The latter implies that all packages should have RC bugs on them because we should not believe that any of the licenses and copyrights are what upstream says they are. How is that reasonable? Forgive me if I'm wrong, but I think it is still not fully understood what I mean. I will try to explain the better I can. I'm not saying exactly this: We should not believe X when we have no evidence that X is true. Instead, I'm trying to say this: I see that A says X+Y, not only X, and Y is so grave by itself to kick immediately the package from main until solved. If upstream had never said Y, I would never reported this bug, I would never worried abut its legal status, and I would probably never noticed the Copyright by Corel string. Now, the question is, how are this kind of things (Y) supposed to be handled? You say that it should be safe unless proven to be not. I believe that the fact that Y exists it is just enough to be incompatible with Debian policies, and the package should be blocked immediately until clarified by upstream and corrected. In case that Y is supposed to be handled the way you say, I will sadly accept it, but I beg for policies to be updated. I currently feel badly fooled by Debian free software claims, as I think they are not true in practice. Sorry to say that, but it is just the truth on what I believe now. I honestly hope my position is clear now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Sorry, no more RC bugs for non-free data in main (was: Bug#385115: chromium-data: Unclear license for some files)
OK, you win, I will not continue with this. Do whatever you want with the bug. I'm sending this message to debian-legal, in case other people care. On 8/30/06, Steve Langasek [EMAIL PROTECTED] wrote: For all you've said up to this point, the sound files being used could be in the public domain; in which case the only controlling copyright is that governing the packaging and support files. OK, so I take files from the web and put them on packages. They could be in public domain, so there is no problem unless someone find that they are not, uh? I think it is silly. Copyright does not work this way. Something should be treated as copyrighted unless clearly stated it is under public domain. That they are unknown to *you* is not grounds for an RC bug claiming that upstream is distributing files illegally. And they are unknown to upstream. AFAIK, upstream does never claim that those files are under artistic license nor under public domain. It is not me. Why it is this so difficult to understand? If you're going to claim that the license on these sounds is not what upstream and the packaging claim it is, the burden of proof lies with you. Again, upstream does not claim he is copyright holder, and license for them is not specified. He only claims that he took the files from other sources. Even if the files are free, credit should be provided, and the origin clarified. As a positive example, look at this package (monsterz-data), it is a example of someone who has taken the time to correctly provided credits and copyright information for the included wav files: /usr/share/doc/monsterz-data/copyright To put all copyrights and references in detail for code and data can be boring, but omitting them makes no favor to free software. Please, note that including source code for data files is a different issue. This is about copyright problems on Debian main archive. I'm getting tired of all of this. There are still an important number of packages that carry unlicensed data with them, but I WON'T CONTINUE reporting bugs. Believe it or not, I have lots of more exciting things to do than searching for copyright problems and reporting them on my free time. And instead of people helping me to solve the problems and make Debian a better product, I got negative responses saying the problem is myself. Defending my position each time takes a lot of time (English is not my native language and my level of English is rather poor). Things I'm reporting are obviously not allowed by current Debian guidelines, so justifying and fighting for them each time is a waste of my time. If most people here thinks that we should not care about this, I would prefer that guidelines to be updated in consequence, so people who really care about this kind of copyright issues would know before choosing to use Debian. So Debian will remain 100% free unless we got sort of time for the next release, or something taken from the web is public domain unless someone demonstrate that it is not... So do not expect myself to give any more of my time to this. And you can downgrade the priority again or even close the bug if you want, I do not mind anymore. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorry, no more RC bugs for non-free data in main (was: Bug#385115: chromium-data: Unclear license for some files)
I strongly disagree with your arguments. It looks that we have opposite way of thinking, so I will not reply to them, it is going to nowhere. Don't worry, as I said, I won't continue searching for this. If this is the common feeling here, I think I made a serious mistake choosing Debian, because it does not follow my definition of freedom. I would like to urge to change the Social Contract to be clarified this in this case. I'm serious about that, it is no joke, because I feel mislead. When reading it I was thinking I was doing the correct. I was not sending those bugs because I am bad person, I was actually thinking that was the common feeling and the correct think to do. Currently, under my point of view, the Social Contract and guidelines do not reflect reality, they are just hypocrisy. This is a subjective view, I know, but I think I'm not the only person in the world who may understand it this way, so please, clarify. And in case your way of think is not the common feeling, please make a poll or something. Until this is completely clear, I won't be morally happy using nor giving my time to the Debian project, so you won't be bothered with those bugs again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorry, no more RC bugs for non-free data in main (was: Bug#385115: chromium-data: Unclear license for some files)
On 8/30/06, Raul Miller [EMAIL PROTECTED] wrote: Steve Langasek has said, in essence When A says X, and we have no evidence to the contrary, we believe A. Your objection, in essence seems to be We should not believe X when we have no evidence that X is true. Well... more exactly, I try to say A does not say X, he says Y. And we appear to differ on how much serious is Y. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RC bugs for non-free data in main
I will start to fill bugs for packages containing data (sound, music, images, textures, icons...) when its origin is not specified (see below). Many of this bugs will be RC, because of legal issues; that is the reason for asking first on this list. I won't make an extensive search, but I will fill bugs anytime I found by chance some of this: 1. Packages using unlicensed data when it is known they came from non-free software will receive an RC bug. There appears to be several of these, like games that rip data from other non-free commercial games. Example: package: powermanga-data file: /usr/share/games/powermanga/sounds/bonus4.wav File has following strings: Windows 95 Utopia Sound Scheme, 1995 Microsoft Corporation, Utopia Question. Appears to be one of the Windows standard sounds. It is non-free (and also non distributable at all, not even on non-free section). 2. Packages using data from unknown sources sometimes will receive a bug. Severity will vary depending of the case. If there are not reason to think data is not original, it will be a whislist asking for clarification of procedence of all works beside code. If there are strong suspects that data comes from non-free sources, it may be an RC bug. Example: package: chromium-data Upstreams claims that music loops and raw sound effects were taken from http://www.partnersinrhyme.com/ and http://www.findsounds.com/. It is very likely for most of them to be non-free, as stated here: http://www.findsounds.com/cpolicy.html 3. Packages using data taken from other free software should give credits and point to the proper license for data, because sometimes can be different than the one used for the program itself. Not as critical as n.1, but it should be fixed anyways. Severity can be relaxed in this case, I think. This kind of problems are not new, they have been discussed before. While we are more or less careful with code coming from unknown places, it appears to me that we turn a blind eye on licensing other data :-) So, I'm sorry for growing up again the number of RC bugs, but I think this is important to be fixed before etch release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
Olaf van der Spek wrote: I guess the conclusion is that being a Debian developer means you're right and not being one means you're wrong? More like, being a Debian developer means your arguments are ignored and not being a Debian developer means your arguments are ignored (for a completely different reason). -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
KJV Bible - Crown Copyright in UK [was: Bug#338077: ITP: sword-text-kvj -- King James Version with Strongs Numbers and Morphology]
On Tue, Nov 08, 2005 at 06:16:52PM +0100, Lionel Elie Mamane wrote: ( Please mail followups to: [EMAIL PROTECTED], debian-legal@lists.debian.org, [EMAIL PROTECTED], [EMAIL PROTECTED] ) On Tue, Nov 08, 2005 at 10:13:42AM -0500, Roberto C. Sanchez wrote: Quoting Lionel Elie Mamane [EMAIL PROTECTED]: On Mon, Nov 07, 2005 at 08:51:26PM -0500, Roberto C. Sanchez wrote: * License : Public Domain Description : King James Version with Strongs Numbers and Morphology This is the King James Version of the Holy Bible (also known as the Authorized Version) with embedded Strong's Numbers. The rights to the base text are held by the Crown of England. What rights are you speaking about? The text certainly is far too old for any copyright to hold and you yourself tag it as public domain. So what right is being spoken of here? Based on my understanding [0], the Crown of England maintains the perogative to authorize printings of the KJV text in Great Britain. It is in the public domain everywhere else. Ain't law fun? grin This makes the KJV of the bible non-free in GB and probably even illegal to distribute at all in GB, unless the Crown gives a blanket license for electronic distribution. Does it? According to the wikipedia article, we can escape this Crown Copyright if what the package will contain is an annotated Study Bible. The question is whether that thing will be annotated enough to be considered as such. Please investigate this before uploading to Debian. [0] http://en.wikipedia.org/wiki/King_James_Version_of_the_Bible#Copyright_status Well, the CrossWire page does not have any warnings about distribution. They are pretty good about putting warnings on texts that may still be copyrighted in certain parts of the world, which is usually only a concern for newer texts. Additionally, the KJV text I downloaded from CrossWire contains all the Strong's Hebrew and Greek numbers cross referenced to the text itself and the sword-text-kjv package I made also suggests the sword-dict-strongs-hebrew and sword-dict-strongs-greek packages the I created. The CrossWire page [0] also caims that their text is a derivative work (probably becase of the integration of the Strong's references) and they place it into the public domain. If there is still an issue, I suppose we could start a non-GB section :-) -Roberto [0] http://www.crosswire.org/sword/modules/ModInfo.jsp?modName=KJV -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpBJrze4fZIs.pgp Description: PGP signature
Re: KJV Bible - Crown Copyright in UK
On Tue, Nov 08, 2005 at 07:52:26PM +0100, Florian Weimer wrote: * Lionel Elie Mamane: Please investigate this before uploading to Debian. Or alternatively, depend on the bible-kjv-text package, which already is in main. The text included in bible-kjv-text is not SWORD-compatible. I looked :) -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpdkGKrMLokV.pgp Description: PGP signature
Re: Is this OK to get httperf back into main?
[Please CC me, I am not on -legal] On Wed, Jun 29, 2005 at 08:51:12PM -0700, Martin Arlitt wrote: Roberto all of the copyright holders have agreed to the exception. as for the rewording of the exception, I will have to check with the people who provided me with the exception that I sent you. I won't be able to get an answer to you until after July 4th. Martin That's fine. I am more interested in doing this correctly (so the problem does not resurface), rather than quickly. As it stands, httperf is no longer in the stable Debian distribution, so there is no need to rush. -Roberto On Wed, 29 Jun 2005, Roberto C. Sanchez wrote: [Please CC me, I am not on -legal] On Thu, Jun 30, 2005 at 01:10:07AM +0200, Francesco Poli wrote: On Wed, 29 Jun 2005 15:01:51 -0400 Roberto C. Sanchez wrote: Is this OK to get httperf back into main? Assuming that * httperf is currently released under the GNU GPL v2 It is. * the only issue that bans httperf from main is its linking against OpenSSL Aside from OpenSSL, it links to libc6. * every copyright holder has agreed to grant a link exception I believe so. Martin, is this statement true? * httperf does not include or link against any other purely GPL'd work (i.e. with no link exception for OpenSSL) It does not. then yes, it seems that an appropriate link exception would suffice. [...] In addition, as a special exception, the copyright holders give permission to link the code of httperf with the OpenSSL I think that an s/of httperf/of this work/ would improve the exception, as it would apply even to a differently-named modified version of httperf. project's OpenSSL library (or with modified versions of it that use the same license as the OpenSSL library), and distribute the linked executables. Following http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs, the canonical phrasing suggests an s/the linked executables/linked combinations including the two/ Martin, would you consider the suggested changes? You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpvs8QdGN8hu.pgp Description: PGP signature
Is this OK to get httperf back into main?
Is this OK to get httperf back into main? -Roberto - Forwarded message from [EMAIL PROTECTED] - Date: Wed, 29 Jun 2005 07:43:27 -0700 (PDT) From: Martin Arlitt [EMAIL PROTECTED] Reply-To: Martin Arlitt [EMAIL PROTECTED] Subject: Re: forwarded message from Roberto C. Sanchez To: Roberto C. Sanchez [EMAIL PROTECTED] Roberto here is the text of the exception. please let me know if this is adequate for your needs. In addition, as a special exception, the copyright holders give permission to link the code of httperf with the OpenSSL project's OpenSSL library (or with modified versions of it that use the same license as the OpenSSL library), and distribute the linked executables. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. thanks Martin - End forwarded message - -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is this OK to get httperf back into main?
[Please CC me, I am not on -legal] On Thu, Jun 30, 2005 at 01:10:07AM +0200, Francesco Poli wrote: On Wed, 29 Jun 2005 15:01:51 -0400 Roberto C. Sanchez wrote: Is this OK to get httperf back into main? Assuming that * httperf is currently released under the GNU GPL v2 It is. * the only issue that bans httperf from main is its linking against OpenSSL Aside from OpenSSL, it links to libc6. * every copyright holder has agreed to grant a link exception I believe so. Martin, is this statement true? * httperf does not include or link against any other purely GPL'd work (i.e. with no link exception for OpenSSL) It does not. then yes, it seems that an appropriate link exception would suffice. [...] In addition, as a special exception, the copyright holders give permission to link the code of httperf with the OpenSSL I think that an s/of httperf/of this work/ would improve the exception, as it would apply even to a differently-named modified version of httperf. project's OpenSSL library (or with modified versions of it that use the same license as the OpenSSL library), and distribute the linked executables. Following http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs, the canonical phrasing suggests an s/the linked executables/linked combinations including the two/ Martin, would you consider the suggested changes? You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgps9dppR1MPQ.pgp Description: PGP signature
Re: Request for a sponsor for Felix
On Fri, May 27, 2005 at 10:44:49AM +1000, John Skaller wrote: Felix is a 'free for any use' open source advanced License text [0]: Licence Copyright (C) 2004 John Skaller. Felix is Free For Any Use. Redistribution and use in source and binary forms, with or without modification, are permitted. No offense, but you might want to consider using one of the many licenses out there [1]. They are much more well understood and have been well thought out. Your license may leave out things that become important in the future. Based on what your license is trying to say, you may want to consider the MIT/X license, BSD (w/o advertising clause), or public domain. IANAL, but I have seen enough discussions about license issues becuase someone wrote their own and forgot something to think that it is usually a Bad Idea(TM). -Roberto [0] http://felix.sourceforge.net/current/www/licence.html [1] http://zooko.com/license_quick_ref.html -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpD0lXn55SIk.pgp Description: PGP signature
Re: License question about regexplorer
Quoting Roberto C. Sanchez [EMAIL PROTECTED]: Florian Weimer wrote: QPL is usually considered free, but its use is discouraged. An additional exception, as granted by OCaml for example, can improve things. Even though the license says this: You must ensure that all recipients of the machine-executable forms are also able to receive the complete machine-readable source code to the distributed Software, including all modifications, without any charge beyond the costs of data transfer, and place prominent notices in the distribution explaining this. Is this not similar to placing a restriction that binary distribution must be at no cost, or something similar? Is it OK in this case beacuse it only mandates that access to the source must be at no cost? I know that this OK in the case of Debian distributing the source, since there is no charge for people to access the mirrors, but I don't see how this complies with DFSG #1. If I want to sell someone a QPL program, I can only sell the binary and must give away the source. So is the source not part of the program for the purposes of DFSG #1? I don't mean to be belligerent. I just want to make sure I understand. I talked with Branden yesterday and he explained this rather clearly. The requirement in the QPL is no different than the requirement in the GPL that source either accompany the binary, or that a written offer be extended, good for 3 years, blah, blah, only charge a reasonable amount for copying and all that. Sorry for the misunderstanding. I withdraw my question. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: [gnu.org #243939] Question about 3-clause BSD and GPL compatibility]
Bas Zoetekouw wrote: Hi Roberto! You wrote: Per Branden's request, I am forwarding this to -legal. FSF says that the 3-clause BSD-type license is GPL-compatible. http://cvs.sourceforge.net/viewcvs.py/wx4j/modules/wx4j/LICENSE.TXT?rev=1.2view=markup ddd This is not a 3-clause BSD license, but rather an MIT/X11-like one, which is indeed compatible with the GPL Thanks for the clarification. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: License question about regexplorer
Florian Weimer wrote: * Roberto C. Sanchez: I have been recently checking out packages up for adoption or already orphaned. In the process I came across regexplorer [0]. Here are the dependencies of regexplorer and their respective licenses (as I understand it): * libc6 (LGPL) * libgcc1 (GPL w/ exception) * libqt3c102-mt (QPL/GPL) * libstdc++5 (GPL) * libx11-6 (MIT/X) * libxext6 (MIT/X) And the problem is that regexplorer is licensed under the plain QPL? Yes. My question is this. Is Debian accepting QT3 under the GPL or the QPL? As far as I know, Debian complies with the QPL requirements, so we can choose between QPL and GPL on a per-application basis. OK. So if someone offers a program under a dual license, it is possible to accept it under the terms of both licenses at the same time? Specifically: (1) is the exception for libgcc1 sufficient for regexplorer to link? Yes, as long as you use GCC to compile regexplorer. (2) is QT3 in Debian via QPL or GPL? It's dual-licensed. Same question as above. (3) is libstdc++5 actually GPL w/o exception? No, all source files should be covered by the usual exception. If they aren't, upstream considers this a bug. Oops. I went back and read the copyright file and saw right where I missed it. Additionally, it seems like QPL licensed code can't be in main QPL is usually considered free, but its use is discouraged. An additional exception, as granted by OCaml for example, can improve things. Even though the license says this: You must ensure that all recipients of the machine-executable forms are also able to receive the complete machine-readable source code to the distributed Software, including all modifications, without any charge beyond the costs of data transfer, and place prominent notices in the distribution explaining this. Is this not similar to placing a restriction that binary distribution must be at no cost, or something similar? Is it OK in this case beacuse it only mandates that access to the source must be at no cost? I know that this OK in the case of Debian distributing the source, since there is no charge for people to access the mirrors, but I don't see how this complies with DFSG #1. If I want to sell someone a QPL program, I can only sell the binary and must give away the source. So is the source not part of the program for the purposes of DFSG #1? I don't mean to be belligerent. I just want to make sure I understand. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
License question about regexplorer
I have been recently checking out packages up for adoption or already orphaned. In the process I came across regexplorer [0]. Here are the dependencies of regexplorer and their respective licenses (as I understand it): * libc6 (LGPL) * libgcc1 (GPL w/ exception) * libqt3c102-mt (QPL/GPL) * libstdc++5 (GPL) * libx11-6 (MIT/X) * libxext6 (MIT/X) My question is this. Is Debian accepting QT3 under the GPL or the QPL? According the FSF FAQ on licenses [1], the QPL says that modified sources must be distrubted as patches, and that linking to GPL code requires a license exception. However, it gets a bit more complex. I know that this has more or less been discussed before [2], but I think the circumstances have changed. Specifically: (1) is the exception for libgcc1 sufficient for regexplorer to link? (2) is QT3 in Debian via QPL or GPL? (3) is libstdc++5 actually GPL w/o exception? It seems that if any of those fails, then regexplorer can't link to them unless it is relicensed. Additionally, it seems like QPL licensed code can't be in main (which may or may not affect QT and any packages that depend on it, depending on how Debian chooses to make QT available), at least under the version used by regexplorer [3] [4]: QPL: 3. You may make modifications to the Software and distribute your modifications, in a form that is separate from the Software, such as patches. The following restrictions apply to modifications: ME: Ok. This is not reall a problem, since we distribute source as a .orig.tar.gz and a .diff.gz. This is clearly seperate. QPL: a. Modifications must not alter or remove any copyright notices in the Software. ME: No problem here either. QPL: b. When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer. ME: Does this mean that the Debian-specific packaging must be QPL licensed? It is a patch modification to the source. I presume that non-exclusive means Debian can continue to distribute the modifications themselves under other terms, e.g., the GPL. But, I think this implies the modifications must at least be dual/licensed. QPL: 4. You may distribute machine-executable forms of the Software or machine-executable forms of modified versions of the Software, provided that you meet these restrictions: ME: Ok. At least there is a chance to distribute the modified binaries. QPL: a. You must include this license document in the distribution. ME: No sweat. QPL: b. You must ensure that all recipients of the machine-executable forms are also able to receive the complete machine-readable source code to the distributed Software, including all modifications, without any charge beyond the costs of data transfer, and place prominent notices in the distribution explaining this. ME: Does this even comply with DFSG? This would imply that if make a CD which includes regexplorer (which is in main), then I can't charge money for it above the cost of duplication. QPL: c. You must ensure that all modifications included in the machine-executable forms are available under the terms of this license. ME: Not sure how that affects Debian's distribution of the package. Sorry if this has already been discussed, but I am trying to wrap my head around this. Also, please CC me on all replies, as I am not subcribed to -legal. -Roberto [0] http://pacakges.debian.org/regexplorer [1] http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses [2] http://lists.debian.org/debian-legal/2000/01/msg00203.html [3] http://cvs.sourceforge.net/viewcvs.py/*checkout*/regexplorer/regexplorer/QPL.html?rev=1.1.1.1 [4] http://packages.debian.org/changelogs/pool/main/r/regexplorer/regexplorer_0.1.6-12/regexplorer.copyright -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: [WASTE-dev-public] Do not package WASTE! UNAUTHORIZED SOFTWARE [Was: Re: Questions about waste licence and code.]
Peter Samuelson wrote: I know at least one developer on a prominent open source project who believes otherwise, and claims to be prepared to revoke their license to her code, if they do certain things to piss her off. Presumably this is grounded on the basis of her having received no consideration, since it's a bit harder to revoke someone's right to use something they bought and paid for. It is also possible that she's a looney. That is completely not possible. Once you offer (and someone accepts) code under the terms of the GPL, they are for evermore entitled to use *that* code under the GPL. About the only thing that can be done is to quite releasing new versions of the software or release newer versions under a more restrictive license. That, or hope everyone who receives the code violates the GPL (since that is about the only you lose your rights under it after the fact). Yes, I'm aware that if it's possible to revoke the GPL, it fails the Tentacles of Evil test, and GPL software would be completely unsuitable for any serious deployment. Note, however, that but it *can't* be that way because if it is, we're all in trouble is not a very strong argument. But it can't be done, period. Reference: http://www.gnu.org/philosophy/free-sw.html In order for these freedoms to be real, they must be irrevocable as long as you do nothing wrong; if the developer of the software has the power to revoke the license, without your doing anything to give cause, the software is not free. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: Question on gnuplot licensing and why it is in main
Henning Makholm wrote: No, because the quoted license explicitly allows the distribution of binaries built from modified sources. That kind of patch-clause licenses is specifically blessed by DFSG #4. OK. I think understand. qmail and pine are non-free because they disallow binary distribution, period. gnuplot can go into main since the Debian project distributes sources as a .orig.tar.gz and a .diff.gz (except for native Debian packages like apt)? For instance, if DFSG required the ability to distribute complete modified source as one monolithic entity, then that would be incompatible. Correct? I am just trying to make sure that I understand this, for my own edification. -Roberto P.S. Please CC me, as I am not subscribed to -legal. -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Question on gnuplot licensing and why it is in main
While looking at the gnuplot documentation (trying to figure out how to make a bar graph) I came across this in the FAQ: 1.6 Legalities Gnuplot is freeware authored by a collection of volunteers, who cannot make any legal statement about the compliance or non-compliance of gnuplot or its uses. There is also no warranty whatsoever. Use at your own risk. Citing from the README of a mathematical subroutine package by R. Freund: For all intent and purpose, any description of what the codes are doing should be construed as being a note of what we thought the codes did on our machine on a particular Tuesday of last year. If you're really lucky, they might do the same for you someday. Then again, do you really feel *that* lucky? 1.7 Does gnuplot have anything to do with the FSF and the GNU project? Gnuplot is neither written nor maintained by the FSF. It is not covered by the General Public License, either. It used to be distributed by the FSF, however, due to licensing issues it is no longer. Gnuplot is freeware in the sense that you don't have to pay for it. However it is not freeware in the sense that you would be allowed to distribute a modified version of your gnuplot freely. Please read and accept the Copyright file in your distribution. So, I checked the copyright file and found this: * Permission to modify the software is granted, but not the right to * distribute the complete modified source code. Modifications are to * be distributed as patches to the released version. Permission to * distribute binaries produced by compiling modified sources is granted, * provided you * 1. distribute the corresponding source modifications from the *released version in the form of a patch file along with the binaries, * 2. add special version identification to distinguish your version *in addition to the base release version number, * 3. provide your name and address as the primary contact for the *support of your modified version, and * 4. retain our contact information in regard to use of the base *software. * Permission to distribute the released version of the source code along * with corresponding source modifications in the form of a patch file is * granted with same provisions 2 through 4 for binary distributions. This seems very similar to the pine and qmail licenses (http://www.fsf.org/licensing/licenses/license-list.html#NonFreeSoftwareLicense) which would make it non-free. Is this correct? Should a bug be filed against the gnuplot* packages? -Roberto P.S. please CC me as I am not subscribed to -legal -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
OpenPBS/Torque license conclusion?
From the threads http://lists.debian.org/debian-legal/2004/debian-legal-200402/msg00108.html and http://lists.debian.org/debian-legal/2004/debian-legal-200403/msg00208.html, i think that the license for Torque and OpenPBS are not acceptable, because there is not consensus and people complained for many annoyances in the license text. I also noticed those annoyances, and this is the reason for which i've asked for opinions... so i agree with many of them. :-( It looks like people have tried to contact previously with the copyright holder, does anybody know of a response or a negotiation currently in process? -- Roberto Gordo Saez - Free Software Engineer Linalco Especialistas en Linux y Software Libre http://www.linalco.com/ Tel: +34-914561700
License for the Torque Resource Manager (RFC)
| NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, | EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | | This license will be governed by the laws of the Commonwealth of Virginia, | without reference to its choice of law rules. AFAIK: - Has the BSD advertising clause - GPL incompatible. - Source must be provided (like the GPL). - The expiration clause is dated in the past, so i think that sections 1 and 2 can't be enforced anymore. If we ignore those clauses, there is little information about redistribution remaining in the text, but i think that the permissive notice in the header is sufficient. - Looks like it is DFSG-free (please, confirm). Comments, aditional information are welcome, including concerns about the license. I want to be sure that the license is acceptable. -- Roberto Gordo Saez - Free Software Engineer Linalco Especialistas en Linux y Software Libre http://www.linalco.com/ Tel: +34-914561700
Re: Packages with non-original copyrighted sounds
Thomas Uwe Gruettmueller wrote: It is also urgently needed for the creation of free music that is not necessarily used by free programs. Due to the lack of free samples, composers are currently forced into the creation of non-free music. That's a similar problem to the font's one, i guess. It is really hard to make professional quality, original samples. Almost all samples that are distributed as freeware are extracted from digital synthesizers, actually copyrighted by the instrument manufacturer, and definitely not free. The DFSG does not really care about these things, and if it did, the GPL and the BSD would not qualify as free if applied on non-program-works. This means that Debian cannot become entirely free regarding the rights listed above in the near future, but it should be possible to create a subset of Debian that uses a clarified DSFG6 clause and thus cares about the above rights. Are public domain files (true public domain, copyright declined by the author) also restricted by default? -- Roberto Gordo - Free Software Engineer Linalco Especialistas en Linux y Software Libre Tel: +34-915970074 Fax: +34-915970083 http://www.linalco.com/
Re: Packages with non-original copyrighted sounds
Found another one: package powermanga-data is shipped with a sound that comes from Windows 95 sounds (file bonus4.wav). The file contains the strings Microsoft Corporation and Windows 95 Utopia Sound Scheme. Should bugs be filled against mentioned packages? -- Roberto Gordo - Free Software Engineer Linalco Especialistas en Linux y Software Libre Tel: +34-915970074 Fax: +34-915970083 http://www.linalco.com/
Re: Packages with non-original copyrighted sounds
On Mon, May 26, 2003 at 01:03:28AM -0400, Anthony DeRobertis wrote: It is very likely that the same occurs with icons, images and other artwork. A lot of the icons in, e.g., GNOME are Tigert's original works. Yes, they are. But it is easy to find other cases; this is from SciTE source file gtk/pixmapsGNOME.h: // Set of images for tool bar buttons // Icons Copyright(C) 1998 by Dean S. Jones // http://jfa.javalobby.org/projects/icons/ // Modified to have same names as tigert.h // Not really anything to do with Gnome - just calling this // file pixmapsGNOME to fit in with previous code. [...] The icons can be downloaded from http://sourceforge.net/projects/icon-collection/, since the main site does not work. The README file says: [...] You are free to use them [the icons] in your programs, but I am retaining Copyright, and they can not be used in any books, CD-ROM's, Web pages, or any other form of image collection without my consent. I ask that if you do use them to drop me some e-mail at [EMAIL PROTECTED], also, if a screen shot of your application using these icons is available I will add a link to it from this page. I would please me greatly if you would add a little blurb in something like a ``Help about..'' screen like: Icons Copyright(C) 1998 by Dean S. Jones [EMAIL PROTECTED] www.gallant.com/icons.htm [...] Anyway, from the feedback received from my previous message it seems to me that very few people care about that nor consider it to be a problem. Regards. -- Roberto Gordo - Free Software Engineer Linalco Especialistas en Linux y Software Libre Tel: +34-915970074 Fax: +34-915970083 http://www.linalco.com/
Packages with non-original copyrighted sounds
While looking at the game chromium came to me the idea of taking some of the sound effects and loops for other unrelated tasks, so i skimmed through readme and copyright files. Since only the license for the whole game is there (the same that is in the upstream sources), i've assumed that the individual sounds are under the same terms. But casually i found this in chromium's homepage: Music Loops and raw Sound Effects from: Partners in Rhyme [http://www.partnersinrhyme.com/] FindSounds.com [http://www.findsounds.com/] That make me suspect that the sounds are under a different license or, at least, requires a different copyright citation or author acknowlegde than the game itself when used individually. www.findsounds.com is a search service for sound files in the Web, and states that the sounds may be copyrighted, with a disclaimer: http://www.findsounds.com/cpolicy.html That does not look good to me. Not sure, but seems like a bunch of files with unknown copyright. Please, note that i do not want to restart here the discussion for whether data that is not software should be strictly adjust to the DFSG or not (although personally, i would really appreciate that, or at least a clear identification). Since that, i looked into some old games that remains installed in my system since years, and i quickly found this: - mirrormagic and rocksndiamonds: Music by Tangerine Dream, ripped from albums by this group. The files are very short fragments repeated in a loop. - xboing: Years ago i recognized a sound that was ripped from the movie Aliens, when a soldier (don't remember name) says Game over man!. I've never gave importance to this (until now ;-) Please, note that i'm not a lawyer and have no idea of the legal issues with such sort samples, but this is not what i want to emphasize here. I looked only at 4 programs and all contains non-original sounds! I am sure that there are many more... but that not only affect to games. Package timidity-patches has been in Debian main (and is still there), and turned out to be non-free (completely non-free, not even suitable for the non-free section). See http://lists.debian.org/debian-legal/2002/debian-legal-200209/msg00099.html It seems that also many (probably all) tracked music files (XM, IT, MOD) included in Debian packages contain unidentified or ripped samples. IMHO, i believe that there are an urgent need for a library of free sound, music, samples, etc. to take as a base to ease the creation of free software which need sounds. The library should asure at least that: - The author of each file is clearly identified and acknowledged. - License is sufficiently permissive to be clearly compatible with Debian guidelines. It is very likely that the same occurs with icons, images and other artwork. Maybe i am a little strict with that issues ??. Comments and ideas are apreciated. -- Roberto Gordo - Free Software Engineer Linalco Especialistas en Linux y Software Libre Tel: +34-915970074 Fax: +34-915970083 http://www.linalco.com/
Re: Question on wxWindows packages
--- Adam Warner [EMAIL PROTECTED] escribió: Hi Roberto Sanchez, Roberto, this is a standard permissive MIT/BSD-style licence that has no advertising clause and is GPL compatible. The ambiguity in the without fee section is frequently misinterpreted (it means you can do everything listed without payment of any fee to the licensor). For this reason it's best left as an historical licence and not used for new software projects. The OSI calls it the Historical Permission Notice and Disclaimer: http://www.opensource.org/licenses/historical.php The GPL-incompatible BSD advertising clause is different from a copyright notice appearing in the supporting documentation. You can read about the advertising clause here: http://www.gnu.org/philosophy/bsd.html. Welcome to Debian. Regards, Adam Adam, Thanks for the info. Those links provided some good reading. -Roberto ___ Yahoo! Messenger - Nueva versión GRATIS Super Webcam, voz, caritas animadas, y más... http://messenger.yahoo.es
Question on wxWindows packages
I came across the following while reading the wxWindows documentation (from the wxwin2.4-doc package): We also acknowledge the author of XFIG, the excellent Unix drawing tool, from the source of which we have borrowed some spline drawing code. His copyright is included below. XFig2.1 is copyright (c) 1985 by Supoj Sutanthavibul. Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of M.I.T. not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. M.I.T. makes no representations about the suitability of this software for any purpose. It is provided as is'' without express or implied warranty. This text can be found at the following URL after apt-get'ing wxwin2.4-doc: file:///usr/share/doc/wxwin2.4-doc/wxWindows-manual.html/wxwin9.htm#topic6 It is my understanding that requirement to preserve the copyright notice and persmission notice are something from a BSD-type license. Is this compatible with the GPL? Does this apply to only the documentation package or also to the others (since the code would be in the library and development packages)? I am pretty sure that all or most of the wxwindows packages are in the main part of the repository. Do they belong in nonfree or contrib because of this? I apologize if this has been asked before or if I am off base, but I am still learning my way around Debian. -Roberto Sanchez ___ Yahoo! Messenger - Nueva versión GRATIS Super Webcam, voz, caritas animadas, y más... http://messenger.yahoo.es
Re: Timidity-patches eek
David Given [EMAIL PROTECTED] wrote: Looking into it, timidity-patches turns out to have been put together from patch files taken from the Midia patch set, distributed with the Midia MIDI renderer that ran on SGI workstations. Midia and its patch Yes, i've been suspecting that, because of the FreeBSD legal file. Timidity is considered non-free by FreeBSD: (http://www.freebsd.org/cgi/cvsweb.cgi/ports/LEGAL?rev=1.254content-type=text/x-cvsweb-markup) DistPortWhy -- [...] timidity-* ports/audio/timidityUses copyrighted patches. Well, the program is free (should go into contrib?). If you are looking for collection of instruments, give a look at samplenet (samplenet.co.uk). They have an enormous collection of original, non copyrighted, public domain samples both in wav and mp3 for free download, with multiple samples for each instrument. Unfortunately, the site is closed now, but they say that it is for a short time while the data is reorganized. I wonder how difficult will be to make a new set of patches for timidity... any volunteer?
