Re: Does this license meet DSFG?
Anthony W. Youngman deb...@thewolery.demon.co.uk wrote in message news:mp+abdfeudxlf...@thewolery.demon.co.uk... In message 20100410130817.gq25...@anguilla.noreply.org, Peter Palfrader wea...@debian.org writes So I cannot combine a work licensed under this license with a work licensed under GPL3 + SSL exception because the latter does not allow downgrading to gpl2 (or upgrading to gpl3+). I think you're wrong here. Being pedantic, NO version of the GPL allows regrading. It's the grant of licence that allows the regrading. Is this intentional? No. Because the grant of licence DOES allow regrading, therefore what any particular version of the GPL says is irrelevant. The recipient CAN change the licence from GPL3 to GPL2 (or vice versa) because the *grant* gives him permission. Except the grant as stated in awful license grant posted appears to be approximately the following the following: - 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. As a special exception you may link this work with OpenSSL as long as you comply with its license, and comply with the GPL v3 (or at your option) any later version in all remaining respects, provided that the terms OpenSSL's licence contain no additional GPLv3 (or the later version you chose) incaptible terms relative to the version of the licences used by OpenSSL 1.0 in May of 2010, and under the condition that any recipients can upon removal of OpenSSL use this work under their choice of one the following: * no version of the GPL * GPL v2 only * GPL v3 only * GPL v2 or V3 only * GPL v2 or later * GPL v2 or later (except for V3) * GPL v3 or later * only versions later than GPL v3 -- That is pretty much what the terms currently say. I'm pretty sure that last part was not fully intended tro come out like that, but that is how the terms currently appear to read. That is why doing things like seperately listing V2, V3, and post V3 as seperate items was very stupid. What the grant writer actually wanted was most likely: --- 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. As a special exception you may link this work with OpenSSL as long as you comply with its license, and comply with the GPL v3 (or at your option) any later version in all remaining respects, provided that the terms OpenSSL's licence contain no additional GPLv3 (or the later version you chose) incomptible terms relative to the version of the licence used by OpenSSL 1.0 in May of 2010. That requires users to abide by V3 or later terms while using the SSL exception, allowing for any changes in the OpenSSL licence that do not make the OpenSSL license less compatible with the chosen version of the GPL than the current license is. (Changes that don't impact compatibility, or that increase compatibility with the GPL being of course permmitted). Of course that last clause could use a bit of cleaning up, and may have minor grammar or spelling issues, but I think I captured the basic idea. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hqdiu7$4j...@dough.gmane.org
Re: Skype/Facebook trademark logos in Debian packages
Gunnar Wolf gw...@gwolf.org wrote in message news:20091125220338.gb24...@gwolf.org... Mike Hommey dijo [Tue, Nov 24, 2009 at 10:30:58AM +0100]: More than the trademark fair use problem, there is one of a license one: Are these logo really free ? (keep in mind that for example, the Firefox logo is not, whatever the trademark status is) Depends on its source. If I were to draw a very-similar-but-not-identical Firefox logo, its copyright would be mine, but I would be breaching their trademark. The other part of this is that if if you are trying to recreate the original logo, while not directly copying it, the result could still be a derivative work, especially if you are reffering to the original during the creation. Paining replicators (people who attempt to recreate a painting, as closely as possible, but without try to pass the new copy of as the original (so they are not forgers)) are an example of an area where this concept often bites people. Even If I own the only authentic copy of a painting in the world, if the painting is recent enough to still be protected under copyright law, then I cannot have my painting replicated without permission from the copyright holder (which my be me if i am the artist, comissioned the work, or purchased/inherietd the rights to the work), since any such replica would be either a derivitve work under copyright law (should there be sufficent creativity), or be a considered an unauthorized copy under copyright law. Now I looka at the other extreme. In theory, with copyright if you independently create a work that happens to be absolutely identical (say letter by letter or pixel by pixel), without even knowing about the other work, then the result is two works each with a seperate copyright that just happen to be indistinguishable. Of course that is scholarly theory, and the law in the real world is ill equiped to handle such a possibility. (I speak loosly above, talking about a work having a copyright. I obviously mean that the authors or some other rights holder (such as in the case of a work for hire) being granted a limited monopoly on repdoucing the work, among other things.) For the record, IANAL, IANADD. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Looking for +info about the license of a new package: Ossec
Jose Antonio Quevedo wrote: [snip] The license can be founded here: http://www.ossec.net/main/license/ What can you tell me about it? I find the the fact that they belive including the program in a propritary installer executable creates a derivitive work worrysome. Normally that is considered mere aggregation, and only rquires that they make the source available. Then there is the worry that they feel that any program that executes their code is a derivative work. I've seen plenty of propritary programs that include GPL'd programs in the background interacting with them soley through the limited interfaces the program provides on the command line. AFAIK the FSF has always considered that acceptable. This allows things like proprietary GUIs to be built around GPL'd programs. An execlent example would be a propritary IDE built around GDB, GCC, and GNU Make. That would be considered acceptable, and standard procedure would be to include the GPL''d programs in the same installer executable. Further the if-it-executes-this-code-it-is-a-derived-work interpretationimpacts not just propritary software, but free software that wished to utilize the program. It is especially troublesome since it prevents a gui wrapper that is free, but has a GPL incompatible license from being permitted. Now this is all assuming that a court is willing to accept Ossec's interpretation, and not use the more traditional interpretation, but since it is usually better to fall on the side of caution, this is a good assumption to make. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The Clearthought Software License, Version 2.0
jochen georges gnu...@gnugeo.de wrote in message news:200906221753.51922.gnu...@gnugeo.de... /* * * * The Clearthought Software License, Version 2.0 * * Copyright (c) 2001 Daniel Barbalace. All rights reserved. * * Project maintained at https://tablelayout.dev.java.net * * I. Terms for redistribution of original source and binaries * * Redistribution and use of unmodified source and/or binaries are * permitted provided that the following condition is met: * * 1. Redistributions of original source code must retain the above *copyright notice and license. You are not required to redistribute *the original source; you may choose to redistribute only the *binaries. * * Basically, if you distribute unmodified source, you meet * automatically comply with the license with no additional effort on * your part. Unmodified redistribution in source and binary forms are effectively conditionless. This is good. * II. Terms for distribution of derived works via subclassing and/or * composition. * This section can be ignored, as long as all derivities are made using section 3. * * III. Terms for redistribution of source modified via patch files. * * You may generate derived works by means of patch files provided * that the following conditions are met: * * 1. Redistributions of original source code must retain the above *copyright notice and license. You are not required to *redistribute the original source; you may choose to redistribute *only the binaries resulting from the patch files. That is all fine. * 2. The original source files are not altered. All alteration is *done in patch files. * This is explicitly allowed by DFSG 4. * 3. Derived works are not contained in the info.clearthought *namespace/package or any subpackage of info.clearthought. This *means that your patch files must change the namespace/package *for the derived work. See section II for examples. This one is tricky. This may be acceptable under DFSG 4. It is clearly within the spirit of DFSG 4. * 4. Derived works do not use the class or interface names from the *info.clearthought... packages. This means your patch files *must change the names of the interfaces and classes they alter. *See section II for examples. If each class/interface is considered a seperate work, then this is probably acceptable under DFSG 4. * 5. Derived works must include the following disclaimer. *This work is derived from Clearthought's TableLayout, * https://tablelayout.dev.java.net, by means of patch files * rather than subclassing or composition. Therefore, this work * might not contain the latest fixes and features of TableLayout. This may be a problem. The idea here is to warn users that this, although a derivitive of the TableLayout package, will not automatically inherit the latest fixes and patches by merely installing the Tablelayout Java classes. * IV. Terms for repackaging, transcoding, and compiling of binaries. * * You may do any of the following with the binaries of the * original software. These are additional permissions for binary files. This basically is giving explict permission to transform the binaries to whatever form is most suitable. I see no issue here. * 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 THE AUTHOR, AFFILATED BUSINESSES, * OR ANYONE ELSE 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. * */ Reasonably standard disclaimer. There are no freeness issues here, that i can see. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#523093: undetermined copyright/license violation
Robert Millan r...@aybabtu.com wrote in message news:20090410200117.gb30...@thorin... On Fri, Apr 10, 2009 at 09:15:39PM +0200, Francesco Poli wrote: On Thu, 09 Apr 2009 20:38:33 -0400 Hubert Figuiere wrote: [...] Except that the original files don't have any notice. For those that did, the notice has been kept. In that case, I personally think the safest strategy is including such notice, even though it was not present in the first place. This is getting extreme. If the original author didn't bother asserting their copyright, why would one have to do it in the modified version? Fully agreed that adding a full copyright statement for the past contributers seems excessive. What would not be excessive is a note along with the new copyright statement that others hold copyrights to parts of the file, but chose not to add a full notice at that time. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GCC 4.4 run-time license and non-GPLv3 compilers
Stéphane Glondu st...@glondu.net wrote: So one could even make a proprietary compiler using C as an intermediate langage, and GCC for the final stage, I guess. Comeau C++'s GNU/Linux builds do exactly that. (In general it uses the local C compiler as a slightly higher level assembler. This saves them the work of needing to write a backend for every target platform. They do need to tweak the C-backend for specific platforms/compiler combinations, so as to be able to maintain maximum performance of the final binary. That is especially true of the exception feature, which has always been problematic for similar efforts.) -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Combining Apache with GPL in one package - Re: libxdoclet-java_1.2.3-2_i386.changes REJECTED
Florian Grandel wrote: I have to make a correction from my earlier post. I said: core library licensed under GPLv2 This is not true. See [1] for the core xdoclet license which doesn't seem to be any standard license. The licence you linked to is the standard 3-clause BSD. They even forgot to change the word REGENTS in the disclaimer. You probably did not recognize the licence because it has been reformated slightly, such that there are no bullet points next to the clauses. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FLTK License
Giacomo A. Catenazzi c...@debian.org wrote in message news:49c8da6f.7050...@debian.org... 4. You do not have to provide a copy of the FLTK license with programs that are linked to the FLTK library, nor do you have to identify the FLTK license in your program or documentation as required by section 6 of the LGPL. However, programs must still identify their use of FLTK. The following example statement can be included in user documentation to satisfy this requirement: [program/widget] is based in part on the work of the FLTK project (http://www.fltk.org). The December version has the above statement. The inclusion of such a statement appears to be a limitation on the the permission to omit the LGPL licence text. Even if that is not a limitation on this new permission, in this wording, the existing requirements of the LGPL to preserve copyright notices appears equivlent. Indeed all of the december licence appears to be additional permissions. It would be preferable if it were clear if this is really just the GPL+special exceptions, such that derivitives could remove the special exceptions. If it is not intended to be such, the FSF would probably take issue with this license So, my thought are that the December version is free, being just LGPL+additional permissions. I also tend to think it is fully GPL compatible, although I would really prefer clarification on it being just standard removable special exceptions. Unfortunately the same is not true of the May version: 4. Authors that develop applications and widgets that use FLTK must include the following statement in their user documentation: [program/widget] is based in part on the work of the FLTK project (http://www.fltk.org). That requirement is free, but makes this GPL-incompatible. This also appears to be an abuse of the LGPL, which should never have additional restrictions attached to it. Reccomendation: Check with upstream to see if the December version applies to libfltk2. If so, that is good. If not, try to convince them to update it to use the new license or preferably, an even newer version of the license that uses the standard special exception terms. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Creative Commons CC0
Ben Finney ben+deb...@benfinney.id.au wrote: I'd hardly call that “the whole point” of the licenses; if anything, it's a property of how they're used. Fair enough It's also a pretty poor practice: it makes access to that specific document online a pre-condition to knowing the license terms in the work at any given time, and it denies the possibility of the URL leading to a different document (or to nothing) at some arbitrary future time. But Cool URIs don't change [0]. :-D In reality you have a point. The hope is that there would be few enough CC licenses that most people would know the basic terms well enough that they never really need to look them up, but people do need internet access to look them up the first time, as well as if they ever have a detailed question that you require scrutenizing the Legal Code. Nonsense. Exactly the same approach could be taken with the Expat license; this is not a distinguishing feature of the Creative Commons licenses. One could, except for the fact that the Expact License terms assume that the license is included as part of the work itself, alongside the copyright notice. It is somehat difficult to meat the condition The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. if you are just linking to http://www.jclark.com/xml/copying.txt or annother online copy of the license. Of course, an MP3 is also software :-) and is equally valid as a work for applying the Expat license. Of course. The only issue is that dragging around the license text in an MP3 ID3 tag is a pain. [0] http://www.w3.org/Provider/Style/URI IANAL, IANADD. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Creative Commons CC0
Ben Finney wrote Yes. If anything, the length of verbiage that Creative Commons feels necessary to effectively place a work in the public domain, under the current copyright regime, only supports the idea that it's significantly *more* complicated than working with copyright and using an appropriate license. The legal code is long and complex, because it can be. The whole point of the Creative Commons Licenses is that the license text is not included with the work, but instead just the license URL is included. Therefore it is in the interest of everybody to ensure it covers everything to the greatest extent possible. Thus the CC0 licence takes only one line to apply to a work. #authornamemakes this work avilable under CC0 (http://creativecommons.org/publicdomain/zero/1.0/) That is a heck of a lot simpler than including the Expat license, and people can easilly recognize it. With Expat or similar licenses, you should always be looking very closely to make sure no words were changed, or if they were changed, to determine the relevance of the changes. Of course, for software sticking with Expat makes good sense, but Expat could be a bit of a pain to use as the license for an mp3 (for example). IANAL, IANADD. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Short copyright notice in script file
Ken Arromdee arrom...@rahul.net wrote in message news:20090322071908.98b07b...@violet.rahul.net... First sale in the US only applies if the product was made in the US. Where on Earth did you hear or read that? I've never head such a thing. http://supreme.justia.com/us/523/135/case.html Read carefully the sections describing 602(a), particularly page 148. # copies that are not subject to the first sale doctrine-e. g., copies # that are lawfully made under the law of another country Hmm, interesting... Without scutinizing the code, and reading the entire order I cannot see what exactly is being implied there. Some of the text appears at a quick glance to imply that giving away a legally owned copy is always allowed unless barred by contractual restircitions, regardless of origin, and it is the right of sale may be lacking in some imported works. But I only read bits very quickly so I may be completely wrong. IANAL, IANADD. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Short copyright notice in script file
Ken Arromdee arrom...@rahul.net wrote: First sale in the US only applies if the product was made in the US. Where on Earth did you hear or read that? I've never head such a thing. IANAL, IANADD. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Short copyright notice in script file
Alexander Block wrote: MJ Ray wrote: There's no clear permission to distribute in any way, so it's not great. I believe we're unlikely to get sued for it, but it would be better if Matt Johnston had used a widely-known licence instead of that. Best course of action is to request relicensing. [snip] thanks for the response. I asked Matt about changing the copyright notice and he changed it to the following: # (c) 2004 Matt Johnston matt @ ucc asn au # This code may be freely used, distributed, relicensed, and modified for any # purpose. Does that sound ok for Debian? It is still not a great license, but the reference to distributing helps, and I belive the word relicense implicitly grants rights to create derivitives, (since there are no restirctions placed on the new license the new license can allow derivitives.) If the version distributed is modified, you should extend the notice to declare what license you choose to relicense it under. The Expat license is a good choice. IANAL, IANADD. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Transitive Grace Period Public Licence
MJ Ray m...@phonecoop.coop wrote: in which I dare OSI to sue me for describing TGPPL as Open Source: http://www.crynwr.com/cgi-bin/ezmlm-cgi?17:mss:531:200902:ofpndmgcgmbhbmimpkpe The OSL copyright holder is Lawrence Rosen, not OSI, so I think it is Lawrence Rosen, not OSI, who could sue you. In case that's so, I don't want to repost the copyright-infringing licence for detailed commentary. The OSL gives permission to create derived licenses. Granted there is a condition attached, which Zooko is aparrantly violating, relating to use of the term open source, but it is not clear if that term is enforcible. Any which way, Lawrence Rosen did comment on the licence on the OSI lince approval mailing list several times withou bringing this up, so he may belive it is a non issue. It would be worth asking him. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License issue on tiny Javascript fragment
Ben Finney ben+deb...@benfinney.id.au wrote in message news:874oyuq3ki@benfinney.id.au... Joe Smith unknown_kev_...@hotmail.com writes: This new version is the very definition of a function too trivial to copyright That's a pretty strong assertion. The “very definition of” as defined where? Or what, exactly, are you claiming? That was intended to be hyperbole. But, surely if any code could reasonably be claimed to be too trivial for copyright protection to apply, that work could. You also seem to be under the misapprehension that “to copyright” is something that a creator does to a work. It's not. Instead, copyright is an automatic monopoly granted *to* the creator; under the Berne convention, nobody decides “to copyright” a work. I am well aware of that, but trying to use more accurate phrasing like too trivial for copyright protection to apply, made the sentence sound awkward. You are of course correct that I should have used better phrasing here. “Difficult to read” isn't the same thing as “non-creative”. On the contrary; you have demonstrated that someone can creatively decide on different creative expressions of the same work, to the extent that you contrast your expression with one that differs in its uses of variable names and whitespace. Yes, but use of the most trivially functional possible version minimizes the amount of creative content. If I write a phonebook, in which I hand selected the order of names such that they fit an acrostic, that may very well be be subject to copyright. But it is well established that the standard alphabetical ordering is purely functional (non-creative). Moreover, I'm not aware of a valid legal theory that use of variable names or whitespace have any bearing on whether a particular work is subject to copyright. In general no variable names and whitespace should not make a difference, although surely by minimizing the amount of potentially creative content in a work makes it less likely to fall on the side non-trivial, rather than trivial. Normally only on edge cases should variable names or whitespacing make a difference. However the edge between sufficently creative to subject to copyright protection, and innsufciently creative to be subject to copyright protection is certainly not well defined. Therefore, for this purpose, it was decided to err on the side of caution. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License issue on tiny Javascript fragment
Colin Turner c...@piglets.com wrote in message
news:498d8af3.7030...@piglets.com...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi All,
I hope you can help and advise on this issue. I am packaging a web
application for Debian, I am also the principal upstream author. The
code is generally GPL v2 PHP. Over the years the project inherited, from
a side project, a small fragment of Javascript that has no explicit
license.
The problem I have is that the code is, like so much JS, sitting
available, apparently for general consumption on several websites. I
have been unable to acquire a license from any of the authors (no reply
to emails) and the code is so astonishingly trivial it's hard to see how
it could possibly be re-implemented without it being the same code with
different variable names.
Any guidance on what I should do? The functionality the code provides
(counting and capping characters in textareas) is quite useful and
losing it would probably cause dataloss in use of the application.
CT.
Code follows...
// Use one function for multiple text areas on a page
// Limit the number of characters per textarea
Here, is a clean room implmentation of a drop-in compatible (same argument
order) function that will do the job.
function functionName(textObject,sizeRemainingObject,maxSize)
{
textObject.value=textObject.value.substring(0,maxSize);
sizeRemainingObject.value=maxSize-textObject.value.length;
}
Compared to the above it works the same, except that the second parameter
will always be updated, to the number of characters remaining. Seeing as
this appears to be intended to limit the size of text input in a textarea,
while visually displaying the number of characters left in something else,
that should be fine.
(Yes I've checked, and substring does the right thing here).
This new version is the very definition of a function too trivial to
copyright, even the variable names and whitespaceing are as non-creative as
possible. (Although I would recomend reformatting the whitespace used to be
more readable).
Use it and be happy.
Joe Smith
--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Which license am I looking for?
Anthony W. Youngman deb...@thewolery.demon.co.uk wrote: Actually, iiuc, no they are not. It sounds like the LGPL 2 would satisfy your requirements. And while there is no LGPL 3 (and I don't think there will be), the GPL 3 has optional relaxation clauses, one of which makes it a replacement for the LGPL. There most certainly is an LGPL3! See http://www.gnu.org/licenses/lgpl.html IANAL. IANADD. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ITP: ssreflect -- small scale reflection extension for the Coq proof assistant
MJ Ray m...@phonecoop.coop wrote: I think we've consensus on software that uses CeCILL (upgradeable to GPL, so meets DFSG) and we've discussed CeCILL-C, but what do we think of B? My searches didn't find much discussion of it here, or any packages in the archive using it yet. A copy follows. Please cc the bug report on relevant replies. My concerns are the infinitely-recursive definition of Software in 1, deemed acceptance of the licence by downloading (possibly before seeing the licence) in 3.1, the disconnected advertising requirement in 5.3.4.3 and the choice of Paris as venue in 13.2. There seems no obvious GPL-upgrade escape route this time. 5.1 RIGHT OF USE The Licensee is authorized to use the Software, without any limitation as to its fields of application, with it being hereinafter specified that this comprises: 1. permanent or temporary reproduction of all or part of the Software by any or all means and in any or all form. 2. loading, displaying, running, or storing the Software on any or all medium. 3. entitlement to observe, study or test its operation so as to determine the ideas and principles behind any or all constituent elements of said Software. This shall apply when the Licensee carries out any or all loading, displaying, running, transmission or storage operation as regards the Software, that it is entitled to carry out hereunder. Right to use, copy, and reverse engineer (that last one seems odd since any work under this license would come with source code). Good so far. 5.2 ENTITLEMENT TO MAKE CONTRIBUTIONS The right to make Contributions includes the right to translate, adapt, arrange, or make any or all modifications to the Software, and the right to reproduce the resulting software. The Licensee is authorized to make any or all Contributions to the Software provided that it includes an explicit notice that it is the author of said Contribution and indicates the date of the creation thereof. This is a right of modification, although it is VERY poorly worded, due to the choice of the word contributions, when in fact the changes may be under a license that does not allow for the Licensor to integrate these contributions upstream. The changelog requirement requirement here is of course fine. The plain text here strongly implies that a pseudonym is sufficent for identification. 5.3 RIGHT OF DISTRIBUTION In particular, the right of distribution includes the right to publish, transmit and communicate the Software to the general public on any or all medium, and by any or all means, and the right to market, either in consideration of a fee, or free of charge, one or more copies of the Software by any means. Nothing but a clarification of what distribution entails. Commerical distribution is clearly allowed wherever distribution is allowed, and there are no restristions on the publication medium. The Licensee is further authorized to distribute copies of the modified or unmodified Software to third parties according to the terms and conditions set forth hereinafter. The words further authorized here should be scrapped, as it makes it sound like the previous paragraph is actually authorizing something, when in fact it is not. 5.3.1 DISTRIBUTION OF SOFTWARE WITHOUT MODIFICATION The Licensee is authorized to distribute true copies of the Software in Source Code or Object Code form, provided that said distribution complies with all the provisions of the Agreement and is accompanied by: 1. a copy of the Agreement, 2. a notice relating to the limitation of both the Licensor's warranty and liability as set forth in Articles 8 and 9, and that, in the event that only the Object Code of the Software is redistributed, the Licensee allows effective access to the full Source Code of the Software at a minimum during the entire period of its distribution of the Software, it being understood that the additional cost of acquiring the Source Code shall not exceed the cost of transferring the data. The terms on distribution of unmodified sources are trivially Free. 5.3.2 DISTRIBUTION OF MODIFIED SOFTWARE If the Licensee makes any Contribution to the Software, the resulting Modified Software may be distributed under a license agreement other than this Agreement subject to compliance with the provisions of Article 5.3.4. Ok, modified versions may be reliced under any license at all as long as the following conditions are met: 5.3.4 CREDITS Any Licensee who may distribute a Modified Software hereby expressly agrees to: 1. indicate in the related documentation that it is based on the Software licensed hereunder, and reproduce the intellectual property notice for the Software, Your modified version must include a note in a documentation. Presumably putting the notice near any other copyright notices, would qualify, so if such notices are in a sereate peice of
Re: deluge and GeoIP database license
Cristian Greco wrote: Hi all, I'm working for a new upload of deluge[0] (bittorrent client). The source tarball includes a GeoLite Country (binary) database by MaxMind, which should be distributed using the license[1] below. I've found that ktorrent (CCing to pkg-kde-extras, please CC your replies because I'm not subscribed) uses the same DB by MaxMind, but that license has been considered non DFSG-free two years ago by the list[2]. Well, the actual license seems to be different from the previous one, and in particular it probably lacks of the non DFSG-compliant text. The licence text as shown has no DFSG issues. The avdertising clause is annoying but it does not make it non-free. If and only if the other licenses really do not apply to the data, and that upstream is not just lying by not showing those notices anymore, then there is no problem with the data being included in main. Doubts: 1) Is this license really suitable for distribution in main now? 2) If so, what about ktorrent? Should they update their copy of the database in order to avoid source repackaging? From your other message it sounds like ktorrent may still have another reason to repackage, so little is gained by updating the copy. If that is not the case, then updating the copy to avoid repackaging sounds like a good idea. Disclamers: IANADD, IANAL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: licensing issue at APT
Andre Felipe Machado [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, The most recent source package could be downloaded from http://packages.qa.debian.org/a/apt.html For convenience, attached is the file to be analyzed (COPYING). Please, what are the possible consequences of removing the Qt portion or leaving the file as it is? Concequences includes a slightly smaller package size. That is about the extent of it. You are obligated to supply a copyright and license notice no less valid than the one you were given, and to follow any other terms of the license. The license in this case, does request that notices that refer to it be kept intact, but that applies only the the first section of the notice in the COPYING file. The rest is a notice of other terms, which are no longer in force. The GPL does not require that notices refering to other licenses must be kept intact. Since the other notice no longer applies, if you remove it the remaining notice is still no less valid, so all your obligations are satified. Therefore, it is perfectly safe to remove the old section refering to Qt. There are no legal consequences for doing so, only practical consequences, such as having a smaller and easier to read COPYING file. IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Alternatives to Creative Commons
The following is a bit of a late reply, but I is probably still worth making. Matthijs Kooijman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] In short, I think it is better to avoid the matter alltogether and not try to make section 3 apply to this work. This automatically happens when you apply a strict interpretation of object code and executable form. Since not applying section 3 is not really a problem for us, I mainly want to confirm if this interpretation of the GPL is in fact an acceptable one. The interpretation you made here was perfectly reasonable, although to be on the safe side, when using works from pther people one should include any form of source they reasonably can to sastify all reasonable interpretations. When a person releases thier own work under the GPL it is never a problem for them to interpret the terms more permissively than some other might. So I see no issue, unless you try to rely on your interpretation when using GPL'd work from a different copyright holder. In that event you would want to clarify the potential ambiguity with them first, or just stay on the side of caution, and include source according to what seems to you to be the preferred form of further modification. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: geotrans license: asking for advice
Peter S Galbraith [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Roberto Lumbreras [EMAIL PROTECTED] wrote: 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/ I'm quite surprised that they are not claiming copyright under US law, but yet claim copyright under other jurisdictions (if I understood correctly). Traditionaly, software developed by the US government has had no copyright (i.e. public domain). It is strange to see an outfit cliam it only in other jurisdictions. Seems to go against the principle. This interpretation of the relevent clause of the constitution has been around since the begining. The Government can own copyright on works they developed, but are barred from enforcing the copyright inside the country or against American citizens. (It is one of those, or perhaps both, I don't rember which.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: independent.nu - DFSG compatible?
Don Armstrong [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The key words here are what totally free means, and what use means. If totally free means you have the freedom to do anything you wish with these works then that's a different meaning entirely than you don't have to pay for these works. Likewise, if use means just perform, then it's totally different from a standin for use in any manner, including but not limited to modifcation, distribution, and performance. Well, the word fri (plural/definiate-form fria) in Swedish is exactly equivlent to the English word free including the meanings libre, gratis, without (e.g. lead-free), and not blocked (available, like a free seat at a table). So there is no help there. I cannot find information about the meanings of använda to fins out how closely it mimics the english word use, but i will note that all online sources do claim that the correct english translation for the verb använda is the verb use So that does not help either. Clarification from the copyright holder would help a lot here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DFSG compatibility of the Poetic License
Ben Finney [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Maximilian Gaß [EMAIL PROTECTED] writes: These rights, on this notice, rely. Is this meant to have some legal meaning? Or should we ignore it? The poem is obviously a form of translation of a simple permisive license like the expat license. That line attempts to embody the concept that the notice must be maintained, as the rights granted in the notice rely on the notice. By removing the notice, you removed that on which the licence relies and lose the license. But of course, you know that already, having read the blog post, and even posted there. Your guess is as good as mine on how a court would interperate that line. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Glade no longer generates C source code
Neil Williams wrote: On Sun, 2008-08-31 at 04:17 +0300, Sami Liedes wrote: I grepped the source tarballs in Lenny (testing) main section for the note DO NOT EDIT THIS FILE - it is generated by Glade. which indicates the file is generated using the Glade UI editor. Then I checked if these packages have any *.glade* files, which would be the Glade projects, i.e. the source code (at least in the GPL sense, preferred form of modification) for these. For those of these packages for which this is not a false alarm, I believe this would fail DFSG #2, and for those being licensed under GPL, it would probably make them non-distributable. No. It would just mean that Glade was used to *originally* create the file but then the file *has* been modified (many, many times) but the warning simply hasn't been removed. Glade no longer even generates the C files. Glade-2 did, Glade-3 does not. (Try it, load glade-3, create a .glade file and try to get the interface.c, support.c and callbacks.c source code files.) Therefore, no matter what the C files say, it is no longer possible to generate the C files using the current version of Glade and the C files MUST be the preferred form for modification! There is something wrong with that logic. The .glade file may still be the prefered form of modification, especially if the files had not been hand edited. The fact that the current version of the software used to generate it does not generate it anymore is quite irrelevant. If any of those packages have not modified the C output of the old glade, then if I wanted to make a change to the UI, the prefered method would be to edit the .glade file and regenerate the files using an old version of glade. I do agree that *if* the files have been *extensively* hand edited, then they are indeed the prefered form of modification. Minor hand edits might not make the the C files the prefered form, as being minor edits, the prefered form might be to edit the .glade files, regerate the c files with the old version of glade, and reapply the minor by-hand changes. The case of the not modified 'C' files would be much like saying the Windows 3.1 .exe's generated by Microsoft Visual Basic 3 are the prefered form of modification for those programs because the latest version of Visual Basic no longer supports generating 16-bit executables. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Misuse of Debian logo for City Tourism
Mauro Lizaur [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Cyril Brulebois wrote: Will you please respond to my E-Mail ASAP. I am curious as to whether this promotion, for self-profit, is a valid use. I personally do not like the Debian GNU/Linux Logo being used for the profit, and the profit of a city. One, that I will admit, lacks anything interesting. Anyway, http://www.debian.org/logos/ has licensing info for both logos, which probably will answer your question? quoting http://www.debian.org/logos/: Copyright (c) 1999 Software in the Public Interest *This logo or a modified version may be used by anyone to refer to the Debian project*, but does not indicate endorsement by the project. In this case this is not happening, since the commercial is about something not even related with Debian or computers. Even Though IANADD or a /lawyer/, I believe they should remove the Debian logo from their something-they're-advertising. Regards, Mauro Unfortunately, The Debian logo was made using a common peice of propreitary software. It consists of a pre-made brush stroke placed on a spiral. At least one message indicated that the spiral was created using basically the default settings of annother part of said software. This has the unfortunate effect that many other people have created logos virtually identical to the Debian Logo completely independently. That makes it difficult for the project. When possible some member will contact the involved party and ask that they consider using a different logo, but in reality, there is little Debian (or SPI) can do unless the other logo is also used in the same feild (namely computer software). Trademarks are generally limited to a specific feild. There are somne exceptions. For example trademarks creative enough that the odds of anybody else independendtly inventing it are negligable. In that case, it is sometimes possible to sucessfuly argue that the other party is using the mark soley to create customer confusion. Debian's logos do not fit that requirement. The name Debian might fit that requirement, but that does not help with the logos. DISCLAMERS: IANAL, IANADD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicting license for Adeona?
Arnoud Engelfriet [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Ben Finney wrote: I don't think is intended for [use Foo, Bar, Baz] only is a restriction upon the recipient. It states the *intent*, but isn't phrased as a condition or restriction on what the recipient actually may do. I agree. My reading is that this is a warning of some kind. If you use this for commercial purposes, it's at your own risk. Something like that. Arnoud I'm not sure though. The listing of an e-mail adress for licensing information in the TERMS AND CONDITIONS FOR USE section makes it sound like they think usage is a licenseable right independent of the other rights. In that case, they may belive that uses other than the intended uses are forbidden by default, and a license is nessisary for those purposes. It is rather common for Universities' legal departments to have unusual theories about copyright law. Some universities belive that they have the rights to all work created by any of its students, even those not in any employment relationship with the University, and despite the lack of such terms in any contracts the students have signed. I'm pretty sure that is a near laughable belief, but some universities do belive that. As such, I would recommend cation when dealing with software from a univeristy. So recieving a clarification would be quite desirable. DISCALIMER: IANAL, IANADD However, I do agree that they may just be trying to warn that the program was not designed with certain uses in mind (such as law enforcement use) and thus might be unsuitable for such purposes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Legal Provisions Relating to IETF Documents
Simon Josefsson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] All, The IETF Trust has requested feedback on the license for IETF RFCs, see announcement below. As we know, they have decided not to release entire RFCs under DFSG terms. The intention is to allow code-like portions to be licensed under a BSD-like license. It would be useful if we can review the license for the code-like portions, to make sure that it meets the requirements of the DFSG. It will be harder to change this wording later on. In this context, I'm worried about one thing: Section 5 Supersedure says that the code-license can be superseded later on. How does Debian treat license text that says some code is released under the BSD license with the caveat that the license can be changed later on? The section does limit the superseding to be for those in writing between the IETF Trust and the licensee, but the question may still be relevant. If any end user or upstream wishes to enter into an agreement with the IETF to have different code section licesning terms, that is their business, and I do not see how that applies to the other users. The existing license grant should still be valid, since the others did not enter into an agreement superceding the original. That whole clause is most likely legally a no-op, since my undertstanding is that a license can always be superceded by written agrement between the involved parties. IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Legal Provisions Relating to IETF Documents
Simon Josefsson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] All, The IETF Trust has requested feedback on the license for IETF RFCs, see announcement below. As we know, they have decided not to release entire RFCs under DFSG terms. The intention is to allow code-like portions to be licensed under a BSD-like license. It would be useful if we can review the license for the code-like portions, to make sure that it meets the requirements of the DFSG. It will be harder to change this wording later on. In this context, I'm worried about one thing: Section 5 Supersedure says that the code-license can be superseded later on. How does Debian treat license text that says some code is released under the BSD license with the caveat that the license can be changed later on? The section does limit the superseding to be for those in writing between the IETF Trust and the licensee, but the question may still be relevant. If any end user or upstream wishes to enter into an agreement with the IETF to have different code section licesning terms, that is their business, and I do not see how that applies to the other users. The existing license grant should still be valid, since the others did not enter into an agreement superceding the original. That whole clause is most likely legally a no-op, since my undertstanding is that a license can always be superceded by written agrement between the involved parties. IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: review of package inform
Ben Finney [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Joe Smith [EMAIL PROTECTED] writes: Jan Christoph Nordholz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Is the archive granting rights without the authors' consent here? Or does such downloading fall under fair use? The IF-archive has always existed for the express purpose of publishing author's Interactive fiction works, tools, and in some cases code. The very act of uploading a file fairly explicltly implies consent for personal use. The question is, what does the copyright license explicitly allow? The act of uploading isn't what grants freedom to the recipient. Only the terms of the license (in combination with the copyright laws of the recipient's jurisdiction) do that. If an author (and copyright holder) places his work in an archive whose sole purpose is to diseminate copies to anybody for personal use, is that not a effeciftively a license grant to make copies for personal use? I'll admit it is a best an implicit license, but one due to a very specific and deleribate action on the part of the copyright holder. This is somehwat academic anyway, though as Jan plans to remove the questionable works, until proper permission can be secured, possibly adding a semi-automated download option. Since people already manually download, that should be no problem. Regardless there is no real possibility that any of the authors in question would sue, and even if they did, this seems like a near textbook case for the defenses of latches and/or equitable estoppel. However, I suspect some insight into the issue could be gathered by reading through http://groups.google.com/group/rec.arts.int-fiction/browse_frm/thread/56f2f8fe64104402/b1ad0dd79b24ed37?hl=enlnk=gstq=if-archive#b1ad0dd79b24ed37 and determining what (if any) final conclusion was reached. I do not have the patience to read quite that many posts though. IANAL, IANADD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: review of package inform
Jan Christoph Nordholz [EMAIL PROTECTED] wrote... I've extracted my current license list from my WIP inform package to - http://www-pool.math.tu-berlin.de/~hesso/deb/inform_copyright_list I guess it will be no problem to reach at least the more prominent RAIF regulars like Emily Short, Roger Firth or Andrew Plotkin... but that's my second step. I'd like to get the inform package into an acceptable state first, so that it can be autobuilt (and migrate to testing). I can always re-add those modules later. So the files in question are the Inform library extentions? To me those are not a very important part of the package. Based on my Windows experience with Inform6, I would have expected the binaries and perhaps the standard library in an 'Inform' package, but would not have expected any of the library extentions. So the removal is not really a big deal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: review of package inform
Jan Christoph Nordholz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Ok, just what I thought - but would it be different if I converted the package to download those files during postinst, similar to flash- plugin? Does that README's free for personal use apply at all, so I could make automatic downloading possible? Is the archive granting rights without the authors' consent here? Or does such downloading fall under fair use? The IF-archive has always existed for the express purpose of publishing author's Interactive fiction works, tools, and in some cases code. The very act of uploading a file fairly explicltly implies consent for personal use. I'm not sure about automatically downloading the files, but providing a script that downloads and installs the files is definately fine, as that is a mere automation of something that is permisible. Anyway, what files in particular are included in the Inform package that are thought to be problematic and who are the authors of those files? Many of the more prominent authors are still easy enough to reach on RAIF. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Inc. logo in game data
Wen-Yen Chuang [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, The beneath-a-steel-sky and flight-of-the-amazon-queen are two packages in Debian main/games. I opened ITP #478543 for the game lure-of-the-temptress. Its license is as same as beneath-a-steel-sky. They are both products of Revolution Software Ltd., and are released as freeware. Gonéri Le Bouder pointed that commercial Inc. logos are showed at the very begining of those games. [1] He thinks that those games should to be put in non-free, unless we can remove those logos. [2] If you are unable to remove the logos due to lack of ability, then I really am not persuaded by the argument that the software is free. Even if the argument that the .dsk file is the prefered form of modification, Without the ability to actually modify it, it really fails Freedoms #1 and #3 of the Free Software Definition, and thus could not be considered free. The licence of the games most certainly is not intended to extend to modification of the logos. Removal of the logos may be fine (if possible replace them with textual notices, so as not to be removing proper credit to the creator and original publisher), but keeping them is almost certainly not. Considering the previous 2 arguments, I belive the games belong in non-free unless those logos are removed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Review of license
I agree with Francesco Poli that the license, while not ideal, is acceptable. Using 3a (licencing the changes under the same license, or any compatible licence, and distributing them through the Debian mirror network definately satisfies that requirement. End users can choose 3b if they will not distribute, 3c if they want to distribute changed source without making the changes publicly available (like posting them on the web), or 3a if they are willing to post them on the web. For both Debian and end users, the binary version freedoms should be satisifed by 4b. The nastiest part of the whole licence is 3, since just placing the work under a free license is possibly not sufficent for 3a, if public distribution is not also performed. The whole idea here though was that the copyright holder has the rights to see any use any changed version of the source that did not also change the name and manpages. The licence of the changes might not even allow the Copyright holder to incorporate the changes without changin the licence on the work as a whole, such as if the changes were placed under the GPL. And in fact nobody else besides the change authors or the copyright holder could use the changes if they were placed under the GPL, but that would still wualify under 3a. 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IBM Public license compatibility
Alan Woodland [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm currently looking into packaging a module for OpenDx. OpenDx is distributed under the IBM public license 1.0. The addon module for OpenDx currently doesn't have any specific license terms associated with it, however I've talked to the upstream author who said: b) If you could clarify what license terms it is distributed under? I've never thought about the license. I'd like GPL version 2, but I'm not sure if an external module with this license can be dynamically linked with OpenDx, that has, if I remember correctly, a GPL-incompatible license. What do you think? Anyway, I'm pretty sure it's not compatible with GPL, so does anyone have any suggestions for a similar suitable alternative that would be compatible with the IBM public license? Well, if the module is not considered a derived work of OpenDx, then the GPL with aspecial linking exception would work just fine. Otherwise the code must be distributed under a an IBM public licence compatible licence, with the combined work as a whole being shipped under the IBM public licence. Of course, dual licencing the the code under the users choice of the IBM Public Licence and the GPL is also a reasonable idea if copyleft and GPL-compatibility is desired. (Both licences are copyleft. The IBM one lets extra terms be imposed or offered on the licence of an object code form of the program, but it still requires the corresponding source code to be available to users under itself.) DISCLAIMERS: IANAL. IANADD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Nikto license on data files
Paul Wise [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sat, Apr 5, 2008 at 9:55 PM, Vincent Bernat [EMAIL PROTECTED] wrote: OK. Another question: nikto has been removed but is still present in stable. It contains the same non-free data. Since the package has been orphaned, who should I contact about this? ftp-master? I'd say nikto is in the 'never should have been uploaded in the first place' category. I think it is reasonable to remove it from etch too. This page says that removals from stable are handled by the stable release managers: http://wiki.debian.org/ftpmaster_Removals I suspect a message like the following is in order (to be sent to the stable RMs): The orphaned package Nikto has been determined to be non-free but distributable, and is present in Etch's main section. It should be removed at your earliest convenience (preferably as part of the next point release). Thanks. Or something to that effect. Notably this makes it clear that pulling it from the existing release is not an urgent priority, as it would be for undistributable content, but to uphold our Social Contract we must remove it as soon as reasonably possible which would be the next point release. IANAL, IANADD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Grammarsoft Public Licence 1.0
Francesco Poli [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sun, 2 Mar 2008 22:07:40 -0500 Joe Smith wrote: [...] Well it is no less free than the MPL. IMO, the MPL does *not* meet the DFSG. That is exactly why I phrased it as no less free than. Nothing was added that could cause freeness problems, but other freeness problems that may exist in the MPL could still be present. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL code concatenation
Ben Finney [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Robert Millan [EMAIL PROTECTED] writes: Suppose you have a chunk of code that implements initialisation of an MSDOS executable. If you concatenate a payload (raw code) after it, you obtain a .exe that runs your code (at a specific, agreed upon, address I think). My question is, would such combination qualify as a derivative program as per GPL requirements? Wrong question: the GPL, like any copyright license, doesn't have any say over what is a derivative work. Whether a work W is a derivative work of another work X is a function of your local copyright law. Thus, the answer depends on a judge's interpretation of your local copyright law; please consult a lawyer who knows your jurisdiction. True enough. However, I think the poster wanted to know if such a program met the FSF's thoughts on derivitive works. In general the FSF's position may be a bit more inclusive than copyright law's definition, but it seem like it would be quite rare to ever have a work meet the legal definition of derivitive work, but not also meet the FSF's definiton. Thus using the FSF's defintion causes us to err on the side of caution, which is good. Now, as for the poster's question, that is difficult, and depends on several things. First of all, which work is GPL'ed? Thoughts on the case were the loader is GPL'ed. I think this case *might* be mere aggrigation, especially if the result is easy to seperate back into two components. Of course, ideally the LGPL would have been used, since that would make it perfectly clear that the combination is fine as long as source for the loader was distributed, and it is reasonable easy to seperate and recombine the work. Thoughts on the other case (code appended that is GPL'ed): If the loader code is the code the linker normally appends, things are fine. The FSF definately intended the major components exception to cover things like that. If the loader is code that did not come with one of the major components, then things are much less clear. More information about the loader would help much in analysing it in that case. IANAL, IANADD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Grammarsoft Public Licence 1.0
Francis Tyers [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello there, I'd like to package piece of software for Debian called VISL CG (Constraint Grammar). The licence file (see Appendix A.) is a bit strange, and although it states it is derived from the MPL, I'd like to get an opinion as to if it is a free-software licence or not (as defined by the DFSG). A related issue would be that I would be interested if it is GPL compatible, I have emailed the owners to this effect but have received no reply as of a week. Would anyone on the list be able to tell me? Many thanks for your time, Francis Tyers PS. I have enclosed the licence file below as it does not seem to be readily downloadable outside the software. ==Appendix A== Well it is no less free than the MPL. This is because only the company names and choice of law has changed. (plus that section at the begining added) I determined this by running it through wdiff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: logwatch: list of copyright holders
John Halton [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Thu, Feb 21, 2008 at 10:00 AM, Michael Below [EMAIL PROTECTED] wrote: Am Do 21 Feb 2008 10:25:01 CET schrieb Giacomo A. Catenazzi [EMAIL PROTECTED]: IMHO the patches sent to a upstream author which doesn't patch the original copyright (adding a name or a copyright line) should be interpreted as the above case. IMHO the author implicit acknowledges that the patch is simple and doesn't include enough intellectual work. So I interpret the patch as outside copyright laws I would be careful about that. Such a notice isn't required for copyright protection, so it is at least difficult to interpret the absence of a copyright note as a legal declaration about copyright. Plus, I don't think authors can decide whether something is copyrightable (legal systems may differ about this). Agreed. Under UK law, the threshold for copyright protection is quite low, and is an objective test without any need for the author to claim copyright or include a copyright notice. IIRC (haven't looked it up) an author cannot even disclaim copyright as such - though if the author does state that material is public domain and not protected by copyright then s/he may be estopped from reversing that statement later, if people have acted in reliance on it. But the mere absence of a copyright notice is highly unlikely to raise an estoppel against the author asserting copyright at a later date. Indeed, all of that is also more or less true in the United States. So, assuming the lack of a copyright notice means something is questionable at best, and quite likely dangerous. On the other hand, it tends to hint that the work was not that important to the author, but this is only a tendency, so relying on it is unwise. IANAL, IANADD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intel microcode CPU (#3)
Giacomo Catenazzi [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello! Now microcode as a new license Backgroud: In 2000 (or 2001) we already discussed about license of the microcode, and I convinced Intel to change license. But also the second license was not so clear, and a strict interpretation doesn't allowed us to distribute in non-free. Now intel put a new license (I don't know if I convinced again Intel or the change is independent). So I ask you if now the license is enough free for non-free: / Copyright (c) 1995-2008, Intel Corporation. / All rights reserved. / / Redistribution. Redistribution and use in binary form, without modification, are / permitted provided that the following conditions are met: / .Redistributions must reproduce the above copyright notice and the following / disclaimer in the documentation and/or other materials provided with the / distribution. / .Neither the name of Intel Corporation nor the names of its suppliers may be used / to endorse or promote products derived from this software without specific prior / written permission. / .No reverse engineering, decompilation, or disassembly of this software is / permitted. / .Binary form includes any format commonly used for electronic conveyance / which is a reversible, bit-exact translation of binary representation to ASCII or / ISO text, for example, uuencode. / / DISCLAIMER. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT / HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS 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 THE COPYRIGHT OWNER / OR 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. / / These microcode updates are distributed for the sole purpose of / installation in the BIOS or Operating System of computer systems / which include a Genuine Intel microprocessor sold or distributed / to or by you. You are not authorized to use this material for / any other purpose. The old license was the last paragraph. So the problematic part is still included. What do you think? The first part clarify the meaning of the last paragraph? I did not read or comment on the earlier licences. However, While it is clear that UUecnoded disdtribution is allowed, it does not explicitly indicate that gziped (or other binary achived) distibution is allowed. However, on the other hand, I think that clause is simply explaining that ascii representations still qualify as the binary form, and is not intended as a restriction on distribution formats. Given then that gziped copies are a standard meathod of distributing unmodified copies of binary data, I'll take it as implicit that that is permitted. Surely Debian has no need to modify the bytecode files themselves, so no problem there. So the top part sounds fine. From that alone it sounds distributable. That buttom part seems ok to me as well. It is limiting it's use, but that is not unexpected in non-free licences. There is effecively no other real use for the files anyway, except reverse enginerring them, which was prohibited in the top section. So to me, It sounds distributable in non-free. Let's see if anybody else sees any problem's I've missed. IANADD, IANAL. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free application linked to Qt.
Charles Plessy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Dear debian-legal, A non-free program for which I maintain a package has changed its UI toolkit from lesstif to Qt. The program is free for non-commercial use, and upstream payed for a Qt licence. I understand that producing binaries within Debian would be an infringement of the Qt licence. It would certainly seem so. The following message from the trolltech site seems to confirm that: #*) Please note if you choose an open source license for your Qt-based application this license #needs to be compatible with the Qt Open Source Edition licensing (GNU GPL or one #of the licenses listed in Trolltech’s GPL Exception) for your end users to be able to #compile, run and further modify your application. #You may not change the license terms of any parts of Qt itself. Upstream has asked me if it would be possible to distribute the program as a source package only, à la 'pine'. Can you confirm that it is the case? Also, we are wondering if it is the first time this kind of problem happens. I'm not sure about the second part of the question, but my understanding is that there should be no problem with that solution. Surely the program in question's licence would not prevent it (or they would not be asking you). Then the GPL v2 definately does not prevent linking applications to a library if the resulting linked application is never distributed. But yet us assume that form some reason the GPL does not allow this. It would appear theat the second exception to the GPL that trolltech uses would allow this. The exception is: #The right to link non-Open Source applications with pre-installed versions of #the Licensed Software: You may link applications with binary pre-installed versions #of the Licensed Software, provided that such applications have been developed #and are deployed in accordance in accordance with the terms and conditions of #the Qt Commercial License Agreement. That would give us therequired permissions to provide it as source for end users to compile and link, assuming that that method of deployment is allowed under the Qt Commercial License Agreement. That exception notice was found at http://trolltech.com/products/qt/gplexception Browsing a sample QT commercial licence appears to indicate that the Qt Commercial License Agreement would allow such distribution if the licence certificate allows distribution on the OS platforms in question. (Presumeably it must list Linux systems.) Upstream sells licences of its program for commercial use, so it is difficult for them to free their code. The program exists in a graphical version and a command line version. Both can operate independantly and the command-line version is widely used on workstations. Would I be legally wrong if I advised Upstream to separate the GUI code from the algorithms, double-license the GUI under non-commercial or GPL terms, and make it call the command-line version independantly (no C linking)? That could be a reasonable possibility assuming it is reasonably possible for them to set it up that way. I've seen many commercial apps whose main executable is really just a very large and nice GUI convince wrapper around the command line tools that do the real work. If it is reasonably possible for upstream to do that, that would eliminate this issue entirely. After all, if it is just a wrapper (even a really nice wrapper) around the CLI utility, and is not using undocumented features of the CLI utility then there is no reason somebody else could have developed the software independently, and we know that GPL'ed wrappers around commercial CLI tools are entirely legal. In that case, I think that it would preserve their revenue model: people who want to use the GUI for commercial use would have to buy a licence for the commercial use of the command-line version anyway. But I do not know if it would be fair to Trolltech. Or maybe the licence of the command-line version could mandate that if the program is used through the Qt GUI, a Qt license has to be bought? You are right that this could be deemed unfair to trolltech, especially if upstream just put the GUI under just GPL, as that would eliminate the need for them to use the commercial licence. The goal of this is to keep a gratis and open source access to the program and its GUI to academic users, and require a commercial licence from industrial users. In the split system it would be the terms of the CLI that would be the deciding factor here. After all, an industry could legally use the GUI shell without paying, but without the CLI portion the shell would be quite useless. [Please CC me, I am not subscribed] My overall thoughts are that just the pine-like distribution should be sufficient, and that the rest may be highly academic anyway, as it might not be reasonably feasible to restructure the GUI version in the required way. IANAL, IANADD.
Re: web hosting providers' modified .debs
Arnoud Engelfriet [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Florian Weimer wrote: | You may make, run and propagate covered works that you do not | convey, without conditions so long as your license otherwise remains | in force. You may convey covered works to others for the sole purpose | of having them make modifications exclusively for you, or provide you | with facilities for running those works, provided that you comply with | the terms of this License in conveying all material for which you do | not control copyright. Those thus making or running the covered works | for you must do so exclusively on your behalf, under your direction | and control, on terms that prohibit them from making any copies of | your copyrighted material outside their relationship with you. This was put into the license at the very last moment. Maybe it does not apply to the Dreamhost case, but I think it does apply to appliances like the Tivo, and especially to customer premises equipment given to To me the clause reads like a work-for-hire or have-made clause. If a company needs private modifications made to a GPLv3 work, it may need to hire a third-party programmer. Giving this programmer the (possibly already modified) source code normally constitutes conveyance, so the programmer would be free to publish the source code. It also is intended to cover giving a copy of the code to your hosting provider for them to run on your behalf (the or provide you with facilities for running those works part). However, that part could indeed be read in such a way as to create a loophole. One case where this would be a bit more clear is if by default the Tivo box did not contain any GPL'ed code, but still had the key restriction thing. Once you have the device plugged in, Tivo makes an arrangement with you to run the code on the device on their behalf. That would likely be allowed under a strict interpretation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#461659: warsow: New version of warsow possibly non-distributable.
Andres Mejia [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, I'm sorry, I forgot to ask about other concerns that myself and another member of the Debian Games team had. You should have been more clear that you were concerned not about freeness, but about the ability to distribute the data in non-free. I'll repeat what Vincent (the other member) was concerned about. On Jan 21, 2008 10:26 PM, Andres Mejia [EMAIL PROTECTED] wrote: 3. You may not copy, modify, publish, transmit, sell, participate in the transfer or sale or reproduce, create Derivative Works from, distribute, perform, display or in any way exploit any of the Material released under this License unless expressly permitted by the Warsow Team. 4. You may freely distribute the Warsow archive/installer unmodified on any media. You may re-compress using different archival formats suitable for your OS (i.e. zip/tgz/rpm/deb/dmg), any changes beyond that require explicit permission of the Chasseur de bots association. This two points are contradictory: 3 says no one can distribute, 4 says it's fine to distribute if you don't touch anything. Moreover, there are two different groups mentioned in here: the 'Chasseurs de bots association' and the 'Warsow Team'. We'd better take this to debian-legal. To me, it looks like a very badly-written license with ambiguous clauses. I agree that it is a very poor licence. It is obviously not free. As stated it is definately questionable. They probably do intend for Debian to be able to continue packaging the data in non-free, hence the mention of the deb format, but in this case clarification is definately desireable. That was his concern. My concern was that this license stated Assets that are property of Chasseur de bots, use the following Warsow Content License. However, the last part of clause 3 mentions that exceptions can be made by the Warsow Team. Would this be a problem if we are to distribute warsow in Debian? It is certainly odd, but I suspect that Warsow Team is the same thing as the Chasseur de bots team (the development team for Warsow) which I suspect is the primary (only?) subdivion of the Chasseur de bots association. They are definately being quite loose with their terminology. I would seek clarifiaction from the Association itself as to whether we may contine to distribute the data files in non-free as we have done in the past, with further clarification that the message is also the position of the Warsow Team. Based on the terms, clarifcation from both the Association itself and the team that we may continue to package the files as we have should be sufficent to allow the distribution of the packaged form of the new data files. Below is the previous question I asked earlier. There's an issue with the new upstream version of warsow that I think will make it undistributable, even in the non-free category of Debian. I've attached the entire license file for the new version of warsow. I want to know if it will still be possible to distribute the old version of warsow. The old license states, Warsow license information: The game engine is based on the QFusion engine and licensed under the GNU General Public license. A copy of the GPL license should come with this package, in file named gnu.txt, if not look at http://www.gnu.org/licenses/gpl.txt Game data files are copyrighted by their respective authors. You may only redistribute the game data in unmodified form unless you have written permission from the copyright owner. Until clarification can be obtained, I would remain with the old version, as that definately gves us permissions we need, and nothing has indicated that they revoked this permission, only that the new versions come under a different set of terms. Please CC myself and [EMAIL PROTECTED] when replying to this email. Done. Disclamer: IANAL, IANADD -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licensing exception to increase product compatibility
Ivan Ristic [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, I am the original author of ModSecurity (http://www.modsecurity.org), an open source web application firewall, which is licensed under GPLv2. ModSecurity was acquired by Breach Security in late 2006. I joined the company at the same time, continuing to manage the project, which remained open source. ModSecurity used to be distributed in Debian but this is no longer the case, due to the incompatibility between the GPLv2 and the Apache Software License. I would like to explore a licensing exception as the fastest way of resolving this problem. The problem is that an Apache installation typically consists of many modules, each with a potentially different licence. I am only aware of the incompatibility between the GPLv2 and the ASL, although other issues may exist. Although GPLv2 is our licence of choice, we do not have an intention to force this licence upon other users and developers. I think that it's possible to design a licensing exception that would essentially say the following: - For non-ModSecurity-related modules, allow any open source licence. We would either call for any OSI-certified licence, or explicitly list every licence allowed. - Changes to ModSecurity, or modules that work with ModSecurity to change or extend its functionality, would remain covered under GPLv2. Indeed that should be possible. Of course, all contributions to the code would require relicencing by the contributer unless a copyright assignment system was in place. But if you can get all of the work relienced, such an exception could correct any issues. However, how important is it that all used modules be open source? I'm sure it is important that anything directly extending the ModSecurity module ti be GPL'ed, but that is the easier part of the exception to draft. The other section is admittedly much more difficult to do well. If it is not really that important that the other modules be open source then omitting that exception entirely would simplify things entirely. If dropping the first requirement, my rough draft would be somthing like the following: -BEGIN DRAFT- In addition, as a special exception, the copyright holders give permission to link the code of this program with the Apache Web server (or with modified versions that use the same license as Apache Web Server), and distribute linked combinations including the two. You must obey the GNU General Public License in all respects for all of the code used other than Apache. 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. In addition, as a special exception, the copyright holders give permission to link the code of this program with other Apache modules that are not designed to change or exend the funcionality of ModSecurity, regardless of the license terms of those modules, and distribute the resulting combination. You must obey the GNU General Public License in all respects for all of the Program code and other code used in conjunction with the Program except the Non-GPL Code covered by this or the previous exception. 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. - Those exceptions are based on the standard exception template provided by the GNU foundation, along with a few terms from the classpath exception and Red Hat GPL exception. There may be a few small tweaks that should be made, but this should be a solid foundation. Assuming the only problem with distributing your module was the GPLv2-ASL licence incompatibility, that exception should allow Debian to distribute your module. PLEASE NOTE: Am am not a laywer, so this was not legal advice. The draft exception was constructed as an informational tool, and should be reviewed by an actual lawyer and changed as needed. I am not a Debian Developer, and this message is in no way an official statment of the Debian Project. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: patents on Frets on Fire, Pydance, StepMania and such games
Don Armstrong [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Fri, 18 Jan 2008, Joe Smith wrote: That is not sheet music, but more of a raw storage of notes, timings, and durations (not too unlike a midi file). What else is sheet music but a storage form of notes, timings and durations? I agrue that sheet music differs significantly from midi files, although it is generaly possible to generate one from the other with a reasonable level of accuracy. Basically, AIUI that requirement is about a machine readable representation of the notes, etc. I will agree that at least some sheet music creation software must store data in a format that qualifies. But the key here is that this specifies that the interface must have two different types of controls. One that must be pressed with the correct timing (the strum bar on a Guitar Hero controler) as well as selection buttons that need not be pushed with exact timing, but need only be pushed in the right combination when the timing control is pushed. So you have an instrument which has to preselect a note, and another which much be pressed with exact timing. Most wind instruments satisfy that requirement. True enough. However, to find prior art for this claim would likely require we find a game system which shows players some form of sheet music representation of data stored in a more machine readable format , to which such a wind instrument is played. If we can find that we have prior art. It seems entirely possible that such software exists, but I don't know of any such software off the top of my head. Further, this does show that this particular patent would not apply to pydance or StepMania. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Review of CeCILL-C? (This is not â?oplainâ ? CeCILL.)
Cyril Brulebois [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, it looks like one can't help writing new licenses, so in addition to CeCILL, CeCILL-B[1] (said to be BSD-like) and CeCILL-C[2] (said to be adapted to software components) have been published[3]. Note that French versions are available as well (s/en/fr/ in URL), as well as text-only versions (s/html/txt/ in URL). 1. http://cecill.info/licences/Licence_CeCILL-B_V1-en.html 2. http://cecill.info/licences/Licence_CeCILL-C_V1-en.html 3. http://cecill.info/licences.fr.html I'd be glad if those licenses (in particular CeCILL-C) could be reviewed. Thanks in advance. Cheers, The following is a review of the CeCILL-C licence. Further, it is only an analysis of the English text. Disclamers: IANAL, IANADD. Article 3 makes it clear that the license is accepted by using the software.Further the licence explicitly covers use of the software. I rather prefer it when licenses do not do this, but this is not a freeness problem Section 5.1 is basically an unlimited right of use. It expliclty allows the use for any purpose (DFSG #6), and also explicitly allows reverse engineering. Section 5.2 allows modification of any type including the creation of a derivitive work. The only condition is such modification must included a notice indicating the author of the modification, and the date of said modification. The GPL has an equilvent term, so this is no problem. Section 5.3.1 (distribution of unmodified copies) is contains terms less restrictive than the GPL v2, so that section is fine. Section 5.3.2 (distribution of modified copies) is identical to the previous section, except that the source code must be the full sorce code for the modified version. This section is obviously fine. Section 5.3.3 (distribution of derivitive software). This section is interesting. Let us look at the relevent definitions here. Derivative Software: means any combination of the Software, modified or not, and of a Related Module. Related Module: means a set of sources files including their documentation that, without modification to the Source Code, enables supplementary functions or services in addition to those offered by the Software. An unusual defintion of derivitive software by my definition. It is also not entirely clear what a related module actually is. A plugin would certainly be a related module under this definition, but exactly what else is covered is not entirely clear to me. Anyway, this section allows derivitive works to be licensed under a different license, as long as section 6.4 holds. Further if said derivitive work required modification of the software, the modified version of the software must be licenced under the CeCILL-C license, the changes to the software must be clearly identified (the GPL has a similar requirement), and the same source code availability requirements as in the other two sections still hold. This section seems to indicate GPL-incompatibility, as it shows a copyleft requirement that would prevent the GPL from being allowed to cover the work as a whole. Section 5.4 disables a single clause in section 6.4 if a contribution under the CeCILL license is integrated, or is included as a Related Module in a Derivitive Software. Section 6.4 is the next relevet section. The first two clauses are basically a notice preservation requirement. The requirement is a little stronger than most are, requiring exact preservation of the notices, modifications of any sort or not allowed. The third clause is the one that section 5.4 can disable. The text is: to ensure that use of the Software, its intellectual property notices and the fact that it is governed by the Agreement is indicated in a text that is easily accessible, specifically from the interface of any Derivative Software. That clause is similar to one in the GPL v2, but is just slightly more obnoxious. I'm not sure it is a free-ness problem, but it might be. At the very least, it can be a pain. Section 8 is quite unusual, as it explicitly mentions that the licensee may claim compensation from the licensor for direct damages should the licensor fail to meet its requirements. Of course, this would not apply in the event that the licnesor fails to meet its requirements because the licensee failed to meet its own requirements. Certainly not a freeness issue, but just a little odd to see in a free software license. Section 11 adds an exception to liability in the event that the failure to meet the terms of the agreement are directly atributable to major events outside the parties control including acts of god, telephone or communications network problems, network problems due to a virus, intervention by the government, strikes, etc. The rest of section 11 is very standard. Section 13 contains some possibly problematic terms: It has a choice of law provision, specifically French Law. That is not a problem. However it
Re: patents on Frets on Fire, Pydance, StepMania and such games
Don Armstrong [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Fri, 18 Jan 2008, John Halton wrote: 1. A game system comprising: an input apparatus which is manipulated by a player; performance data memory device which stores performance data stipulating a series of manipulations of said input apparatus arranged in correspondence with a predetermined musical piece; Interesting that they've managed to patent sheet music stored in a computer. That is not sheet music, but more of a raw storage of notes, timings, and durations (not too unlike a midi file). Further that is not an independent claim, the patent *only* protects a *game system* that contains *all* these components. manipulation guide device which specifies the series of manipulations of said input apparatus arranged in correspondence with said musical piece to the player based on said performance data; That does cover any sheet-music or sheetmusic-like interface that displays the notes stored above. said performance data comprising information which specifies timings of manipulations relating to at least one timing manipulation member provided on said input apparatus, and information which specifies at least one selection manipulation member to be manipulated in correspondence with the manipulation of said timing manipulation member from a plurality of selection manipulation members provided on said input apparatus; But the key here is that this specifies that the interface must have two different types of controls. One that must be pressed with the correct timing (the strum bar on a Guitar Hero controler) as well as selection buttons that need not be pushed with exact timing, but need only be pushed in the right combination when the timing control is pushed. Thus this patent very much is specific to Guitar-hero like games, and does not cover generic dance games, which have only timing buttons, and no selection buttons. Futher it is unclear to me that a distributer would be infringing the patentent anyway, as they would be providing only a portion of the game system claimed, but not the input device. (Now if the person was distributing a cd containing frets-on-fire along with a Guitar-hero style controler, that would be covered by this claim) And then continue to even more precisely define digital sheet music. Oh well; it's not like patent examiners are actually capable of understanding the patents which they are examining. Don Armstrong -- A Democracy lead by politicians and political parties, fails. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TrueCrypt License 2.3
Francesco Poli [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] IV. Disclaimer of Warranties and Liabilities; Indemnification [...] 4. You shall indemnify, defend and hold all (co)authors of This Product, their agents and associates, and applicable copyright/trademark owners, harmless from/against any liability, loss, expense, damages, claims or causes of action, arising out of Your use, inability to use, reproduction, (re)distribution, import and/or (re)export of This Product (or portions thereof) and/or Your breach of any term of this License. Warning! Indemnification clause: is it acceptable? It smells as non-free... Ok. Lets look closely at this. In most of those cases, I cannot see any valid reason for anybody (except perhaps myself) to sue the company for those actions. Without knowing exactly what sort of things the company could be liable for based on my actions, and thus what type of liability I am indemifying them from, I cannot make any sort of freeness judment on this part of the licence. Could somebody give examples of what sort of liabilty for them could result from my perfroming the listed actions? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PSI('s icons) license vs EKG and EKG2
Marcin Owsiany [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [0] My explanation of the problem | | I had a look at the COPYING file in the root of PSI source tree [1], which, | due to lack of any more specific licensing information seems to be the | binding license for the icons. It is GPL with two special exceptions. | | Since the icons are built directly into ekg2's gtk plugin, their license | effectively limits what the plugin may be linked against. In particular, | PSI's license only allows to link the software it covers (i.e. the icons as | well) against OpenSSL via Qt or QCA plugin APIs, which ekg2 does not use. Hmm... I suppose this is valid, although it does seem a bit of a strech to call the graphics linked to the openSSL library, it does seem to be basically the case. | This raises Ye Olde GPL vs OpenSSL issue [2]. | | Since the gtk plugin is linked (indirectly, via ekg2 and other plugins) to | OpenSSL library, this makes the binary package illegal to distribute for | Debian, according to its more or less official position. [3] | | I am by no means an expert, but think there are two potential ways around | this problem. | | 1) relicense the icons, to a more permissive license (i.e. add another | exception). This might be the easiest way or impossible, depending on the | copyright holders' position. That is definately possible. the LGPL is a good choice here if a copyleft on the images is highly desired. (Obviously the LGPL is compatible with GPL linking exceptions). Otherwise, I would suggest the Expat licence. | 2) change gtk plugin's code to load the icons at runtime, rather have them | built directly into the binary. That would certainly work. There is definately no need for the icons to be linked to the OpenSSL library. There is no problems with a GPL'ed program using non-GPLed graphics file, or a non-gpl program using GPL'ed graphics files (although admittedly some people would not be happy about this). So certainly there is no need to worry about possible licence conflicts in this case. | Please also note that this problem now affects ekg (1), as the gtk UI code | was recently added to it. | |[1]. http://dev.psi-im.org/websvn/filedetails.php?repname=Psipath=%2Ftrunk%2FCOPYING |[2]. http://www.gnome.org/~markmc/openssl-and-the-gpl.html |[3]. http://lists.debian.org/debian-legal/2002/10/msg00113.html IANADD. IANAL. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JOGL in Debian
John Halton [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Fri, Dec 07, 2007 at 10:33:14PM +0100, Francesco Poli wrote: Are you implying you have any evidence that the GNU GPL v2 is *incompatible* with french law?!? I gather that one reason for some of the changes in GPL v2 (in particular the change from distribute to propogate/convey) was to address concerns over how GPL v2 would be interpreted under French law, where distribute has (I gather) a very specific meaning. Hmm.. I'd be surprised if distribute had any meaning in french law at all. I mean perhaps Distribuer has a specific legal meaning, but if I were a judge, i would interprete foreign language legal terms not by the meaning of the closest translated word, but the local legal term that is closest in meaning to the original legal term. It seems a reasonably safe assumption that french law has some term that means roughly the same thing as distribute does in Common Law. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Review-request for Mugshot Trademark Guidelines
John Halton [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Including that notice in the package long description would certainly cover the packages.debian.org and downloading via aptitude/synaptic. But I don't think out ftp architecture is set up such as to allow us to include a README file in the same directory. My guess is that including the statement in the package's long description is would be considered by RedHat as sufficient, but we should really get clarification. I'd be amazed if this approach was a problem, but I agree a clarification is worthwhile. Presumably the notice could also be included in the copyright file? Yes, I would say the notice should be in the copyright file, especially to point out the fact that it should not be removed from the long description. IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Review-request for Mugshot Trademark Guidelines
John Halton [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 3. If they charge a fee for the CD-ROM or other media on which they deliver the Mugshot™ code, they warranty the media on which the Mugshot™ code is delivered, thus ensuring that the recipient receives a usable copy. Paragraph 3 may be the first problem. It basically prevents cheap CD vendors from selling copies of Debian on an as is basis. I'm not sure this is a real concern. are they really selling the media as-is? So If the cd comes scratched so bad it does not work, or is warped, the buyer has no recourse? I can see no warrenty on data being useable for anything, but I'm not aware of anybody who sells Disc's who does not have at least a limited warrenty covering manufactiong defects on the media. (As opposed to data defects) [Snip, following quote is in regard to the FTP part of the license] If Red Hat consider a README in the same download directory to be good enough then that should be fine, however. Presumably it would be fine in general. However, it may be a problem for Debian, as I'm not sure our arcitecture is properly set up for this. Including that notice in the package long description would certainly cover the packages.debian.org and downloading via aptitude/synaptic. But I don't think out ftp architecture is set up such as to allow us to include a README file in the same directory. My guess is that including the statement in the package's long description is would be considered by RedHat as sufficient, but we should really get clarification. Modified Mugshot Client Code – Limited Trademark Permission Red Hat and the Mugshot Project support the extension of Mugshot™ to new platforms and languages. Red Hat grants a limited permission to use the Mugshot™ mark on these modified versions of the Mugshot™ client code Note that is only covers extending Mugshot to other platforms and languages, not distributing modified versions for the same platform or language. But packaging it for Debian probably counts as extension ... to a new platform, especially given the stated purpose of this limited permission being to make Mugshot as widely available as possible (while preserving Red Hat's trade mark rights). Indeed. I would consider Debian a seperate platform, in so far as it has a seperate package managment system. Clarification by RedHat on this point would be nice, but I'm fairly convinced this is not a problem. provided the following conditions are met: 1. You identify your version of the client code as an adapted version of Mugshot™ in the “About” dialog associated with the Mugshot icon. The attribution statement should be similar to: “Mugshot™ client code adapted for .” I'm guessing that's OK. I agree. There is no special freeness problem here because we (or the end user) could always change the program name if they wanted to remove that message. 2. You do not prefix the named product with Red Hat (e.g. Red Hat Mugshot is not allowed.). That's fine too. Agreed. No problem there. After all Debian's Red Hat Mugshot package would sound really weird. :-D. 3. The changes you make do not alter the fundamental user experience from that provided by Mugshot™ as made available by Red Hat. That is, you can: 1. localize the client code; 2. provide patches or bug fixes to the client code; 3. provide extensions or plug-ins to the client code; or 4. adapt the client code to run on another platform; but 5. you cannot substantively modify or remove basic components of the client code such that the user experience is altered. 4. You do not redirect the client code to operate with a server other than the server found at mugshot.org Again, that's probably OK too. From a free software POV, it's always open to people to do any of the unpermitted acts under a different name. Yeah. That sounds fine, and sounds like it includes all we really would need to make a Debian package using the Mugshot name. It is very important that any modified version of Mugshot™ meet (or exceed) the quality level people have come to associate with Mugshot™. Red Hat reserves the right to require persons to cease use of the Mugshot™ mark if they are redistributing software with low quality and efforts to remedy the situation have not succeeded. This is probably a key point in practice. It would be worth getting Red Hat to confirm that they are happy with the Debian package. IIRC the issue over Firefox/Iceweasel arose (at least in part) because Mozilla were unhappy with some of the changes being made in order to Debianize the software (e.g. disabling the built-in update system). That was a small part. They had a policy of not letting patched versions be called Firefox, unless the patches were approved. That is fair enough, and I suspect that most changes
Re: [Pkg-fonts-devel] STIX Fonts Beta Test Version Ready for Download
My reading of this says that any modified version cannot be called STIX or any confusingly similar name. You may add or change characters. You may remove characters but if you do so you must note that the font does not contain the full set of characters that STIX had. Well that is at least my reading of the intent. The actual wording should be fixed, but baring the naming clause being a bit too broad, the license seems to be intended to be DFSG-free. So lets work on fixing the wording. IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Build system GPLv3+, *.(c|h) LGPLv2.1+ -- What is the library copyright?
Florian Weimer [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] * Andreas Metzler: I think that the resulting library /usr/lib/libtasn1.so.3 does not inherit the licenses of the build-system, and ends up as LGPLv2.1+ both in 0.3.x and 1.x. Can you confirm this? You should ask the GNUTLS folks. I'm sure they will confirm this. Fully agreed. Their intent is clear, but verification of this is quite useful anyway. (Prevents second guessing). IANAL, IANADD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: licensing of XMPP specifications
Peter Saint-Andre [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] It has been brought to my attention that the current licensing of the protocol specifications produced by the XMPP Standards Foundation (XSF) is not in compliance with the Debian Free Software Guidelines (DFSG). The specifications in question, called XMPP Extension Protocols (XEPs), define the protocols used by a wide variety of Jabber software implementations (servers, libraries, clients, etc.). Some of these implementations may be licensed such that their code complies with the DFSG. However, if such implementations wish to include XEPs or substantial portions thereof in their distributions, then the current XEP licensing will prevent the software from being included in free Debian distributions. This is sub-optimal (especially because the jabber.org/xmpp.org infrastructure is hosted on server machines that run Debian!). Therefore we want to make sure that the XEP licensing is in compliance with the DFSG. The specifications are covered by the XSF's IPR policy: http://www.xmpp.org/extensions/ipr-policy.shtml From 2002 to 2005 these specifications were licensed under the Open Publication License (OPL). In 2005 we changed the licensing to use the Creative Commons Attribution License (CC-BY) because it appeared that the OPL was not being maintained. However, I now realize that CC-BY is considered to violate the DFSG. (Sorry, I have not followed the long-running controversy over CC licenses and the DFSG, although I have done some cursory research into the matter today.) As Executive Director of the XSF, I am willing to push for a change to the licensing so that the XEP licensing is consistent with the DFSG. Although we need to complete some due diligence and come to consensus in our community before settling on a license, it appears to me that the MIT license would be appropriate. (If it were up to me I would place the documents in the public domain, but that may not be consistent with the consensus of our community or the XSF's intended role as a neutral third party and intellectual property conservancy for Jabber/XMPP protocols.) However, the MIT license talks about software, not documentation or, more precisely in our case, protocol specifications. Is it considered acceptable (for the purpose of DFSG compliance) to formulate a legal notice that is nearly identical to the MIT license but that talks about specifications instead of software? I am thinking of a legal notice along the following lines... ** This XMPP Extension Protocol is copyright (c) 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at http://www.xmpp.org/extensions/ipr-policy.shtml or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the Specification), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in code and to read, copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that this copyright notice and permission notice shall be included in all copies or substantial portions of the Specification. THE SPECIFICATION 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 THE SPECIFICATION OR THE IMPLEMENTATION OR OTHER USE OF THE SPECIFICATION. ** That look pretty good to me. But I note a small issue: I'm concerned about the first statement of the licence becoming innacurate whem modified versions are distributed. Specifically the part about complience with the IPRP. Modified versions might not meet that, and then the statment becomes misleading. I would suggest considering moving that whole sentence to a seperate standalone paragraph. Then people would be less hesitant about removing parts of that that are no longer true. But otherwise, it looks pretty good to me. A modification of the MIT License seems like a good choice to me, as if a specialized license is needed for clarity, starting from a well known and well unstood base and making the minimum nessisary changes keeps the effort needed to analyze the license to the minimum. I am not a Debian Developer, so this message in no way is a statement on behalf of the Project. (Although I suspect many would agree with my sentiments on this issue). I am also not a Lawyer, ergo, this is not Legal Advice. Joe
Re: Which GPL for Ogg Frog?
Ben Finney [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Music in digital form, being digitially-stored information, *is* software :-) As Eben Moglen said, it's foolish to try to distinguish different freedoms for a bitstream depending on how those bits happen to be interpreted at some point in time. That sounds like an argument against the GFDL licence. I am convinced that it is, yes. IF Eben Moglen really belived that, why did he allow rms to create that license? That presumes that Eben was in any position to allow RMS to do anything. In any case, you'd have to ask him. My understanding is that as of the time of the drafting of the GFDL, Eben was the primary lawyer at the FSF. Now, I find it hard to belive that rms would actually publish a license that has not been approved by the FSF lawyers, and Eben would have been in a position to convince rms that this was a bad idea. Of course, if Eben came to the above conclusion after the FSF published the GFDL, that would explain things. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Which GPL for Ogg Frog?
Ben Finney [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Music in digital form, being digitially-stored information, *is* software :-) As Eben Moglen said, it's foolish to try to distinguish different freedoms for a bitstream depending on how those bits happen to be interpreted at some point in time. That sounds like an argument against the GFDL licence. IF Eben Moglen really belived that, why did he allow rms to create that license? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unauthorized use of debian logo?
Michael Pobega [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Aug 30, 2007 at 07:18:37AM -0400, Quintin Riis wrote: Whilst searching google for a linux monopoly clone, I found the following site that appears to be using the debian logo in their artwork. http://www.adultmatchmaker.biz/ Thoughts? Looks to me like they've taken the logos down. I assume somebody got in touch with the site admin or webhost? I'm not sure, but the logo is definately gone. It used to be on the bottom right hand corner of the package image. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unauthorized use of debian logo?
Ben Finney [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Quintin Riis [EMAIL PROTECTED] writes: Whilst searching google for a linux monopoly clone, I found the following site that appears to be using the debian logo in their artwork. http://www.adultmatchmaker.biz/ Yes, especially since the image is a link to a MS Windows executable program file 'sexydreams.exe'. It also seems to misuse the Fedora logo for a different link. Damn, that is definately the fedora logo. I was going to give them the benefit of the doubt on the debian logo, but seing the fedora logo abused like that, makes me positive that the spiral is the debian logo. This seems to be one of the few times a report of logo misuse appears to be an actual misues case. all to often they are merely similar logos generated be the same meathod. Further, this is a time when the logo is being used in the same feild as the Debian logo. WOW. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Linux ECCN-Codes?
Diehl Markus [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, on one of our VoIP GSM gateways we use Debian/GNU Linux. For export issues according to US law we require a so called ECCN code for the gateway. The ECCN code of our VoIP GSM gateway will be determined by the ECCN codes of the used sub components (e.g. a ECCN code of the Linux system). Is there an ECCN code for Debian/GNU Linux? Best regards + Many thanks! Markus First of all, I am not a laywer. So the following is not legal advice, but only what i know. I'm not aware of any ECCN that would cover an operating system as a whole. However, parts of Debian may be covered under ECCN 5D002. However, those parts fall under the TSU licence exception, so no licence is required for that component. I'm not sure of any other applicable ECCN. Also note that the ECCN of a GNU/Linux distribution can vary depending on what components of it are exported. (Your GSM gateway presumably does not use every component of Debian GNU/Linux). Your safest bet would be to submit a classification request for the entire system to BIS, as described in the answer to question 3 at http://www.bis.doc.gov/Licensing/Do_I_NeedAnECCN.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Exporting Issues related with US laws
Ben Finney [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Dererk [EMAIL PROTECTED] writes: The developer of a software I'm about to package, faced the problem of exporting cryptography libraries outside the US, he finally turned out his view and he will make his main repository available outside the US, punctually in the U.K. On reading the whole message, I'd like to summarise for those who (like me) believe they already know the answer: Daniel Drake (a UK citizen currently living in the USA) wants to release, under the GNU LGPL, software that involves fingerprint recognition algorithms. This, according to Daniel's research into the laws, falls foul of US munitions export regulation under a category separate from cryptographic algorithms — and does *not* have an exception allowing export of free software. I don't have an answer, but I hope for a successful conclusion that allows free release of this software. Yeah, this does not look good. He can legally export to England (no licence needed, but paperwork might need to be filed). However, he would need a licence to export to many countries, Specifically all countries with checks in column CC1 or AT1 need a licence to export. (The relevent chart is at http://www.gpo.gov/bis/ear/pdf/738spir.pdf). Further, exporting to england with the intention of re-exporting from there may be considered a crime in the US. (Which is absurd, but the whole munitions control system is mostly absurd anyway). There looks to be no relevent blanket exceptions to licence requirements for that catagory. Yuck. IANAL IANADD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: us crypto export regulations
Pat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] How would the US export restrictions be applicable to a custom debian cdrom? The cdrom would have no additional crypto functionality than what is already available in debian and there would be no changes to the source code, so how would it apply regarding distributing isos? How are these export restrictions applicable to mirroring Debian? Is there anything additional I need to do or is it covered by Debian as it is Debain software? I am not a lawyer, so this is not legal advice. I am not a Debian Developer, and this is in no way an official statement of the project. Based on http://www.debian.org/legal/cryptoinmain which was written by a lawyer: Only one notification for one U.S. site is required; no separate notification is required for mirror sites inside or outside the U.S. This notification would only have to be updated if you added a new program implementing encryption. So assuming that the laywer was correct (and it seems likely, more below), you should be fine. (Unless the law has changed, but i have not heard of any change). Apparently Debian has been used by the government as an example of the right way to do things (see http://lists.debian.org/debian-project/2005/08/msg00018.html), so it seems safe to assume that the lawyer was correct. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about patent notice in copyright header of package exempi
Michael Biebl [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] and a copy of it: == This package is based off Adobe XMP SDK 4.1.1, distributed under the BSD license reproduced thereafter for convenience and available in docs/BSD-License.txt This package is licensed under the same license. Since that is indeed the only license on the SDK, I think it reasonable to assume the patent is licenced under those terms. So I would say, everything looks fine. IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GFDL and cover texts
Jordi Gutiérrez Hermoso [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On 07/08/07, Joerg Jaspert [EMAIL PROTECTED] wrote: On 11104 March 1977, Jordi Gutiérrez Hermoso wrote: : Why are three words enough to make thousands upon thousands of words nonfree? Because it is non-free. Compare with a source tarball, where one could say But this is just one twenty-line file which is non-free, and the other 50 lines are free. Why is this enough to make the rest non-free?. That just doesn't work. But we can't modify the COPYING file in a source tarball, and that's ok. Why isn't a cover text like a GNU manual also acceptable? - Jordi G. H. It really is not as much the non-modifiable nature of cover texts, as the fact that they are mandatory to include. Lets say somebody was writting a manual for a utility that is similar to the GNU utilitiy in some respects. The person's utility is not a GNU utility. It would be very useful if the person could reuse some parts of the GFDL'd manual that still apply (perhaps a section explaining Regular expressions (for example)). If he did so though, he would need to keep the a GNU manual cover text on his manual, which is hardly a GNU manual, condisering that it was not written for or as part of the GNU project, nor is it about a GNU utility. Further one could very easilly see a problem occuring if one borrows text from a bunch of manuals all having different covet texts. There would be quite a few required cover texts in that case, many of which really make no sense for the end result. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: uploading GPLv3 packages
You are always free to upload a package, as long as the Legal file documents all known legal issues (and it is in fat legal for you to distribute it). The job of determining if the work meets the DFSGs belongs to the ftpmasters. Debian-legal exists to discuss the issues, which is hoped to assist the ftpmasters in making their decision. My understanding is that the ftpmasters are accepting packages using the GNU GPL v3. They apparently feel that it meets the DFSGs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why is firebird in Debian?
Anthony Towns [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 1) The MPL requires you to make the source code to your modifications available for six-to-twelve months electronically _or_ to make it available on the same media as the executable version. We do the latter. In this case the licence is the IPL. Lets take a close look at the eact terms that are relevent. #1.4. ''Electronic Distribution Mechanism'' means a mechanism generally #accepted in the software development community for the electronic #transfer of data. #Any Modification which You create or to which You contribute must be #made available in Source Code form under the terms of this License either #on the same media as an Executable version or via an accepted Electronic #Distribution Mechanism to anyone to whom you made an Executable version #available; and if made available via Electronic Distribution Mechanism, #must remain available for at least twelve (12) months after the date it #initially became available, or at least six (6) months after a subsequent #version of that particular Modification has been made available to such #recipients. You are responsible for ensuring that the Source Code version #remains available even if the Electronic Distribution Mechanism is #maintained by a third party. #You may distribute Covered Code in Executable form only if the requirements #of Section 3.1-3.5 have been met for that Covered Code, and if You include a #notice stating that the Source Code version of the Covered Code is available #under the terms of this License, including a description of how and where You #have fulfilled the obligations of Section 3.2. The notice must be conspicuously #included in any notice in an Executable version, related documentation or #collateral in which You describe recipients' rights relating to the Covered Code. If distibuting both binary and executable from the same server is considered on the same media then there is no problem, except perhaps the notice requirement. If they are not considered to be on the same media, (as one could consider that electronic distribution is media-less distribution, then we are depending on snapshot. That is actually fine, as long as ftp-masters are willing to take on the burden of providing access to the source should snapshot fail. The problem with the wording of the MPL/IPL there is that it seems to assume that binaries will be shipped on physical CDs (or similar). As such the distributer can either include the source, or make sure the recipients can retrive it from the web (or similar) for at least 1 year after the distibution (or for at least 6 months after they offer to send the recipents a newer version [obviously the requirements start all over for the new version] ). The licence seems to completely ignore the possibility executables distributed electronicly. I'm guessing based on the same media thing that the drafters wanted basically the main GPL distribution option and a modified version of the written offer option, where instead of a written offer, it is electronic availabity of code. However, the drafters did not make this clear. (I'm guessing the drafters were lawyers who normally wrote licences relating to software on disc, and completely overlooked the possibility of distributing the executables over the Internet.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
I agree with AJ's statements and add only this: Apt is priority important. That is the same priority as openssl. Apt has relativly few revese dependencies (it appears to have less than openssl does). But libapt is without any doubt a system library under the GPLv3. It accompanies apt which is without doubt a genuinely fundamental component of the system. So I'm thinking the Brett's criteria are not quite ideal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 app with copied GPLv2 or later source and linked against LGPL-2 or later libraries
Anthony W. Youngman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] In message [EMAIL PROTECTED], Neil Williams [EMAIL PROTECTED] writes All the gnucash source code used in gpe-cash is GPLv2 or later. The Gtk frontend for gpe-cash is GPLv3 or later. I am therefore using my option to distribute and modify the gnucash source code under a later version of the GPL, bringing the entire source code for gpe-cash under version 3 of the GPL. This specifically includes the shared library libqofcashobjects. Neil Williams [EMAIL PROTECTED] You are NOT bringing the entire source code for gpe-cash under version 3 of the GPL. If it was licenced 2 or later, it STAYS 2 or later. What you are doing is saying gpe-cash contains some code that is '2 or later' and some code that is '3 only' or '3 or later', therefore 3 is the only licence that is valid for gpe-cash. To re-iterate. You are NOT changing the pre-existing licence on code you've borrowed. But because of the mix of licences, the only licence that is valid for the combined work is v3. Perhaps a bit pedantic, but you are right. What he is doing is doesn't actually change the licences, but the result effectively has the licence of GPL v3 (or perhaps GPL v3 or Later). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Kern Sibbald [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello Shane, Bacula is nearing the end of a development cycle and the next version will be released in a matter of weeks, so I would like to revisit the problem that recently came up with the Bacula license. My purpose is not to debate the issues but rather come up with a plan forward for Bacula so that all distributions can use it with OpenSSL or any other Open Source code without problems. Please excuse me if I provide you with a bit of my reasoning and thoughts -- the idea is to help you target responses so I can end up with an accpetable solution. History: Bacula originally used the GPL v2 license, but I added some modifications to it -- most if not all are (IMO) now contained in the GPL v3. However, some of my original modifications created objections with Debian, so I removed them. In addition, Debian has an issue with distributing Bacula linked with OpenSSL and as a consequence, I added a modification to the GPL permitting Debian to link Bacula with OpenSSL. In more recent discussions with you, it seems that some of my modifications to the GPL (particularly the Debian clause) created a legal problem with Fedora and hence Red Hat because the GPL v2 is incompatible with the OpenSSL license and because there are about 10-20 files in the Bacula source that are copyrighted by third-parties under the GPL, so by modifying my license, I was or could have been technically violating their licenses. Well it is not a violation to have a mechanism to allow third parties to link to openSSL. The third parties would be violating licences by linking the work (assuming the FSF's linking theories are in fact leagally sound), however that is not your concern. What would be your concern is that distributions are often not willing to distribute the linked executables, for obvious reasons. However, for you the ideal situation would be to get permission from the copyright holders of the gpl'ed code you did not write to add a clause allowing linking to openssl. If you could do that, then just add the clause and everything is fine. One other possibility you did not list in your message would be to convince openSSL to change the licence to one that is GPL-compatible. This seems highly unlikely (nearly impossible), but would finally fix this problem once and for all. (The OpenSSL team feels the licence is GPL-compatible. It's unclear why, as it has a BSD like-advertising clause that is infamous for its GPL-incompatibility). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 app with copied GPLv2 or later source and linked against LGPL-2 or later libraries
Neil Williams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] All the gnucash source code used in gpe-cash is GPLv2 or later. The Gtk frontend for gpe-cash is GPLv3 or later. I am therefore using my option to distribute and modify the gnucash source code under a later version of the GPL, bringing the entire source code for gpe-cash under version 3 of the GPL. This specifically includes the shared library libqofcashobjects. Neil Williams [EMAIL PROTECTED] libgpewidget, GPE and gpe-cash: === libgpewidget is licensed under the Lesser GPL v2 or later, like most gpe libraries. gpe-cash under the GPLv3 can be linked against these libraries. See http://gplv3.fsf.org/dd3-faq Have I got that right? As far as the legality and licence compatibility, everything looks fine. As for what is going into the copyright file, I have no comment. Somebody more familiar with that than me should address that. IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: whichwayisup: CC-v3.0 licenses do not meet the DFSG
Thadeu Lima de Souza Cascardo wrote in message news:[EMAIL PROTECTED] [...] | e. For the avoidance of doubt: | | i. Non-waivable Compulsory License Schemes. In those | jurisdictions in which the right to collect royalties through | any statutory or compulsory licensing scheme cannot be | waived, the Licensor reserves the exclusive right to collect | such royalties for any exercise by You of the rights granted | under this License; This is worrying, IMHO. DFSG#1 states, in part: The license may not require a royalty or other fee. Hence I would say that a license where the Licensor reserves the exclusive right to collect royalties does *not* meet DFSG#1. On the other hand, in a jurisdiction in which royalty collection rights cannot be waived, this issue seems to be *unavoidable*... How can that be worked around? Is this clause a legal no-op? But is this a freeness issue anyway? How do we deal with jurisdictions where granting some of the permissions required by the DFSG is *impossible*? IANAL, IANADD, TINLA, etc. Same here. I guess the meaning of this clause is that the Licensor will be the only one to collect such royalties. That is, nobody else will collect them. That is a plus. I agree. First of all, in the case of cc-by, the licence is explicitly royalty free. This clause is about the right to collect the non-existant royalties. Also this only applies to forced royalties like compulsory licencing. Now, it might be that some legal system does not allow royalty free-licences. In that case this clause can become meaningful. It is also possible that in some legal system, while royalty-free licences are legal, there are certain activies that require royalties regardless. In that case again, this clause is meaningful. Finally, in some countries, there are compulsory licenses, which much be made available. For example, the compulsory licensing for music in the United States. AIUI basically, the law says that if you pay a certain amount, you recive a licence to use the song. This true regardless of the wishes of the copyright holder. This clause may be relevent in the case of a song licenced under something like CC3.0 BY-NC, and somebody choses to use the compulsory linsencing system. That clause may allow the copyright holder to collect the royalty directly, rather than having ASCAP (or whoever it is who normally collects this) take a chunk. Regardless of all of that, I do not believe a program should be considered non-free because of messed up laws in some countries. It seems reasonable for a licence to acknowledge the possibilty of such messed up legal systems, and try minimize the damage. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Jagged Alliance 2 Source Code
Ben Finney [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Dennis Schridde [EMAIL PROTECTED] writes: This is not Debian related, but I think you are the ones who know best about licensing issues. This list, debian-legal, is a resource for Debian developers to determine whether a work is free software compliant with the DFSG. Its regular members contribute largely on the understanding that they're helping the Debian project. Yes. For what its worth, The code looks non-free (by DFSG and FSF standards). It is definately not GPL compatible. The code does look distributable, but only in non-free, and I'm not certain of that either (did not look closely enough). That is about all the anaysis he will be likely to get from this list, unless and until the program is proposed for packaging, and/or a Debian legal contributer feels bored. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of GPL v3
Florian Weimer [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] * Francesco Poli: To be honest, I can't see any problems with this particular aspect of the SHING GPL. SHING GPL ? Sun HP IBM Nokia Google, major funders of the FSF and beneficiaries of this clause: | You may convey covered works to others for the sole purpose of | having them make modifications exclusively for you, or provide you | with facilities for running those works, provided that you comply | with the terms of this License in conveying all material for which | you do not control copyright. Those thus making or running the | covered works for you must do so exclusively on your behalf, under | your direction and control, on terms that prohibit them from making | any copies of your copyrighted material outside their relationship | with you. Among other things, this allows to run GPLv3-software-turned-proprietary on grid-like services. I would have preferred that this remained a grey area. On the other hand, without this, there would be the legal questions of runing GPL software on your web server, when you do not own the server. (I think that some colo-facilities work like this, and know that some hosting services work like this.) I'm not really to concerned with people running modified GPL'ed programs on third party grid services, as they could in theory do the same thing with an internal grid service if they had one. Ideally they would release any useful changes anyway. If not it still does not seem like too big a deal (to me). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of GPL v3
Steve Langasek [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Here I'm confused again. What does making the source code available have to do with patents? Isn't it the case that the license already requires source code availability? How does making the source code available help the patent problem? First of all the requirement is for *public* availability (even in the case of private distribution), which is not a requirement of the rest of the licence. I think it is the ffmpeg situation. They distribute code (which allegedy cannot violate a patent), and the end users can download and compile it. I guess the FSF feels that end users are unlikly to be sued for this, although AIUI, under US law they can be sued for that. This only seems to benefit those people who the patent does not apply, such as people in contries that do not allow software patents. Is the meaning here that the Corresponding Source is only available if there are no patents applying to it? That's the only sensible meaning I can extract, but the license seems to go about saying this in a rather obtuse way. What does (2) really mean? How can one arrange to deprive [oneself] of the benefit of the patent license -- by goading the licensor into suing you? :) Otherwise, even if the patent license agreement is terminated on paper, how do you force the patent holder to still treat everyone fairly? Well, in many cases patent licences require continuing royalty payments. I'm pretty sure that if you start refusing to pay, but continue to use the patent, you will be sued. I agree that in the case of a licence involving a flat payment for perpetual use, this clause does not do much to level the playing feild, as the patent holder is unlikely to sue somebody who has made all applicable payments, even if they have nominally terminated the contract. But, ok; in spite of the above doubts, they've done a pretty good job of closing the patent loophole, and done so in a way that I think is DFSG-ok. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [long] Last call draft of GPL v3
Francesco Poli [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi all, a new Last Call Draft of the GNU GPL v3 has been published on 31 May 2007 by the FSF. The full text of this fourth draft can be read at http://gplv3.fsf.org/comments/gplv3-draft-4.html My comments on the draft follow. I will send them to the FSF public consultation system RSN (since they are accepting comments for only 30 days, starting on 31 May). The usual disclaimers: IANAL, IANADD. [snip] Bad: too restrictive Clause 5d is now simpler and clearer than in the previous drafts: as a consequences, its issues are more apparent! ;-) This clause is worse than the corresponding clause 2c in GPLv2... :-( [snip] I would like to see clause 5d dropped entirely. Or, at least, it could be modified so that it only applies to cases where the original Program is also interactive. Something like: | d) If the Program has interactive user interfaces which display | Appropriate Legal Notices, this feature must be preserved in each | interactive interface that is also present in the work. It is one thing to require preservation of the Appropriate legal notices feature in existing interactive user interfaces. It is entirely different to compel users to include such a feature in any newly created interactive interfaces. This is far worse than the equivalent clause in GPL v2. People WILL ignore this requirement, and assume it merely mandates preservation of the feature in existing interfaces. This is a *critical* problem with the license IMHO. Further there is no exception for interactive user interfaces where it is *impossible* to meet the definition of displays 'Appropriate Legal Notices'. Cases like an audio-only interactive interface could not possibly include a convenient and prominently *visible* feature, and might not be able to tell the user [..] how to view a copy of this License. It might not be possible to tell the user how to view the licence. Especially if the device has no means of visual output, in which case there is no way to view the licence. The program could perhaps give instructions on how to request to have the licence read to them, but that is not what is required. Kills copyleft: are these the cousins of GFDL's Invariant Sections? What exactly is a reasonable legal notice? What exactly is an author attribution? It seems that these terms are not defined anywhere in the license. I'm concerned that they could be interpreted in a broad sense and allow people to take a GPLv3'd work and add some sort of invariant long text that nobody will ever be able to remove or modify... This option could make a work include unmodifiable unremovable parts and thus fail to fully grant the freedom to modify. I would rather avoid introducing such options in the GPLv3! === this option could make the work fail DFSG#3, when exercised Hmm... reasonable legal notice will at least include a copyright statement. Some further guidence could be useful. Can a mandate to include an entire licence (talking abiout one of the short licences, like BSD, Expat, etc. [obviously a modified version of the licence, with a mandate to include the licence text in the Appropriate Legal Notice]) be considered a resonable notice? It almost seems reasonable, but on the other hand it is somewhat long, which may be unreasonable, especially in certain types of interactive interfaces. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
Francesco Poli [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I am sorry for not being clear enough: I meant to refer to the *thread* that started from your message, not just to your message. I now realize that, unfortunately, the rest thread was on the next month and hence is not linked by the web archives! I apologize, the rest of the thread starts here: http://lists.debian.org/debian-legal/2007/04/msg1.html Not a problem. The Final draft of the GPL 3 is now out. At least serveral of the issues you brought up have been addressed. For example the part that began If the work has interactive user interfaces, each must include a convenient feature that is now: d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so. A new definition has been added: An interactive user interface displays Appropriate Leal Notices to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion. One other potential issue with this is the additional terms section which a clause that reads: b. requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or This still places some slight restrictions on modification, but it is limited. This does looks better overall IMHO, and is probably about as good as the FSF is willing to get, on this issue. There is also now a dissussion draft of the GNU AGPL (acoording to the changes document, although there is no sign of it on the discussion site. The reference to the Magnuson-Moss Warranty Act has been removed. The basic interperation concepts that were desired have been explicitly stated, rather than referencing US caselaw. They did not change anything in the anti-circumvention section, except for the title of the section. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
Francesco Poli [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Sam Hocevar [EMAIL PROTECTED] wrote: 1. The GPLv3: the latest draft did not raise major objections from -legal I don't think that this is an accurate description of the discussion. See http://lists.debian.org/msgid-search/[EMAIL PROTECTED] I'm not sure if I would charcterize my analysis as including major objections, but rather some concerns. I explicitly stated that I did n ot actually find DFSG problems, although two complicated portions were not analyized. So I would say I had concerns but not nessisrally objections. Nevertheless, I would also say that my post is hardly consensus. So while no major objections may have been raised on list, it is also true that there is no real consenus that the licence in its current draft from does meet the DFSG. Impling that it does to the FSF is not a great idea. IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#383316: Please vet this modified CC license for uploading FoF music to non-free (was: Re: Could you please forward this proposed license to Teosto?)
Jason Spiro [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On 5/15/07, Matthew Johnson [EMAIL PROTECTED] wrote: ... How about: http://creativecommons.org/licenses/by-nd-nc/1.0/legalcode with 4. d. added saying: You may not publicly display, publicly perform, or publicly digitally perform the Work except as part of the game and you may not distribute the Work except with the intention of it being used with the Game. and 1. g.: The Game means the game Frets on Fire or a derivative work of Frets on Fire. Dear debian-legal, The license is below. Is it good enough for Tommi Inkila's FoF music to be uploaded to non-free? I do not personally see any distribution problems with this licence. The only possible (general) issue is the exact definition of the game Frets on fire. Does that alow minor derivitives that use the same name? (That is what Debian would be distributing, most likely, as Debian packages often include patches against the source code). It would be nice if this would be expanded to include all derivitves of FoF. However, even just expansion to include all derivitives of FoF that retain the same game style (that is to say are still Guitar Hero clones), would be an improvment. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Logo trademark license vs. copyright license
Francesco Poli [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I don't know if Debian logos are actually *registered* marks. In the US: The word Debian is a regestered trademark of SPI. Or more accurately, the word Debian is a trademark registered by SPI on behalf of the Debian Project. It is regerstered in the category: IC 009. US 021 023 026 036 038. G S: Computer Utility and Operating System Software. Trademark serial number 75386376. The only other trademark registered by SPI is Open Source, which is now a Dead Mark. This was from before OSI has split off. So it does not look like the logos are registered marks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BSD MIT licenses compatible?
Suraj N. Kurapati [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Andrew Donnellan wrote: On 4/14/07, Suraj N. Kurapati [EMAIL PROTECTED] wrote: The BSD is not compatible with the MIT license because it has an additional condition (i.e. you cannot use copyright holder's names to promote the product) that the MIT license lacks. Um, neither the BSD nor the MIT licenses have a clause saying 'You may not add additional restrictions.' Wonderful! Thanks for the clarification. :-) So when I appended bsd.c to mit.c, did the entire mit.c become licensed under both licenses? That is, did the originally-MIT portions of mit.c inherit the extra condition from the BSD license? Thanks for your consideration. That is an easy way to view it. Technically, what you had said before is perfectly correct, but thinking of the file as being licenced under the combination of the conditions is also perfectly valid (as long as you realize that if the parts are seperated, the original lices still apply, of course). In summary, just make sure you meet all the terms of both, and you are fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 Draft 3- text and comments
Francesco Poli [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Mon, 2 Apr 2007 21:50:12 -0400 Joe Smith wrote: [...] I think this stems from source code not requireing a patent license. So if the source code is available, the patent can be bypassed by having the consumer download and compile the code themselves. Of course all of this can only protrect the downstream consumer if the compiled binaries are not being passed around. Hence, with this kind of protection from patents we lose the permission to distribute binaries! It does not look as a good enough protection, then... I agree. It does protect the freedom of the end user, but without more effort on the part of the licensor, things can be problematic. I'm not sure about commerical entities compiling from source code and using the application. I suspect that sort of use may still need a patent license. Thus we have effetive discrimination against businesses. (That discrimination is not part of the licence, but is part of the source-code only software patent workaround.) Thus ideally the GPL v3 would not allow public availability of source code as an option, but require further protections. However that could be a problem. There has historicly been a fair amount of GPLv2 covered code that was distributed source-only because of patent issues. On the other hand, most of the time most of the time that happened the party did not have an actual patent license, so that clause would not apply to them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 Draft 3- text and comments
The following is intended to be a compression of your comments down into the most important points (generally, the areas you are concerned about), to aid further discussion. As well as some responses to your comments. (I had to manually fix the quoting, so apologies if I mess it up somewhere). Francesco Poli wrote in message news:[EMAIL PROTECTED] [...] 3. No Denying Users' Rights through Technical Measures. No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures. Problematic: possibly untrue This clause is improved (being now denationalized), but still problematic. It could be seen as an untrue statement in some cases. How can the licensor say that the covered work won't be judged as part of an effective technological measure under a given law? That is for the courts to decide. In some scenarios, GnuPG may actually be considered part of an effective technological measure and could be deemed so by a judge... I think most courts do not rule on uncontested fact. This clause is probably intended to prevent EvilCorp(TM) from claiming that the work falls into that class. The other party is unlikely to contest that, claiming the work does fall into that class, as that could only hurt said other party. When you convey a covered work, you waive any legal power to forbid circumvention of technical measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, Bad: possibly overreaching This clause is clearer than in the previous draft, but still troublesome, as it seems to be overreaching. For instance, it could be interpreted as covering legal powers to forbid computer crimes such as unauthorized intrusion into computer systems. E.g.: suppose that the covered work is a vulnerability scanner, or password cracker, or anyway a tool that could be used (among other things) to break into other people's computers. Using that tool in this manner is exercising a right under this License and is a circumvention of appropriate technical measures set to protect a computer system or network from unauthorized access. Gaining unauthorized access to a protected computer system or network is forbidden by law in several jurisdictions; do I waive such a legal protection, when I convey the covered work? I suggest dropping the waiver entirely, thus leaving the following disclaimer only. === waiving legal rights can be seen as a fee: this clause could fail DFSG#1 and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technical measures. Agree with your assesment, assuming the disclaming of intention could let a defentent invoke estoppel or other similar. Presumably that clause is intended to prevent the obvious workaround of moving the anti-copyprotection-circumvention law outside the copyright law. Overall, I find this to be one of the parts of the licence that is very unclear if approched without knowing it is about DCMA-style anti-circumvention laws. If one was not aware of that problem, one may well be quite confused while tying to figure out the purpose of that section [...] d) If the work has interactive user interfaces, each must include a convenient feature that displays an appropriate copyright notice, and tells the user that there is no warranty for the work (unless you provide a warranty), that licensees may convey the work under this License, and how to view a copy of this License. Specifically, if the interface presents a list of user commands or options, such as a menu, a command to display this information must be prominent in the list; otherwise, the work must display this information at startup. However, if the Program has interactive interfaces that do not comply with this subsection, your work need not make them comply. Bad: too restrictive Clause 5d in GPLv3draft3 is basically unchanged with respect to previous drafts. It's worse than the corresponding clause 2c in GPLv2... :-( It's an inconvenience and border-line with respect to freeness. Actually this clause restricts how I can modify what an interactive program does when run. It mandates a feature that I *must* implement in *any* interactive interface of my modified work. It's very close to place an unacceptable restriction on modification. What is more awkward is that it seems that when a non-interactive work is modified so that it becomes an interactive work, the modifier is *compelled* to implement these features in *any* newly created interactive interface... I would like to see clause 5d dropped entirely. === very close to
Re: Debian-approved creative/content license?
Francesco Poli [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Exactly, and in some cases an author/maintainer *may* prefer to modify a lossy-compressed form directly. In some other cases, he/she *may* prefer working on uncompressed data and recompress afterward... Yes, I'm really starting to question the idea of source. It seems to me that the preferred form of modification seems to depend on the desired modification. Since this is Debian, I will use the example of Toy Story. Let us say that Steve Jobs inexplicably decides he wants to release Toy Story as a open-source movie, and manages to convince the rest of the people at Disney that this was a good idea. Thinking about only the video portion, what would we call source? I can see three answers to this: 1. The model files, lighting, and animation information. This can be used to regenerate the movie. 2. The original raw frames of the rendered video. 3. The compressed final video stream. Lets take a closer look at these: First look at the first option. This is clearly the most high-level description. It may seem like this is the ideal format to call source. Certainly this would be the form one would prefer if one wanted to introduce a new character, or replace a character in the movie. Also this would likely be the preferred form for making major plot changes etc. However, the recourses required to render the movie are significant. The movie used 117 computers (87 dual-processor and 30 quad-processor SPARCstation 20s and one eight-processor SPARCserver 1000 [How 87+30+1=117 is unclear to me.])which thus totals 302 processors, and a combined performance rate of 16,000 MIPS (This is probably the value most relevant for today).It allegedly would have taken 43 years for a single processor to render the entire feature. Even with the significant speed increase in computers since 1995, it should be clear that rendering the movie would still be a significant undertaking. That to me indicates that for many types of modification this would not be the preferred form. Now lets look at the raw frames. They took up approximately 300 MB of storage each, for a total of 144000 frames. That yields a total of around 43.2 terabytes. I think we can rule this out as the preferred form for the vast majority of modifications. So how about the compressed video stream? For some types of modifications such as creating a music video by syncing clips from the movie to music (Youtube is full of examples of this), this is probably the ideal form for modification. But it is not really useful for some types of modifications which may include introducing new characters, or major plot changes. So which one(s) should be considered source? Sincerely, Tacvek Source for Toy Story Statistics: http://www.sun.com/smi/Press/sunflash/1995-11/sunflash.951130.3411.xml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GPL v3 Draft 3- text and comments
The entire draft can be found at the end of the message. I belive some positive changes have been made, but some changes are for the worse. Here is my analysis of the license. This is more a general analysis, but I am trying to point out any DFSG-freeness problems I find. I have no real comments on the preamble. Copyright also means copyright-like laws that apply to other kinds of works, such as semiconductor masks. (from Section 0) I like this, but I'm not sure that it is not problematic. I am aware that Nintendo's official policy on ROMs (Dumps of the data contained in the ROM chip of a cartidge based game) is that they are not lawful, even if you both own the original, and are creating the ROM file yourself. They mention some sort of exception to the rules regarding media-shifting and backup/archival copying due to the games being stored on a chip in a cartrige. I'm guessing they are trying to claim that Mask Rights apply. They may be right if a user intends to create a new ROM chip containg the data, but if a computer file is the final destination, that seems highly unlikely. I'm guessing this clause intended to cover these sorts of claims with respect to GPL'ed software. It also clarifies that if a semiconductor mask design is what is being licenced, then Mask Rights are licenced just as Copyright is. No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures. (from Section 3) Trying to remove the US specific law refernce on this clause intended to defeat the concept of DCMA-like anti-circumvention rules only makes this harder to understand, and makes its purpose less clear. When you convey a covered work, you waive any legal power to forbid circumvention of technical measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technical measures. ( from section 3) That sentence is only a little less cryptic. Sure we understand what it is intended to mean, but what about other people unfamilar with the DMCA anti-circumvention rules. What would they think is being said? Section 4 (about verbatim source code copying) looks fine to me. I see not problems with it, except perhaps that the section title may be a bit misleading as it only applies to works in source form. The work must carry prominent notices stating that you modified it, and giving a relevant date. (from section 5) This is ok, but I'm not sure about the relevant date. Would the date I first thought about making the change be sufficient? (The date the change was made or published is presumeably what was intended). Section 5d (If the work has interactive user interfaces ...) is one I've never liked. I don't like the way it is worded currently. Especially the last sentence. The way it was stated in GPLv2 seemed clearer to me than this does. Section 6b says valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, That is an interesting concept. I suppose it is good. That is not a new change so I must have missed that change when it was first made. The new stuff at the end of section 6, about consumer products and Installation infromation is the new form of the TiVo clause, and is likely a DFSG--freeness minefeild. I'm not certain of that, but it seems big and complicated and consists almost entirely of completely new wording. This is one section that is important to look closely at. Section 7 Seems better, and far less problematic. Section 8 looks ok to me, but perhaps there is some freeness problem with it that I am not seeing. Section 11 may be tricky as it is covers patents. I would not be too suprised to find freness problems associated with this section. Section 13 is far better than the equivlent that was found in the previous section 7. I'm not a fan of the licence explicitly referencing that other licence, but it prevents Affero-covered code from being considered GNU-gpled. It is basically equivlent for our purposes to an additional permission that allows linking to a proprietary library. If used the complete work as a whole is non -free, but the GNU-GPL'ed part seperated is free, but may need to be in contrib it it depends on the Affero Code. (This is all based on the assumption that the affero V2 is considered DFSG-nonfree. If it is considered DFSG-free then this is not an issue at all.). My current conclusion is that I'm not seeing any DFSG-freeness problems. Some may still exist, and iif so likely exist witith the
CC 3.0-SA unported
http://creativecommons.org/licenses/by-sa/3.0/legalcode I tried to include the text, but had trouble getting it to degrade nicely. This message will have general comments about the licence mixed in with DFSG freeness concerns. Unless I explicitly mention a comment as being a freeness-concern it is safe to assume I see it as only a general concern. Interesting definition of distribute: means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership. I would not personally have required public availablily in the definition of distribute. The definition of Publicly perforn is sufficiently complex as to be a candidate for breaking out and numbering the subclauses. Section two looks perfectly fine to me. What is the need for Section 3(e)? The licence is explictly royalty-free. Is it really a legitimate concern who has the right to collect the non-existant royalties? I think this is cruft left over from the noncommercial versions of the licence. Section 4(a) has the first DFSG question that I have noticed: When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This is the old DRM problem. It does not look to be resolved with this particular wording. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(c), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(c), as requested. This has been argued to potentially be a problem. It looks to exist in this form of the licence as well. Section 4(c) The credit required by this Section 4(c) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. This one looks like it might be accaptable under the DFSG this time. For adaptations or collections, the promenance clause is restricted to those places where a complete enumeration of contributers can be found. That sounds to be like it is saying: if there is a section listing all contributers, then in that section, you should list all contributers in a manner that is equally prominent. In this form it sounds inconvient, but not nessisarally non-free. So all I'm noticing as potentially DFSG-freeness problems is the DRM, and credit removal. . -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Java in Debian advice result
Walter Landry [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] John Goerzen [EMAIL PROTECTED] wrote: Back in summer 2006, there was a thread regarding the inclusion of Sun's Java under the DLJ in Debian's non-free area on its FTP site. Questions about the license were raised at that time. In my then-capacity as president of SPI, I asked SPI's attorney to give advice on the questions. For various reasons, we just recently have the answers back. Current DPL Anthony Towns and SPI President Bdale Garbee have asked me 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. The short answer is that there should not be a legal liability on SPI from this action. Due to the indemnification clause in the Sun license, there is a possibility -- though it is remote -- of legal liability on some or all Debian developers. Just whom such theoritical liability would rest upon depends on whether the ftpmasters are acting on their own behalf or on that of the organization, which is unclear legally-speaking at the present moment. Does this potential liability include mirror operators? Also, I presume that you don't really mean *all* Debian developers. I do not see how it could extend beyond the ftpmasters, the DPL, the package maintainers, and perhaps some other officials in Debian. Agreed. If a judge does not view Debin as any sort of oranization or corporation for legal purposes, then it seems unlikely that any person who was not involved with this package would have any liability. Alternatively a judge could potentially decide that Debian is some form of organization/company/corporation (It has a constitution, bylaws, elected officials, and the TC could perhaps be interpreted as a Board of Directors [Although that would not be very accurate.]). In this case, I could see the possbily of liability ending on one or more of the elected officials, but still not see how unrelated regular developers would have liability. IANAL. IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412063: ITP: rott -- Rise of the Triad: The HUNT begins
Fabian Greffrath [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] A quick glance showed me nothing that seemed to prevent downloading the data files from the ftp site, but it does bring up the question of whether the port of the main program was possible without violating [6][d] or the equivelent clause in the EULA for the non-sharewhare version of the game. (Assuming that a clause like [6][D] is in fact enforceable.) Please note that the source code hast been released on December 20, 2002. This is more than 8 years later than the release of the shareware version which contains the `VENDOR.DOC' file. The original source code is released under the terms of the GPL and can be found at ftp://ftp.3drealms.com/source/rottsource.zip/. Ok. then I see no problem there. There would have been no reverse engineering needed, and the GPL licence would end up overriding the original licence on the program (not the data, of course). Now, as for Debian, I suspect this package will need to be in contrib, but I'm sure you have already though about that. In other words, in my non-legal opinion, everything looks fine. IANAL IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412063: ITP: rott -- Rise of the Triad: The HUNT begins
Fabian Greffrath wrote in message news:[EMAIL PROTECTED] That zip does not contain that file: Sorry, you are right. It is contained in the `ROTTSW13.SHR' file which is just another zip file. Find attached the full VENDOR.DOC. A quick glance showed me nothing that seemed to prevent downloading the data files from the ftp site, but it does bring up the question of whether the port of the main program was possible without violating [6][d] or the equivelent clause in the EULA for the non-sharewhare version of the game. (Assuming that a clause like [6][D] is in fact enforceable.) IANAL IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creative Commons Attribution 2.5
Matthew Johnson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've seen a previous review from debian legal about the Creative Commons licences which renders them non free. However, I've just come across a licence claiming to be Creative Commons Deed Attribution 2.5 which is considerably shorter and afaict is free. I wanted to check here before packaging, however. The relevant segment is included here and the full copying.txt is attached. We are aware that the songs and fonts need replacing before packaging. Well that is just the non-legalese synopsis of the CC-by-2.5. It was not intended to be used as an actual licence text. It certainly can be used as a licence text. (Just about anything can be). It is also reasonable likely to hold up it court. It does lack some of the legal protections the legal text has, such as the warrenty disclaimer, but I suspect that a court would treat it as equivlent to the Expat licence, except perhaps in the case of a warrenty dispute. However, It is not clear if copyright holder intended to licence the works using the text of the dead as the licence, rather than using the actual licence itself. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Legal status of tkchooser (microsoft logo used)
Jeff Carr [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On 12/21/06 13:53, Joe Smith wrote: That's probably considered fair use for the purpose of which it was intended. I'd guess Microsoft is unlikely to complain. In any case, you should ask the tkchooser authors about it and they can contact Microsoft if they think it is necessary. The use there does appear to fall under trdamark fair use. If there is no copyright problems with respect to the image (which could happen if the image is taken directly from one in windows, for example) then there should be no problem with that image. Sorry for the long delay in responding. Your reasoning here is not clear to me. It would be interesting to know how you come to that conclusion if you care to explain. It seems completely opposite to my own conclusion and experience. I concluded that the image did look to fall under trademark fair-use, as the Windows logo was being used to reference the Microsoft Windows brand Operating System. Your original message also appeared to agree with me on that point. I did express concerns that the image may still have copyright problems if it was taken directly from Windows, rather than being recreated. Even if one is to argue that by considering the image a trademark Microsoft implictly grants a copyright licence to use that image in cases where the trademark law considers the use of the trademark as fair use, the image would still have the problem of failing the DFSG. So my conclusion was that if there is no copyright problems with respect to the image, it appears to be fine the way it is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnuplot, is it free?
Carles Pina i Estany [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, Gnuplot has a non-common license: http://packages.debian.org/changelogs/pool/main/g/gnuplot/gnuplot_4.0.0-5/gnuplot.copyright It says: It is obligatory to add oneself (e.g. Debian) as primary contact if you distribute modified binaries, but in Gnuplot Debian package the primary contact is upstream. It is not possible to distribute new versions of gnuplot (only original source code and patches), etc. Should be gnuplot included in Debian, with this license? Thanks! Well Let's look at it. /*[ * Copyright 1986 - 1993, 1998 Thomas Williams, Colin Kelley * * Permission to use, copy, and distribute this software and its * documentation for any purpose with or without fee is hereby granted, * provided that the above copyright notice appear in all copies and * that both that copyright notice and this permission notice appear * in supporting documentation. I'm fairly sure that is good. The supporting documentation clause can be a pain, but I'm not sure i rember anybody arguing that it is non free. * 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. We allow this, but it is inconvient. DFSG #4 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, This could be problematic. Would this require that the patches be shipped in the binary packages? Or would shipping the source package (which includes the patches as required below) be sufficient? I think the former may be non-free, but the latter is free. I'm also thinking the latter is what is meant. * 2. add special version identification to distinguish your version *in addition to the base release version number, once again allowed by DFSG #4 * 3. provide your name and address as the primary contact for the *support of your modified version, and This one could be free, but there has been some debate over similar clauses. I'm thinking this is acceptable * 4. retain our contact information in regard to use of the base *software. That is fine. * 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 works, but any problems caused by sections 2 through 4 apply here as well. * This software is provided as is without express or implied warranty * to the extent permitted by applicable law. That is fine To me it looks free, but the Debian maintainer must be listed as the primary contact. Of course others could disagree. IANAL, IANADD Complete licence text: /*[ * Copyright 1986 - 1993, 1998 Thomas Williams, Colin Kelley * * Permission to use, copy, and distribute this software and its * documentation for any purpose with or without fee is hereby granted, * provided that the above copyright notice appear in all copies and * that both that copyright notice and this permission notice appear * in supporting documentation. * * 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 software is provided as is without express or implied warranty * to the extent permitted by applicable law. ]*/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Legal status of tkchooser (microsoft logo used)
Jeff Carr [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On 12/21/06 11:00, Daniel van Eeden wrote: The file /usr/lib/tkchooser/icons/winpop.pnm from the tkchooser package uses an microsoft windows logo. Is that legally permitted? Please CC or BCC me, I'm not on the list. That's probably considered fair use for the purpose of which it was intended. I'd guess Microsoft is unlikely to complain. In any case, you should ask the tkchooser authors about it and they can contact Microsoft if they think it is necessary. The use there does appear to fall under trdamark fair use. If there is no copyright problems with respect to the image (which could happen if the image is taken directly from one in windows, for example) then there should be no problem with that image. IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: firefox - iceweasel package is probably not legal
Sean Kellogg [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Wednesday 06 December 2006 18:47, Ben Finney wrote: Sean Kellogg [EMAIL PROTECTED] writes: On Wednesday 06 December 2006 14:30, Michael Poole wrote: Apparently law instead requires us to assume users are in fact morons in a hurry. What a sad state of affairs. Yes, that's exactly what the law requires. IANAL. I will merely draw to your attention that, as far as I can tell, the consistent usage of the phrase a moron in a hurry in trademark history has been to describe the level of confusion which trademarks should *not* protect. Fair enough. But there is a great deal of room between Debian FTP Master and Moron in a Hurry that is being glossed over here. In my own Linux Users Group there has been a lot of confusion over what is, and is not, Iceweasel and the why behind the change. I consider none of them to be morons or in much of a hurry. It is unfortunate. And many people seem to grab onto the problem with the unapproved patches. I'm quite confident that would have been resolved, probably by MoCo maintaining a list of approved patches, and Debian making an exception to the no new upstream versions in stable rule. The problem was with the logo copyrights. That really confused people. People assume we meant the logo trademark, but that is not the case. Many people do not seem to understand that something can have protection in multiple ways. Indeed it is possible to have a whole bunch of protections. For example a computer chip can be protected by patent, mask rights, copyright (especially if the chip contains a standard mask rom, where the data contained therein can be copyrighted), and trademark (or related like tradedress, if part of the design is unique and non-functional). That is a lot of protection. So it is not surprising that some users may become confused. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XBRL XML schema
Warren Turkal [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Can someone take a look at these docs at [1] and let me know if the XML schemas that are distributed by XBRL International can be redistributed in a Debian compatible way? It doesn't look like the documents can be modified, but I cannot tell if that applies to the schemas as well. They appear to intend to have effectively the same licence as the W3C with minimal modifications. The only modifications are: 1. To update the names 2. Remove a nonbinding section that mentions that the w3c will sometimes grant rights to prepare derivitive works under special circumstances. 3. Explicitly list schemas as being available under the software notice. The software notice is what coversd the schema. Because they forgot to copy over the software notice and link to it, we cannot be certain of the intent. However, based on the modifications to the document notice, It seems pretty clear that the Software notice was supposed to be http://www.w3.org/Consortium/Legal/copyright-software-19980720 with the relevent names changed. That is more or less an MIT/X11/expat style licence, which is fine. It claims to be GPL compatable, and does indeed look that way. I reccomend you contact XBRL International, asking them to post their Software Notice, and to link to it from their document copyright notice found at http://www.xbrl.org/Legal2/Copyright-Info.htm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: firefox - iceweasel package is probably not legal
Arnoud Engelfriet [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] MJ Ray wrote: Don't trademarks apply even less to included executable file names than to package names? They're not even used to label anything supplied in trade. They are names of controls used to operate the machinery. I could call my firm's new car model 'steering wheel' and trademark it, but could I then go sue other makers for labelling a control in their cars 'steering wheel'? In your example of the Steering Wheel trademark for cars versus steering wheels in cars, a steering wheel is a functional name,. That makes it entirely appropriate to refer to any steering wheel as a steering wheel. What I don't understand is why a package for the Iceweasel software would carry the name firefox. There's no such thing as a firefox. There is such thing as a firefox. In fact there are wo such things. One is the red panda. Firefox is an unofficial nickname for that species, but is a perfectly valid name. There is also a type of actual fox with the nickname firefox. I will admit that Mozilla firefox did vastly increase the popularity of that nickname for the red panda, but it was not the source. The source of the nickname is a literal translation of a chinese nickname for the red panda. Firefox is thus an arbitray mark, which has a very similar level of protection as a fanciful mark, but jut slightly less. Mozilla is fanciful mark. Fanciful marks that are well established can be used to refute the validity of a new trademark far more easilly than other marks, even if the new mark is in an feild unrelated to that that the current fanciful mark. This is because customer confusion is still likely to result. A Mozilla car manufacture is is likely to have problems because people will likely assume it is related to Mozilla web browsers in some way. There are web browsers, distinguished by names such as Firefox, Iceweasel, Opera and Internet Explorer. When a user does apt-get install firefox he is not saying I want to install a firefox, but I want to install the browser with the name Firefox. I agree that they are not wanting to install a firefox, because that would be absurd. How does one install a red panda? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: firefox - iceweasel package is probably not legal
Sean Kellogg [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [1] My trademarks prof, who did trademark work for wine companies, really disliked that line of reasoning, since wine consumers are usually of higher sophistication and could distinguish beer from wine. However, the PTO commonly denied his client's marks on the grounds that a beer company already had the mark and the international goods category lumped wines and beer together as alcoholic beverages. I agree that the wine consumers would not be confused, but the average beer drinker might assume that a wine sold under the same name as a beer he know of is made by the manufactures of said beer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: photo licenses
Ben Finney [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Maarten de Boer [EMAIL PROTECTED] writes: Ben Finney [EMAIL PROTECTED] wrote: If you want to allow just about any use of the work, while still retaining copyright, you can distribute your work under the Expat license. URL:http://www.jclark.com/xml/copying.txt Which also talks explicitely about software... That's only a problem if your definition of software is too narrow to include any information stored digitally. Note that one reason I recommended the terms of that license for your photographic work is that it doesn't mention source or program. Also, If the person is still concerned about other people interpreting the word Software too narrowly, it would be within reason to use the Expat licence with the word Software replaced with something else suitable. It is preferable to avoid that, as it is a form of licence proliferation, but I think it generally agreed that if somebody wishes to use a non-standard licence, creating the licence by making only small changes to a well established licence is better than writing a new one from scratch. (More likely to result in a free licence.) IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: http://pdphoto.org/
Maarten de Boer [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, I would to know if the use of 'public domain' photos from the website http://pdphoto.org/ to be distributed with an application would be considered DFSG-compatible. Most photo's come with a link to the CC public domain dedication http://creativecommons.org/licenses/publicdomain IMO, that dedication is one thing CC has done quite well. It is a clear statement of intent, and if in a country it is possible to reliquish copyright (In some countries it may not be possible), the statement listed in that dedication is almost certain to be sufficent. In countries that do not recongnize the ability to reliquish copyright, it is unclear if that dedication would have any effect, but being such an overt statement of intent, it is perhaps possible that those countries would conclude that it grants an implied all-permisive licence. (I want include the text here, because I are probably familiar with it) But the website also contains the Copyright page, http://pdphoto.org/Copyright.php , from which I include the contents below. maarten The information on that page indicates that the author is fairly aware of the some of the inportant legalities related to the images, such as noting that he lacks model relases, and also warning about misuse of photos that may contain trademarks or copyrighted material of others (especially of companies). While some of the text is decidedly unprofessional, there seems to be nothing problematic about any statements on that page. IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: main or contrib?
Marco d'Itri [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Please clarify for me, in which section should go a GPL-licensed package, which is quite unusable without (but technically not Depends on), er, obscure blobs of data, usually gathered by a way of sniffing data flow between a proprietary application and a hardware device, an then just replaying? To me, this package should be moved from main to contrib. Yes. No. The package just uploads this data to the hardware device, if requested. It does not use it. Are you saying that this is roughly equivlent to something like a firmwae uploading utility for a proprietory PDA? (That sounds like something that could go in main). If so I would agree that this is a somewhat similar case, however, the device is effectively a component of the computer (albeit an external component), and the software is a driver, which brings it back closer to contrib. Nevertheless, I belive that the plan with the Kernel drivers is that if they can load the firmware from a file, (which can be part of a non-free package), and has no licencing problems, then it can stay in main. I'm not sure that userspace drivers should be treated differently. This one has no licence problems, and can load the firmware from a file, so it is reasonable to let it stay in main. I will say that it is also not unreasonable for the maintainer to decide to move the package to contrib, as it is not really useful without something that is not a component of main. So in summary, it could move to contrib, but that is not required. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
