Re: Question regarding QPLed plugins for a GPLed app
Ben Burton <[EMAIL PROTECTED]> wrote: > http://lists.kde.org/?l=kdevelop-devel&m=02280128853&w=2 > I received the following response, claiming that dlopened plugins do not > need to be GPL-compatible: As described on the GPL FAQ linked from the page above, this is a borderline case. If the kpart and other programs don't need any internal knowledge of each other during authoring, compilation or execution, I'd argue that the undistributable derivative work is only created after run-time. Beyond that, it needs more knowledge of KDE's workings than I have. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Subscribed to this list. No need to Cc, thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Combining GPL and BSD/CeCILL/whatever
Jarno Elonen <[EMAIL PROTECTED]> wrote: > I'd like to get some clarifications on how to interpret GPL's > derivations-must-also-be-licensed-under-GPL feature and similar demands in > other licenses. Namely: [...] Please try http://www.gnu.org/licenses/gpl-faq.html first. > My understanding is that the often told "you may relicense BSD-new code under > GPL" doesn't actually mean "you may wipe away the BSD license text and put > GPL in its' place (along with the copyright notices)" but instead "you may > amend the BSD-new license with (e.g.) GPL's extra restrictions, hence, making > it effectively GPL'd"? Also, have I understood correctly, that the package > should contain *both* license texts (or references to them) along with a list > stating which parts fall under which license? I think you need to ask: What is copyright? I was told that it's a right, a property created by creative work. It is attached to the output of that action (what we usually call "the work" here), but it is not that output: it's intangible itself. At http://www.eff.org/IP/?f=copyright_law.paper.txt there's a bit about "What is copyright?" which is along these lines. So, you can license your copyright, the result of any creative work you put into the software, with any compatible license, but the copyright to the original work remains under its original licence, no matter what you do. You still have to satisfy any conditions for accessing the copyright to that work, and people can take that bit and discard the stuff covered by your copyright if they want. See the GPL FAQ question about extracting a public domain part from a GPL-covered work. I think that covers your next two questions too. How clear you have to be about which parts have which copyrights attached depends on the licences, I think. Interpretations are often a bit dangerous to rely upon, so I won't answer the last two questions. I'm not a lawyer. Find better advice before doing anything which might even possibly be copyright infringement. ;-) -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Subscribed to this list. No need to Cc, thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question regarding QPLed plugins for a GPLed app
In message <[EMAIL PROTECTED]>, Ben Burton <[EMAIL PROTECTED]> writes Hi, I'm currently involved in a discussion on kde-core-devel regarding the use of a QPLed plugin that is dlopened within a GPLed application. For details: http://lists.kde.org/?l=kdevelop-devel&m=02280128853&w=2 I received the following response, claiming that dlopened plugins do not need to be GPL-compatible: > Given that the QPL is GPL-incompatible, this raises issues for GPLed > programs that wish to use this kpart. I believe this at least > includes quanta and kdevelop (unless I'm mistaken). kparts are loaded at runtime. It has always been understood in the community that the license restrictions based on copyright law do not apply to runtime components. The implications of reinterpreting USC 17 this way are profound. The effects on Java development alone would be catastrophic. It is somewhat understood that a deliberate misuse of runtime components to circumvent copyrights is not allowed, but this is certainly NOT the case for quanta and kdevelop (you also forgot konqueror). These applications are designed to load available runtime components solely on the basis of the services made available. There is no copyright violation occuring when a user loads a plugin at runtime, particularly one with a generic interface like a kpart. Given that the GPL explicitly does not cover use of the software, and permits use as required, I would say it's definitely the case that no copyright violation occurs when the user loads the component. Assuming the main app is GPL, and the plug-in is QPL, the user has legal possession of both and therefore the GPL permits their use. I'd appreciate if debian-legal could offer their advice here as to whether this situation is allowable or not. I'm assuming the main app looks in a standard directory for plug-ins, and has a standard means of querying the plug-in to find out what it does. Provided the main app has no prior knowledge of that particular plug-in, I'd say that the main app is an independent work separate from the plug-in. Indeed, while I will be using the LGPL (where this sort of thing doesn't matter), as and when I get round to writing the app I'm working on I intend to use exactly this technique as a means of separating code and dealing with licensing issues. Okay, so the main app is independent of the plug-in. The next question is whether the plug-in is separate from the main app. How much does the plug-in know about the main app? Are you only using header files (which aren't copyrightable)? Are you linking to any of the main app's libraries!? How much does your makefile know about the main app? Those are the crucial questions, as they determine whether the main app's GPL spills over and infects the plug-in. In which case, it becomes a copyright violation if you distribute the plug-in as anything other than GPL. Please CC me on replies; I'm not subscribed. Thanks - Ben. Cheers, Wol -- Anthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Draft summary of Creative Commons 2.0 licenses (version 3)
Hi, everyone. At long last, I've made some final revisions to the draft summary of the Creative Commons 2.0 licenses. The main changes have been: * Additional phrasing changes due to MJ Ray * Additional phrasing changes due to Francesco Poli * Clear textual recommendations for Creative Commons * Recommendations for trademark restrictions The summary is also available here: http://people.debian.org/~evan/ccsummary.txt http://people.debian.org/~evan/ccsummary.html Creative Commons has expressed interest in discussing these recommendations with Debian representatives, with (I believe) the intention to make the licenses DFSG-free. I'd like to leave this draft up for a few days, and then put together a workgroup of ~5 people (including, hopefully, the DPL or some other official Debian representative, at least in an advisory role) to discuss these licenses with Creative Commons. I'm thinking this work would consist of one or two telephone conference calls of less than an hour each, with possibly some email discussions. ~Evan = debian-legal Summary of Creative Commons 2.0 Licenses = :Author: Evan Prodromou <[EMAIL PROTECTED]> :Date: 18 Mar 2005 :Version: 3 :Contact: debian-legal mailing list :Copyright: This document is dedicated by the author to the public domain. This document gives a summary of the opinion of debian-legal members on the six licenses that make up the Creative Commons license suite. About debian-legal == Debian [DEBIAN]_ is an operating system consisting entirely of Free Software. Our definition of "Free Software" is specified in the Debian Free Software Guidelines [DFSG]_. debian-legal [LEGAL]_ is a mailing list whose members provide guidance for the Debian project on, among other things, the acceptability of software and other content for inclusion in the Debian operating system. This includes comparing software against the DFSG to determine if the packages are Free Software. From time to time the debian-legal list provides a review of a well-known software license to express a rough consensus opinion on whether software released solely under the license would be Free Software. Although these summaries are not binding, they do provide some basis for the Debian project to make decisions about individual packages. About Creative Commons == Creative Commons [CC]_ is an organization "devoted to expanding the range of creative work available for others to build upon and share." The organization has created a suite of licenses [LICENSES]_ that content creators can use to specify certain rights that the public can exercise with respect to a particular work. The licenses were released in December of 2002 and revised in May of 2004; there are already over 1 million works released under a Creative Commons license. Although Creative Commons explicitly recommends that their licenses not be used for programs [1]_, works licensed under the Creative Commons licenses are still of interest to the Debian project. Debian includes documentation for programs, and many programs included in Debian use digital data such as images, sounds, video, or text that are included with the programs in Debian. The Creative Commons licenses are based on a common framework, but have a varied number of license elements that can be included to grant or revoke particular rights. Because of the similarity between the licenses, this document covers all six of the revised (version 2.0) licenses. License summaries = Attribution 2.0 --- debian-legal contributors think that works licensed solely under the Creative Commons Attribution 2.0 license [BY]_ are not free according to the DFSG and should not be included in Debian. We see the following problems with the license. Removing References ~~~ Section 4a of the license states, in part, If You create a Collective Work, upon notice from any Licensor You must, to the extent practicable, remove from the Collective Work any reference to such Licensor or the Original Author, as requested. If You create a Derivative Work, upon notice from any Licensor You must, to the extent practicable, remove from the Derivative Work any reference to such Licensor or the Original Author, as requested. Per DFSG 3, any licensee should be allowed to make and distribute modified versions of a work. The above clause allows a licensor to prohibit modified versions that mention them or reference them. For example, an author who made a novel available under an Attribution 2.0 license could give notice to disallow an annotated version that mentions the author by name or simply as "the author". A more specific example for Debian would be a programmer who creates documentation licensed under Attribution 2.0. He could requi
Denied vote and the definition of a DD
Quoted with permission: On Fri, Mar 18, 2005 at 12:17:36AM -0600, Manoj Srivastava wrote: > On Thu, 17 Mar 2005 22:50:47 -0600, Taral <[EMAIL PROTECTED]> said: > > > On Thu, Mar 17, 2005 at 06:15:41PM -0600, Debian Project Secretary wrote: > >> NOTE: The vote must be GPG signed (or PGP signed) with your key > >> that is in the Debian keyring. > > > Okay, so whomever maintains the keyring still hasn't updated my > > key. I can't sign with the key in the keyring, it's expired. > > > Can I send in my vote by mail? If not, what alternate mechanism > > exists? If none, please make one. I don't want to be left out of > > the voting because of someone else's inaction. > > I'm sorry, but I don't think I can just make up rules. You > need to be a DD in good standing in order to vote, and that > essentially means having a key in the keyring. Okay, can someone here maybe suggest a solution? I see nothing in the Constitution that requires a key in the keyring. In fact, I see no formal document defining a Developer or the conditions under which one is or is not one. Questions to consider: 1. Whence does the requirement for signed votes come from? 2. Who is empowered to change the policy surrounding the voting system? 3. By what authority can the Secretary reject an authenticatable vote provided by alternate means? (e.g. notarized document by certified mail) 4. What defines who is and is not a Debian Developer? 5. How do I fix my current problem? -- Taral <[EMAIL PROTECTED]> This message is digitally signed. Please PGP encrypt mail to me. A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgp3GZFFmEN5H.pgp Description: PGP signature
Debian License Summaries
So, this page: http://www.debian.org/legal/licenses/ ...lists some license summaries and makes some statements about whether the licenses are free or not. It's not clear to me how these summaries become "official", or at least posted on that page. Any suggestions? I'll like to get the CC 2.0 licenses summary listed. ~Evan -- Evan Prodromou <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Debian License Summaries
On Fri, Mar 18, 2005 at 04:34:56PM -0500, Evan Prodromou wrote: > So, this page: > > http://www.debian.org/legal/licenses/ > > ...lists some license summaries and makes some statements about whether > the licenses are free or not. > > It's not clear to me how these summaries become "official", or at least > posted on that page. Any suggestions? I'll like to get the CC 2.0 > licenses summary listed. I set up this page after suggestions from debian-legal. Somehwat after that a big discussion started on the list whether these summaries make sense. Noone contacted me after this discussion with a new summary and I didn't care enough to dig out the result of the discussion, I just decided the people on debian-legal would surely contact the web team if they want any changes... Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Denied vote and the definition of a DD
First and formost, this discussion doesn't belong on -legal at all, as -legal isn't the body responsible for interpreting the constitution. That's the Secretary's job under 7.1.3. Forwarding to -vote as that (or possibly -project) is the correct list. On Fri, 18 Mar 2005, Taral wrote: > Quoted with permission: > On Fri, Mar 18, 2005 at 12:17:36AM -0600, Manoj Srivastava wrote: > > On Thu, 17 Mar 2005 22:50:47 -0600, Taral <[EMAIL PROTECTED]> said: > > > On Thu, Mar 17, 2005 at 06:15:41PM -0600, Debian Project Secretary wrote: > > >> NOTE: The vote must be GPG signed (or PGP signed) with your key > > >> that is in the Debian keyring. > > > Can I send in my vote by mail? If not, what alternate mechanism > > > exists? If none, please make one. I don't want to be left out of > > > the voting because of someone else's inaction. > > > > I'm sorry, but I don't think I can just make up rules. You need to > > be a DD in good standing in order to vote, and that essentially > > means having a key in the keyring. > > Questions to consider: > > 1. Whence does the requirement for signed votes come from? Via 7.1.1 and A.6.1 > 2. Who is empowered to change the policy surrounding the voting > system? If the change requires a change to the constitution, the Developers are by an appropriate GR. Otherwise, the Secretary sets the policy. > 3. By what authority can the Secretary reject an authenticatable > vote provided by alternate means? (e.g. notarized document by > certified mail) By 7.1.1 and A.6.1 again. > 4. What defines who is and is not a Debian Developer? Having control of a valid key in the keyring is pretty much the de facto definition of a Debian Developer. > 5. How do I fix my current problem? From /usr/share/doc/debian-keyring/README.gz Getting your key into the debian keyring If you are an old debian developer who hasn't uploaded your packages for a long time, and your key is not in the keyring, send a mail to [EMAIL PROTECTED] explaining the situation, and including your public PGP key. All new maintainers should apply at http://nm.debian.org/, and your key(s) will be added to the keyring as part of the admission process. Don Armstrong -- The solution to a problem changes the problem. -- Peer's Law http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Draft summary of Creative Commons 2.0 licenses (version 3)
On Fri, 18 Mar 2005 14:28:24 -0500 Evan Prodromou wrote: > Hi, everyone. At long last, I've made some final revisions to the > draft summary of the Creative Commons 2.0 licenses. Great! :) > The main changes > have been: > > * Additional phrasing changes due to MJ Ray > * Additional phrasing changes due to Francesco Poli Wow! Thanks for the credit! :) [...] > Debian [DEBIAN]_ is an operating system consisting entirely of Free > Software. Our definition of "Free Software" is specified in the > Debian Free Software Guidelines [DFSG]_. Maybe you'd better say something along the lines of: | Our criteria for "Free Software" are specified in the Debian Free | Software Guidelines [DFSG]_. IMHO, with this phrasing, it would be clearer that we think the DFSG *cannot* be seen as a definition (in the mathematical or legal meaning of the term)... They are just *guidelines*, as their very name should make clear. -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpyYPHas15Hm.pgp Description: PGP signature
