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

[Charles Plessy]

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
> initial discussion was started on debian-devel [1], and since there
> have been no large objections I would like to formalize it.
> 
> For now, am I the only driver of this DEP. I would like to maintain
> the DEP in the DEP Team's repository [2].

Dear Stephan,

thank you for your initiative.

I just added you to the dep-team/deps project on Salsa.  Please open
issues if you have technical problems while adding DEP17.

Have a nice week-end,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy


signature.asc
Description: PGP signature

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

[Russ Allbery]

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 instead.

-- 
Russ Allbery (r...@debian.org)  

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

[Dominik George]

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 in.

I am totally for aligning the License: field with SPDX licence specifications, 
but that's it. For everything else, SPDX is a PITA.

-nik

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

[Felix Lechner]

Hi,

On Tue, Feb 8, 2022 at 9:31 AM Russ Allbery  wrote:
>
> No one uses our RFC-2822-style thing except us, and no one has tools
> for it, so people are understandably quite reluctant to adopt it.

I agree with that assessment.

As far as I understand the situation of DEP-5 tooling, I may now have
(reluctantly) implemented in Lintian the most commonly used—and
therefore the authoritative—parser for the DEP-5 format. [1] I am only
aware of one other relevant implementation. [2]

> it really should have been (a restricted subset of) YAML

The issue with DEP-5 is not merely one 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 the
d/copyright file is to supply license information only for installable
packages. [4] For sources, there are other mechanisms, such as
comments or COPYRIGHT files, that are unlikely to be replaced by this
or other efforts.

Some folks even ship different copyright files with installables
generated from the same sources. [5]

Kind regards,
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Debian/Copyright/Dep5.pm
[2] https://bugs.debian.org/1000319
[3] https://bugs.debian.org/969541
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672284#31
[4] https://bugs.debian.org/672284

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

[Stephan Lachnit]

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 here or at d-devel, or
> both?!?
>
> I tried to encourage keeping the broader discussion at d-devel by only
> pointing towards it from here, but perhaps that was wrong/silly...

To answer this quickly: the former one is my plan. But plans won't
always work, so I will also look at the latter option (i.e. REUSE ->
SPDX -> DEP5). Note that DEP5 -> SPDX is afaik not possible
standalone, but REUSE essentially is already a DEP5 -> SPDX converter
if given the source files.

Regards,
Stephan

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

[Jonas Smedegaard]

Quoting Russ Allbery (2022-02-08 18:22:46)
> 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 (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 now shared my objection to the 
> > idea at that thread: 
> > https://lists.debian.org/164433477648.2636895.1692225734052...@auryn.jones.dk
> 
> The point, as I understand it, [...]

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 here or at d-devel, or 
both?!?

I tried to encourage keeping the broader discussion at d-devel by only 
pointing towards it from here, but perhaps that was wrong/silly...


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

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

[Russ Allbery]

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 (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 now shared my objection to the 
> idea at that thread: 
> https://lists.debian.org/164433477648.2636895.1692225734052...@auryn.jones.dk

The point, as I understand it, of the SPDX specification is to be even
more machine-readable, which implies to me that we could generate the
current debian/copyright format from it, and possibly vice versa.  I think
the best way to move forward with compatibility with SPDX may be to
improve our side so that we can consume that format and capture all of the
same information (think JSON and YAML interoperability), which would allow
us to use tools from their ecosystem while still producing the same output
files that people are used to today.

This is a hindsight is 20/20 sort of thing, and I was among the people who
resisted doing the right thing at the time (mea culpa), but we kind of
shot ourselves in the foot with the current debian/copyright format.  No
one uses our RFC-2822-style thing except us, and no one has tools for it,
so people are understandably quite reluctant to adopt it.  In hindsight,
it really should have been (a restricted subset of) YAML or something else
that everyone else knows how to use; if it had been, I'm not sure we'd be
in a situation where the rest of the industry is going in a different
direction.  But that's where we're at, and I think we're at significant
risk of ending up in a dead end and thus not being able to take advantage
of a ton of licensing work that's being done upstream but is in a format
that we don't use, requiring us to tediously recreate that work instead.

My goal in this discussion is to avoid that.  I don't really care that
much about what the canonical output format is because, if done properly,
I think we should be able to generate multiple output formats from the
same data with minimum effort.  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.

To make that concrete, I want to ship structured copyright and license
information with all of my upstream packages.  I'm currently doing that in
Debian's format, but Debian's format is not useful to anyone other than
Debian.  I plan on switching to SPDX or REUSE or something similar because
then someone else has a hope of being able to consume that data.  The
thought of then having to do additional work when packaging to cater to
Debian is very unappealing; I want to be able to fully automate generating
the debian/copyright file from the data that I'm already maintaining
upstream.

-- 
Russ Allbery (r...@debian.org)  <https://www.eyrie.org/~eagle/>

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

[Russ Allbery]

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], and since there have been no
> large objections I would like to formalize it.

Thank you very much for working on this!  I've been looking at adopting
this for all the packages for which I'm upstream, and really appreciate
other people also looking at it so that we can figure out the best
approach.

-- 
Russ Allbery (r...@debian.org)  <https://www.eyrie.org/~eagle/>

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

[Jonas Smedegaard]

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 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 now shared my objection to the 
idea at that thread: 
https://lists.debian.org/164433477648.2636895.1692225734052...@auryn.jones.dk

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

New DEP: Usage of SDPX in debian/copyright

[Stephan Lachnit]

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 objections I would like to formalize it.

For now, am I the only driver of this DEP. I would like to maintain
the DEP in the DEP Team's repository [2].

The header for the DEP:

Title: Usage of SDPX documents in debian/copyright
DEP: 17
State: DRAFT
Date: 2021-02-08
Drivers: Stephan Lachnit 
URL: http://dep.debian.net/deps/dep17
Source: https://salsa.debian.org/dep-team/deps/-/blob/master/web/deps/dep17.mdwn
License: https://spdx.org/licenses/MIT.html
Abstract:
 Accept SPDX documents as format for debian/copyright to use upstream copyright
 and licensing information, reducing manual copyright review labor.

Once the DEP number is confirmed, I will upload an initial draft in
the following days.

Regards,
Stephan

[1] https://lists.debian.org/debian-devel/2022/01/msg00309.html
[2] https://salsa.debian.org/dep-team/deps

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

[Mo Zhou]

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 files are reviewed.*

It's designed for people who "review all the files" when the package
turns to be NEW. For example, one who is about to upload a NEW package.
This aims to speed up a **rigorous** review, instead of a much less
rigorous review. Generally reviewing things quickly and carelessly makes
the life of every uploader much easier -- but that means more burden for
our last shield, ftp team.

Again, the specification talks about how the status of files are changed
in the status space {"N/A", "outdated", "ACCEPT", "REJECT"}, which is a
pure interpretation of the modeling of the process, and it did not say
any preference on political stuff such as "when the review should be
triggered" -- I have no intention to talk about it. My specification is
invariant to the review whatever frequency people prefer. If people
prefer to do the review after every git commit, libawsl can be useful.
If people prefer to slack off and only do the review when the package
has to go through the new queue again, libawsl can also be useful.

> But to an outsider, what it sounds like Mo is proposing is that whenever
> the salt is changed, review needs to be triggered, even if new would not
> be triggered in the current model.

Talking about how the file status move in the status space
  {"N/A", "outdated", "ACCEPT", "REJECT"}
does not imply any preference on the frequence of review.

Why not take git as an example?

 "N/A": the user didn't git add 
 "outdated":  has been changed, stage and commit it when user
 sees appropriate.
 "accept":  has not been changed, nothing to do
 "reject": ? no analogous concept, but it does not matter.

When did git urge people to stage files, do commits, or push when it
gets unhappy about the modified files and unsynced tree status?  Is the
git efficiency seriously impacted by "how frequent the user does
commits", "how frequent the user does commits"?

Similarly, when did libawsl urge people to do the review once the file
status has been changed?
 
> My thoughts are that
> 1) I think it's worth being clear that you're not proposing increasing
> the rounds of new review.

No. libawsl is independent and ignorant to the review frequency. It is
designed to **help human** when they need to do a review, not designed
to **prod or force people** to do review once it gets unhappy.
 
> 2) Long term, having a persistent database of review state might allow
> us to have better criteria for when to trigger license review.

libawsl can use a persistent database to reduce redundant reviews, as
long as the salthash do match. There is no design consideration on given
answers to questions such as "when to trigger a review". Whatever the
review frequency is, libawsl is invariant and will do its job.
 
> --Sam


signature.asc
Description: PGP signature

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

[Sam Hartman]

>>>>> "Michael" == Michael Lustfield  writes:

Michael> On Tue, 26 May 2020 08:13:24 -0400
Michael> Sam Hartman  wrote:

>> Unfortunately, being a member of Debian, I find myself getting
>> stuck in the details and think you may have gotten a few things
>> wrong.
>> 
>> * I think that reviewing a file every time the salt changes is
>> too frequent.  It is a sign that we might need to review, not
>> that we certainly do.  We don't tend to review files every time
>> they change today, and I think pushing toward this would be
>> problematic.

Michael> At the moment, when a package hits binNEW or NEW, *all*
Michael> files need to be re-checked by the reviewer. There is no
Michael> single-file review. This is appropriate because there are
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 would reduce efforts, not increase
Michael> them.

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 files are reviewed.*
But to an outsider, what it sounds like Mo is proposing is that whenever
the salt is changed, review needs to be triggered, even if new would not
be triggered in the current model.

My thoughts are that
1) I think it's worth being clear that you're not proposing increasing
the rounds of new review.

2) Long term, having a persistent database of review state might allow
us to have better criteria for when to trigger license review.

--Sam

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

[Michael Lustfield]

On Tue, 26 May 2020 08:13:24 -0400
Sam Hartman  wrote:

> Unfortunately, being a member of Debian, I find myself getting stuck in
> the details and think you may have gotten a few things wrong.
> 
> * I think that reviewing a file every time the salt changes is too
>   frequent.
>   It is a sign that we might need to review, not that we certainly do.
>   We don't tend to review files every time they change today, and I
>   think pushing toward this would be problematic.

At the moment, when a package hits binNEW or NEW, *all* files need to be
re-checked by the reviewer. 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 reduce efforts, not increase them.

> * Unfortunately the srcpkg-bool problem does not decompose into a set of
>   file-bool problems the way you describe.
>   The issue is license compatibility.
>   Two licenses may be DFSG-free, but their combination may not be
>   distributable (and thus not DFSG-free).

Two DFSG-free but incompatible licenses is a non-trivial concern and likely
only caught in more extreme cases. This is really something that should become
a lintian check that only reads through d/copyright.

> Next Steps
> 
> The biggest thing I see missing here is what are the next steps?
> If we agree with your principles, what next?
> How does this work go forward?

Mo has made it clear that his ambition has run out. However, we had many
discussions, including with ftpteam members, prior to either of our
announcements. In a sense, libAWSL is aimed at being both a stand-alone utility
as well as a module usable by the project I previously described.

It's probably worth noting, based on previous conversation, I don't expect
anyone in ftpteam would want to see anything discussed implemented as a formal
review tool. Therefor, my own goal is to ultimately build a tool that focuses on
package uploaders, so that they can be confident their package will be approved.

If there are developers interested in working on this tool, I'd be happy to
discuss further in #debian-review and write an actual requirements document to
aid collaboration and development.

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

[Sam Hartman]

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
* Minimizing duplicate review or unnecessary re-review is valuable
* getting reviewers the information they need so that they are not being
slowed down searching for it is valuable

