Re: New DEP: Usage of SDPX in debian/copyright

Le Tue, Feb 08, 2022 at 04:02:20PM +0100, Stephan Lachnit a écrit : > I would like to request to take the next available DEP number (17 as > of today). It is about using the SPDX specification as an alternative > to the machine-readable debian/copyright (previously DEP-5). An > initia

Re: New DEP: Usage of SDPX in debian/copyright

Jonas Smedegaard writes: > Are we discussing one (or more) of those topics here or at d-devel, or > both?!? Sorry, I for some reason thought the DEP discussion was moving here and had it stuck in my head that debian-project was where DEPs are discussed. I'll discuss this in debian-devel

Re: New DEP: Usage of SDPX in debian/copyright

Hi, > No one uses our RFC-2822-style thing except us, and no one has tools for it Well, then they should just apt install them. I failed to understand SPDX until today (with the exception of the license specifiers), which is mostly due to the quadrillion different formats SPDX data can come

Re: New DEP: Usage of SDPX in debian/copyright

ne of format. The standard is also not fully specified. [3] > My hope is that we can reuse standard data > in a format that upstreams will start supplying, thus reducing the amount > of Debian-specific work we need to do. There is an opinion, possibly a minority, that the purpose of

Re: New DEP: Usage of SDPX in debian/copyright

On Tue, Feb 8, 2022 at 6:55 PM Jonas Smedegaard wrote: > > Are we dicussing the request to take DEP-17 for a 3rd copyright file > format, or more generally how to best integrate SPDX in copyright files, > or something else? > > Are we discussing one (or more) of those topics

Re: New DEP: Usage of SDPX in debian/copyright

lternative to > >> the machine-readable debian/copyright (previously DEP-5). An initial > >> discussion was started on debian-devel [1], and since there have been > >> no large objections I would like to formalize it. > > > Sorry that I initially missed it - I have n

Re: New DEP: Usage of SDPX in debian/copyright

