On Mon, May 10, 2021 at 2:18 PM Alexander Mazuruk wrote:
> I'm writing this as I've noticed that some packages have copyright file
> filled with records for source code, while the package contains binaries.
Essentially all packages in Debian do this, with a couple of
exceptions where the maintain
Alexander> I wanted to get some clarification as I couldnt find this
Alexander> info via googling/debian pages (but I might've missed
Alexander> something obvious, if so - I'd appreciate pointing me in
Alexander> right direction on what should i read)
Under section 2.4 of debian
Hello,
I'm writing this as I've noticed that some packages have copyright file
filled with records for source code, while the package contains binaries.
I've CCd maintainer of one of such packages (bsdutils)
I wanted to get some clarification as I couldnt find this info via
googling/debian p
[ Note the cross-posting... ]
Hi debian-legal,
The COPYING.md file of rdma-core [1] says: "Refer to individual files
for information on the copyright holders." but some files (e.g.
ibacm/man/ibacm.1) do not specify a copyright holder. The copyright
holder grants the user additional rights by putt
On Mon, 26 Oct 2015 23:06:25 +0100
Francesco Poli wrote:
> On Fri, 23 Oct 2015 12:13:52 +1100 Riley Baird wrote:
>
> [...]
> > But even if the person who wrote a program wrote it in such a way that
> > it was unreasonably difficult to understand (something which is very
> > unlikely), then we mu
On Fri, 23 Oct 2015 12:13:52 +1100 Riley Baird wrote:
[...]
> But even if the person who wrote a program wrote it in such a way that
> it was unreasonably difficult to understand (something which is very
> unlikely), then we must say that that, even though no better form of
> modification ever exi
> > Being insecure shouldn't be a reason for a program to be declared
> > non-free, but being unreasonably difficult to understand should be.
>
> Not if the program is difficult to understand even for its
> maintainers...
A program will never be *unreasonably* difficult to understand for its
main
On Tue, 20 Oct 2015 18:17:31 +1100 Riley Baird wrote:
> On Mon, 19 Oct 2015 22:43:59 +0200
> Francesco Poli wrote:
>
> > On Mon, 19 Oct 2015 11:00:19 +1100 Riley Baird wrote:
> >
> > [...]
> > > We can declare that the source did exist, but it doesn't anymore.
> >
> > I don't think so.
>
> Wh
On Mon, 19 Oct 2015 22:43:59 +0200
Francesco Poli wrote:
> On Mon, 19 Oct 2015 11:00:19 +1100 Riley Baird wrote:
>
> [...]
> > We can declare that the source did exist, but it doesn't anymore.
>
> I don't think so.
Why not? "The preferred form of modification among those that have
existed" is
On Mon, 19 Oct 2015 11:00:19 +1100 Riley Baird wrote:
[...]
> We can declare that the source did exist, but it doesn't anymore.
I don't think so.
>
> People use open-source software for a variety of reasons. Some people
> use it for security reasons. Auditing a program where all copies of the
>
> > > One completely different thing is when nobody has some form of
> > > the work any longer. That form cannot be preferred for making
> > > modifications, since it no longer exists. In this case, the actual
> > > source is the preferred form for making modifications, among the
> > > existing one
On Thu, 15 Oct 2015 08:57:47 +0900 Charles Plessy wrote:
> Le Wed, Oct 14, 2015 at 11:47:02PM +0200, Francesco Poli a écrit :
> >
> > I am personally convinced that nowadays the definition of source should
> > *no longer* be regarded as an open question: I think that the most
> > commonly used an
On Thu, 15 Oct 2015 09:12:21 +0200 Ole Streicher wrote:
[...]
> Yes, this is a nice summary. Thank you very much;
You're welcome!
> would it be possible
> to add it somewhere to Debian (Wiki or so?)
I tend to avoid the Debian Wiki, because it is a licensing mess: almost
nobody cares about addin
On Thu, 15 Oct 2015 09:02:08 +0200 Vincent Bernat wrote:
> ❦ 15 octobre 2015 10:26 +1100, Ben Finney :
[...]
> > There are many cases that are clarified by that
> > definition, to the point of clear resolution.
>
> The recent discussions on debian-devel@ shows that not everybody agree
> with th
On Thu, 15 Oct 2015 09:50:06 +1100 Riley Baird wrote:
> On Wed, 14 Oct 2015 23:47:02 +0200
> Francesco Poli wrote:
[...]
> > For further details on what I think about the definition of source,
> > anyone interested may read my essay:
> > http://www.inventati.org/frx/essays/softfrdm/whatissource.h
Charles Plessy writes ("Re: Source files"):
> sorry for drifting that thread further... I can not help adding
> that, the world being in perpetual change, the definition of source
> will one day become an open question again. My favorite guess is
> that at some point, it w
Paul Wise writes:
> On Mon, Oct 12, 2015 at 5:49 PM, Ole Streicher wrote:
>
> > https://bugs.debian.org/798900
>
> FYI folks: the outcome of this bug report is that the jQuery
> dataTables plugin has been packaged properly and built from source
> properly using the upstream build system.
Great
On Mon, Oct 12, 2015 at 5:49 PM, Ole Streicher wrote:
> For one of my packages (python-astropy), I got a Lintian error that it
> would contain a non-source file jquery.dataTables.js. This is mainly
> discussed in a bug report
>
> https://bugs.debian.org/798900
FYI folks: the outcome of this bug
Ángel González writes:
> On 15/10/15 00:50, Riley Baird wrote:
>> On Wed, 14 Oct 2015 23:47:02 +0200
>> Francesco Poli wrote:
>>
>>> The alternatives you propose are vague at best.
>>>
>>> For further details on what I think about the definition of source,
>>> anyone interested may read my essay:
❦ 15 octobre 2015 10:26 +1100, Ben Finney :
>> > I am personally convinced that nowadays the definition of source
>> > should *no longer* be regarded as an open question: I think that the
>> > most commonly used and accepted definition of source code is the one
>> > found in the GNU GPL license.
On Thu, 15 Oct 2015 16:05:39 +1100
Ben Finney wrote:
> Riley Baird
> writes:
>
> > Okay, I guess that handling problematic cases by consensus works too.
> > We can intuitively state what is and what is not source in practically
> > all cases, even if we can't give a reason for it.
>
> We shoul
Riley Baird
writes:
> Okay, I guess that handling problematic cases by consensus works too.
> We can intuitively state what is and what is not source in practically
> all cases, even if we can't give a reason for it.
We should be able to give good reason for it, we certainly should not
rely on i
On Thu, 15 Oct 2015 10:26:47 +1100
Ben Finney wrote:
> Riley Baird
> writes:
>
> > On Wed, 14 Oct 2015 23:47:02 +0200
> > Francesco Poli wrote:
> >
> > > I am personally convinced that nowadays the definition of source
> > > should *no longer* be regarded as an open question: I think that the
Le Wed, Oct 14, 2015 at 11:47:02PM +0200, Francesco Poli a écrit :
>
> I am personally convinced that nowadays the definition of source should
> *no longer* be regarded as an open question: I think that the most
> commonly used and accepted definition of source code is the one found
> in the GNU G
On 15/10/15 00:50, Riley Baird wrote:
On Wed, 14 Oct 2015 23:47:02 +0200
Francesco Poli wrote:
The alternatives you propose are vague at best.
For further details on what I think about the definition of source,
anyone interested may read my essay:
http://www.inventati.org/frx/essays/softfrdm/
Riley Baird
writes:
> On Wed, 14 Oct 2015 23:47:02 +0200
> Francesco Poli wrote:
>
> > I am personally convinced that nowadays the definition of source
> > should *no longer* be regarded as an open question: I think that the
> > most commonly used and accepted definition of source code is the on
On Wed, 14 Oct 2015 23:47:02 +0200
Francesco Poli wrote:
> On Wed, 14 Oct 2015 20:43:31 +1100 Riley Baird wrote:
>
> > > What I meant here is that you should explain a bit what you consider a
> > > source and what not
> >
> > This question comes up in so many discussions, we really need to hav
On Wed, 14 Oct 2015 20:43:31 +1100 Riley Baird wrote:
> > What I meant here is that you should explain a bit what you consider a
> > source and what not
>
> This question comes up in so many discussions, we really need to have a
> definition that we can all live with, record it somewhere and the
> What I meant here is that you should explain a bit what you consider a
> source and what not
This question comes up in so many discussions, we really need to have a
definition that we can all live with, record it somewhere and then move
on.
I can think of several ideas:
1. Source code must not
On 14.10.2015 10:35, Bastien Roucaries wrote:
Le 14 octobre 2015 08:51:16 GMT+02:00, Ole Streicher a
écrit :
I am not a specialist at all for Javascript, and all I try is just
to keep a Python package (with a very responsive upstream!) in a
good shape. Unfortunately, nobody with Javascript exp
Le 14 octobre 2015 08:51:16 GMT+02:00, Ole Streicher a
écrit :
>
>
>Am 13.10.2015 um 22:23 schrieb Walter Landry:
>> Ole Streicher wrote:
>>> Walter Landry writes:
Ole Streicher wrote:
> What are the general guidelines here? Somewhere in written form?
>The
> DFSG does not contai
Am 13.10.2015 um 22:23 schrieb Walter Landry:
> Ole Streicher wrote:
>> Walter Landry writes:
>>> Ole Streicher wrote:
What are the general guidelines here? Somewhere in written form? The
DFSG does not contain a hint here.
>>> The rule of thumb that I have seen applied is that 'sourc
Ole Streicher wrote:
> Walter Landry writes:
>> Ole Streicher wrote:
>>> What are the general guidelines here? Somewhere in written form? The
>>> DFSG does not contain a hint here.
>>
>> The rule of thumb that I have seen applied is that 'source' is the
>> preferred form of modification for the
> Charles Plessy writes:
> >
> > Maybe the long line was machine-generated at the beginning, but it does not
> > matter anymore.
Le Tue, Oct 13, 2015 at 10:12:07AM +0200, Ole Streicher a écrit :
>
> Why not? If I take the GPL definition, the question is not whether it is
> actual (and, BTW, als
Charles Plessy writes:
> Maybe the long line was machine-generated at the beginning, but it does not
> matter anymore.
Why not? If I take the GPL definition, the question is not whether it is
actual (and, BTW, also not whether it is automatically generated) but
what "is preferred" (holy passive)
Ben Finney writes:
> Ole Streicher writes:
>> However, it contains one line
>> /*globals $, jQuery,define,_fnExternApiFunc,[...]
>> which is ~1400 characters long and may be automatically inserted.
>
> I would say the test of whether a file is source is whether it can be
> described as “the prefe
Walter Landry writes:
> Ole Streicher wrote:
>> What are the general guidelines here? Somewhere in written form? The
>> DFSG does not contain a hint here.
>
> The rule of thumb that I have seen applied is that 'source' is the
> preferred form of modification for the people making modifications.
>
Le Mon, Oct 12, 2015 at 11:49:03AM +0200, Ole Streicher a écrit :
>
> For one of my packages (python-astropy), I got a Lintian error that it
> would contain a non-source file jquery.dataTables.js. This is mainly
> discussed in a bug report
>
> https://bugs.debian.org/798900
>
> however it seems
Ole Streicher writes:
> However, it contains one line
>
> /*globals $, jQuery,define,_fnExternApiFunc,[...]
>
> which is ~1400 characters long and may be automatically inserted.
If it's automatically inserted into that file, that seems to entail the
resulting file is not the source but is instea
Ole Streicher wrote:
> What are the general guidelines here? Somewhere in written form? The
> DFSG does not contain a hint here.
The rule of thumb that I have seen applied is that 'source' is the
preferred form of modification for the people making modifications.
If a person really prefers editin
Hi,
For one of my packages (python-astropy), I got a Lintian error that it
would contain a non-source file jquery.dataTables.js. This is mainly
discussed in a bug report
https://bugs.debian.org/798900
however it seems that the problem is more general. The python-astropy
package indeed contains a
"Giacomo A. Catenazzi" writes:
> Ben Finney wrote:
>
> > Too often, though, such files are a set of license *terms* only
> > (e.g. the text of the GPL), with no copyright status or explicit
> > *grant* of license. That's not enough for Debian to know the
> > rights of recipients: mere inclusion
* Giacomo A. Catenazzi [090320 10:08]:
> >Too often, though, such files are a set of license *terms* only (e.g.
> >the text of the GPL), with no copyright status or explicit *grant* of
> >license. That's not enough for Debian to know the rights of
> >recipients: mere inclusion of license terms is
Ben Finney wrote:
[note: quotations in random order]
(We're now in ‘debian-legal’ territory; please follow up there.)
Too often, though, such files are a set of license *terms* only (e.g.
the text of the GPL), with no copyright status or explicit *grant* of
license. That's not enough for Deb
(We're now in ‘debian-legal’ territory; please follow up there.)
Dominik Smatana writes:
> One more "license-newbie" question:
>
> In some upstream source files there is just one single line comment at
> beginning:
>
> // Please see included LICENSE.TXT
&g
correct:
Manterola writes ("Re: 25+2 packages with (Glade) generated C source files
without the source"):
> On Sat, Aug 30, 2008 at 10:17 PM, Sami Liedes <[EMAIL PROTECTED]> wrote:
> > [ stuff ]
>
> No. .c files are still source code.
This is not correct. `Source c
On Sun, Aug 31, 2008 at 09:12:34AM +0200, Josselin Mouette wrote:
> I’m pretty sure many of the list are in similar cases. Now loading the
> UI directly into the application is the standard, but not so long ago
> people generated template code with glade and then edited it by hand.
> The .glade fil
On Sat, 2008-08-30 at 23:19 -0300, Margarita Manterola wrote:
> On Sat, Aug 30, 2008 at 10:17 PM, Sami Liedes <[EMAIL PROTECTED]> wrote:
> > The only questionable case I found
> > by this sampling is dia, where the file is "generated by Glade and
> > then hand-coded to make GNOME optional and add t
Le dimanche 31 août 2008 à 04:17 +0300, Sami Liedes a écrit :
> I went through some of these and checked them by hand, and generally
> couldn't find the glade project anywhere in the source tarball (it
> might be in the diff, I didn't check for that - would that BTW be OK,
> to have source code in
On Sat, Aug 30, 2008 at 10:17 PM, Sami Liedes <[EMAIL PROTECTED]> wrote:
> I grepped the source tarballs in Lenny (testing) main section for the
> note "DO NOT EDIT THIS FILE - it is generated by Glade." which
> indicates the file is generated using the Glade UI editor. Then I
> checked if these p
7;t filed bugs for any of these, save for tangogps which was the
first case I encountered and after which I got the idea to do this.
In addition to the cases I found in main, the packages easyspice and
gtktrain in contrib seem suspect too (but I didn't take such a close
look).
Øystein Gisnås wrote:
> I've gone through license considerations of RFP-marked package
> libbtctl lately, and have questions about two concerns:
>
> * 7 source files are have LGPL license in their headers, but link
> against bluez-libs, which is licensed under the GPL. On
Le jeudi 28 septembre 2006 à 05:01 +0200, Øystein Gisnås a écrit :
> I've gone through license considerations of RFP-marked package
> libbtctl lately, and have questions about two concerns:
>
> * 7 source files are have LGPL license in their headers, but link
> against
I've gone through license considerations of RFP-marked package
libbtctl lately, and have questions about two concerns:
* 7 source files are have LGPL license in their headers, but link
against bluez-libs, which is licensed under the GPL. One such file
ishttp://cvs.gnome.org/viewcvs/libbtct
On Fri, 29 Jul 2005 15:58:36 +0100 Andrew Suffield wrote:
> > Yes, I think it's time to propose a GR to do a s/program/work/ in
> > the DFSG. Since IANADD, I cannot propose GRs, but I hope that some
> > DDs will help.
>
> It's not quite that simple; you can't just change that bit alone. I'm
> w
On Thu, Jul 28, 2005 at 11:47:58PM +0200, Francesco Poli wrote:
> On Thu, 28 Jul 2005 15:00:29 +0100 Steve McIntyre wrote:
>
> > Florian Weimer wrote:
> [...]
> > >The GR did not change the wording of the DFSG at all. However, it's
> > >clear that a significant shift took place in SC interpretati
On Thu, 2005-07-28 at 20:08 -0700, Steve Langasek wrote:
> On Fri, Jul 29, 2005 at 12:44:26AM +, Brian M. Carlson wrote:
> > On Thu, 2005-07-28 at 15:15 +0100, Steve McIntyre wrote:
[argument of program vs. software]
> > If you are only looking at the DFSG, you are missing the point. The
> > p
On Fri, Jul 29, 2005 at 12:44:26AM +, Brian M. Carlson wrote:
> On Thu, 2005-07-28 at 15:15 +0100, Steve McIntyre wrote:
> > I'm arguing with your interpretation of "program" to mean anything you
> > want - in this case potentially any random string of bytes. That most
> > certainly _is_ new, a
On Thu, 2005-07-28 at 15:15 +0100, Steve McIntyre wrote:
> I'm arguing with your interpretation of "program" to mean anything you
> want - in this case potentially any random string of bytes. That most
> certainly _is_ new, and is completely bogus. As I said, propose a GR
> to change the wording s/
On Thu, 28 Jul 2005 15:00:29 +0100 Steve McIntyre wrote:
> Florian Weimer wrote:
[...]
> >The GR did not change the wording of the DFSG at all. However, it's
> >clear that a significant shift took place in SC interpretation, from
> >a foggy definition of "program" to a more dogmatic "everything w
O Xoves, 28 de Xullo de 2005 ás 16:19:02 +0200, Florian Weimer escribía:
> > I'm arguing with your interpretation of "program" to mean anything you
> > want - in this case potentially any random string of bytes.
> Why do you think this would change anything? Isn't this the
> assumption under whic
On 7/28/05, Andreas Barth <[EMAIL PROTECTED]> wrote:
> * Raul Miller ([EMAIL PROTECTED]) [050727 18:45]:
> > On 7/27/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > I'd prefer to approach this issue from a different direction.
> >
> > The point behind the DFSG is that we need to be able to solve
* Steve McIntyre:
>>Why do you think this would change anything? Isn't this the
>>assumption under which debian-legal operates in general? With a few
>>practical exceptions, of course (license texts, public key
>>certificates, etc.), but the general rule seems to be followed.
>
> What?
>
> I'm a
* Andreas Barth:
>> > I'm arguing with your interpretation of "program" to mean anything you
>> > want - in this case potentially any random string of bytes.
>
>> Why do you think this would change anything? Isn't this the
>> assumption under which debian-legal operates in general?
>
> Actually
On Thu, Jul 28, 2005 at 04:19:02PM +0200, Florian Weimer wrote:
>* Steve McIntyre:
>
>>>The interpretation I outlined is certainly not new. It reflects the
>>>current practice, and I think we're in a pretty good position as far
>>>as compliance is concerned. Even the notorious GNU FDL issue is no
* Florian Weimer ([EMAIL PROTECTED]) [050728 16:19]:
> * Steve McIntyre:
> >>The interpretation I outlined is certainly not new. It reflects the
> >>current practice, and I think we're in a pretty good position as far
> >>as compliance is concerned. Even the notorious GNU FDL issue is not a
> >>
* Steve McIntyre:
>>The interpretation I outlined is certainly not new. It reflects the
>>current practice, and I think we're in a pretty good position as far
>>as compliance is concerned. Even the notorious GNU FDL issue is not a
>>real problem here (beyond the invariant section business) -- th
Florian Weimer wrote:
>* Andreas Barth:
>
>>> It's clear from the context (and previous discussion) that this has to
>>> be interpreted as "software".
>>
>> I disagree with that. As there were "editorial changes" that had as
>> declared goal to replace any such places with the "real meaning", and
>
On Thu, Jul 28, 2005 at 04:08:09PM +0200, Florian Weimer wrote:
>* Steve McIntyre:
>
>> Please, no. We've already had long, tedious discussions about what
>> "software" means. Don't go trying to change the meaning of "program"
>> too. If you think that the places where we currently talk about
>> "p
* Steve McIntyre:
> Please, no. We've already had long, tedious discussions about what
> "software" means. Don't go trying to change the meaning of "program"
> too. If you think that the places where we currently talk about
> "program" are unclear and should say "software", then propose a GR to
>
* Andreas Barth:
>> It's clear from the context (and previous discussion) that this has to
>> be interpreted as "software".
>
> I disagree with that. As there were "editorial changes" that had as
> declared goal to replace any such places with the "real meaning", and
> this was not touched, it has
* Raul Miller ([EMAIL PROTECTED]) [050727 18:45]:
> On 7/27/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > Uh, I don't? I said that the other guidelines are *applicable* to
> > non-program works, and *should be applied* to non-program works -- not that,
> > as presently written, we are obliged
On 7/27/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Uh, I don't? I said that the other guidelines are *applicable* to
> non-program works, and *should be applied* to non-program works -- not that,
> as presently written, we are obliged to apply them to non-program works.
I'd prefer to approac
On Wed, Jul 27, 2005 at 12:28:23AM +0200, Francesco Poli wrote:
> On Tue, 26 Jul 2005 05:17:35 -0700 Steve Langasek wrote:
> > I think that clauses 6, 7, and 8 are applicable to documentation and
> > data as well as to programs, and I think that they're rules that
> > Debian should follow for ever
On Wed, 27 Jul 2005 00:28:23 +0200 Francesco Poli wrote:
[some hopefully useful contributions to the discussion, but with *wrong*
Mail-Followup-To:]
Please, ignore the wrong Mail-Followup-To: set in the my previous
message.
I forgot to disable it! :-(
I really really apologize.
Sylpheed authors
On Tue, 26 Jul 2005 05:17:35 -0700 Steve Langasek wrote:
> I think that clauses 6, 7, and 8 are applicable to documentation and
> data as well as to programs, and I think that they're rules that
> Debian should follow for everything we distribute.
>
> I think that clause 2 is *not* clearly applic
On Sat, Jul 23, 2005 at 01:01:07AM +0200, Florian Weimer wrote:
> * Steve Langasek:
> >> It's clear from the context (and previous discussion) that this has to
> >> be interpreted as "software".
> > No, it isn't. Considering we went through all the effort of a GR to amend
> > the DFSG and this s
On Sun, 24 Jul 2005 03:17:59 -0400 Nathanael Nerode wrote:
> My gut instinct is "no, it's fine, put it in main," because the
> compiler is not "required" by the system, since the system functions
> fine without recompiling the graphics (and will continue to). I may
> be wrong, though!
Huh?
Are
Andreas Barth wrote:
> > Obviously e.g. fonts are no programms, even if they are in main.
Read TrueType "instructions" and say that again! Some fonts are most
certainly programs.
PDFs are arguably executables designed for a PDF interpreter.
But let's not get into that again right now.
--
To
[EMAIL PROTECTED] wrote:
> However, when I found that (some of) the graphics had a source from which
they
> could be compiled, I concluded two things:
> - To satisfy the GPL, the source for those graphics needs to be distributed
as
> well, so it must be in the source package.
Probably correct.
On Sat, Jul 23, 2005 at 09:50:56AM -0700, Ken Arromdee wrote:
> On Sat, 23 Jul 2005, David Nusinow wrote:
> > This is true, but not because the driver isn't commented. It's because the
> > specs for the card have not been released, and as such we don't know what
> > the magic numbers mean. The hard
On Sat, Jul 23, 2005 at 10:40:36AM +0100, Matthew Garrett wrote:
> Machine generated assembly is, in general, significantly less modifiable
> than hand-written assembly.
And code in which information that the original coder inserted has been
removed is less modifiable than code written without th
On Sat, 23 Jul 2005, David Nusinow wrote:
> This is true, but not because the driver isn't commented. It's because the
> specs for the card have not been released, and as such we don't know what
> the magic numbers mean. The hardware specs are entirely external to the
> source code for the driver i
On Fri, Jul 22, 2005 at 11:28:54PM -0700, Michael K. Edwards wrote:
> On 7/22/05, Glenn Maynard <[EMAIL PROTECTED]> wrote:
> > In other words, we'll take something as source that we know isn't,
> > because we like nVidia. ...
>
> Hey, I didn't say I liked the idea myself. I'm just calling it lik
On Fri, 22 Jul 2005 18:09:56 -0400 Glenn Maynard wrote:
> On Fri, Jul 22, 2005 at 11:47:09PM +0200, Florian Weimer wrote:
[...]
> > I think it's not acceptable to yse pregenerated files to prevent
> > software from entering contrib. (Look at all the Java programs, for
> > instance.) If there's a
On Sat, 23 Jul 2005 07:29:19 -0400 Glenn Maynard wrote:
> You seem to be arguing that "preferred form for modification" is a
> poor definition of "source" based on the fact that it doesn't permit
> passing off obfuscated code (such as, perhaps, nVidia's) as "source",
> and that seems to me to be o
>> If upstreams sues you, the freedoms granted by the license texts don't
>> matter much. A court case is a great inconvenience, even if the
>> defendant wins in the end.
>
> Are you missing the point deliberately?
>
> The question was: if we have two examples of source code; one stripped
> of com
23.07.2005 pisze Florian Weimer ([EMAIL PROTECTED]):
> > What difference does upstream intent make to the freedoms that our users
> > receive?
> If upstreams sues you, the freedoms granted by the license texts don't
> matter much. A court case is a great inconvenience, even if the
> defendant w
* Matthew Garrett:
> On Sat, Jul 23, 2005 at 12:47:03PM +0200, Florian Weimer wrote:
>> * Matthew Garrett:
>> > How is one of these free and the other non-free?
>>
>> In the end, you have to take upstream intent into account. We already
>> do this when interpreting licenses (at least in one dire
On Sat, 23 Jul 2005 01:01:07 +0200 Florian Weimer wrote:
> * Steve Langasek:
>
> >> It's clear from the context (and previous discussion) that this has
> >> to be interpreted as "software".
> >
> > No, it isn't. Considering we went through all the effort of a GR to
> > amend the DFSG and this st
On Thu, 21 Jul 2005 21:15:12 -0400 Glenn Maynard wrote:
> I think it would be massive negligence for the project to accept as
> source something which it knows has been obfuscated. If that's the
> case, I'm rather disgusted. It's hard to take a project seriously
> which claims to require source,
On Sat, Jul 23, 2005 at 10:44:36AM +0100, Matthew Garrett wrote:
> Glenn Maynard <[EMAIL PROTECTED]> wrote:
> > One provided source, the other did not, and Debian considers having source
> > fundamental to having a free program.
>
> "Because it is, damnit"?
No, because one provided source, and th
On 20050723T013237+0100, Matthew Garrett wrote:
> So if I write C with comments and then remove them that's not DFSG free,
> but if I fail to add them in the first place then it's fine for main?
This is not a universally applicable rule, but:
When a good programmer writes uncommented code, it's u
On Sat, Jul 23, 2005 at 12:22:34AM +0100, Matthew Garrett wrote:
> Florian Weimer <[EMAIL PROTECTED]> wrote:
> > * Matthew Garrett:
> >
> >> There's two main issues here.
> >>
> >> 1) Does everything in main have to include the preferred form of
> >> modification?
> >>
> >> I don't believe so,
>
On Sat, Jul 23, 2005 at 11:24:12AM +0200, Andreas Barth wrote:
> * Glenn Maynard ([EMAIL PROTECTED]) [050723 11:15]:
> > (CC's trimmed.)
> > On Sat, Jul 23, 2005 at 09:21:04AM +0200, Andreas Barth wrote:
> > > > It's clear from the context (and previous discussion) that this has to
> > > > be inter
On Fri, Jul 22, 2005 at 03:47:41PM -0700, Steve Langasek wrote:
> On Fri, Jul 22, 2005 at 11:56:01PM +0200, Florian Weimer wrote:
> > * Andreas Barth:
> >
> > > Actually, the DFSG says:
> > > | 2. Source Code
> > > |
> > > | The program must include source code, and must allow distribution in
> >
On Sat, Jul 23, 2005 at 12:47:03PM +0200, Florian Weimer wrote:
> * Matthew Garrett:
> > How is one of these free and the other non-free?
>
> In the end, you have to take upstream intent into account. We already
> do this when interpreting licenses (at least in one direction), so I
> don't think
* Matthew Garrett:
> So say we have two drivers for a piece of hardware. One is written
> without comments. One was originally commented, but the comments have
> been removed. Both provide the same amount of information about how they
> work. Both are released under the same license. Both provide
Glenn Maynard <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote:
>> So say we have two drivers for a piece of hardware. One is written
>> without comments. One was originally commented, but the comments have
>> been removed. Both provide the same amount of
Jeff King <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote:
>
>> So say we have two drivers for a piece of hardware. One is written
>> without comments. One was originally commented, but the comments have
>> been removed. Both provide the same amount of
1 - 100 of 169 matches
Mail list logo