* Better tooling can help with the above.

I tend to agree with all those principles and believe they are similar
in spirit to what you state.

Unfortunately, being a member of Debian, I find myself getting stuck in
the details and think you may have gotten a few things wrong.

* I think that reviewing a file every time the salt changes is too
  frequent.
  It is a sign that we might need to review, not that we certainly do.
  We don't tend to review files every time they change today, and I
  think pushing toward this would be problematic.

* Unfortunately the srcpkg-bool problem does not decompose into a set of
  file-bool problems the way you describe.
  The issue is license compatibility.
  Two licenses may be DFSG-free, but their combination may not be
  distributable (and thus not DFSG-free).



Next Steps

The biggest thing I see missing here is what are the next steps?
If we agree with your principles, what next?
How does this work go forward?

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

[Mo Zhou]

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 willing to do.

I understand that doing nothing is the most comfortable choice for a
human being, but that does not prevent me from thinking constructively.
Though, I quickly found that the negative feelings against the theory
overweighs the positive ones. Anyway, as a cheap theoretical discussion
(talk is cheap), it should not impose pressure and unhappiness on anyone.

I shall call it the end of my participation in this thread. I didn't
violate the code of conduct, and I'm not going to find trouble for anyone.

On Sat, May 23, 2020 at 12:46:45PM +, Mo Zhou wrote:
> This thread is for non-technical discussions. If it turns out that the
> community can reach some common agreement, we can move to the technical
> (implementation) discussions on -devel.

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

[YunQiang Su]

> * 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

[Olek Wojnar]

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 our
entire community greatly!

-Olek

libAWSL: Improving Human Efficiency for debian/copyright Reviewer

[Mo Zhou]

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 hereby presenting my "libAWSL" specification, aiming to shed some light
on the software/workflow designing issues on improving human efficiency while
doing the reviewing work on `debian/copyright`:

  https://salsa.debian.org/lumin/awsl/-/blob/master/specification.md

Exhaustive details can be found in the above link. In the following part of
this mail I'm presenting some of the key points in my specification. Note,
I'm trying to do some THEORETICAL discussion on the possibility to improve
human efficiency, INSTEAD OF proposing to enforce anything.

Proposed Principles in Human-Understandable Language


* The reviewer does not have to review the IDENTICAL file more than once.

* The time complexity for going through a package should be less or equal
  to O(num-of-files).

Explanations can be found at:
 https://salsa.debian.org/lumin/awsl/-/blob/master/specification.md

How Can We Benifit from LibAWSL in Practice
---

* Instant acceptance for source packages with merely binary package rename
  (without change in upstream code)

* More verbose and structured feedback from ftp team

* Accumulation of precious educational resources, and reducing training cost
  for ftp-trainees

* Convenient new-upstream-release checks for maintainers and reviewers

* Making the reviewing process interruptable

* Possibility for open/collaborated reviewing workflow

Explanations can be found at:
https://salsa.debian.org/lumin/awsl/-/blob/master/specification.md

---

This thread is for non-technical discussions. If it turns out that the
community can reach some common agreement, we can move to the technical
(implementation) discussions on -devel.

Mo,
For sake of a more efficient Debian Community.



signature.asc
Description: PGP signature

Re: The copyright checking question

[Michael Lustfield]

One of the things that attracts me to Debian the most is it's consistency. We
all tend to follow a standardized policy and have tools to make sure the policy
is followed. This means we've collectively built a system that we all
(generally) agree on.

The benefit to this is that I'm still able to run almost (32 of 34) every single
system of mine without SysD. I may occasionally need to copy/paste/tweak an init
script, but that's it. (... he said, before looking at the last GR results)

These standards, gradual changes, etc. also mean it's /usually/ extremely easy
and safe to do upgrades 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 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.

Another major thing I like about Debian is it's review process. I know it's
currently a pain point, but having the review step means that we can be
reasonably sure what software on our systems is legally free.

Sure, in practice, that hasn't been a problem, but let's imagine/pretend evil
corporations exist... Microsoft decides Gitea is proving too much competition
to Gitlab. They take a look through the source and find a number of unlicensed
modules and offer the original creator(s) some money for them. They now have the
ability to stick their own license on it, call it their own, and sue anyone
using that module, which would include Gitea and Gogs.

I spent >50hr/wk for over half a year attempting to get Gitea packaged for
inclusion in Debian main. Working through that showed me just how often
incorrectly licensed or unlicensed work winds up in larger projects. I also
found that code copying is very common, making it nearly impossible to update
or track.

[Fortunately, a majority of project maintainers are more than happy to find out
their library was useful and quickly add an open source license. A few don't,
but the majority do.]

Here's an example of what sort of headache that can look like:
- https://github.com/go-gitea/gitea/pull/2241/files
- https://github.com/go-gitea/gitea/pull/2383/files

When I install something from Debian main, I get to have a reasonable level of
confidence that I can't wind up a victim of this sort of problem. As someone
who's been involved in copyright conflicts, this is something that is extremely
valuable to me.

> > Russ goes on to list several alternative strategies, concluding with
> >
> > But I do think it's worth occasionally explicitly asking the question 
> > and
> > then making an intentional choice, rather than assuming we're obligated 
> > to
> > continue doing what we're doing.
> >
> > I agree.  This seems to me something worthy of a general resolution on, 
> > since 
> > these discussions pop up every 6-12 months and don't go anywhere.  I don't 
> > have the stamina to go through with proposing a resolution but I hope 
> > others 
> > will.  

I don't think this copyright/license/qa check is a "legally
responsible" /requirement/. In some ways, we're acting like a web hosting
company, but for packages. We have reasonable efforts (policies, auto-reject,
peer-review, etc.) to keep "bad" packages out and if we're made aware of
something that's problematic, we can remove it at the request of any cease &
desist.

This extra step probably doesn't protect the distribution, but it /does/
protect it's users and it protects the people uploading the packages.

> I'm not sure about the GR, but these are exactly the sorts of questions
> and ideas that need to be raised and discussed.

I'd prefer hold off on a GR.

> It is particularly odd to me that there is absolutely no review required
> to introduce code to Debian in general (particularly if a package is
> already in sid), but we have this one-time thing.  I agree with Russ;
> maybe it's needed, but it's high time we give it careful consideration
> again.

I think the cause-effect relationship might be backward here. From my
observation, the number one reason we don't do license checks with updates is
because we don't have the capacity for just what's handled in NEW, and part of
that is related to burn-out.

Sure, we could do away with this amazing bit of peer-review, but I strongly
believe that the cost is too great.

... We might be known as the bickering distro, but we bicker because we care
and because we let passion fuel our emotions.


The options I see:
1) Stop doing this review step
   ^ I reviewed an upload today that had extra DLL files and the entire .git/
   ^ Ask me about Gitea...
2) Get more DDs volunteering t

Re: The copyright checking question

[John Goerzen]

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,
> but other choices exist, and other entities make different choices.
>
> Russ goes on to list several alternative strategies, concluding with
>
> But I do think it's worth occasionally explicitly asking the question and
> then making an intentional choice, rather than assuming we're obligated to
> continue doing what we're doing.
>
> I agree.  This seems to me something worthy of a general resolution on, since 
> these discussions pop up every 6-12 months and don't go anywhere.  I don't 
> have the stamina to go through with proposing a resolution but I hope others 
> will.

I'm not sure about the GR, but these are exactly the sorts of questions
and ideas that need to be raised and discussed.

It is particularly odd to me that there is absolutely no review required
to introduce code to Debian in general (particularly if a package is
already in sid), but we have this one-time thing.  I agree with Russ;
maybe it's needed, but it's high time we give it careful consideration
again.

John


>
> -Steve
>
> [1] https://lists.debian.org/debian-project/2019/12/msg00188.html

The copyright checking question

[Steven Robbins]

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 goes on to list several alternative strategies, concluding with

But I do think it's worth occasionally explicitly asking the question and
then making an intentional choice, rather than assuming we're obligated to
continue doing what we're doing.

I agree.  This seems to me something worthy of a general resolution on, since 
these discussions pop up every 6-12 months and don't go anywhere.  I don't 
have the stamina to go through with proposing a resolution but I hope others 
will.

-Steve

[1] https://lists.debian.org/debian-project/2019/12/msg00188.html



signature.asc
Description: This is a digitally signed message part.

Re: Article 13 of the EU copyright review

[Chris Lamb]

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 should be ;)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Article 13 of the EU copyright review

[Kurt Roeckx]

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]

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 Project. Feel free to
also sign it in an individual capacity if you wish.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Article 13 of the EU copyright review

[Adam Borowski]

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 about this reform attempt:
> >
> >   
> > https://www.linuxjournal.com/content/how-eus-copyright-reform-threatens-open-source-and-how-fight-it
> 
> Which part?
> 
> I think the upload filters are fairly sensible, and Debian would
> implement them if required in practice.  For us, infringing content is
> low-quality content, and we train our users to avoid uploading it.
> This is different for the likes of Youtube and Github.

We can't reasonably filter places that anyone can post to.  Packages
themselves are closely reviewed by humans (NEW), but Salsa, the BTS, wiki,
and probably plenty of other services we run rely on removal after the fact.

It's not about filtering spam, it's about a piece of software some vile
litigious company places an (often false) claim to.  We'd have to implement
a before-the-fact filter that censors every such service run by the Project.

That'd be a serious burden that would limit what we can do.

> I find it also problematic to suggest that copyright infringement is
> somehow necessary for a thriving free software ecosystem.

There's a difference between "copyright infrigement" and "alleged copyright
infrigement".  Accuracy of this kind of filters, as required by
"rightholders" and written into the law, is pretty egregious.  They have no
incentive to reduce the amount of false positives.

> I find Title IV, Chapter 3 (“Fair remuneration in contracts of authors
> and performers”) far more problematic because as written, in seems to
> effectively ban irrevocable free software licenses

Sounds nasty, too.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢰⠒⠀⣿⡁ productivity.  You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so.  I recommend Skepticism
⠈⠳⣄ (funeral doom metal).

Re: Article 13 of the EU copyright review

[Ian Jackson]

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:
> 
>   
> https://www.linuxjournal.com/content/how-eus-copyright-reform-threatens-open-source-and-how-fight-it
> 
> … and the FSFE's campaign which anyone can sign in an individual
> capacity:

I haven't researched this, but FSFE are IMO an extremely reliable
guide to what to think about things.  As a general rule, I woud
support any of their campaigns.  (I have a number of their excellent
T-shirts too.)

NB that FSFE are quite are a different thing to the FSF, although,
obviously, they are allies.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Article 13 of the EU copyright review

[Chris Lamb]

Hi Florian,

> I think the upload filters are fairly sensible

This is not the general consensus within the free software community
and is actually the very part in question.

I don't really wish to dilute (nor duplicate the discussion from
elsewhere..), but the general sentiment is that whilst 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

[Florian Weimer]

* 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-reform-threatens-open-source-and-how-fight-it

Which part?

I think the upload filters are fairly sensible, and Debian would
implement them if required in practice.  For us, infringing content is
low-quality content, and we train our users to avoid uploading it.
This is different for the likes of Youtube and Github.

I find it also problematic to suggest that copyright infringement is
somehow necessary for a thriving free software ecosystem.

I find Title IV, Chapter 3 (“Fair remuneration in contracts of authors
and performers”) far more problematic because as written, in seems to
effectively ban irrevocable free software licenses:

