Preferred licences for audio data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have just got involved with the packaging for FretsOnFire[1] (ITP[2]). One of the problems we have is that upstream say the songs they distribute with it (a song corresponds roughly to a 'level' in the game) can't be redistributed. Therefore, we are seeking replacement songs for the game. However, I'm not sure what a suitable licence for these would be (we are likely to have our choice of licence, since either any open licence will be acceptable to the performer or none). I've heard that there are some problems with the Creative Commons ones, which would be my first port of call. So, does debian-legal have any suggestions for the most appropriate licence for audio data which is DFSG-compatible? (or at least some suggestions of what is DFSG compatible or what might look suitable, but isn't, so that I don't make any mistakes). Finally, if we were to ship the game without any levels is it still suitable for main (I'm guessing not, since quake2 is in contrib and in a similar case)? The upstream game only ships with 3 tracks, you are generally expected to get extra levels either from the commercial equivalents or community sources even in that. Matt - -- Matthew Johnson http://www.matthew.ath.cx/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFweDKpldmHVvob7kRAgb6AKDGYZrBr+wQTUtxnTvGbAPf54Fy/gCfcqXR a9DY0wE8tNK6pJtzSDY6HdI= =aTTH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Creative Commons Attribution 2.5
-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.
All data files, except the songs and the font files mentioned above,
are licensed under the following license:
-
Creative Commons Deed
Attribution 2.5
You are free:
* to copy, distribute, display, and perform the work
* to make derivative works
* to make commercial use of the work
Under the following conditions:
* Attribution. You must attribute the work in the manner specified
by the author or licensor. For any reuse or distribution, you must
make clear to others the license terms of this work.
Any of these conditions can be waived if you get permission from the
copyright holder.
- ----
Matt
- --
Matthew Johnson
http://www.matthew.ath.cx/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFFyzE5pldmHVvob7kRAiQUAJ0RyfKgK3DdUxHo7Po6xHBRHAeCigCg3XUd
3AkcNbOc/c3azyXcMqVatBw=
=Iz7f
-END PGP SIGNATURE-
All source code and data files are copyright 2006 by Sami Ky�stil�,
Tommi Inkil�, Joonas Kerttula, except:
* Font data/title.ttf copyright by Astigmatic One Eye.
* Font data/default.ttf copyright by 1001 Free Fonts.
* Font data/international.ttf Bitstream Vera font license described below.
All data files, except the songs and the font files mentioned above,
are licensed under the following license:
Creative Commons Deed
Attribution 2.5
You are free:
* to copy, distribute, display, and perform the work
* to make derivative works
* to make commercial use of the work
Under the following conditions:
* Attribution. You must attribute the work in the manner specified
by the author or licensor. For any reuse or distribution, you must
make clear to others the license terms of this work.
Any of these conditions can be waived if you get permission from the
copyright holder.
Distribution, modification or commercial usage of the songs is not allowed.
The following is the license for the source code of the game. Note that some
source files derived from other sources might have differing licenses.
Bitstream Vera Fonts Copyright
The fonts have a generous copyright, allowing derivative works (as
long as "Bitstream" or "Vera" are not in the names), and full
redistribution (so long as they are not *sold* by themselves). They
can be be bundled, redistributed and sold with any software.
The fonts are distributed under the following copyright:
Copyright
=
Copyright (c) 2003 by Bitstream, Inc. All Rights Reserved. Bitstream
Vera is a trademark of Bitstream, Inc.
Permission is hereby granted, free of charge, to any person obtaining
a copy of the fonts accompanying this license ("Fonts") and associated
documentation files (the "Font Software"), to reproduce and distribute
the Font Software, including without limitation the rights to use,
copy, merge, publish, distribute, and/or sell copies of the Font
Software, and to permit persons to whom the Font Software is furnished
to do so, subject to the following conditions:
The above copyright and trademark notices and this permission notice
shall be included in all copies of one or more of the Font Software
typefaces.
The Font Software may be modified, altered, or added to, and in
particular the designs of glyphs or characters in the Fonts may be
modified and additional glyphs or characters may be added to the
Fonts, only if the fonts are renamed to names not containing either
the words "Bitstream" or the word "Vera".
This License becomes null and void to the extent applicable to Fonts
or Font Software that has been modified and is distributed under the
"Bitstream Vera" names.
The Font Software may be sold as part of a larger software package but
no copy of one or more of the Font Software typefaces may be sold by
itself.
THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTI
Re: Creative Commons Attribution 2.5
On Thu, 8 Feb 2007, Stephen Gran wrote: All data files, except the songs and the font files mentioned above, are licensed under the following license: Creative Commons Deed Attribution 2.5 That looks fine. cool Distribution, modification or commercial usage of the songs is not allowed. This is a showstopper. We are aware that the songs and fonts need replacing before packaging. ^^ yup, we're going to try and source some songs licenced appropriately. The above CC licence looks like a good one to use then. Matt -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Choosing a license for Frets on Fire songs
On Tue Mar 27 20:54, Jason Spiro wrote: > 2007/3/27, Don Armstrong <[EMAIL PROTECTED]>: > >On Tue, 27 Mar 2007, Jason Spiro wrote: > >> Maybe if debian-legal or I wrote the license (I have never written a > >> license before, but maybe I could modify the MIT license) we could > >> get Teosto to agree on more liberal terms than we would get if > >> Teosto wrote one? > > > >The following is what I would use if I were to license my own > >compositions[1] for distribution in Debian: > > > I'm sure you realize Teosto would consider the BSD license far too > liberal, and forbid it. :-) Seriously, do you think my idea of writing > a license has merit? Such a licence would not get the songs in main, though. I imagine it would fail DFSG 6 and possibly 3. It would get them in non-free though which would allow the rest of the game in contrib or, if we managed to find some free songs to go with it, in main. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Choosing a license for Frets on Fire songs
On 3/28/07, Andrew Donnellan <[EMAIL PROTECTED]> wrote: > On 3/28/07, Don Armstrong <[EMAIL PROTECTED]> wrote: > > Well, it actually seems rather strange to me for an organization which > > is designed to "protect" artists disallowing artists from determining > > how their own works are licensed, so I'm trying to give them the > > benifit of the doubt here. > > Do they really? That would mean that all the copyright holders would > have given them exclusive licensing rights. Yes that's the contract you have to sign to be part of Teosto (which you have to do if you ever want to make a living in Finland as a musician). > I haven't read the full bug log, but has anyone contacted the > composers directly? Yes, we have. They are part of the upstream team and their contract forbids them from releasing _anything_ which is not under a licence Teosto agree with. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Could you please forward this proposed license to Teosto? (was: Re: Choosing a license for Frets on Fire songs)
On Thu Apr 26 16:25, Jason Spiro wrote: > Copyright (C) > > Permission is hereby granted, free of charge, to any person obtaining > a copy of this work (the "Work") to use, modify, copy, publish, > distribute, publicly perform, and/or sublicense copies of the Work, > and/or to charge a fee for the physical act of transferring copies, > and/or to offer warranty protection for a fee, and/or to permit > persons to whom the Work is furnished to do all of the aforementioned > actions, subject to the following conditions: > > * Persons distributing the Work to the general public may only do so > if the Work is distributed and/or bundled with game software. > * No person may musically rearrange the Work or modify the lyrics of > the Work unless that person obtains permission to do so from either > the author or the copyright holder. This contradicts "Permission is hereby granted, ... to use, modify," above. May I suggest using a CCby licence and adding 'may only be distributed with the game' rather than cobbling together your own inconsistent one... Matt > -- Matthew Johnson signature.asc Description: Digital signature
Re: Could you please forward this proposed license to Teosto? (was: Re: Choosing a license for Frets on Fire songs)
On Thu Apr 26 21:16, Jason Spiro wrote: > I don't know much about how to write licenses, and this is the first > one I have ever written. I figured that everything after the "subject > to the following conditions:" would automatically override the initial > permissions I gave. I guess I was wrong? This is a very very good reason not to write your own. debian-legal always advises against doing so. How about using: http://creativecommons.org/licenses/by-nd-nc/1.0/legalcode with 4. d. added saying: You may not distribute, publicly display, publicly perform, or publicly digitally perform the Work except as part of the game. and 1. g.: "The Game" means the game Frets on Fire or a derivative work of Frets on Fire. This would, of course, have to be renamed something else, but it is good to make as small modifications as possible. It would also need t be run past debian-legal and Teosto's legal team. Matt -- Matthew Johnson signature.asc Description: Digital signature
Derivative works for songs
For the Frets on Fire arcade game which we are packaging I have found an original artist willing to licence his works under the MIT licence. Four of the five songs are completely original works; the fifth, however, whilst being an original composition is inspired by another song. The email I have from the artist is below; I think that probably this counts as a derivative work, and hence would need permission from the original author, but I am not sure. Obviously debian-legal are not lawyers, but I would appreciate your opinions. I could just leave it out to be on the safe side, I could leave it in, hope that the ftp-masters accept it and hope that nothing comes of it or I could try and get an opinion from someone like SPI. What do you think is the best way to proceed? Thanks, Matt - Forwarded message from Carlos Viola <[EMAIL PROTECTED]> - From: Carlos Viola <[EMAIL PROTECTED]> To: Matthew Johnson <[EMAIL PROTECTED]> Subject: Sectoid´s Frets on Fire Song Pack Hello Matt, I´ve added the file "License.txt" with que MIT license agreement, and put the license text in the comments of the .ogg files too. I think I´ve well done, if I forget something or I´ve done it wrong please tell me (I´m newbie in license stuff). Well, here is the link: http://www.nivel21.net/personal/sectoid/fretsonfire/Sectoid_Frets_on_Fire_Song_Pack.zip I have a little question: The song "Ryu´s theme" is a heavy metal version of the Ryu´s Song in the famous videogame Street Fighter 2, the song is completely made by me, but it´s a version of another, I don´t know if there is a problem with this. I suppose you need my name or email to put somewhere in the credits, I give you information about me if you need it. Name : Carlos Viola Iborra Musician´s Nickname : Sectoid Nacionality : Spain E-mail: (this) [EMAIL PROTECTED] Thanks a lot, I´m waiting your reply. Sectoid. - End forwarded message - -- Matthew Johnson signature.asc Description: Digital signature
Re: Could you please forward this proposed license to Teosto? (was: Re: Choosing a license for Frets on Fire songs)
On Tue May 15 17:25, Jason A. Spiro wrote: > But one question: > > Do those license terms allow the songs to be distributed in a separate > Debian package from the primary "fretsonfire" package? No, it will have to be amended to allow this as was suggested elsewhere in this thread. > What if the song package Depends on fretsonfire?[1] What if it > Recommends it?[2] I think our current model has fretsonfire-data-foo depending on fretsonfire. If the licence says "these songs may only be used with fretsonfire and it's derivatives" then that's clear whatever the package manager says. 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. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Bug #383316: Derivative works for songs
Francesco Poli wrote: > > Now, it would be preferable to be able to regenerate the > > recording from the MIDI. Which would mean including the > > soundfonts (instrument descriptions, basically) used. So the question > > of whether they are free is also important. > > Really important, IMO. > > > Here's a legal > > question: Do you need a copyright license for the soundfont in order > > to distribute or modify the recording made using them? > > I don't know, but I'm afraid we need one, as long as the soundfonts are > copyrightable works by themselves... what if the recording was of actual people playing actual instruments? You know, like people always used to. How to you generate that from 'source' at build time? what _is_ the source? Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: CC Non-waivable Compulsory License Scheme (was: Anti-TPM clauses)
Francesco Poli wrote: > On Thu, 13 Sep 2007 14:06:12 +0200 Freek Dijkstra wrote: > > So it seems to me that CC does not make any more limitations or > > restrictions then those that are already there in the law (e.g. the > > restriction "you can only buy blank CDs and DVDs if you pay a fee"). > > So this part basically says "we can't circumvent the law". Not much > > news there, so I would consider the CCv3 equivalent if it simply had > > this part removed. So in my view this is a non-issue. > > Thanks for adding useful information. > What is not clear to me is: if "Non-waivable Compulsory License Schemes" > are absurd things such as sort-of-taxes on virgin media (recordable CDs, > DVDs, ...), why does the clause included in CC-v3.0 licenses talk about > the right to collect royalties "for any exercise by You of the rights > granted under this License" ? > Here's the text of the clause, again: > > | 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; > > I fail to see any connection between buying a CD-R(W) and exercising the > rights granted under the license... > Hence I cannot understand how can those "Non-waivable Compulsory License > Schemes" be things like sort-of-taxes on virgin media. I read this as saying that no-one else can claim the money on his behalf. If there is a CC-licenced piece of music, presumably someone is entitled to collect some amount of royalties from the blank media scheme. I read the whole section as saying "where possible all royalties are waived, where not possible, no-one else can claim royalties from the work". I certainly don't think it can be _worse_ than not including that block. I'm not necessarily sure such schemes have to exist, it's more covering their ass; like not using public domain, but an explicit licence, since not everywhere has PD. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Licensing of package nauty
On Thu Jan 24 09:35, [EMAIL PROTECTED] wrote: > > Copyright (1984-2007) Brendan McKay. All rights > reserved. Permission is hereby given for use and/or > distribution with the exception of sale for profit or > application with nontrivial military significance. You must > not remove this copyright notice, and you must document any > changes that you make to this program. This software is > subject to this copyright only, irrespective of any copyright > attached to any package of which this is a part. > >Absolutely no guarantees or warranties are made concerning >the suitability, correctness, or any other aspect of this >program. Any use is at your own risk. > > I can ask the author if would distribute under some DFSG free license, > but in the case that he declines, is there any other clarification > needed before it can be included in non-free? This looks like it gives us permission to distribute it in non-free if you can get it licenced under a DFSG-compatible licence. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: web hosting providers' modified .debs
On Thu Jan 24 11:37, John Halton wrote: > It seems clear enough that the administrators of toad are > "propagating" /bin/ls. And that "propagation" is one that "enables > other parties to make or receive copies". Nor is this "mere > interaction ... with no transfer of a copy" - *running* /bin/ls would > fit this category, but making a copy of /bin/ls in your home directory > is a different matter. > > So this would seem to be "conveying" within the meaning of GPL v.3, > and thus will fall within clause 6 of GPL v.3, "Conveying Non-Source > Forms". So, do we need to have the sources all installed on our shell hosts? or a written offer good for three years to provide the source? Maybe having a deb-src line is good enough since users can run apt-get source? Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: web hosting providers' modified .debs
On Thu Jan 24 22:02, John Halton wrote: > On Fri, Jan 25, 2008 at 08:26:19AM +1100, Ben Finney wrote: > > Here's a 2003 debian-legal discussion about the ASP loophole: > > > > http://lists.debian.org/debian-legal/2003/03/msg00755.html> > (Incidentally, I'm assuming that the earlier suggestion of removing > the read permissions for users wouldn't work, because they wouldn't be > able to execute the binaries without read as well as execute > privileges. Is that correct?) You can execute things you cannot read: $ ls -l /bin/ls ---x--x--x 1 root root 77352 2007-01-30 18:51 /bin/ls Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Do web applications disable GPL obligations?
On Tue Mar 11 16:14, Mark Tyler wrote: > A friend and I have developed a web application for an online shop > with some pretty advanced features that were requested by our > customers. We included GPL sources into the application and for that > reason distributed the application according to the same license > (GPLv3). > When we asked him to comply with the GPL he only replied that web > applications are not affected, because the application is only used, > but not distributed. It is true, that the application is installed on > the server side, but parts of it, namely java classes, are distributed > to the clients (=the shop visitors) in binary form. As he says, if they are not distributing the binaries they are not obliged to distribute or publish the source code (GPL section 2, and the definition of propogate in section 0). Indeed, licences which _do_ mandate such are regularly labelled as non-free here (see the desert island test). However, as you say, some code _is_ distributed, namely the Java classes. Thus, the vender must comply with GPL section 6 for at least those parts which are distributed. Matt -- Matthew Johnson
Re: Do web applications disable GPL obligations?
On Thu Mar 13 16:38, M. Tyler wrote: > Sorry, but I don't understand what this implies. Our friendly customer, who > modified the code, who published icons and other binaries, refuses to open > the modifications. He has currently disabled the java code, but we still > find our graphics on his website. > Can we force him on this grounds to publish the source of all modifications? > Or can he pretend that the icons form a single new work, so that he only has > to publish them together with the unmodified work which we delivered to him? > I think it reasonable for them to only distribute the source for those parts for which they distribute the binary. In this case the icons probably count as both the source and binary (although, see "preferred form of modification", which is unclear for icons) and so you have no further complaint. Of course you may still be annoyed that they are running a modified version without sending you the modifications, but this is allowed. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Gibson's possible patent on Guitar Hero idea
On Mon Mar 24 17:03, Miriam Ruiz wrote: > Gibson's system is designed to be used with a "musical instrument" -- > and no matter what the Guitar Zeros have to say, it seems unlikey that > Guitar Hero controllers, or a computer keyboard, really qualifies. I agree, also: > A musician can simulate participation in a concert by playing a > musical instrument and wearing a head-mounted 3D display that includes > stereo speakers. I don't recall any head-mounted 3D displays in either guitar hero or frets-on-fire. > Audio and video portions of a musical concert are pre-recorded, along > with a separate sound track corresponding to the musical instrument > played by the musician. No video here... > An external bypass switch allows the musician to suppress the > instrument sound track so that the sounds created by actual playing of > the musical instrument are heard along with the pre-recorded audio and > video portions. There's certainly not one of these either. I think Gibson are being very optimistic here and neither Activision nor Debian have anything to worry about. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Applying the terms of GPL to your program
On Fri Apr 04 18:47, Y Giridhar Appaji Nag wrote: > You should have received a copy of the GNU General Public License > with the Debian GNU/Linux distribution in the file > /usr/share/common-licenses/GPL; if not, write to the Free Software > Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. This does imply that it's only being distributed with Debian. If so, then I don't see a problem with this. The given wording is only an example of a clear licence grant, it's in no way tied to the licence itself. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Applying the terms of GPL to your program
On Sat Apr 05 00:06, Y Giridhar Appaji Nag wrote: > I should've been a bit more explicit. > > So if I am packaging a piece of software for Debian and the software is > licensed > under the GPL, is the above valid (and more importantly, is it enough) for > debian/copyright? Or is wording like the following a _must_: Yes, I would say it is. debian/copyright needs to give the licence status for everything in the package, so any isomorphic declaration is fine. It's just customary to copy the upstream declaration verbatim and then add clarification below. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Applying the terms of GPL to your program
On Sat Apr 05 10:00, Y Giridhar Appaji Nag wrote: > On 08/04/04 21:21 +0100, Matthew Johnson said ... > > On Sat Apr 05 00:06, Y Giridhar Appaji Nag wrote: > > > > > So if I am packaging a piece of software for Debian and the software is > > > licensed > > > under the GPL, is the above valid (and more importantly, is it enough) for > > > debian/copyright? Or is wording like the following a _must_: > > > > Yes, I would say it is. > > As in, > > Yes, including /usr/share/common-licenses in the 'license blurb' text > itself is valid? This is what I meant. As long as the text in debian/rules unambiguously declares the licence of the program, it doesn't matter what it is. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: BSD/GPL/LGPL and OpenSSL
On Thu Jun 05 18:02, Vincent Danjean wrote:
> What I'm thinking with a program that links with 2 libraries:
> NOT valid: progA[GPL]{libssl}
if this is not valid then neither is:
> valid: progA[GPL+ssl]{libssl,libB[GPL]}
here you are linking libssl and libB[GPL] into the same process so the
resulting binaries must be distributed under a licence which satisfies
both clauses, which you cannot. It's exactly the same as:
> progA[GPL]{libssl}
and
> NOT valid: progA[BSD]{libssl,libB[GPL]}
and
> NOT valid: progA[GPL]{libB[LGPL+ssl]{libssl}}
and also therefore:
> valid: progA[GPL+ssl]{libB[LGPL+ssl]{libssl},libC[GPL]}
which is also not allowed. Nor is:
> valid: progA[GPL+ssl]{libB[BSD]{libssl},libC[GPL]}
Basically, you have to take the entire linked set and satisfy all
licences simultaneously. If any component is GPL and any other component
openssl, the result is not distributable.
Incidentally that also applies for:
A[GPLv3]{B[GPLv2+]{C[GPL2]}}
even though A and B can be combined as can B and C.
Note that this does not apply to "system libraries" which the GPL
specifically exempts (eg libc).
Matt
signature.asc
Description: Digital signature
Re: ok for Redland to link against openssl?
severity 488766 wishlist retitle 488766 librdf0-dev: Please provide gnutls flavor thanks On Tue Sep 02 14:17, Jonas Smedegaard wrote: > Hi, > > I filed bug#488766 some months ago with no response from maintainer. > > Could I please have some more eyeballs on that: Am I right that Redland > violates GPL? No, it does not, because: > Or is it ok since Redland is dual-licensed, so it should simply always > be considered as Apache licensed when used with Debian? Correct. However, both licences should still be listed in debian/copyright because if you were to rebuild it not linked against openssl then you may chose either. It is the resulting linked binary that may not be distributed under the GPL, but there are alternate permissions which allow us to distribute, namely Apache+OpenSSL. > Currently morla (ITP bug#431824) cannot be packaged as it is GPL. Should > I convince upstream to dual-license, or convince Redland maintainer to > extend with a GPL-compatible package non-postgres package? If upstream morla uses redland linked against OpenSSL then they don't have permission to distribute the resulting binaries either, so upstream probably want to know. It would probably be enough for ether morla or both morla and redland to add an openssl exception to their GPL licence. I've downgraded the bug and retitled it. The bug should only be wishlist since there is nothing wrong with redland itself, nor is a change required in general to use it in other programs. The normal response would be to convince upstream to licence appropriately for linking against an Apache licence and an OpenSSL licence. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: bash completion script licensing
On Fri Jan 02 19:50, Mike Hommey wrote: > As the GPL and CDDL are incompatible, as GPL code has some strange > interactions with other code (library linkage, etc.), and as I'm not > sure how sourced bash scripts are supposed to be considered in this > context, I wonder if having such a CDDL bash script would be > problematic license-wise. There would be no problem with a CDDL bash script per-se, any more than there would be with a CDDL jpeg or a GPL word document. I suppose you could argue that since it is modifying the behaviour of one of bash's built-in functions it counts under the (already dubious) GPL linkage clause, but I think it would be a stretch. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: bash completion script licensing
On Sat Jan 03 09:22, Mike Hommey wrote: > On Fri, Jan 02, 2009 at 09:53:06PM +0000, Matthew Johnson wrote: > > On Fri Jan 02 19:50, Mike Hommey wrote: > > > As the GPL and CDDL are incompatible, as GPL code has some strange > > > interactions with other code (library linkage, etc.), and as I'm not > > > sure how sourced bash scripts are supposed to be considered in this > > > context, I wonder if having such a CDDL bash script would be > > > problematic license-wise. > > > > There would be no problem with a CDDL bash script per-se, any more than > > there would be with a CDDL jpeg or a GPL word document. I suppose you > > could argue that since it is modifying the behaviour of one of bash's > > built-in functions it counts under the (already dubious) GPL linkage > > clause, but I think it would be a stretch. > > I'd add that "require" or "import" in perl, python, ruby, etc. fall > under the GPL linkage clause. Why would bash's "source" not ? > Yes, but they aren't linking with _perl itself_ but rather with the other perl script they are imported to. Now, you might not be able to use such a bash completion script if your ~/.bashrc is licenced under the GPL (-; Also, rereading the OP, the licence of other bash completion scripts _might_ be an issue, but I don't think the licence of bash itself is an issue. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Question regarding Crown Copyright waiver
On Thu Jan 15 12:19, Francis Tyers wrote: > I'd like some advice on a particular instance of Crown Copyright > which includes a waiver for free distribution. I'm going to try > and make out my case below, but I'd be very happy to hear other > opinions -- particularly if the waiver is compatible with the DFSG. > You've done a pretty good analysis and it would seem to fail DFSG3 and 6, making it suitable for non-free, but not for main: > == > ==3. Derived Works== > > I can't see anything about this. > > ==6. No Discrimination Against Fields of Endeavour== > > I think it falls down here: > > "13. The Proceedings must not be used in connection with advertising or > product endorsement or in any context which could be viewed as > undignified association." > > (Really problematic) > > "14. The Proceedings must not be used in any circumstances which are > knowingly or potentially libellous or slanderous of individuals, > companies, organisations or political parties." > > (Wouldn't this be against the law anyway?) > > "16. The Proceedings must not be reproduced for overtly political > purposes." > > (Really problematic) Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: DRM legal advice
On Wed Mar 04 09:32, Jonathan Wiltshire wrote: > get_iplayer (renamed to get-iplayer for Debian naming restrictions) > avoids this by fetching programmes through the iPhone channel in > reasonable quality and saving them to disk. However, this also evades > the DRM protection so the user is free to keep the files for as long as > (s)he likes, which obviously isn't what the BBC wishes. AIUI the BBC service provides 3 viewing channels: - flash (online streamed only) - Windows client (DRM restricted) - iPhone client (no restrictions) If you were removing the DRM on the windows channel I would certainly say that was against the law in DMCA/EUCD countries. In the case of the iPhone downloads there is (AFAIK) no restriction on the download other than claiming to be an iPhone, so I don't think you can be said to have circumvented an effective technical protection measure. One might claim that the act of claiming to be an iPhone when one is not would count as such a circumvention, but I don't believe merely checking the user-agent string (or whatever) would count as an 'effective technical protection measure'. Obviously IANAL etc. Matt P.S. if you don't upload it to Debian proper, consider contacting the debian-multimedia guys. -- Matthew Johnson signature.asc Description: Digital signature
Re: The copyright of a keyboard mapping and its implementation
On Mon Mar 16 17:47, Josselin Mouette wrote: > It is my opinion that, in European law, the copyright on a keyboard > mapping does not affect that of its implementation, because, among other > things, of the interoperability exception – in the same way a function > prototype is not subject to copyright while the function itself is. Indeed, copyright only covers concrete implementations. I think the word he's looking for is "patent". Of course, IANAL, perhaps someone who is could comment. > I’d tend to say we should opt for the conservative approach and > remove them; despite the fact that I like the mapping, we shouldn’t > include software with such an unclear copyright status. Well, if we take the position that it's not copyrightable then for our point of view it's not a problem what the licence is, we can distribute in main. It's also not a problem form his PoV, because he's happy for us to distribute under that licence. The only thing he'll complain about is us distributing derivatives. Therefore, not ripping it out of the X.org package but also not packaging any variants would also seem like a reasonable conservative stance, if a bit schitzophrenic Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: distributing precompiled binaries
On Fri Mar 27 14:57, Chow Loong Jin wrote: > On Fri, 2009-03-27 at 13:57 +, MJ Ray wrote: > >[...] > > I'm not sure that it matters what you call the mobile component, if > > that "data file" is really some sort of program that has sources which > > aren't usable. How is that jar different from a PDF in this way? > > Unless I'm mistaken, a PDF without sources is an issue, but if the PDF > comes with sources, this is not an issue. If you're saying the .jar is > the same as the .pdf, then what's wrong with distributing a .jar that > has sources? A PDF with sources which we can't turn into the PDF is also an issue. (i.e. shipping a frame-maker file and a PDF is not, AIUI, OK) Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: debian control license
On Sat Apr 11 01:53, Avery Fay wrote: > > 1.) What is the license of debian control files? The licence of the packaging varies between packages. Often it is the same licence as the package, BSD or GPL. The debian/copyright file should tell you for each package. We only guarantee that the licence is free, and that it's compatible with the licence of the package itself (since the binary is a derivative work of the source and the packaging scripts) However, I'm not sure that the information you are extracting is covered under copyright. If it's not, then you are good to go. If not, then depending on interpretation, you may be creating a derivative work of them all, which effectively means you need to treat the whole as GPL, and omit any packages which have the packaging under a non-GPL-compatible (but free) licence. I don't know whether such exist. > 2.) What requirements would I have to meet to include this information on a > web site? Assuming for the moment that you are using copyrightable information and creating a derivative work, then you must satisfy the licence of all the source materials. This will resolve to distributing everything under the GPL and therefore providing the "preferred form of modification". > 3.) (depending on the answers to the above) Could I use something like CC-by > for the compete database of my site or would that conflict with using > metadata from the debian packages? See above. First of all, databases are only debatably copyrightable; they have different statuses in different jurisdictions. Secondly, I am still not sure whether the metadata you are extracting is copyrightable. If it's not, you can do what you like. If it is, then you are almost certainly creating a derivative work, so you have to comply with the licences of your source material, many of which are GPL, which means you would have to use the GPL as well. HTH, IANAL, etc Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: PS documentation file, no sources, author died
On Sat May 30 00:21, Rafael Laboissiere wrote: > I would really like to distribute the documentation file but the upstream > author died recently [6] and the chances are small that the sources can > be found. Is there any rule that applies to this case, I mean, when an > author dies? Copyright (at least in some important jurisdiction) applies for life + 70 years, so it still applies and would now be held by the author's estate. > A simple solution would be to strip the PS file from the tarball and, > eventually, create an octave-quartenion-nonfree package containing it. > Otherwise, we could generate a LaTeX file that reproduces that PS file. > If we do that, what should be the Copyright notice and the licence > statement? The problem here is that either there is no copyright licence (in which case we can't distribute it, even in non-free), or the blanket GPLv3 applies (which is, I think, reasonable to assume) in which case either we have a source form, in which case it can go in main, or we don't, in which case we can't distribute it, even in non-free as this violates the licence agreement. The post script definitely looks like it was generated from TeX (from reading the PS source) so we really should try and find said source. Alternatively, I think the reading of the GPL would suggest that if you created a derivative work (eg, by machine translating it back to some sort off TeX, or extracting the text and reformatting) then it would be reasonable to distribute _with the preferred form of modification of that derivative work_, which is your new, translated, TeX file. HTH, Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: PS documentation file, no sources, author died
On Sat May 30 14:33, Rafael Laboissiere wrote: > A. S. Hodel was the original author but this package (quartenion) is > maintained collectively by the Octave-Forge team and it had been for a > long time included in Octave itself, which is actively maintained. My > problem is just with the PS documentation file. In which case it may be worth mentioning to them that they are likely failing to meet the terms of the GPL as well. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Mono License changes over time and the risks this is presenting.
On Mon Jul 06 21:04, Peter Dolding wrote: > What is more worrying here is the progressions of license conversions > it slowly looks like its completely converting to MIT so meaning > Novell will not be blocked by shipping if Patent claims come. GPLv3 would be the only thing which provided any such protection, (L)GPLv2 does not. It would also, however, cripple how it could be integrated with other systems which were not under the GPL. > The simple fact is you cannot develop on top of the MIT based .net > class libraries safely because no one is answering what the status is. > > Next is MS and Novell developers have talk about working with each > other. This is even more risky. I have seen nothing that clearly > states that the MIT section of mono does not contain MS source code. > If that is the case it a rock solid patent case waiting to happen. Patents are unrelated to the source of the code. That would be Copyright law and by contributing the code under an MIT licence the authors have relinquished the right to sue anyone for distributing it. Microsoft contributing code could also be seen as giving an implied licence to use such code and might weaken any patent case they had, so I sincerely doubt they would _both_ contribute patent encumbered code and sue people for using it. > Its either get a patent deal from MS or move the risky bits to > non-free until someone can clear up the status with patents on > implementing .net. You can 100 percent bet MS took out every patent > they could. Finding the patents would make matters worse because > then you would be in known breach. If people are going to be sued for using Mono, it being in non-free does not help, we wouldn't be able to distribute it. > Mono is basically shonky. A simple clear and valid statement would > have stopped all this patent worry dead. There is an aweful lot of FUD surrounding Mono, that is clear. Could things have been said which might reduce it? Possibly. Does Mono have more possible-patents covering it than anything else that's been invented in the last 30 years? Most certainly not. Take a leaf out of the kernel folks book. Don't worry about patents until someone actually starts enforcing them (CF fat32) and then reimplement the feature to work around it. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: RFS: ognl
On Sun Aug 09 23:02, Damien Raude-Morvan wrote: > > I've reviewed the package and it looks clean, but I have one question. > > Which bit is licenced under the apache-derived licence? I can only find > > BSD-licenced files. > > OpenSymfony Licence (Apache derived one) is promoted by upstream as official > OGNL project licence [1]. But, as you, every source file I can found under > src/ in tarball were licenced under classical BSD licence. > > IMHO, this OpenSymfony Licence apply, at least, to DocBook sources files in > docbook/. > > All in all, thoses licences seems compatible between each other so it doesn't > hurt. I don't like: * 5. Products derived from this software may not be called * "OpenSymphony" *or "OGNL", nor may "OpenSymphony" or "OGNL" appear in their *name, without prior written permission of the OpenSymphony *Group. since we are, arguably, distributing a derivative work and if we ever patch it then we certainly are. I've CC'd debian-legal to get slightly wider comments on the matter. For debian-legal readers, the full licence is below. Matt /* * The OpenSymphony Software License, Version 1.1 * * (this license is derived and fully compatible with the Apache Software * License - see http://www.apache.org/LICENSE.txt) * * Copyright (c) 2001-2004 The OpenSymphony Group. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, *if any, must include the following acknowledgment: * "This product includes software developed by the *OpenSymphony Group (http://www.opensymphony.com/)." *Alternately, this acknowledgment may appear in the software itself, *if and wherever such third-party acknowledgments normally appear. * * 4. The names "OpenSymphony" and "The OpenSymphony Group" *must not be used to endorse or promote products derived from this *software without prior written permission. For written *permission, please contact lice...@opensymphony.com . * * 5. Products derived from this software may not be called "OpenSymphony" *or "OGNL", nor may "OpenSymphony" or "OGNL" appear in their *name, without prior written permission of the OpenSymphony Group. * * 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 APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * */ -- Matthew Johnson signature.asc Description: Digital signature
Re: Artistic and LGPL compatibility in jar files
remove or reimplement > the JUMBO/CML component. correct. > If it is possible to relicense and be compatible with the LGPL 2.1, > the main CDK developer wants to know how to relicense the software. > Does he need to make a specific source release of JUMBO/CML under > the LGPL 2.1 then turn around and use it inside of his code? Or can > CDK include the JUMBO/CML code and just state somewhere inside the > CDK documentation "Originally under the Artistic License 2.0 and > relicensed under clause 4(c)(ii) to the LGPL 2.1"? A simple statement from the copyright holder(s) (all of them) should suffice. > Can an LGPL package include an XML schema definition which may not be > changed but which is required in order to use part of the LGPL API? regardless of this (and I think the schema can be data for these purposes, so yes), it can't go in Debian main. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Artistic and LGPL compatibility in jar files
On Tue Dec 15 00:42, Andrew Dalke wrote:
> How do I interpret this LICENSE.txt? The Artistic License 2.0 allows
> relicensing to the GPL. I'm well and clear about that (though there's
> still a subtle question of if it allows relicensing to the LGPL).
>
> However, if I use clause 4(c)(ii) to switch the GPL, am I and my
> downstream users still prohibited from:
> - distributing the software under the name JUMBO (or a derivative)
>("Jumbo, Jr", "Dumbo", "Elephant" and "Timothy" all seem derivative)
> - calling a modified version a "compliant CML system"
> - asserting that a modified version can read and write CML?
> That is, are these clauses additions to the Artistic License 2.0 which
> must be preserved even after 4(c)(ii) relicensing to the GPL? My
> suspicion is that derivatives must still be prohibited from those
> activities.
It's interesting, the GPLv3 says explicitly:
...
c) Prohibiting misrepresentation of the origin of that material, or
requiring that modified versions of such material be marked in
reasonable ways as different from the original version; or
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. If the Program as you
received it, or any part of it, contains a notice stating that it is
governed by this License along with a term that is a further
restriction, you may remove that term. If a license document contains
a further restriction but permits relicensing or conveying under this
License, you may add to a covered work material governed by the terms
of that license document, provided that the further restriction does
not survive such relicensing or conveying.
Clause c and the fact that the author may have claims to the JUMBO name
under trademark law means he can certainly require a name change. I
don't think he can stop you from claiming that you can read and write
his format, however. A secondary thing here, however, is that you
generally want to get on with your upstream. If you start doing things
he doesn't like, then he will make life difficult for you (see: ion3).
> Is the resulting software (with these extra limitations) free software
> enough for Debian?
Yes, there's ample example of rename clauses. Iceweasel is a
high-profile example. DFSG4 says:
"... The license may require derived works to carry a different name
or version number from the original software."
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Re: Artistic and LGPL compatibility in jar files
On Thu Dec 17 00:06, Andrew Dalke wrote: > The feedback here has helped. The CML maintainers are going to split > off the CC-BY-ND into another file which can go into non-free, the > rest of the JUMBO code will clarified to be "Apache 2.0", the CML > developers are going through all their code to check that there are no > other outstanding licensing details like that. I assume, then, that it can function without that non-free file? Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Distributing Debian derivative
On Mon Mar 22 14:24, David Given wrote: > > Absent any modifications, all of Debian (that is, the ‘main’ archive > > section) is free to redistribute verbatim in any form. Many other > > actions are also permitted; see the specific license texts for details. > > I've read that; unfortunately, it just talks about the philosophy of > Freeness, and doesn't provide anything about the actual mechanics of > what I need to do. > > Do I, for example, have to manually compile a list of every single > license for every package in the tarball and make those available > individually on my website, or is there a simpler way, like a specific > piece of legal boilerplate approved by debian-legal pointing at the > licenses elsewhere? Is there any overall cover text I need to include? > Or do the copies of the licenses in the tarball itself suffice, meaning > I don't need to provide any additional information, and can just plonk > the tarball distribution on Sourceforge and be done with it? disclaimer: IANAL etc and this is just ottomh, but the most prescriptive licence you'll have to deal with is the GPL, which requires you to either make the source available with the binary or to honour requests for the source for up to 3 years. As far as licence files are concerned, if you are shipping a Debian image then this will (unless you have stripped them) include /usr/share/doc/$package/copyright with all the licence statements in. This should be sufficient. If you are stripping them, then you'll probably have to make other arrangements. I'd have thought that if you build a source tarball with the sources for all the packages in your image and don't strip /usr/share/doc from the image, then you will probably be fine for anything in main. Others can feel free to correct me though. Matt -- www.matthew.ath.cx D-Bus Java signature.asc Description: Digital signature
Re: Distribution of media content together with GPLv2 code in one package?
On Sun Apr 04 17:33, Rudolf Polzer wrote: > > > Well, can it then still be one single download package? > > > > > > Can "the game" consist on multiple differently licensed parts? > > > > > > Can these then be provided as one download (and with an included text file > > > defining the licenses of the parts)? > > > > > > The thing is - does the GPL even allow combining with non-GPL data in > > > such a > > > way? > > > > No way to know until it goes to court. The test is that if distributing > > the game executable alongside its data creates a derivative work or not. > > I would guess that it does not, but who knows what a court would decide. > > Ah, so better not go there yet... and instead wait if anything will happen to > other games doing the same (like Warsow, Tremulous). I think it's pretty clear that you can distribute data alongside a GPL work without it being covered by the GPL. The reason why program objects which link the GPL work need to be distributed under the GPL is that the result constitutes a derivative work. If it did not, then copyright law cannot cover said aggregation. Whether linking constitutes a derivative work is something which has not been tested in court, but since that is the FSF's position, that's what most people go with. There's never been any suggestion that data which is processed by the application is covered: otherwise you couldn't choose the licence of documents you created with a GPL word processor. More importantly, however, the GPL contains a clause permitting 'mere aggregation'. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: CDDL/GPL and Nexenta (with CDDL libc)
On Fri Sep 03 14:04, Paul Wise wrote: > BTW, whatever happened to Debian GNU/kOpenSolaris? > > http://csclub.uwaterloo.ca/~dtbartle/opensolaris/ > How would the licence interactions work here, with a CDDL kernel and a GPL libc/userland? Does the fact that it's specifically the kernel satisfy the exceptions in the GPL? Matt signature.asc Description: Digital signature