Jonas Smedegaard writes: > Quoting Stephan Lachnit (2022-02-08 16:02:20) >> I would like to request to take the next available DEP number (17 as of >> today). It is about using the SPDX specification as an alternative to >> the machine-readable debian/copyright (previousl

Re: New DEP: Usage of SDPX in debian/copyright

Stephan Lachnit writes: > I would like to request to take the next available DEP number (17 as of > today). It is about using the SPDX specification as an alternative to > the machine-readable debian/copyright (previously DEP-5). An initial > discussion was started on debian-devel [1

Re: New DEP: Usage of SDPX in debian/copyright

Quoting Stephan Lachnit (2022-02-08 16:02:20) > I would like to request to take the next available DEP number (17 as > of today). It is about using the SPDX specification as an alternative > to the machine-readable debian/copyright (previously DEP-5). An > initial discussion

New DEP: Usage of SDPX in debian/copyright

I would like to request to take the next available DEP number (17 as of today). It is about using the SPDX specification as an alternative to the machine-readable debian/copyright (previously DEP-5). An initial discussion was started on debian-devel [1], and since there have been no large

Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer

Hi Sam, Even if I said I'll no longer participate, there are some substantial misunderstandings to correct. On Tue, May 26, 2020 at 04:44:49PM -0400, Sam Hartman wrote: > I think you and Mo are a bit stuck in the ftp-team mindset with the > above. *whenever new or bin-new is triggered, all

Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer

Michael> many times where code copies have been added to the source Michael> but not added to d/copyright. Some of these code copies are Michael> even embedded in previously-reviewed files that have Michael> another license. Michael> Pushing this direction woul

Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer

ewer. There is no single-file review. This is appropriate because there are many times where code copies have been added to the source but not added to d/copyright. Some of these code copies are even embedded in previously-reviewed files that have another license. Pushing this direction would redu

Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer

Hi. I've reviewed most of the spec you point to on salsa. I think you might be getting some of the details before the basic principles. I agree with the principles you state, but would probably state them differently: * Incremental review is valuable and is likely to improve our processes *

Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer

Some people are interested in a demonstration program. But sorry, to make it clear, I confirm that this is merely a theoretical proposal, and I'm at no liberty and in no position to write the demo program. I have run out of my motivation to go any further, since I have already done what I'm

Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer

> * Instant acceptance for source packages with merely binary package rename (without change in upstream code) Do we currently have a tool to pick these packages out? I think that this is the simplest, and can solve lots of problems. -- YunQiang Su

Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer

Hi Mo, I love this idea, thanks for putting it together! I have not read the details (yet) but I strongly support your overall purpose. Specifically, I think that automating repetitive and structured parts of the review process for both sponsors and the ftp team is a great idea and will benefit

libAWSL: Improving Human Efficiency for debian/copyright Reviewer

Hi Debian Project, (Human Efficiency Problem is non-technical) As we know, the human efficiency in the debian/copyright reviewing process can be optimized, reducing the development cost of the community. However, the possibilities of performing that kind of optimization are left uncharted. I'm

Re: The copyright checking question

between major Debian releases. On Tue, 31 Dec 2019 23:39:32 -0600 John Goerzen wrote: > On Mon, Dec 30 2019, Steven Robbins wrote: > > > In another thread, Russ Allbery makes a salient observation [1]: > > > > Requiring ftpmasters to [review debian/copyright before accep

Re: The copyright checking question

On Mon, Dec 30 2019, Steven Robbins wrote: > In another thread, Russ Allbery makes a salient observation [1]: > > Requiring ftpmasters to [review debian/copyright before accepting an > upload] is a choice that Debian has made. Maybe it's the right choice, > bu

The copyright checking question

In another thread, Russ Allbery makes a salient observation [1]: Requiring ftpmasters to [review debian/copyright before accepting an upload] is a choice that Debian has made. Maybe it's the right choice, but other choices exist, and other entities make different choices. Russ

Re: Article 13 of the EU copyright review

Dear -project, > FYI as I didn't receive any strong objections I went ahead and signed > on behalf of the Project. Feel free to > also sign it in an individual capacity if you wish. Our signature with our logo is now live. Note that we are first in the list… as we

Re: Article 13 of the EU copyright review

On Tue, Jun 05, 2018 at 07:10:05PM +0100, Chris Lamb wrote: > https://savecodeshare.eu/ There is also https://saveyourinternet.eu/ Kurt

Re: Article 13 of the EU copyright review

Chris Lamb wrote: > Would there any strong objections to the Project aligning itself > against the new EU copyright review? […] > https://savecodeshare.eu/ FYI as I didn't receive any strong objections I went ahead and signed <https://savecodeshare.eu/> on behalf of the Pro

Re: Article 13 of the EU copyright review

On Tue, Jun 05, 2018 at 10:28:56PM +0200, Florian Weimer wrote: > * Chris Lamb: > > > Would there any strong objections to the Project aligning itself > > against the new EU copyright review? For more background, here's a > > recent Linux Journal article a

Re: Article 13 of the EU copyright review

Chris Lamb writes ("Article 13 of the EU copyright review"): > Would there any strong objections to the Project aligning itself > against the new EU copyright review? For more background, here's a > recent Linux Journal article about this reform attempt: > > >

Re: Article 13 of the EU copyright review

lst this is no doubt intended to prevent uploads that infringe copyright, the same technology could soon be required for filtering of content for compliance with other statutes. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-

Re: Article 13 of the EU copyright review

* Chris Lamb: > Would there any strong objections to the Project aligning itself > against the new EU copyright review? For more background, here's a > recent Linux Journal article about this reform attempt: > > > https://www.linuxjournal.com/content/how-eus-copyright-ref

Article 13 of the EU copyright review

Dear developers, Would there any strong objections to the Project aligning itself against the new EU copyright review? For more background, here's a recent Linux Journal article about this reform attempt: https://www.linuxjournal.com/content/how-eus-copyright-reform-threatens-open-source

Re: Debian infrastructure in the EU / copyright challenges

* gregor herrmann: > Question 2: What about the "uploads by their users"? Since Debian > doesn't allow random people to upload random stuff to its servers > which Debian then promotes, I think this also doesn't apply. Correct, and Debian provides training to DDs to recognize

Re: Debian infrastructure in the EU / copyright challenges

On Wed, 23 Aug 2017 11:02:51 +0200, Adam Borowski wrote: > Not found nor apparently even linked anywhere on the EFF site, they seem to > refer to http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=17200 Thanks for digging up this document. > # Article 13 > # > # Use of protected content by

Re: Debian infrastructure in the EU / copyright challenges

On Wed, Aug 23, 2017 at 09:36:08AM +0200, Florian Weimer wrote: > * Daniel Pocock: > > > There has been some discussion about the potential impact of the latest > > copyright legislation[1] on sites/services that share source code or > > facilitate collaborative developme

Re: Debian infrastructure in the EU / copyright challenges

* Daniel Pocock: > There has been some discussion about the potential impact of the latest > copyright legislation[1] on sites/services that share source code or > facilitate collaborative development services. Do you have a link to the text of the proposal? The EFF probably misrepre

Debian infrastructure in the EU / copyright challenges

There has been some discussion about the potential impact of the latest copyright legislation[1] on sites/services that share source code or facilitate collaborative development services. The EU vote on those rules potentially takes place in about 2 months. One of the key concerns is that while

Re: Unaddressed use cases for machine-readable debian/copyright files

On Saturday, 25 March 2017 16:25:38 CEST Guillem Jover wrote: > Personally I have no issue with coalescing > copyright notices, as long as they are all for the same license, etc. > I even coalesce copyright years for the same owner. Coalescing copyright notices and years is also done whe

Re: Unaddressed use cases for machine-readable debian/copyright files

conventions I took my first serious look at good old DEP5, and brought > > the debian/copyright file for my first-ever package, xtrs[1], into > > conformance with the new[2] standard[3]. > > > > However, in doing so, I encountered some use cases that are not covered &

Re: Unaddressed use cases for machine-readable debian/copyright files

Guillem Jover <guil...@debian.org> writes: > Something that is also a common source of confusion, is that because > it specifies a Files field, it seems it compels people to do very > fine-grained splitting. Personally I have no issue with coalescing > copyright notices, as lo

Re: Unaddressed use cases for machine-readable debian/copyright files

Hi! On Fri, 2017-03-24 at 14:02:49 -0400, G. Branden Robinson wrote: > In returning my attention to current Debian packaging practices and > conventions I took my first serious look at good old DEP5, and brought > the debian/copyright file for my first-ever package, xtrs[1], into >

Re: DEP-5 (copyright file format) ... gap with practice

embedded code copies (including autotools related files, m4 macros etc). Agreed, but we must still respect copyright and licensing for all code that we distribute - also what we distribute in source form, even if regenerated during build. How do we ensure that we respect copyright and licensing

Re: DEP-5 (copyright file format) ... gap with practice

On Thu, Sep 18, 2014 at 05:03:07PM -0400, David Prévot wrote: Why do you believe repacking upstream tarball should be the default behavior (especially when, as already pointed before, “You *should* upload packages with a pristine source tarball if possible”)? I don't suppose I'll have much

Re: DEP-5 (copyright file format) ... gap with practice

On Wed, Sep 10, 2014 at 12:27:58AM -0400, David Prévot wrote: On the other hand, it defeats the principle of least surprise. Distributing a different upstream tarball in Debian than upstream, just because, seems plain wrong. Even the dev-ref agrees: “You *should* upload packages with a

Re: DEP-5 (copyright file format) ... gap with practice

On Mon, Sep 15, 2014 at 04:51:19PM +0200, Andreas Tille wrote: Just for the sake of interest: Is there any reason not to use uscan? (I hope the answer will not be since I need to remove files from upstream source.) This wouldn't help those not using uscan, of which I am one, but what about

Re: DEP-5 (copyright file format) ... gap with practice

Hi, Le 18/09/2014 02:28, Jonathan Dowland a écrit : what about extending uscan to have a list of autoconf-like files that it automatically excludes by default (override-able of course), saving people from listing the exact same files in Files-Excluded: for every autotools-using package? Why

Re: DEP-5 (copyright file format) ... gap with practice

On Thu, Sep 18, 2014 at 2:26 PM, Jonathan Dowlandwrote: But how do you feel about the slightly different situation of shipping a pristine tarball but not performing an autoreconf (etc etc) prior to ./configure -- thus deviating from the normal process of building that package from source? At

Re: DEP-5 (copyright file format) ... gap with practice

Hi, On Wed, Sep 10, 2014 at 10:48:22AM +0600, Andrey Rahmatullin wrote: On Tue, Sep 09, 2014 at 05:40:46PM -0400, Michael Gilbert wrote: Not sure how that's a lot of work since uscan does all the magic for you. I don't use uscan to download tarballs for packages I maintain. Not to

Re: DEP-5 (copyright file format) ... gap with practice

On Mon, Sep 15, 2014 at 04:51:19PM +0200, Andreas Tille wrote: Not sure how that's a lot of work since uscan does all the magic for you. I don't use uscan to download tarballs for packages I maintain. Not to mention time required to fill in the Files-Excluded field. Just for the sake

Re: DEP-5 (copyright file format) ... gap with practice

On Wed, Sep 10, 2014 at 11:48:38PM +0900, Osamu Aoki wrote: The debmake command (in python) offers such copyright file verification against the current source files by running it in the source tree as. Thanks Osamu, I meant to check the implementation before replying, but ran out of time

Re: DEP-5 (copyright file format) ... gap with practice

On Wed, Sep 10, 2014 at 12:48 AM, Andrey Rahmatullin wrote: another clear benefit is reduced package cruft. The only thing that is reduced is the size of the orig tarball. People do actually do review package source changes (think every release team unblock, security analysis, etc.), and the

Re: DEP-5 (copyright file format) ... gap with practice

Quoting Russ Allbery (2014-09-10 06:38:21) Osamu Aoki os...@debian.org writes: It may be good to have a set of specifically defined file types for exclusion in DEP-5 policy. Then we can skip listing them in the copyright file. The helper script can generate a template for the copyright

Re: DEP-5 (copyright file format) ... gap with practice

to /usr/share/common-licenses that is always assumed included in debian/copyright of any package. Concretely I propose the attached file for that. Thanks a lot for your snippet!, I find it very helpful. OTOH, the proposal of shipping it under /usr/share/common-licenses/ violates the self

Re: DEP-5 (copyright file format) ... gap with practice

(with the correct license) in debian/copyright. ^^ The debmake command (in python) offers such copyright file verification against the current source files by running it in the source tree as. $ debmake -k Its manpage goes as: -k

Re: DEP-5 (copyright file format) ... gap with practice

Hi here is an example: On Wed, Sep 10, 2014 at 11:48:38PM +0900, Osamu Aoki wrote: ... $ debmake -k ... === debian/copyright checked for 90 data === Pattern #00: * File: data/symbol.txt - GPL-2+ + BSD-3-Clause Pattern #00: * File: depcomp config.sub m4/intltool.m4

Re: DEP-5 (copyright file format) ... gap with practice

with very permissive license with mostly identical but not quite the same copyright phrases which reqire us to quote them separately. I am talking about autotools files such as: PERMISSIVE * */Makefile.in * m4/*.m4 * configure * INSTALL * aclocal.m4 GPL-2.0+ with autoconf

Re: DEP-5 (copyright file format) ... gap with practice

a lot of work since uscan does all the magic for you. One benefit is less time on copyright file research/review, and another clear benefit is reduced package cruft. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble

Re: DEP-5 (copyright file format) ... gap with practice

reasons) for absolutely no gain. One benefit is less time on copyright file research/review, On the other hand, it defeats the principle of least surprise. Distributing a different upstream tarball in Debian than upstream, just because, seems plain wrong. Even the dev-ref agrees: “You *should

Re: DEP-5 (copyright file format) ... gap with practice

Osamu Aoki os...@debian.org writes: It may be good to have a set of specifically defined file types for exclusion in DEP-5 policy. Then we can skip listing them in the copyright file. The helper script can generate a template for the copyright file in line with the actual practice

Re: DEP-5 (copyright file format) ... gap with practice

but Debian Policy. Hi Osamu and Jonas, the final authority to decide what debian/copyright must contain is the FTP team. There is a long-standing tolerance for not documenting the files autogenerated by the autotools system, but it has not been formally codified, so the Policy can not reflect

Re: DEP-5 (copyright file format) ... gap with practice

that's a lot of work since uscan does all the magic for you. I don't use uscan to download tarballs for packages I maintain. Not to mention time required to fill in the Files-Excluded field. One benefit is less time on copyright file research/review, and People actually check licenses

DEP-5 (copyright file format) ... gap with practice

the same copyright phrases which reqire us to quote them separately. I am talking about autotools files such as: PERMISSIVE * */Makefile.in * m4/*.m4 * configure * INSTALL * aclocal.m4 GPL-2.0+ with autoconf exception * compile * depcomp * missing * py-compile * test-driver * m4

Re: DEP-5 (copyright file format) ... gap with practice

permissive license with mostly identical but not quite the same copyright phrases which reqire us to quote them separately. I am talking about autotools files such as: PERMISSIVE * */Makefile.in * m4/*.m4 * configure * INSTALL * aclocal.m4 GPL-2.0+ with autoconf exception * compile

Re: Copyright arrangements for a web project

Thorsten Glaser writes (Re: Copyright arrangements for a web project): It has recently been “discovered” (i.e. the implications finally arrived in peoples’ heads) that the AGPL prevents making available embargoed security hotfixes (because you can’t deploy them because that would break

Re: Copyright arrangements for a web project

Ian Jackson ijackson at chiark.greenend.org.uk writes: (The main program I'm thinking of here is a Ruby on Rails application.) What are people's feelings about AGPLv3 ? Completely beyond licencing (I’m firm on the BSD side of things ofc): It has recently been “discovered” (i.e. the

Re: Copyright arrangements for a web project

the language, it's not even been read twice, feedback welcome) /* Really Important Project for Debian - does important things. * * Copyright (C) 2013 Paul R. Tagliamonte t...@pault.ag * * This program is free software; you can redistribute it and/or * modify it under

Re: Copyright arrangements for a web project

* Paul Tagliamonte paul...@debian.org, 2013-12-15, 10:02: As an additional permission, you may use, redistribute and/or modify this work under any DFSG (Debian Free Software Guidelines) free license, as interpreted by the Debian FTP Team, or the Debian Project by means of General Resolution.

Re: Copyright arrangements for a web project

On Fri, Dec 13, 2013 at 12:32:59PM +, Ian Jackson wrote: Nevertheless your opinion is interesting to me [...] [explanations] Thanks for that. If you find clarification of the license that are grounded in the actual text and written by B. Kuhn or the FSF, please forward them.

Re: Copyright arrangements for a web project

Bill Allombert writes (Re: Copyright arrangements for a web project): On Thu, Dec 12, 2013 at 07:45:14PM +, Ian Jackson wrote: Perhaps I haven't looked in the right places but either I don't see the same concerns as you do, or I haven't seen them, or I don't think they're relevant

Copyright arrangements for a web project

is probably yes because the licensing landscape for web applications isn't settled yet. Is this a good idea and how should it be done ? Ideally it would be good to avoid requiring copyright assignment to the licence steward. Can this be achieved by some text in the standard licence rubric eg

Re: Copyright arrangements for a web project

. Is this a good idea and how should it be done ? The licensor can not change the license unless the licensor also owns the copyright for contributions. Contributions are owned by their authors. Therefor this is a rather moot point, unless your idea is to require copyright assignment as well as license

Re: Copyright arrangements for a web project

and the free software community. Ideally it would be good to avoid requiring copyright assignment to the licence steward. Can this be achieved by some text in the standard licence rubric eg. While I understand the value of or later clauses, these gives a very broad degree of power. They allow

Re: Copyright arrangements for a web project

in ways other than just upgrading to newer versions ? I think the answer is probably yes because the licensing landscape for web applications isn't settled yet. Is this a good idea and how should it be done ? Ideally it would be good to avoid requiring copyright assignment

Re: Copyright arrangements for a web project

Joshua D. Drake writes (Re: Copyright arrangements for a web project): On 12/12/2013 06:44 AM, Ian Jackson wrote: * It would clearly be sensible to appoint a licence steward in the GPLv3 sense. If the current project leadership lack free software credibility, could SPI serve

Re: Copyright arrangements for a web project

Eitan Adler writes (Re: Copyright arrangements for a web project): On Thu, Dec 12, 2013 at 9:44 AM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: * Personally I'm an AGPLv3 proponent. The system ought to be suitable for AGPLv3 provided that its submodules are AGPLv3-compatible

Re: Copyright arrangements for a web project

On Thu, Dec 12, 2013 at 02:44:19PM +, Ian Jackson wrote: * Personally I'm an AGPLv3 proponent. The system ought to be suitable for AGPLv3 provided that its submodules are AGPLv3-compatible (and if they aren't, then we can probably write a licence exception). (The main program I'm

Re: Copyright arrangements for a web project

Paul Tagliamonte writes (Re: Copyright arrangements for a web project): On Thu, Dec 12, 2013 at 02:44:19PM +, Ian Jackson wrote: 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

Re: Copyright arrangements for a web project

Eitan Adler writes (Re: Copyright arrangements for a web project): On Thu, Dec 12, 2013 at 12:30 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Eitan Adler writes (Re: Copyright arrangements for a web project): [AGPLv3] is the least-free license currently approved by the OSI

Re: Copyright arrangements for a web project

On Thu, Dec 12, 2013 at 12:30 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Eitan Adler writes (Re: Copyright arrangements for a web project): On Thu, Dec 12, 2013 at 9:44 AM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: * Personally I'm an AGPLv3 proponent. The system ought

Re: Copyright arrangements for a web project

On Thu, Dec 12, 2013 at 06:35:05PM +, Ian Jackson wrote: Of course that only applies to future versions of the GNU GPL. It's not possible to switch from AGPL to GPL (or the other way) with that wording. Indeed, just a datapoint for what other projects do. I'd be fine to include in my

Re: Copyright arrangements for a web project

On Thu, Dec 12, 2013 at 07:45:14PM +, Ian Jackson wrote: Bill Allombert writes (Re: Copyright arrangements for a web project): I am fine with the stated purpose of the AGPLv3, however I do not think the actual implementation is compatible with free software. Perhaps I haven't looked

Re: Copyright assignement for Debian tools?

On Sat, Feb 09, 2013 at 06:51:54PM +0100, Stefano Zacchiroli wrote: It wouldn't make sense to assign copyright to the Debian Project, but it might make sense to assign it to some of our trusted organization, like SPI. I'm myself not aware of mechanisms offered by SPI to allow volunteer

Re: Copyright assignement for Debian tools?

Thomas Koch writes (Copyright assignement for Debian tools?): I'm currently hacking on the maven-repo-helper package. The source code contains copyright statements from the original author. Now when I add classes it would be logical to add Copyright 2013 Thomas Koch. Right. But I don't see

Re: Copyright assignement for Debian tools?

On Mon, February 11, 2013 14:54, Antonio Terceiro wrote: There are several cases where upstream explicitly puts Copyright 2013 The Foo Developers and similar statements. Are they invalid as well? If they are valid, wouldn't Copyright 2013 Debian Project have the similar (if not the same

Re: Copyright assignement for Debian tools?

Antonio Terceiro terce...@debian.org writes: There are several cases where upstream explicitly puts Copyright 2013 The Foo Developers and similar statements. Are they invalid as well? If they are valid, wouldn't Copyright 2013 Debian Project have the similar (if not the same) meaning? *All

Re: Copyright assignement for Debian tools?

On Sun, Feb 10, 2013 at 09:14:12AM +0800, Paul Wise wrote: If you are contributing to copyleft projects, it is important to have diverse copyright holders to prevent converting projects to proprietary licenses. FWIW, we are far from having consensus on this aspect in the free software world

Copyright assignement for Debian tools?

Hi, I'm currently hacking on the maven-repo-helper package. The source code contains copyright statements from the original author. Now when I add classes it would be logical to add Copyright 2013 Thomas Koch. But I don't see any sense in this. I've no interest to be the copyright holder. I'd

Re: Copyright assignement for Debian tools?

On Sat, Feb 09, 2013 at 05:23:59PM +0100, Thomas Koch wrote: I'm currently hacking on the maven-repo-helper package. The source code contains copyright statements from the original author. Now when I add classes it would be logical to add Copyright 2013 Thomas Koch. But I don't see any

Re: Copyright assignement for Debian tools?

On Sat, Feb 9, 2013 at 12:51 PM, Stefano Zacchiroli lea...@debian.org wrote: On Sat, Feb 09, 2013 at 05:23:59PM +0100, Thomas Koch wrote: I'm currently hacking on the maven-repo-helper package. The source code contains copyright statements from the original author. Now when I add classes

Re: Copyright assignement for Debian tools?

* be that voluntary copyright assignments are a special case, especially if SPI does not offer that service, but I very much doubt it. Either way, several people active in SF Conservancy people are also active on SPI mailing list, so we won't miss chances of collaborating on this if there are some

Re: Copyright assignement for Debian tools?

Stefano Zacchiroli lea...@debian.org writes: Thanks Brian. As a matter of fact, I discuss with Bradley (Conservancy's Executive Director) fairly regularly and I've in the past discussed with him the possibilities of benefiting of SF Conservancy services as Debian Project. The problem is that

Re: Copyright assignement for Debian tools?

On Sat, Feb 09, 2013 at 11:20:17AM -0800, Russ Allbery wrote: Doesn't Debian as a whole also have nearly as many assets as all other projects in the Software Freedom Conservancy put together? In terms of reserves, it might be. But in terms of expenses / revenue they're way more active than we

Re: Copyright assignement for Debian tools?

Le Sat, Feb 09, 2013 at 05:23:59PM +0100, Thomas Koch a écrit : I've no interest to be the copyright holder. I'd much rather like to write Copyright 2013 The Debian Project. (Actually I'm totally annoyed by anything related to copyright...) Hi Thomas, I share the same feeling and in some

Re: Copyright assignement for Debian tools?

On 10/02/2013 03:14, Paul Wise wrote: My advice would just to put Copyright 2013 Thomas Koch and a DFSG-free license, anything else would be more effort on your part. I've considered using Copyright 2013 Debian Project for the licensing of packaging that's intended to go into Debian. What

Re: Copyright assignement for Debian tools?

Jonathan Carter (highvoltage) jonat...@ubuntu.com writes: On 10/02/2013 03:14, Paul Wise wrote: My advice would just to put Copyright 2013 Thomas Koch and a DFSG-free license, anything else would be more effort on your part. I've considered using Copyright 2013 Debian Project

Re: Regarding Automated tool for generation and scanning of copying/copyright files

Le Wed, Nov 07, 2012 at 02:18:33PM +0530, Mohamed Fazil a écrit : I am new to Debian OS. Before using this i would like to get clarified for few queries. I am working on a tool called FOSSology, which will do software analysis and then give the output in .txt file. But I need output in SPDX

Re: Regarding Automated tool for generation and scanning of copying/copyright files

On Wed, Nov 07, 2012 at 02:18:33PM +0530, Mohamed Fazil wrote: Hi, I am new to Debian OS. Before using this i would like to get clarified for few queries. I am working on a tool called FOSSology, which will do software analysis and then give the output in .txt file. But I need output in

Re: Regarding Automated tool for generation and scanning of copying/copyright files

You might want to start with the information and contacts from this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597861 Thomas Koch, http://www.koch.ro -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

Regarding Automated tool for generation and scanning of copying/copyright files

Hi, I am new to Debian OS. Before using this i would like to get clarified for few queries. I am working on a tool called FOSSology, which will do software analysis and then give the output in .txt file. But I need output in SPDX format. I have installed the tool in Ubuntu OS. I want to clarify

Re: A media type for the machine-readable copyright format ?

On Tue, Sep 11, 2012 at 08:10:18AM +0900, Charles Plessy wrote: here is the information that I consider submitting to the IANA. Hi Charles, thanks for taking care of this! I'm no expert in the sort of document you're submitting, but to my layman eyes all seem good. Person email address to

Re: A media type for the machine-readable copyright format ?

Le Tue, Sep 11, 2012 at 08:51:24AM +0200, Stefano Zacchiroli a écrit : On Tue, Sep 11, 2012 at 08:10:18AM +0900, Charles Plessy wrote: here is the information that I consider submitting to the IANA. Person email address to contact for further information: Charles Plessy

Re: A media type for the machine-readable copyright format ?

security issues ? No, your security considerations seem reasonable to me. While it is probably very reasonable to do sanity checks as usual the as usual is a hint that the phrase might be redundant. It somehow has the value as People parsing debian/copyright should know their job. As I said

Re: A media type for the machine-readable copyright format ?

On Tue, Sep 11, 2012 at 04:41:52PM +0900, Charles Plessy wrote: I wonder if the contact address shouldn't be something less tied to project individuals, like for instance debian-project@lists.d.o. Given there is already a separation between this and the author field (allowing to give

  1   2   3   >