| Article 15
| Contract adjustment mechanism
| 
| Member States shall ensure that authors and performers are entitled to
| request additional, appropriate remuneration from the party with whom
| they entered into a contract for the exploitation of the rights when
| the remuneration originally agreed is disproportionately low compared
| to the subsequent relevant revenues and benefits derived from the
| exploitation of the works or performances.

<https://ec.europa.eu/transparency/regdoc/rep/1/2016/EN/1-2016-593-EN-F1-1.PDF>
(Apologies if this is not the current version.)

Germany already has similar provisions, but they exempt free
culture/free software licensing: these provisions do not apply to
works for which everyone has been granted basic exploitation rights.

So yes, we should do something about Title IV, Chapter 3, but I expect
that we'd be pretty much alone in that.

Article 13 of the EU copyright review

[Chris Lamb]

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-and-how-fight-it

… and the FSFE's campaign which anyone can sign in an individual
capacity:

  https://savecodeshare.eu/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Debian infrastructure in the EU / copyright challenges

[Florian Weimer]

* 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 potential
copyright infringement, and new packages also need to pass a separate
review step.

That leaves mailing lists and the wiki.  I don't see how
copyright-infringing content wouldn't be low-quality content as well,
so if that happens to a significant degree, we'd have to filter it
anyway to keep those resources useful.

Re: Debian infrastructure in the EU / copyright challenges

[gregor herrmann]

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 information society service providers storing
> # and giving access to large amounts of works and other subject matter
> # uploaded by their users

Question 1: What are "information society service providers"? This is
not defined in this document, but it refers (on page 20) to
"Directive 2000/31/EC" [0] which is about e-commerce and says (on
page 3):

  The definition of information society services already exists in
  Community law in Directive 98/34/EC of the European Parliament and
  of the Council of 22 June 1998 laying down a procedure for the
  provision of information in the field of technical standards and
  regulations and of rules on information society services (4) and in
  Directive 98/84/EC of the European Parliament and of the Council of
  20 November 1998 on the legal protection of services based on, or
  consisting of, conditional access (5); this definition covers any
  service normally provided for remuneration, at a distance, by means
  of electronic equipment …

I don't think that Debian falls under this regime (we don't do
e-commerce for remuneration).

(18) mentions all kinds of non-remunerated activities but it still
talks about "a wide range of economic activities which take place
on-line".
(19) again talks about "pursuit of an economic activity … place of
establishment of a company".

And Art.2 "Definitions" (c) finally reads:

  ‘established service provider’: a service provider who effectively
  pursues an economic activity using a fixed establishment for an
  indefinite period. The presence and use of the technical means and
  technologies required to provide the service do not, in themselves,
  constitute an establishment of the provider;


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.


Cheers,
gregor


[0] 
http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32000L0031=EN

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   BOFH excuse #119:  evil hackers from Serbia. 

Re: Debian infrastructure in the EU / copyright challenges

[Adam Borowski]

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 development services.
> 
> Do you have a link to the text of the proposal?

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

> The EFF probably misrepresents its contents.  It seems unlikely that a
> specific approach to copyright review will be mandated.
> 
> I think we are already removing “meme”-type content from packages for
> copyright reasons, so it is unclear to what extent Debian would be
> affected.

The EFF's campaign sounds alarmist, but this doesn't imply it's untrue.
Here's an analogy:
"By keeping a coal plant for just two days, you're a murderer!"
Which, on the face value is wrong:
* murder requires intent towards a specific person, so here it's
  manslaughter
* no jurisdiction currently makes such a long causal chain criminal
Also, what constitutes a "coal plant" is unclear as you can have a coal
generator in your cellar; this particular sound bite matches the count
of plants >=30MW.
Yet in this analogy the sound bite actually grossly _underestimates_
the problem: it takes only short-term airborne pollution in mind, so fails
to account for much more dangerous global warming, etc.
But just think if you used this sound bite -- most people would call you
an alarmist kook, right?


So with this in mind, let's see the wording of the proposal:

# Article 13
#
# Use of protected content by information society service providers storing
# and giving access to large amounts of works and other subject matter
# uploaded by their users
#
# 1. Information society service providers that store and provide to the
# public access to large amounts of works or other subject matter uploaded
# by their users shall, in cooperation with rightholders, take measures to
# ensure the functioning of agreements concluded with rightholders for the
# use of their works or other subject matter or to prevent the availability
# on their services of works or other subject matter identified by
# rightholders through the cooperation with the service providers.  Those
# measures, such as the use of effective content recognition technologies,
# shall be appropriate and proportionate.  The service providers shall
# provide rightholders with adequate information on the functioning and the
# deployment of the measures, as well as, when relevant, adequate reporting
# on the recognition and use of the works and other subject matter.
# 
# 2. Member States shall ensure that the service providers referred to in
# paragraph 1 put in place complaints and redress mechanisms that are
# available to users in case of disputes over the application of the
# measures referred to in paragraph 1.
# 
# 3. Member States shall facilitate, where appropriate, the cooperation
# between the information society service providers and rightholders through
# stakeholder dialogues to define best practices, such as appropriate and
# proportionate content recognition technologies, taking into account, among
# others, the nature of the services, the availability of the technologies
# and their effectiveness in light of technological developments.

Debian _does_ "store and provide to the public" (with an extensive network
of mirrors, even) "large amount of works" (which, unlike previous such
proposals, are not in any way limited to just music and videos -- software
packages are also copyrighted works.  Packages also often include images,
sometimes music (games) and rarely videos.) "uploaded by users" (DDs are
not employees, and we do take a large amount of sponsored uploads from
contributors with no formal relation at all).

The main archive probably is less in a danger, those provided by Alioth
seem more problematic.  The former would be the target of SCO-likes who are
few, the latter would fall to far more likely campaigns against GitHub and
such.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀-- Genghis Ht'rok'din
⠈⠳⣄ 

Re: Debian infrastructure in the EU / copyright challenges

[Florian Weimer]

* 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
misrepresents its contents.  It seems unlikely that a specific
approach to copyright review will be mandated.

I think we are already removing “meme”-type content from packages for
copyright reasons, so it is unclear to what extent Debian would be
affected.

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.

The EU vote on those rules potentially takes place in about 2 months.

One of the key concerns is that while such sharing won't be banned,
compliance with the laws would be costly.  For a volunteer and
non-profit organization like Debian, this is obviously unpleasant.

While it is the EU right now, this type of thing could appear anywhere
(e.g. the US or a country that leaves the EU but copies EU laws to
maintain market access)

DSA has been talking about a new 5-year plan to start replacing
hardware[2] from 2017 onwards, this will potentially be costly in terms
of volunteer effort and finances and it would be useful to ensure both
the location of the hardware and the strategies used for producing
Debian will be resilient against bumbling lawyers and politicians
throughout the life of that infrastructure.

Has there already been any discussion or assessment of these risks
within Debian or other communities?

How much of the new hardware may potentially be located in the countries
concerned?

This type of situation is not completely new - for many years, we had
the non-US issues[3] which only ended in sarge / 2005.

Regards,

Daniel


1.
https://www.eff.org/deeplinks/2017/03/eu-internet-advocates-launch-campaign-stop-eus-dangerous-copyright-filtering
2. https://micronews.debian.org/2017/1486409314.html
3. https://wiki.debian.org/non-US

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

[Dominique Dumont]

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 when running "cme update 
dpkg-copyright" 

See [1] for more details.

HTH

[1] 
https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme#update-a-package

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

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

[G. Branden Robinson]

On Sat, Mar 25, 2017 at 04:25:38PM +0100, Guillem Jover wrote:
> Hi!

Thanks for your feedback!  Been a while since we've chatted.  :)

> 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
> > conformance with the new[2] standard[3].
> > 
> > However, in doing so, I encountered some use cases that are not covered
> > by this standard.  Happily, all of them triggered lintian warnings as
> > well, which gives me a framework within which to present my problems.
> > 
> > The attached debian/copyright file may also illuminate these matters.
> 
> I think all your concerns are already mostly covered by the spec,
> except notably for the license namespacing.

Thanks!  I did completely overlook the section "Stand-alone License
Paragraph", which you brought to my attention through your patches.

However, I still think the copyright file specification could be clearer
with respect to what is deliberately left unspecified, rather than
leaving it implicit.

> 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 long as they are all for the same license, etc.
> I even coalesce copyright years for the same owner. See for example
> the libbsd copyright file, being more fine-grained would be madness
> IMO. And it is my understanding that ftpmasters find this to be fine.

I agree that this is a maintainer discretion issue; perhaps ultimately
an ftpmaster discretion issue, at least at the lower bound of precision.

That such discretion is available to the maintainer should be made more
clear by the spec.  If we said this clearly, you might find fewer people
picking nits below your threshold of attention-worthiness.

xtrs is small enough that I could go atomic on it without much effort;
it's only 24k lines in 37 *.[ch] files.  I once did a license
enumeration deep dive on glibc that surprised me.  Packages that are
large and old (like glibc) or in languages that encourage rampant
cut-and-paste of source snippets (JavaScript) make exhaustive analysis
more challenging, and I would not mandate that my peers undertake such
without good reason, such as a hostile copyright holder.

> So instead of going over all your fine points, I've taken the liberty
> instead to fix the copyright file in what I'd consider to be correctly
> formatted; in two ways, first following the original spirit, of very
> detailed listing, and then another condensed one which is what I'd
> have done. They are incremental patches over your original one.

I was a little confused by this because your first diff is against the
xtrs debian/copyright file currently in the archive.  I.e., it's against
xtrs 4.9c, not the one for 4.9d which I attached in my mail.

I don't see much to distinguish our approaches:
1. You use forward references to license short names; my preference
   would be to use backward references.
2. You put nothing on the first line of a multi-line Files field; I do.
   But I'll change that.
3. You don't use bracket notation in your globs.  Re-reading the
   copyright format doc, I see I'm out of spec on this.  I'll fix that.
4. You (in your condensed form) always put the contents of the Copyright
   field on the subsequent line, even if it would fit on the first.
5. You place importance on the varying renditions of the copyright sign
   ( (c), ©, etc.); I don't.  My lay understanding of U.S. copyright law
   and the various international treaties on the subject is that
   copyright notices do not require any particular rendition of this
   symbol to be effective.  Either of the foregoing, or "(C)" or the
   word "copyright" in any case rendition is adequate, even leaving
   aside the implicit copyright that attaches to any copyright-eligible
   work that goes into "fixed form", as which a text file surely
   qualifies.  But I'm not quite ready to wade back into debian-legal
   yet...

I don't find any of the foregoing to be hills worth dying on; certainly
not #3, where I am surrendering the field. ;-)

I'm attaching my latest revision of debian/copyright based on your
guidance.  It still reflects a degree of wild card phobia, but that's
mainly because I had already done the work to categorize things.

My file (and the whole package, for that matter) is lintian-clean
now--thank you!

In my view, two questions remain:
A. Does the debian/copyright file format spec require an update to
   improve clarity and guidance?  My opinion is that it does.  What do
   other folks on the list think?
B. Wh

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

[Russ Allbery]

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 long as they are all for the same license, etc.
> I even coalesce copyright years for the same owner.

+1.  I would strongly encourage people to do this wherever possible.
There doesn't seem to be much purpose served by being more granular,
unless it's a side effect of automatically generating the file or
something.

-- 
Russ Allbery (r...@debian.org)   <http://www.eyrie.org/~eagle/>

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

[Guillem Jover]

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
> conformance with the new[2] standard[3].
> 
> However, in doing so, I encountered some use cases that are not covered
> by this standard.  Happily, all of them triggered lintian warnings as
> well, which gives me a framework within which to present my problems.
> 
> The attached debian/copyright file may also illuminate these matters.

I think all your concerns are already mostly covered by the spec,
except notably for the license namespacing.

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 long as they are all for the same license, etc.
I even coalesce copyright years for the same owner. See for example
the libbsd copyright file, being more fine-grained would be madness
IMO. And it is my understanding that ftpmasters find this to be fine.

So instead of going over all your fine points, I've taken the liberty
instead to fix the copyright file in what I'd consider to be correctly
formatted; in two ways, first following the original spirit, of very
detailed listing, and then another condensed one which is what I'd
have done. They are incremental patches over your original one.

Thanks,
Guillem
diff --git a/debian/copyright b/debian/copyright
index 92365ec..5101554 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,46 +1,164 @@
-Package: xtrs
-Obtained from: http://www.tim-mann.org/trs80/xtrs-4.9c.tar.gz
-   http://www.tim-mann.org/trs80faq.html
-Upstream authors: David Gingold, Alec Wolman, Timothy Mann
-Debian package author: Branden Robinson
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: xtrs
+Source: http://www.tim-mann.org/xtrs.html
+Disclaimer: Requires non-DFSG-free ROM images and/or operating systems
+ to be useful for most purposes.
+ .
+ There is a freely-licensed boot ROM for Model 4P emulation provided with xtrs;
+ however, this boot image can only be used to boot an operating system designed
+ for the Model 4 (it is not sophisticated enough to load the BASIC interpreter
+ ROM for Model III compatiblity mode, provided on Model 4P TRSDOS disks as a
+ file called MODELA/III).  Since most users will likely be using this emulator
+ to run proprietary legacy applications for the TRS-80 computers, I do not
+ regard this exception as sufficient to recategorize xtrs for inclusion in main.
+ .
+ It is worth keeping an eye on projects like Contiki and FUZIX; if one of them
+ becomes useful under xtrs, that would be an argument for moving xtrs to main.
+ + http://www.contiki-os.org/
+ + https://github.com/EtchedPixels/FUZIX
 
-Debian copyright notice and license terms:
+Files: *
+Copyright: 1998 Timothy Mann
+License: Timothy-Mann-xtrs-permissive-non-copyleft
 
-Unless otherwise noted, all independently copyrightable modifications and
-additions to xtrs found in its Debian packages bear the following copyright
-and license terms:
+Files:
+ ChangeLog
+ Makefile
+ cassette
+ cassette.man
+ cassette.sh
+ cassette.txt
+ cpmutil.html
+ crc.c
+ do6.jcl
+ dskspec.html
+ expall.bas
+ fakerom.lst
+ fakerom.z80
+ hex2cmd.man
+ hex2cmd.txt
+ m1format.fix
+ mkdisk.man
+ mkdisk.txt
+ reed.h
+ trs_chars.c
+ utility.jcl
+ xtrs.man
+ xtrs.txt
+Copyright: no explicit notices
+License: Timothy-Mann-xtrs-permissive-non-copyleft
+Comment:
+ I (Branden Robinson) presume them to be under Tim Mann's license (see below).
+ Some of them are plainly derived from others (such as cassette.txt from
+ cassette.man), and some may have been written by other people (e.g.,
+ cassette.sh was written by me, albeit obviously a it's a sort of
+ transliteration of cassette [csh]).
 
-Copyright 1998-2006, 2008 Branden Robinson
+Files:
+ cd.ccc
+ mount.ccc
+ pwd.ccc
+ truedam.ccc
+ umount.ccc
+ unix.ccc
+ xtrs8.lst
+ xtrs8.z80
+ xtrshard.lst
+ xtrshard.z80
+ xtrsmous.lst
+ xtrsmous.z80
+Copyright: 1998 Timothy Mann
+License: Timothy-Mann-xtrs-permissive-non-copyleft
 
-This software may be copied, modified, and used for any purpose
-without fee, provided that (1) the above copyright notice is
-retained, and (2) modified versions are clearly marked as having
-been modified, with the modifier's name and the date included.
+Files:
+ cmd.c
+ cmd.h
+ hex2cmd.c
+ trs_disk.c
+ trs_disk.h
+ trs_imp_exp.c
+ trs_imp_exp.h
+ trs_interrupt.c
+Copyright: 1996 Timothy Mann
+License: Timothy-Mann-xtrs-permissive-non-copyleft
 
-Original copyright notice and license terms:
+Files:
+ cmddump.c
+ load_cmd.c
+ load_cmd.h
+ mkdisk.c
+Copyright: 1996-98 Timothy Mann
+License: Timothy-Man

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

[Jonas Smedegaard]

Quoting Paul Wise (2014-09-19 05:46:12)
 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 least it's very clear how an 
 autoconf-output-stripped tarball is going to be built.

 We should be moving towards this:

 Pristine upstream tarballs.
 
 Build tools automatically removing generated files (including 
 autotools files) and unmodified 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 if we do not 
even bother to register what it is?

If some copyright and licensing need no verbatim copy verbatim copy of 
its copyright information and distribution license, I believe that 
should be explicitly stated in Debian Policy §12.5 (and I guess that's 
also what ftpmasters would need for changing their current practise).


 - Jonas

-- 
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

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

[Jonathan Dowland]

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 support for this, but in short: at
present, upstream tarball repacking is a relatively uncommon thing,
which means DDs have to dust the cobwebs off their mental manual (or
the actual manual) every time they either have to repack an upstream
source or interact with a repacked source. This is one of many things
which contribute to making Debian packaging complex and tricky for
newcomers.

If we repacked every tarball as a matter of course, then our
procedures are simpler: we've reduced the branching factor by one.

If we repacked by default then some of the things we'd like to do
with repacking, but put off because it's not worth repacking for
them alone, such as getting rid of some of the autoconf/automake
cruft (which is ignored/overwritten by use of dh-autoreconf etc.)
might be more widespread.

-- 
Jonathan Dowalnd


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140920213516.GA5577@debian

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

[Jonathan Dowland]

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 pristine source tarball if possible”.

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 least it's very clear how an
autoconf-output-stripped tarball is going to be built.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140918062638.GB27586@debian

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

[Jonathan Dowland]

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
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?


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140918062833.GA29551@debian

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

[David Prévot]

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 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”)? Having
uscan making it easier to repack upstream tarball when it is *actually*
sensible shouldn’t be a good excuse to repack every upstream tarball by
default just because it’s easy…

Regards

David



signature.asc
Description: OpenPGP digital signature

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

[Paul Wise]

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 least it's very clear how an
 autoconf-output-stripped tarball is going to be built.

We should be moving towards this:

Pristine upstream tarballs.

Build tools automatically removing generated files (including
autotools files) and unmodified embedded code copies (including
autotools related files, m4 macros etc).

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6ebnstktznzzynwtsmrwa2roaqffya2nk9dezcysd8...@mail.gmail.com

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

[Andreas Tille]

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
 mention time required to fill in the Files-Excluded field.

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.)

Kind regards

 Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140915145119.ge6...@an3as.eu

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

[Andrey Rahmatullin]

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 of interest:  Is there any reason not to use uscan?
For upstreams not using git I already have the new tarball downloaded
before I start working on it. uscan just doesn't have a place in my
workflows, it is necessary only when working on random packages from other
people.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

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

[Stefano Zacchiroli]

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 before doing that --- so better ask here directly and
let others know than forget about this :)

Is debamake's implementation of this feature based on the same corpus of
well-known license paragraphs than that mentioned in this thread
earlier on? If so, I'd say that it would be best not to scatter that
corpus of information in multiple places, as divergences might be quite
annoying.

Or is debmake only comparing past debian/copyright declarations by the
maintainer with the licenses it can currently infer from the upstream
package? That would be tremendous help for the maintainer, but it's a
different issue than the one we are discussing here.

Finally, it's great that debmake can help maintainer with this, but
unfortunately that won't help maintainers which are not using debmake.
Given that lintian is a tool that all maintainers are supposed to use
(and also a tool for which we have a project-wide monitoring
infrastructure at lintian.d.o), I believe it'd be much better to
integrate in lintian these warnings, than to have them emitted by
various tools which are opt-in for individual maintainers.

That said, I'll definitely start playing with debmake -k on my own
packages and see how it goes :-)
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

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

[Michael Gilbert]

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 hugeness of
autotools diff is more often than not rather burdensome.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANTw=MPBCrq5J8yTvkQm1eHnwv6tM=VCnDoQpWn2EQ=08xu...@mail.gmail.com

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

[Jonas Smedegaard]

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 file in line with the actual practice and not to contradict
 with the DEP-5 policy.

 The general rule of thumb appears to be that, provided that the files 
 are DFSG-free and don't pose any surprises or conflicts, there's no 
 need to exhaustively document any source files that are only used as 
 part of the build system and don't contribute code to the binary 
 package.
 
 I've wanted to document this explicitly in Policy for a while, but the 
 blocker is that I've never been able to get anyone to commit to a 
 clear enough rule that it felt like something we could put in Policy.  
 For example, I'm not sure if it applies to the build system in 
 general, or if it's specifically for Autoconf, Automake, Libtool, and 
 friends, which have very well-known and standard license behavior and 
 are common across vast swaths of the archive.
 
 If we had a concrete rule, we could document it in Policy.
 
 Personally, I just document the licenses of all of those files in my 
 debian/copyright files, but I also automated that (with a truly awful 
 and horrible Perl script).  And I'm not sure that documentation is 
 really of much use.

I do the same: document all those licenses in debian/copyright.  And 
also noticed a strong pattern of those files when doing that across 
maybe 50 packages.

How about - instead of codifying into Polict that some licensing is ok 
to ignore (which sounds very wrong to me) we instead recognize that some 
pattern of files are very commonly the same across packages: Add a DEP-5 
snippet to /usr/share/common-licenses that is always assumed included in 
debian/copyright of any package.

Concretely I propose the attached file for that.


 - Jonas

-- 
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Files: lt*.m4
Copyright: 2004-2005,2007-2009, Free Software Foundation
License: GAP

Files: aclocal.m4
 config.guess
 config.sub
 compile
 depcomp
 missing
Copyright: Free Software Foundation, Inc.
License: GPL-2+ with Autoconf exception
 As a special exception to the GNU General Public License, if you
 distribute this file as part of a program that contains a
 configuration script generated by Autoconf, you may include it under
 the same distribution terms that you use for the rest of that program.

Files: ltmain.sh
 libtool.m4
Copyright: Free Software Foundation, Inc.
License: GPL-2+ with Libtool exception
 As a special exception to the GNU General Public License, if you
 distribute this file as part of a program or library that is built
 using GNU Libtool, you may include this file under the same
 distribution terms that you use for the rest of that program.

Files: configure
Copyright: Free Software Foundation, Inc.
License: GAP~configure

Files: install-sh
Copyright: X Consortium
License: Expat~X with X exception
 Except as contained in this notice, the name of the X Consortium shall
 not be used in advertising or otherwise to promote the sale, use or
 other dealings in this Software without prior written authorization
 from the X Consortium.

License: GPL-2+
 This program is free software; you can redistribute it and/or modify it
 under the terms of the GNU General Public License as published by the
 Free Software Foundation; either version 2, or (at your option) any
 later version.
 .
 This program is distributed in the hope that it will be useful, but
 WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 General Public License for more details.
Comment:
 On Debian systems the 'GNU General Public License' version 2 is located
 in '/usr/share/common-licenses/GPL-2'.
 .
 You should have received a copy of the 'GNU General Public License'
 along with this program.  If not, see http://www.gnu.org/licenses/.

License: Expat~X
 Permission is hereby granted, free of charge, to any person obtaining a
 copy of this software and associated documentation files (the
 Software), to deal in the Software without restriction, including
 without limitation the rights to use, copy, modify, merge, publish,
 distribute, sublicense, and/or sell copies of the Software, and to
 permit persons to whom the Software is furnished to do so, subject to
 the following conditions:
 .
 The above copyright notice and this permission notice shall be included
 in all copies or substantial portions of the Software.
 .
 THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 MERCHANTABILITY, FITNESS

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

[Stefano Zacchiroli]

On Wed, Sep 10, 2014 at 10:01:42AM +0200, Jonas Smedegaard wrote:
 How about - instead of codifying into Polict that some licensing is ok 
 to ignore (which sounds very wrong to me) we instead recognize that some 
 pattern of files are very commonly the same across packages: Add a DEP-5 
 snippet 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-containedness of copyright information, which is a
nice property to have.  (To some extent we already violate that property
by shipping some full license texts under /usr/share/common-licenses/,
but at least the information about the mapping file-license names is
currently expected to be available in the packages themselves.)

How about using your snippet to improve our packaging work-flows
instead? For instance, we can have a lintian check that verifies if
those files are present in the source package and emit a warning if they
are not listed (with the correct license) in debian/copyright.

Note that, thanks to the semantics of DEP-5, it is possible to do this
properly and avoid false positives also in the few cases where the files
are present in the source package but do not need explicit mention
(e.g., because their license matches the more general license of the
rest of the package).

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

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

[Osamu Aoki]

Hi,

On Wed, Sep 10, 2014 at 10:20:06AM +0200, Stefano Zacchiroli wrote:
 How about using your snippet to improve our packaging work-flows
 instead? For instance, we can have a lintian check that verifies if
 those files are present in the source package and emit a warning if they
 are not listed (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, --kludge
 compare the debian/copyright file with the source and exit.

 The debian/copyright file must be organized to list the generic
 file patterns before the specific exceptions.

 ·   -k: basic output style

 ·   -kk: verbose output style

It will most likely give you a nice list of such files noting changes of
license and missing licenses.

I am wondering if it is really useful or not for the case of
auto-generated permissive files.  If dropping those files is the
accepted standard behavior (even if it is not codified after this
discussion), I am thinking of dropping those files from the emitted
default output list of -k and template copyright file it generates
unless specifically asked.

Osamu

PS: 
The copyright phrase parser of the debmake command is much tighter than
the licensecheck (in perl) one.


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140910144838.GB8886@goofy.local

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

[Osamu Aoki]

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
config.guess
compile
py-compile
missing
- GPL-2+
+ GPL-2.0+ with autoconf exception

Pattern #00: *
  File: ltmain.sh
- GPL-2+
+ GPL-2.0+ with libtool exception

Pattern #00: *
  File: icons/Makefile.am
data/Makefile.am
- GPL-2+
+ LGPL-2.0+

Pattern #00: *
  File: install-sh
- GPL-2+
+ MIT

Pattern #00: *
  File: m4/intlmacosx.m4
m4/lib-prefix.m4
m4/po.m4
m4/ltoptions.m4
po/Makefile.in.in
src/Makefile.in
m4/Makefile.in
config.rpath
icons/Makefile.in
Makefile.in
aclocal.m4
m4/lt~obsolete.m4
m4/gettext.m4
setup/Makefile.in
m4/ltsugar.m4
m4/ltversion.m4
m4/lib-link.m4
m4/iconv.m4
m4/nls.m4
m4/lib-ld.m4
data/Makefile.in
configure
m4/progtest.m4
INSTALL
m4/libtool.m4
- GPL-2+
+ PERMISSIVE

Pattern #00: *
  File: po/zh_CN.po
po/ko.po
- GPL-2+
+ _SAME_

... Maybe I need to update some of my old packages but that is a lot of
thankless work...

Osamu


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140910145441.GA11298@goofy.local

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

[Andrey Rahmatullin]

On Mon, Sep 08, 2014 at 07:31:02PM -0400, Michael Gilbert wrote:
  DEP-5 as defined in  http://dep.debian.net/deps/dep5/ does not have any
  clause allowing us to skip license entries for certain class of files.
 
  In practice, many packages lack entries for autotools generated files
  which come 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 exception
   * compile
   * depcomp
   * missing
   * py-compile
   * test-driver
   * m4/introspection.m4
   * m4/intltool.m4
  GPL-2.0+ with libtool exception
   * ltmain.sh
  GPL-3.0+ with autoconf exception
   * config.sub
   * config.guess
  MIT
   * install-sh
 You could always use the Files-Excluded field to make uscan remove
 those files from the upstream tarball, 
Too much work (at least when you are not repacking the tarball for other
reasons) for absolutely no gain.


-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140909124044.ga20...@belkar.wrar.name

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

[Michael Gilbert]

On Tue, Sep 9, 2014 at 8:40 AM, Andrey Rahmatullin wrote:
 You could always use the Files-Excluded field to make uscan remove
 those files from the upstream tarball,
 Too much work (at least when you are not repacking the tarball for other
 reasons) for absolutely no gain.

Not sure how that's 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? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANTw=mnsnyjinwj7znpd9pmev+mrz+tso2da8j1awodhyne...@mail.gmail.com

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

[David Prévot]

Hi,

Le 09/09/2014 17:40, Michael Gilbert a écrit :
 On Tue, Sep 9, 2014 at 8:40 AM, Andrey Rahmatullin wrote:

 You could always use the Files-Excluded field to make uscan remove
 those files from the upstream tarball,
 Too much work (at least when you are not repacking the tarball for other
 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*
upload packages with a pristine source tarball if possible”.

https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#repackagedorigtargz

Regards

David



signature.asc
Description: OpenPGP digital signature

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

[Russ Allbery]

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 and not to contradict
 with the DEP-5 policy.

The general rule of thumb appears to be that, provided that the files are
DFSG-free and don't pose any surprises or conflicts, there's no need to
exhaustively document any source files that are only used as part of the
build system and don't contribute code to the binary package.

I've wanted to document this explicitly in Policy for a while, but the
blocker is that I've never been able to get anyone to commit to a clear
enough rule that it felt like something we could put in Policy.  For
example, I'm not sure if it applies to the build system in general, or if
it's specifically for Autoconf, Automake, Libtool, and friends, which have
very well-known and standard license behavior and are common across vast
swaths of the archive.

If we had a concrete rule, we could document it in Policy.

Personally, I just document the licenses of all of those files in my
debian/copyright files, but I also automated that (with a truly awful and
horrible Perl script).  And I'm not sure that documentation is really of
much use.

 ( I think the following must not be skipped.)
 (  LGPL-2.0+)
 (  * m4/vapigen.m4  )

I think it's fine to skip that as well if one skips any of this, since it
doesn't pose any more license issues than any of the rest of the files you
list.  (Actually, it probably just converts to GPL-2 or GPL-3 for the
purposes of generating the build system, given the license of the source
of the rest of the output files to which it contributes.)

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq9c6qf6@hope.eyrie.org

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

[Charles Plessy]

Le Mon, Sep 08, 2014 at 08:12:01PM +0200, Jonas Smedegaard a écrit :
 
 Quoting Osamu Aoki (2014-09-08 17:38:41)
  DEP-5 as defined in http://dep.debian.net/deps/dep5/ does not have any 
  clause allowing us to skip license entries for certain class of files.
 
 I believe the problem is not DEP-5 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 this flexibility.

Note that for the M4 macros, some do not come from the autotools system, and
while one may find packages in the Debian archive where the license and
copyright of these files has been omitted, my gut feeling is that it is not
compliant with the FTP team's views on the debian/copyright file.

But the best is that you ask for a first-hand recommendation from the FTP
team.  If you get an answer, you are welcome to forward it to #462996 or
open a new bug so that we can reflect it in the Policy.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140910044423.gc24...@falafel.plessy.net

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

[Andrey Rahmatullin]

On Tue, Sep 09, 2014 at 05:40:46PM -0400, Michael Gilbert wrote:
  You could always use the Files-Excluded field to make uscan remove
  those files from the upstream tarball,
  Too much work (at least when you are not repacking the tarball for other
  reasons) for absolutely no gain.
 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.

 One benefit is less time on copyright file research/review, and
People actually check licenses for autotools generated files?

 another clear benefit is reduced package cruft.
The only thing that is reduced is the size of the orig tarball.

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140910044822.gb29...@belkar.wrar.name

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

[Osamu Aoki]

Hi,

DEP-5 as defined in  http://dep.debian.net/deps/dep5/ does not have any
clause allowing us to skip license entries for certain class of files.

In practice, many packages lack entries for autotools generated files
which come 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 exception
 * compile
 * depcomp
 * missing
 * py-compile
 * test-driver
 * m4/introspection.m4
 * m4/intltool.m4
GPL-2.0+ with libtool exception
 * ltmain.sh
GPL-3.0+ with autoconf exception
 * config.sub
 * config.guess
MIT
 * install-sh

( I think the following must not be skipped.)
(  LGPL-2.0+)
(  * m4/vapigen.m4  )

FTP master people seem not to worry such loose practice of drop listing
them.

This gap between policy and practice is the problem for tools handling
it.

My debmake package is one of it.  It helps to
 * create the template copyright file and 
 * check the previous copyright file against the updated source tree.
Currently my debmake package pedantically lists and requires them per
policy; and generates the long template copyright file.(*1)

By having such useless entries per policy is not really useful for the
license compliance check purpose and requires extra editorial work for
no real benefit.  (More noise!)

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 and not to contradict
with the DEP-5 policy.

Regards,

Osamu

(*1) The ibus package used the debmake and lists such files.


signature.asc
Description: Digital signature

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

[Michael Gilbert]

On Mon, Sep 8, 2014 at 11:38 AM, Osamu Aoki wrote:
 Hi,

 DEP-5 as defined in  http://dep.debian.net/deps/dep5/ does not have any
 clause allowing us to skip license entries for certain class of files.

 In practice, many packages lack entries for autotools generated files
 which come 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 exception
  * compile
  * depcomp
  * missing
  * py-compile
  * test-driver
  * m4/introspection.m4
  * m4/intltool.m4
 GPL-2.0+ with libtool exception
  * ltmain.sh
 GPL-3.0+ with autoconf exception
  * config.sub
  * config.guess
 MIT
  * install-sh

You could always use the Files-Excluded field to make uscan remove
those files from the upstream tarball, then use dh-autoreconf (or
symlinks for e.g. config.sub and config.guess) to recover them at
build time.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANTw=mm2lqhhckiejq4q7qj+ethi3uuxmor9s9hfvtoyhfc...@mail.gmail.com

Re: Copyright arrangements for a web project

[Ian Jackson]

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 the embargo).
 
 This may or may not be something you’d want to consider.

Of course if one's on the inside one can prepare one's fixes in
advance, and deploy them when the embargo expires.

Whether requiring things to be done that way depends, I guess, on
whether security or fairness (vis-a-vis people not on the inside
of the embargo system) is more important.

Ian.


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21169.44464.383066.903...@chiark.greenend.org.uk

Re: Copyright arrangements for a web project

[Thorsten Glaser]

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 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 the embargo).

This may or may not be something you’d want to consider.

HTH  HAND,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20131216t152210-...@post.gmane.org

Re: Copyright arrangements for a web project

[Paul Tagliamonte]

On Thu, Dec 12, 2013 at 11:57:59AM -0500, Paul Tagliamonte wrote:
 I'd very very much prefer to do something like this for my Debian work,
 even so far as to say that it can be used under the terms of any DFSG
 free license - but I'm also perfectly cool to use {,A,L}GPL-{2,3}+ for my
 work as well.
 
 I trust Debian with license freeness, and I do also trust SPI as well.
 I'd be happy to allow them to relicense my work, or even give a list of
 licenses that it can be used under.

[Stripping SPI]

It's a snowey day, and I had a small bit of time to hack something up
(I've not thought about 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 the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version 2
 * of the License, or (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  
02110-1301, USA.
 *
 * 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. Examples of DFSG free licenses include the GPL,
 * LGPL, AGPL, Apache 2, MIT/Expat, or CDDL. */


Now, if we want to also allow permissive use of the code is another thing, but
I really don't mind (and use Expat enough already), so I'm clearly fine with
language like this.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte paul...@debian.org  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Copyright arrangements for a web project

[Jakub Wilk]

* 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. Examples of DFSG free licenses include 
the GPL, LGPL, AGPL, Apache 2, MIT/Expat, or CDDL.


How is your meta-license better than existing permissive licenses? I 
wish people didn't invent new (meta-)licenses needlessly. :/


Also, don't forget that GPLv7 will be non-free, so you shouldn't include 
versionless GPL on your list. :


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131215153222.ga1...@jwilk.net

Re: Copyright arrangements for a web project

[Bill Allombert]

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. 

But it is probably not the right venue to discuss the AGPLv3.
   
   Perhaps not.  But I don't want to use debian-legal whose focus is
   on DFSG compatibility and whose on-list consensus judgements don't
   always seem to align with the actual decisions of those responsible
   for these judgements within Debian.
  
  Why do you assume I do ?
 
 I'm sorry to have apparently offended you.  I didn't intend to imply
 that you had suggested debian-legal.  It seemed to me that
 debian-legal was an obvious possible place for this conversation and I
 was explaining why I chose not to use it.

Sorry, I just wanted to warn you that I was far from having the majority
opinion in Debian. (We need to fix debian-legal, but this is another
story.)

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131214200947.GB29751@yellowpig

Re: Copyright arrangements for a web project

[Ian Jackson]

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 for the project I'm thinking of.[1]
 
 I suggest you search in debian-vote. But I do not want to stir old grudge.

I guess you are referring to this
  https://lists.debian.org/debian-vote/2009/11/msg0.html
and the related threads.  Thanks for the reference, I had forgotten
that.  I will re-read that thread and consider what you and others
have written.

  Nevertheless your opinion is interesting to me [...]
 
 [explanations]

Thanks for that.

   But it is probably not the right venue to discuss the AGPLv3.
  
  Perhaps not.  But I don't want to use debian-legal whose focus is
  on DFSG compatibility and whose on-list consensus judgements don't
  always seem to align with the actual decisions of those responsible
  for these judgements within Debian.
 
 Why do you assume I do ?

I'm sorry to have apparently offended you.  I didn't intend to imply
that you had suggested debian-legal.  It seemed to me that
debian-legal was an obvious possible place for this conversation and I
was explaining why I chose not to use it.

Thanks again for your considered responses.

This kind of opposition to the AGPL is certainly not irrelevant to me.
Even though I'm still personally a fan of the AGPL, having seen again
these arguments (and seen that it's still considered a problem by
reasonable people) I'm probably not going to recommend it to the
project I mentioned in my head article.

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21162.65147.830714.695...@chiark.greenend.org.uk

Copyright arrangements for a web project

[Ian Jackson]

(This is a bit off-topic for the Debian list; I hope people won't mind
me asking opinions here though.)

I'm being asked for advice on encouraging contributions by the people
behind a couple of community-ish websites which I use regularly.
There's a lot of work to be done to improve the attractiveness to
contributors, and one of the things that needs fixing is the
licensing.

It's my view that a community software project ought to use a copyleft
licence nowadays.  But two questions arise:

* 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 as licence steward ?

  What instructions/directions would SPI take ?  The goal would have
  to include the SPI Board making the value judgement, not just
  deferring to the project's leadership - that is, the SPI Board would
  make the decision itself in what it sees as the interests of the
  project and the free software community.

* Should the project give the licence steward the power to change the
  public licence unilaterally in the future 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 to
  the licence steward.  Can this be achieved by some text in the
  standard licence rubric eg

This program is free software: you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation, version 3, or (at your
option) any other general public free software licence publicly
endorsed for PROJECT by Software in the Public Interest Inc
(i.e. SPI is a proxy as described in s14 of the GNU GPLv3 but SPI
is not limited to endorsing only future versions of the GNU GPL).

  (Along presumably with some Signed-off-by system for contributions.)

* 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 thinking of here is a Ruby on Rails
  application.)  What are people's feelings about AGPLv3 ?

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21161.52163.626205.267...@chiark.greenend.org.uk

Re: Copyright arrangements for a web project

[Joshua D. Drake]

On 12/12/2013 06:44 AM, Ian Jackson wrote:


(This is a bit off-topic for the Debian list; I hope people won't mind
me asking opinions here though.)

I'm being asked for advice on encouraging contributions by the people
behind a couple of community-ish websites which I use regularly.
There's a lot of work to be done to improve the attractiveness to
contributors, and one of the things that needs fixing is the
licensing.

It's my view that a community software project ought to use a copyleft
licence nowadays.  But two questions arise:

* 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 as licence steward ?


What do you mean steward? If you are asking if we should guide them to 
use the GPLv3, I would vote against that. SPI (as a corporation) should 
not value what Free Software license over another.


If you are asking if we could be the entity that the license denotes as 
the licensor, I don't see a problem with that.




   What instructions/directions would SPI take ?  The goal would have
   to include the SPI Board making the value judgement, not just
   deferring to the project's leadership - that is, the SPI Board would
   make the decision itself in what it sees as the interests of the
   project and the free software community.


I don't think this is a board decision. I think we should empower 
members within a committee to make those decisions.




* Should the project give the licence steward the power to change the
   public licence unilaterally in the future 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 ?


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 assignment ala FSF, 
Canonical, MySQL.




   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

 This program is free software: you can redistribute it and/or
 modify it under the terms of the GNU General Public License as
 published by the Free Software Foundation, version 3, or (at your
 option) any other general public free software licence publicly
 endorsed for PROJECT by Software in the Public Interest Inc
 (i.e. SPI is a proxy as described in s14 of the GNU GPLv3 but SPI
 is not limited to endorsing only future versions of the GNU GPL).



I think this re-defines the point of a license. What I read that to say 
is, if I want to use project X, I can use it as any license that project 
X likes or GPLv3. However, I am a BSD License advocate, if project X 
doesn't like BSD (even though it is a Free license), I can't use it? 
That is bogus. I would let the standard license terms stand on their own.




   (Along presumably with some Signed-off-by system for contributions.)

* 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 thinking of here is a Ruby on Rails
   application.)  What are people's feelings about AGPLv3 ?


It is a license. I don't have feelings about it one way or another. 
However, as I noted earlier. I do not think it is SPI's responsibility 
to prefer any Free license over another.


JD

--
Command Prompt, Inc. - http://www.commandprompt.com/  509-416-6579
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc
For my dreams of your image that blossoms
   a rose in the deeps of my heart. - W.B. Yeats


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52a9d619.7010...@commandprompt.com

Re: Copyright arrangements for a web project

[Eitan Adler]

On Thu, Dec 12, 2013 at 9:44 AM, Ian Jackson
ijack...@chiark.greenend.org.uk 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 as licence steward ?

On this I can not comment.

   What instructions/directions would SPI take ?  The goal would have
   to include the SPI Board making the value judgement, not just
   deferring to the project's leadership - that is, the SPI Board would
   make the decision itself in what it sees as the interests of the
   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 an entity other than the author to
change the requirements under which the software may be used.  I'd be
wary, but would not object entirely.

 This program is free software: you can redistribute it and/or
 modify it under the terms of the GNU General Public License as
 published by the Free Software Foundation, version 3, or (at your
 option) any other general public free software licence publicly
 endorsed for PROJECT by Software in the Public Interest Inc
 (i.e. SPI is a proxy as described in s14 of the GNU GPLv3 but SPI
 is not limited to endorsing only future versions of the GNU GPL).

It is my understanding that one would not be allowed to modify the GPL
preamble because it falls under the copyrighted text.  One may be
allowed to add a preamble to the entirety of the GPL.

 * 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 thinking of here is a Ruby on Rails
   application.)  What are people's feelings about AGPLv3 ?

It is the least-free license currently approved by the OSI.


-- 
Eitan Adler


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAF6rxg=AYDJBd5McwzYkD1jSEYc4eerB7ffEv3uiN=i99nf...@mail.gmail.com

Re: Copyright arrangements for a web project

[Paul Tagliamonte]

On Thu, Dec 12, 2013 at 02:44:19PM +, Ian Jackson wrote:
 (This is a bit off-topic for the Debian list; I hope people won't mind
 me asking opinions here though.)
 
 I'm being asked for advice on encouraging contributions by the people
 behind a couple of community-ish websites which I use regularly.
 There's a lot of work to be done to improve the attractiveness to
 contributors, and one of the things that needs fixing is the
 licensing.
 
 It's my view that a community software project ought to use a copyleft
 licence nowadays.  But two questions arise:
 
 * 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 as licence steward ?
 
   What instructions/directions would SPI take ?  The goal would have
   to include the SPI Board making the value judgement, not just
   deferring to the project's leadership - that is, the SPI Board would
   make the decision itself in what it sees as the interests of the
   project and the free software community.
 
 * Should the project give the licence steward the power to change the
   public licence unilaterally in the future 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 to
   the licence steward.  Can this be achieved by some text in the
   standard licence rubric eg
 
 This program is free software: you can redistribute it and/or
 modify it under the terms of the GNU General Public License as
 published by the Free Software Foundation, version 3, or (at your
 option) any other general public free software licence publicly
 endorsed for PROJECT by Software in the Public Interest Inc
 (i.e. SPI is a proxy as described in s14 of the GNU GPLv3 but SPI
 is not limited to endorsing only future versions of the GNU GPL).
 
   (Along presumably with some Signed-off-by system for contributions.)

This is the approach KDE takes (I saw this in NEW a few times) - 

/
| Copyright year  name of author e-mail
| 
| This program is free software; you can redistribute it and/or
| modify it under the terms of the GNU General Public License as
| published by the Free Software Foundation; either version 2 of
| the License or (at your option) version 3 or any later version
| accepted by the membership of KDE e.V. (or its successor approved
| by the membership of KDE e.V.), which shall act as a proxy 
| defined in Section 14 of version 3 of the license.
| 
| This program is distributed in the hope that it will be useful,
| but WITHOUT ANY WARRANTY; without even the implied warranty of
| MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
| GNU General Public License for more details.
| 
| You should have received a copy of the GNU General Public License
| along with this program.  If not, see http://www.gnu.org/licenses/.
\

I'd very very much prefer to do something like this for my Debian work,
even so far as to say that it can be used under the terms of any DFSG
free license - but I'm also perfectly cool to use {,A,L}GPL-{2,3}+ for my
work as well.

I trust Debian with license freeness, and I do also trust SPI as well.
I'd be happy to allow them to relicense my work, or even give a list of
licenses that it can be used under.

 * 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 thinking of here is a Ruby on Rails
   application.)  What are people's feelings about AGPLv3 ?

I like it a lot.

 Thanks,
 Ian.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte paul...@debian.org  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Copyright arrangements for a web project

[Ian Jackson]

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 as licence steward ?
 
 What do you mean steward? If you are asking if we should guide them to 
 use the GPLv3, I would vote against that. SPI (as a corporation) should 
 not value what Free Software license over another.
 
 If you are asking if we could be the entity that the license denotes as 
 the licensor, I don't see a problem with that.

I mean that SPI would fulfil the role of the proxy as described in
GPLv3 s14.

 What instructions/directions would SPI take ?  The goal would have
 to include the SPI Board making the value judgement, not just
 deferring to the project's leadership - that is, the SPI Board would
 make the decision itself in what it sees as the interests of the
 project and the free software community.
 
 I don't think this is a board decision. I think we should empower 
 members within a committee to make those decisions.

If SPI doesn't already have such a committee it would be silly to
create one just for this.  In the past difficult decisions relating to
SPI's copyright or trademark legal powers have been taken by the
board.

Or to put it another way: the purpose of a committee is be delegated
by the board to deal with what would otherwise be an excessive
workload by the board.  This advantage has no relevance if the work
needs to be done very rarely.  And leaving matters with the board
would provide a greater degree of political robustness because the
board are directly elected.

 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 assignment ala FSF, 
 Canonical, MySQL.

Have you read GPLv3 s14 ?  Do you contend that my proposal below is
legally ineffective somehow ?

 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
 
   This program is free software: you can redistribute it and/or
   modify it under the terms of the GNU General Public License as
   published by the Free Software Foundation, version 3, or (at your
   option) any other general public free software licence publicly
   endorsed for PROJECT by Software in the Public Interest Inc
   (i.e. SPI is a proxy as described in s14 of the GNU GPLv3 but SPI
   is not limited to endorsing only future versions of the GNU GPL).
...
 I think this re-defines the point of a license. What I read that to say 
 is, if I want to use project X, I can use it as any license that project 
 X likes or GPLv3. However, I am a BSD License advocate, if project X 
 doesn't like BSD (even though it is a Free license), I can't use it? 
 That is bogus. I would let the standard license terms stand on their own.

I have no idea what you're saying here.  What I intend for this is the
same thing as GPLv3 s14 but also allowing the project to transtion to
a completely different licence if that becomes desirable in the
future.

If everyone who contributes to the project provides a Signed-off-by (a
la the Linux kernel), and thereby licences their contribution under
the terms I quote, then if the licence steward approves a new licence
then everyone automatically has the rights granted under the new
licence.  The licence change would have to be accompanied by a change
to the rubric, to mention the new licence instead of the GPLv3; that
way the new versions of the project are available only under the new
licence.

The decision to adopt a new licence would hopefully in practice be
made within the project but because the clause mentions SPI, it would
need to be rubber-stamped by SPI (and SPI would resolve any dispute).

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21161.62056.698522.952...@chiark.greenend.org.uk

Re: Copyright arrangements for a web project

[Ian Jackson]

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 (and
if they aren't, then we can probably write a licence exception).
(The main program I'm thinking of here is a Ruby on Rails
application.)  What are people's feelings about AGPLv3 ?
 
 It is the least-free license currently approved by the OSI.

Just out of interest, would you describe the GPLv3 as less free than
the MIT licence ?

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21161.62154.22521.479...@chiark.greenend.org.uk

Re: Copyright arrangements for a web project

[Bill Allombert]

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 thinking of here is a Ruby on Rails
   application.)  What are people's feelings about AGPLv3 ?

I am fine with the stated purpose of the AGPLv3, however I do not think the
actual implementation is compatible with free software.

There have been no official clarification how the AGPLv3 is supposed to work in 
a lot 
of situation and how it is compatible with the plain reading of the license.
Without them, I am wary of declaring the AGPL a free software license.
There is a world of difference between the actual text of the AGPLv3 and how it
is advertised.

But it is probably not the right venue to discuss the AGPLv3.

Cheers,
Bill.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131212172049.GA10425@yellowpig

Re: Copyright arrangements for a web project

[Ian Jackson]

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 Software Foundation, version 3, or (at your
  option) any other general public free software licence publicly
  endorsed for PROJECT by Software in the Public Interest Inc
  (i.e. SPI is a proxy as described in s14 of the GNU GPLv3 but SPI
  is not limited to endorsing only future versions of the GNU GPL).
  
(Along presumably with some Signed-off-by system for contributions.)
 
 This is the approach KDE takes (I saw this in NEW a few times) - 

Thanks for the report:

 | This program is free software; you can redistribute it and/or
 | modify it under the terms of the GNU General Public License as
 | published by the Free Software Foundation; either version 2 of
 | the License or (at your option) version 3 or any later version
 | accepted by the membership of KDE e.V. (or its successor approved
 | by the membership of KDE e.V.), which shall act as a proxy 
 | defined in Section 14 of version 3 of the license.

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.

 I trust Debian with license freeness, and I do also trust SPI as well.
 I'd be happy to allow them to relicense my work, or even give a list of
 licenses that it can be used under.

Debian is ill set up to make this decision for other people,
unfortunately.  You'd have to nominate someone in particular.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21162.473.222657.569...@chiark.greenend.org.uk

Re: Copyright arrangements for a web project

[Ian Jackson]

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.
 
  Just out of interest, would you describe the GPLv3 as less free than
  the MIT licence ?
 
 Yes: there are more restrictions using GPLv3 software than when using
 MIT software.  I fear we may be getting into a license flamewar so I
 shall only discuss further off-list.

I have heard views such as yours before.  I don't think it's necessary
to go into them in any more detail so we can save everyone the
flamewar.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21162.532.6724.212...@chiark.greenend.org.uk

Re: Copyright arrangements for a web project

[Eitan Adler]

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 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 thinking of here is a Ruby on Rails
application.)  What are people's feelings about AGPLv3 ?

 It is the least-free license currently approved by the OSI.

 Just out of interest, would you describe the GPLv3 as less free than
 the MIT licence ?

Yes: there are more restrictions using GPLv3 software than when using
MIT software.  I fear we may be getting into a license flamewar so I
shall only discuss further off-list.


-- 
Eitan Adler


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAF6rxg=0gxjo0tCuZO6b+61jZH_HMxcoDwwwggohGz9PV-=t...@mail.gmail.com

Re: Copyright arrangements for a web project

[Paul Tagliamonte]

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 Debian software headers something to the effect of
granting folks the right to relicense under any license the ftp-masters
consider DFSG free. Of course, this leads to a documentation problem, as
I don't think there's a canoincal list. Either way, doing that leads to
new legal language, which I'm not keen to force (but would be happy to
use)

  I trust Debian with license freeness, and I do also trust SPI as well.
  I'd be happy to allow them to relicense my work, or even give a list of
  licenses that it can be used under.
 
 Debian is ill set up to make this decision for other people,
 unfortunately.  You'd have to nominate someone in particular.

Indeed, but the de-jure team that handles this is the ftp-master team,
which I'd be happy to hand control of my code's licensing to. Doubly so
for Debian-related work. Of course, they can be overruled by the
developer body, but saying anything that's been deemed DFSG free by the
project would be good enough for me :)

 Thanks,
 Ian.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte paul...@debian.org  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Copyright arrangements for a web project

[Bill Allombert]

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 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 for the project I'm thinking of.[1]

I suggest you search in debian-vote. But I do not want to stir old grudge.

 Nevertheless your opinion is interesting to me because I want to know
 what people in general think of the AGPL.  So if you have concerns
 that would apply to such a project, which you think are more clearly
 expressed or more relevant to me than those I've already seen, I'd be
 interested to know.

Basically, there are three free software roles:
- Running the software
- Changing the software
- Distributing the software
FSF freedom 0 states that 'Running the software' is not regulated.
Standard free software licenses only regulate 'Distributing the software'. The
AGPL clause regulates 'Changing the software' in a quite ambiguous way.

The problem is that these three roles can be held by three different entities
and having the entity 'Changing the software' liable for the action of the
two other is unfair and dangerous. What happens if the entity 'Running the
software' uses a reverse web proxy that removes all reference to the original
project and source code, dynamically from the HTTP stream ?

 FYI the project is a substantial database-backed web application,
 whose infrastructure could easily accomodate a copy of its own source
 code, and with which users interact via web browsers and email.

Philosophically, I hold that the right to reuse code for completely 
unrelated purposes is part of the libre software definition.
A license being suitable for some applications but not others is not free
in that sense. 

  But it is probably not the right venue to discuss the AGPLv3.
 
 Perhaps not.  But I don't want to use debian-legal whose focus is
 on DFSG compatibility and whose on-list consensus judgements don't
 always seem to align with the actual decisions of those responsible
 for these judgements within Debian.

Why do you assume I do ?

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131212235040.GB13826@yellowpig

Re: Copyright assignement for Debian tools?

[Stefano Zacchiroli]

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 copyright assignment. Hence I've just asked on the
 spi-general mailing list if that is something the organization is
 interested in supporting. I'll let you know if I hear back of anything
 actionable; in the mean time you can follow the discussion there.

The thread is at
http://lists.spi-inc.org/pipermail/spi-general/2013-February/003156.html

In essence, at present there is no standardized mechanisms to assign
copyright (or enter into specific licensing agreements, e.g. to delegate
SPI the power to do license enforcement and/or relicensing) to SPI. My
inquiry has raised some interest in the matter and things might change
in the future, but they are not there yet.

There are entities using copyright notices Copyright (c) SPI... (as we
do in our website), but the validity of that practice is dubious. I'm
myself skeptical it would do any good when it really comes to needing
it, but IANAL.

Bottom line: sorry Thomas, not much help at the moment. But thanks to
your inquiry things might change in the future. (And might change faster
if someone interested and knowledgeable on these matters will join SPI
and help out.)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Copyright assignement for Debian tools?

[Ian Jackson]

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 any sense in this. 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...)

I see.

 Do you have any advise for code that originates in the Debian project?

Well, I would advise you to retain your copyright and publish your
code under a suitable licence.  Ie write

  Copyright (C)2013 Thomas Koch

  This program is free software: you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation, either version 3 of the License, or
  (at your option) any later version.

  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.

  You should have received a copy of the GNU General Public License
  along with this program.  If not, see http://www.gnu.org/licenses/.

But if you don't want to do that, you do have the possibility to
assign it to Software in the Public Interest.  I'm not sure how the
law works exactly in your jurisdiction but in the UK and the US to do
that you need state it in writing.  Something like:

  Written/modified by Thomas Koch, 2013.

  I hereby assign my copyright in Gnomovision (all past and future
  versions) to Software in the Public Interest, Inc.
  - Thomas Koch 21 Feb 2013

  Copyright (C)2013 Software in the Public Interest, Inc

  This program is free software: you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation, either version 3 of the License, or
  (at your option) any later version.

  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.

  You should have received a copy of the GNU General Public License
  along with this program.  If not, see http://www.gnu.org/licenses/.

NB that in your jurisdiction it might be necessary to write something
on paper or something, but in the UK and the US AFAICT writing it in a
computer file is sufficient.

SPI doesn't encourage you to do this.  But they do promise what they
will do with the copyright if you choose to disregard that advice:
  http://www.spi-inc.org/corporate/resolutions/1998/1998-11-16.iwj.2/
See s3 of that resolution in particular.

Ian.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20774.14706.554495.804...@chiark.greenend.org.uk

Re: Copyright assignement for Debian tools?

[Thijs Kinkhorst]

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) meaning?

I do not think such claims are invalid: when there's a clear definition of
what The Foo Developers means (e.g., it's expanded in a central README
file), then its nothing more than a shorthand for the set of people
claiming copyright on the work. The actual, legal copyright is in the
hands of the people the string expands to.

In the case at hand, you could indeed add Copyright 2013 Debian Project
but because that doesn't expand to a clear set of legal rights holders, I
believe this would not have the desired effect, namely that a single legal
entity owns the copyright which then has the possibility to make decisions
on that copyright.


Cheers,
Thijs


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/f344cfd64e5c9d2358e26806e5afa481.squir...@aphrodite.kinkhorst.nl

Re: Copyright assignement for Debian tools?

[Russ Allbery]

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* copyright statements are close to legally meaningless.  The only
truly important thing that one has to do with copyright statements in
Debian is to retain them as required by the license.  (Many licenses
explicitly require that you retain the copyright notice.)  We also ask
that people copy them into debian/copyright so that we have clear
documentation of who upstream claims are the copyright holders.

In all countries that are signatories of Berne (which is essentially all
of them), no copyright notice is required and copyright is held by the
author (or the person who contracts the work for hire) regardless of any
copyright notice.  The only purpose that copyright notices are permitted
to serve under the Berne convention is that they can affect damages in the
event of a lawsuit.  In the event of a lawsuit, I suspect that a judge
would take a look at whether the copyright notice was clear for that
purpose.  (In the US, the primary legal purpose the copyright notice
serves is to pre-empt a defense of innocent infringement.)

See http://uscode.house.gov/download/pls/17C4.txt for all the gory details
in the US.  Each other country probably has its own version of the law,
and they're probably all at least slightly different (sometimes
significantly different in countries with a stronger moral rights
doctrine than the United States).

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gme90n7@windlord.stanford.edu

Re: Copyright assignement for Debian tools?

[Stefano Zacchiroli]

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 at large. For many, copyright assignments to trusted,
transparent, and non-profits entities is a good thing, because: 1/ it
makes licensing enforcements easier in court, and 2/ allow to switch
between free software licenses (or even only decide whether you want to
move to an or later version of a license or not) downstream even in
case of dramatic events like the death of copyright holders. This is the
reason why entities like FSF and KDE e.V. offer the possibility of
centralizing copyright ownership.

In essence: YMMV. But it seems to me that we are by no mean near a point
where, in the public debate on FOSS policies, it is well established
whether this specific kind of copyright assignment is good or bad.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Copyright assignement for Debian tools?

[Thomas Koch]

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 much rather like to write Copyright 2013 The Debian Project. 
(Actually I'm totally annoyed by anything related to copyright...)

Do you have any advise for code that originates in the Debian project?

CC-ing debian-java but this discussion might be best for debian-project.

If you think that it makes sense to identify the original author of some code: 
there is still the @author annotation in many languages. And the best thing is 
to use the appropriate tool for exactly this: git blame (or git praise!).

Regards,

Thomas Koch, http://www.koch.ro


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201302091724.3.tho...@koch.ro

Re: Copyright assignement for Debian tools?

[Stefano Zacchiroli]

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 sense in this. 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...)
 
 Do you have any advise for code that originates in the Debian project?

In essence, you're asking for some sort of volunteer copyright
assignment (or more likely contributor licensing agreement), similar to
what KDE e.V. offers to contributors of the KDE project, see
http://ev.kde.org/rules/fla.php

Those kind of agreements are entirely optional and interesting for
contributors like you, who don't want to care about copyright related
matter and empower trusted 3rd party entities to take care of them
(e.g. for licensing enforcements if/when the need arises).

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 copyright assignment. Hence I've just asked on the spi-general
mailing list if that is something the organization is interested in
supporting. I'll let you know if I hear back of anything actionable; in
the mean time you can follow the discussion there.

Thanks for raising this topic!
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Copyright assignement for Debian tools?

[Brian Gupta]

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
 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 much rather like to write Copyright 2013 The Debian Project.
 (Actually I'm totally annoyed by anything related to copyright...)

 Do you have any advise for code that originates in the Debian project?

 In essence, you're asking for some sort of volunteer copyright
 assignment (or more likely contributor licensing agreement), similar to
 what KDE e.V. offers to contributors of the KDE project, see
 http://ev.kde.org/rules/fla.php

 Those kind of agreements are entirely optional and interesting for
 contributors like you, who don't want to care about copyright related
 matter and empower trusted 3rd party entities to take care of them
 (e.g. for licensing enforcements if/when the need arises).

 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 copyright assignment. Hence I've just asked on the spi-general
 mailing list if that is something the organization is interested in
 supporting. I'll let you know if I hear back of anything actionable; in
 the mean time you can follow the discussion there.

 Thanks for raising this topic!

Zack,

It may also be worth reaching out to the Software Freedom Conservancy
if this turns out to be out of scope for SPI
http://sfconservancy.org/members/current/ (If I recall the SFLC helped
get them off the ground, and they were founded to own projects that
weren't a good fit for the FSF's GNU project).

-Brian

 Cheers.
 --
 Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
 Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
 Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
 « the first rule of tautology club is the first rule of tautology club »


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cacfairw6bhc+yctg78wfynzmnkkf_t7hjowaaixqas+hmk-...@mail.gmail.com

Re: Copyright assignement for Debian tools?

[Stefano Zacchiroli]

On Sat, Feb 09, 2013 at 01:00:27PM -0500, Brian Gupta wrote:
 It may also be worth reaching out to the Software Freedom Conservancy
 if this turns out to be out of scope for SPI
 http://sfconservancy.org/members/current/ (If I recall the SFLC helped
 get them off the ground, and they were founded to own projects that
 weren't a good fit for the FSF's GNU project).

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 SF Conservancy, for various good reasons,
adopt a more exclusive model than SPI. They generally do not welcome
projects that have assets (of various kinds) scattered throughout
different organizations, which is the case for Debian. This has been a
blocker in the past. It *might* 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!

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Copyright assignement for Debian tools?

[Russ Allbery]

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 SF Conservancy, for various good reasons,
 adopt a more exclusive model than SPI. They generally do not welcome
 projects that have assets (of various kinds) scattered throughout
 different organizations, which is the case for Debian. This has been a
 blocker in the past.

Doesn't Debian as a whole also have nearly as many assets as all other
projects in the Software Freedom Conservancy put together?  It may not be
healthy for them to take on Debian, as we could fairly easily turn into
the tail that wags the dog.  I think they mostly deal with much smaller
projects than we are.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txpls39q@windlord.stanford.edu

Re: Copyright assignement for Debian tools?

[Stefano Zacchiroli]

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 are due to the fact they have employees
(for the orga itself or on behalf of affiliated projects), revenues from
court settlement, etc. Both SPI and SFC are very transparent in their
budgets, so anyone can check the actual numbers.

... here we're getting off-topic I suspect :)

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Copyright assignement for Debian tools?

[Charles Plessy]

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 of my latest packages, I simply make no
mention of copyright for my contributions, so that they are distributed under
the same terms as the whole.

Cheers,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130209223343.gb17...@falafel.plessy.net

Re: Copyright assignement for Debian tools?

[Jonathan Carter (highvoltage)]

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 would happen if I 
do that? Would the package get rejected? Is it possible for an entity 
like Debian to gain copyright to something if it's more or less unknowingly?


-Jonathan


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51171c10.9070...@ubuntu.com

Re: Copyright assignement for Debian tools?

[Russ Allbery]

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 for the licensing
 of packaging that's intended to go into Debian. What would happen if I
 do that? Would the package get rejected? Is it possible for an entity
 like Debian to gain copyright to something if it's more or less
 unknowingly?

I'm not sure what the ftp-team would do, but that statement is basically
legally meaningless.  It doesn't change the fact that you personally hold
the copyright, it doesn't give anyone in Debian (or Software in the Public
Interest) the ability to defend the license in court... it basically has
the same amount of effect as putting the moon is made of green cheese in
your packaging.  (There may be some impact on seeking statutory damages in
countries like the US where damages can change based on the presence of a
copyright notice, but that's pretty much an edge case.)

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878v6woj5e@windlord.stanford.edu

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

[Charles Plessy]

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 format. I have installed the tool in Ubuntu OS. I want to clarify
 that Debian OS has some tool to generate/Convert to SPDX Format. I have
 .txt file with me. Need to generate it in SPDX Format.

Dear Mohamed

I do not think the following tools are available in Debian,
but perhaps you will find something useful in http://git.spdx.org/

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121118115948.gd8...@falafel.plessy.net

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

[Tapio Lehtonen]

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 SPDX format. I have installed the tool in Ubuntu OS. I want to clarify
 that Debian OS has some tool to generate/Convert to SPDX Format. I have
 .txt file with me. Need to generate it in SPDX Format.
 
 Could anyone please help me on this issue.
 

The mailing list Debian-project is for Discussion about non-technical
topics related to the Debian Project. Send your question to
debian-user. But can you not use the same tool as in Ubuntu? What tool
is that? Have you read http://wiki.debian.org/SPDX

 
 
 Thanks and Regards,
 Mohamed Fazil
 +91-9900584136

-- 
Tapio Lehtonen
tapio.lehto...@iki.fi
http://www.iki.fi/tapio.lehtonen


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121108080400.ga2...@taleman.fi

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

[Thomas Koch]

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 listmas...@lists.debian.org
Archive: http://lists.debian.org/201211081042.46744.tho...@koch.ro

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

[Mohamed Fazil]

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
that Debian OS has some tool to generate/Convert to SPDX Format. I have
.txt file with me. Need to generate it in SPDX Format.

Could anyone please help me on this issue.



Thanks and Regards,
Mohamed Fazil
+91-9900584136

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

[Stefano Zacchiroli]

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 contact for further information:
   Charles Plessy ple...@debian.org
[…]
 Change controller:
   The Debian Project http://www.debian.org

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 proper credit to who worked on the application), I
think it'd be better to have as contact point some role address of
sort. What do you think?

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

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

[Charles Plessy]

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 ple...@debian.org
 […]
  Change controller:
  The Debian Project http://www.debian.org
 
 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 proper credit to who worked on the application), I
 think it'd be better to have as contact point some role address of
 sort. What do you think?

Hi Stefano and debian-policy@lists.d.o subscribers,

I was wondering about the same, but I was worried that having a
broad-readership mailing list as a contact point would create confusion about
who is expected to answer.  How about debian-policy@lists.d.o ?  It is anyway
the contact point for the specification itself.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120911074152.ga20...@falafel.plessy.net

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

[Andreas Tille]

On Mon, Sep 10, 2012 at 04:45:53PM -0700, Russ Allbery wrote:
 
   - About security, the discussion on debian-devel leads me to think that
   there is no need to worry.  I included a short comment suggesting that
   field values should be sanitised as usual.  Does anybody see other
   potential 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 in a previous mail the attacker is the same person (group of
persons) who writes debian/copyright *and* all the other packaging stuff
- so he would attack himself.

Just my 2 Eurocents

 Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120911075026.gc14...@an3as.eu

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

[Stefano Zacchiroli]

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 proper credit to who worked on the application), I
  think it'd be better to have as contact point some role address of
  sort. What do you think?
 
 Hi Stefano and debian-policy@lists.d.o subscribers,
 
 I was wondering about the same, but I was worried that having a
 broad-readership mailing list as a contact point would create confusion about
 who is expected to answer.  How about debian-policy@lists.d.o ?  It is anyway
 the contact point for the specification itself.

Hi again Charles,
  in fact the above is a typo of mine :-). debian-*policy*@lists.d.o is
in fact what I wanted to propose. Sorry for the confusion.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature