Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #10789 > unrolled thread

anti-tarball clause and GPL

Back to article view | Back to linux.debian.project

Contents

  anti-tarball clause and GPL Adam Borowski <kilobyte@angband.pl> - 2019-07-24 00:50 +0200
    Re: anti-tarball clause and GPL Jonathan Carter <jcc@debian.org> - 2019-07-24 01:30 +0200
    Re: anti-tarball clause and GPL Guillem Jover <guillem@debian.org> - 2019-07-24 02:20 +0200
      Re: anti-tarball clause and GPL Adam Borowski <kilobyte@angband.pl> - 2019-07-24 02:40 +0200
        Re: anti-tarball clause and GPL Scott Kitterman <debian@kitterman.com> - 2019-07-24 07:20 +0200
          Re: anti-tarball clause and GPL Adam Borowski <kilobyte@angband.pl> - 2019-07-25 18:50 +0200
            Re: anti-tarball clause and GPL Russ Allbery <rra@debian.org> - 2019-07-25 19:00 +0200
              Re: anti-tarball clause and GPL Michael Stone <mstone@debian.org> - 2019-07-25 19:20 +0200
              Re: anti-tarball clause and GPL Norbert Preining <preining@logic.at> - 2019-07-25 21:10 +0200
        Re: anti-tarball clause and GPL Simon McVittie <smcv@debian.org> - 2019-07-24 12:00 +0200
        Re: anti-tarball clause and GPL Ian Jackson <ijackson@chiark.greenend.org.uk> - 2019-07-28 15:40 +0200
          Re: anti-tarball clause and GPL Russ Allbery <rra@debian.org> - 2019-07-28 18:30 +0200
    Re: anti-tarball clause and GPL Yao Wei <mwei@debian.org> - 2019-07-24 03:00 +0200
      Re: anti-tarball clause and GPL Adam Borowski <kilobyte@angband.pl> - 2019-07-25 20:10 +0200
        Re: anti-tarball clause and GPL "Yao Wei (魏銘廷)" <mwei@debian.org> - 2019-07-26 03:50 +0200
    Re: anti-tarball clause and GPL Giacomo Catenazzi <cate@cateee.net> - 2019-07-24 10:20 +0200
    Re: anti-tarball clause and GPL Florian Weimer <fw@deneb.enyo.de> - 2019-07-24 22:30 +0200
      Re: anti-tarball clause and GPL Yao Wei <mwei@debian.org> - 2019-07-25 00:40 +0200
        Re: anti-tarball clause and GPL Norbert Preining <preining@logic.at> - 2019-07-25 21:10 +0200

#10789 — anti-tarball clause and GPL

Hi!
In the light of the currently discussed GR proposal, I wonder if the
following license clause would be considered DFSG-free and GPL-compatible:

##################
I do not consider a flat tarball to be a preferred form for modification. 
Thus, like any non-source form, it must be accompanied by a way to obtain
the actual form for modification.  There are many such ways -- unless you
distribute the software in highly unusual circumstances, a link to a
network server suffices; see the text of the GPL for further details.
##################

I believe such a statement would be GPL-compatible; rationale:
* by the 2011 Red Hat kernel sources outcry, it is obvious such a tarball
  is long obsolete
* a flat tarball deprives the recipient of features of modern VCSes
* comments giving rationale for a change tend to be written as VCS commit
  messages
* future forms are not banned: it is conceivable that next week someone
  invents a revolutionary new form that wins over git

Thoughts?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Latin:   meow 4 characters, 4 columns,  4 bytes
⣾⠁⢠⠒⠀⣿⡁ Greek:   μεου 4 characters, 4 columns,  8 bytes
⢿⡄⠘⠷⠚⠋  Runes:   ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes
⠈⠳⣄⠀⠀⠀⠀ Chinese: 喵   1 character,  2 columns,  3 bytes <-- best!

[toc] | [next] | [standalone]

#10791

On 2019/07/23 19:49, Adam Borowski wrote:
> ##################
> I do not consider a flat tarball to be a preferred form for modification. 
> Thus, like any non-source form, it must be accompanied by a way to obtain
> the actual form for modification.  There are many such ways -- unless you
> distribute the software in highly unusual circumstances, a link to a
> network server suffices; see the text of the GPL for further details.
> ##################
<snip>
> Thoughts?

It's a non-issue, really. Tarballs are trivial to extract, and doesn't
block a developer from working on the source in any meaningful way.

This is very different to say, minified javascript that is not
considered source code because you can't practically work with that as
source.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

[toc] | [prev] | [next] | [standalone]

#10792

On Wed, 2019-07-24 at 00:49:24 +0200, Adam Borowski wrote:
> ##################
> I do not consider a flat tarball to be a preferred form for modification. 
> Thus, like any non-source form, it must be accompanied by a way to obtain
> the actual form for modification.  There are many such ways -- unless you
> distribute the software in highly unusual circumstances, a link to a
> network server suffices; see the text of the GPL for further details.
> ##################
> 
> I believe such a statement would be GPL-compatible; rationale:
> * by the 2011 Red Hat kernel sources outcry, it is obvious such a tarball
>   is long obsolete
> * a flat tarball deprives the recipient of features of modern VCSes
> * comments giving rationale for a change tend to be written as VCS commit
>   messages
> * future forms are not banned: it is conceivable that next week someone
>   invents a revolutionary new form that wins over git

This concept keeps being put forward from time to time, and it keeps
making little sense to me. The "preferred form of the work for making
modifications to it" is the actual source files, that's the work. A
tarball is a way to *transport* and *disseminate* those files, it's
not the work, and people do not edit the tarball. A VCS can be used
to *record* those modifications, or to *transport* and *disseminate*
them, in the same way you could do with a series of patches. But
"modifying" the VCS is a by-product of having modified the actual
source.

Regards,
Guillem

[toc] | [prev] | [next] | [standalone]

#10793

On Wed, Jul 24, 2019 at 02:14:38AM +0200, Guillem Jover wrote:
> On Wed, 2019-07-24 at 00:49:24 +0200, Adam Borowski wrote:
> > ##################
> > I do not consider a flat tarball to be a preferred form for modification. 
> > Thus, like any non-source form, it must be accompanied by a way to obtain
> > the actual form for modification.  There are many such ways -- unless you
> > distribute the software in highly unusual circumstances, a link to a
> > network server suffices; see the text of the GPL for further details.
> > ##################

> > * comments giving rationale for a change tend to be written as VCS commit
> >   messages

> This concept keeps being put forward from time to time, and it keeps
> making little sense to me. The "preferred form of the work for making
> modifications to it" is the actual source files, that's the work. A
> tarball is a way to *transport* and *disseminate* those files, it's
> not the work, and people do not edit the tarball. A VCS can be used
> to *record* those modifications, or to *transport* and *disseminate*
> them, in the same way you could do with a series of patches. But
> "modifying" the VCS is a by-product of having modified the actual
> source.

By this logic, a pile of .c files with comments removed or preprocessed
with cpp would be allowed as well.  The VCS is also a means to store
human-readable comments.

Another piece of [meta]data that a flat tarball lacks is authorship
information.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ At least spammers get it right: "Hello beautiful!".
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#10797

On July 24, 2019 12:34:13 AM UTC, Adam Borowski <kilobyte@angband.pl> wrote:
>On Wed, Jul 24, 2019 at 02:14:38AM +0200, Guillem Jover wrote:
>> On Wed, 2019-07-24 at 00:49:24 +0200, Adam Borowski wrote:
>> > ##################
>> > I do not consider a flat tarball to be a preferred form for
>modification. 
>> > Thus, like any non-source form, it must be accompanied by a way to
>obtain
>> > the actual form for modification.  There are many such ways --
>unless you
>> > distribute the software in highly unusual circumstances, a link to
>a
>> > network server suffices; see the text of the GPL for further
>details.
>> > ##################
>
>> > * comments giving rationale for a change tend to be written as VCS
>commit
>> >   messages
>
>> This concept keeps being put forward from time to time, and it keeps
>> making little sense to me. The "preferred form of the work for making
>> modifications to it" is the actual source files, that's the work. A
>> tarball is a way to *transport* and *disseminate* those files, it's
>> not the work, and people do not edit the tarball. A VCS can be used
>> to *record* those modifications, or to *transport* and *disseminate*
>> them, in the same way you could do with a series of patches. But
>> "modifying" the VCS is a by-product of having modified the actual
>> source.
>
>By this logic, a pile of .c files with comments removed or preprocessed
>with cpp would be allowed as well.  The VCS is also a means to store
>human-readable comments.
>
>Another piece of [meta]data that a flat tarball lacks is authorship
>information.
>
I infer from this you think projects without a public VCS (postfix is an example) belong in non-free?

Scott K

[toc] | [prev] | [next] | [standalone]

#10842

On Wed, Jul 24, 2019 at 05:18:28AM +0000, Scott Kitterman wrote:
> On July 24, 2019 12:34:13 AM UTC, Adam Borowski <kilobyte@angband.pl> wrote:
> >By this logic, a pile of .c files with comments removed or preprocessed
> >with cpp would be allowed as well.  The VCS is also a means to store
> >human-readable comments.
> >
> >Another piece of [meta]data that a flat tarball lacks is authorship
> >information.
> >
> I infer from this you think projects without a public VCS (postfix is an example) belong in non-free?

At this moment, not yet.  Obviously, old projects didn't even _have_ a VCS,
and I'm not proposing imposing a VCS workflow on the upstream.  I'd like to
consider, at some point in the future, hidden private VCSes where the upstream
occassionally releases a tarball of to be non-free, just like the same PNG
image can be free if there's no XCF file but is not if the upstream holds a
private XCF version they routinely modify -- a "preferred form for
modification" is not required to be good, merely no worse than what upstream
themselves use.

What I'm proposing today is to let upstreams demand no freeness regressions,
in the spirit of my understanding of the GPL.

And while we don't have 3.0 (git) yet, I argue that a technical solution of
requiring a link to a public git service (assuming no extraordinary needs on
the recipient's side), while not very good, meets GPL3 and sort of GPL2.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#10843

Adam Borowski <kilobyte@angband.pl> writes:

> At this moment, not yet.  Obviously, old projects didn't even _have_ a
> VCS, and I'm not proposing imposing a VCS workflow on the upstream.  I'd
> like to consider, at some point in the future, hidden private VCSes
> where the upstream occassionally releases a tarball of to be non-free,
> just like the same PNG image can be free if there's no XCF file but is
> not if the upstream holds a private XCF version they routinely modify --
> a "preferred form for modification" is not required to be good, merely
> no worse than what upstream themselves use.

I don't understand why you chose the VCS specifically and alone to elevate
to the level of required source.  If I had to pick what additional
information I'd want over and above the current source code, I'd be way
more interested in the bug tracking system than the VCS.  I use that an
order of magnitude more often than I use Git history when developing
software.

There are a few other really obvious reductio ad absurdum arguments here,
too.  For example, most of the critical documentation for the Linux kernel
that's practically required in order to understand it well enough to
meaningfully maintain it is in LWN or the linux-kernel mailing list
archives.  Guess we need to start including those in the source package
now too....

The line between source and supporting useful stuff that's not source is
inherently arbitrary.  For better or worse, we have thirty years of
history behind drawing the line in one specific place.  That doesn't mean
there are no good reasons to change that line; it does mean that any other
place we draw the line is still going to be arbitrary.  Redrawing the line
is a *huge* amount of disruption and energy drain because we have to
relitigate endless mostly-settled discussions from the past thirty years
around what source code means.  The payoff needs to be correspondingly
large to be worth the effort, and I'm just not seeing it.

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

[toc] | [prev] | [next] | [standalone]

#10845

On Thu, Jul 25, 2019 at 09:56:49AM -0700, Russ Allbery wrote:
>The payoff needs to be correspondingly
>large to be worth the effort, and I'm just not seeing it.

+1

[toc] | [prev] | [next] | [standalone]

#10848

On Thu, 25 Jul 2019, Russ Allbery wrote:
> is a *huge* amount of disruption and energy drain because we have to
> relitigate endless mostly-settled discussions from the past thirty years
> around what source code means.  The payoff needs to be correspondingly
> large to be worth the effort, and I'm just not seeing it.

Strongly supported, thanks for the very clear statement!

Norbert

--
PREINING Norbert                               http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

[toc] | [prev] | [next] | [standalone]

#10810

On Wed, 24 Jul 2019 at 02:34:13 +0200, Adam Borowski wrote:
> > > ##################
> > > I do not consider a flat tarball to be a preferred form for modification. 
> > > Thus, like any non-source form, it must be accompanied by a way to obtain
> > > the actual form for modification.  There are many such ways -- unless you
> > > distribute the software in highly unusual circumstances, a link to a
> > > network server suffices; see the text of the GPL for further details.
> > > ##################

Are you asking this hypothetically, or is there a piece of software that
someone intends to apply this to?

As always for legal questions on whether something is allowed in Debian,
asking -legal will only get you some speculation: the ftp team is the
authority on what can and can't be in Debian. However, I think this would
be an unwise precedent to set, with undesirable practical implications,
and I suspect the ftp team would think the same.

Remember that GPL-2 §3c is only allowed for non-commercial redistribution,
so commercial redistributors have to use §3a or §3b. This means they have
to take steps to redistribute the preferred form for modification themselves
(e.g. copy it to *their* network server).

In the GPL-3 case, a commercial redistributor could rely on §6d (GPL-3
§6 is the equivalent of GPL-2 §3), but it's unwise to rely on a third
party for this without some sort of contractual relationship, because
"you remain obligated to ensure that it is available for as long as
needed to satisfy these requirements" (so linking to upstream's network
server is not enough, because if upstream stop distributing source,
you would be in violation of the license unless you immediately stop
distributing binaries). Debian and its derivatives are longer-lived
than many of the packages we include, so we need to know that we are
already distributing source for all our binaries.

Redistributing the entire history of a third-party project is practically
problematic because it is no longer enough to check that there is nothing
you don't want to distribute (e.g. non-free software) in the HEAD commit:
you also have to check that there is nothing that you don't want to
distribute anywhere in the history. If I remember correctly, this is
why the ftp team do not allow "3.0 (git)"-format source packages in the
Debian archive: if a git-based source package format is allowed in future,
it will have to be "shallow", which makes it functionally equivalent to
a tarball plus metadata.

For established projects, the complete history is also inconveniently
large: my git clone of glib2.0 has a 57M .git, which compares poorly
with a 4.5M source tarball (and glib2.0 isn't even particularly big or
old by the standards of projects like glibc and the Linux kernel).

> By this logic, a pile of .c files with comments removed or preprocessed
> with cpp would be allowed as well.  The VCS is also a means to store
> human-readable comments.

We have to draw a line somewhere. You could equally well say the software's
bug tracking system and mailing lists, which also store human-readable
comments, are part of the preferred form for modification - but those
don't normally have any copyright license granted (I certainly didn't
put this email under a copyright license!) so they are non-free.

> Another piece of [meta]data that a flat tarball lacks is authorship
> information.

Projects that consider this to be important put copyright notices in
source files, lists of authors in source files and/or lists of authors
in ./AUTHORS.

    smcv

[toc] | [prev] | [next] | [standalone]

#10859

Simon McVittie writes ("Re: anti-tarball clause and GPL"):
> Are you asking this hypothetically, or is there a piece of software that
> someone intends to apply this to?

There are existing packages for which I consider the PFM to include
the git history.  I'm not pressing this point from a legal point of
view because, well, that just generates lots of heat and no light.

I think that we should address this potential problem by arranging to
give to the history to our users and downstreams.  There are lots of
other really good reasons to do this.

(ISTM that whether the PFM needs the upstream vcs history or not is a
question of fact which depends strongly on the context, how the thing
is developed, etc.  I don't think a GPL rider like the one quoted
earlier is definitive either way - it's a statement of the author's
opinion and perhaps implies something about their practices.)

> Redistributing the entire history of a third-party project is practically
> problematic because it is no longer enough to check that there is nothing
> you don't want to distribute (e.g. non-free software) in the HEAD commit:

This boat already sailed a long time ago.  Via alioth and now salsa,
and via the dgit git server, we are in many cases distributing that
complete history already.

> For established projects, the complete history is also inconveniently
> large: my git clone of glib2.0 has a 57M .git, which compares poorly
> with a 4.5M source tarball (and glib2.0 isn't even particularly big or
> old by the standards of projects like glibc and the Linux kernel).

Right.  Bundling up git histories in tarballs is not a really sensible
way to carry on (unless trying to make a source CD for offline use or
something).  Better to just have a git server, since then you only
need to keep one copy of the history, and in many cases clients can
only transfer updates.

> We have to draw a line somewhere. You could equally well say the software's
> bug tracking system and mailing lists, which also store human-readable
> comments, are part of the preferred form for modification - but those
> don't normally have any copyright license granted (I certainly didn't
> put this email under a copyright license!) so they are non-free.

So that interpretation of the PFM is not compatible with upstream's
practices.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These 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.

[toc] | [prev] | [next] | [standalone]

#10860

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> There are existing packages for which I consider the PFM to include
> the git history.  I'm not pressing this point from a legal point of
> view because, well, that just generates lots of heat and no light.

> I think that we should address this potential problem by arranging to
> give to the history to our users and downstreams.  There are lots of
> other really good reasons to do this.

Since I was arguing in another branch of the thread that I didn't think
trying to use the GPL clause to force this made sense, I want to say here
that I completely agree with this: we should make the VCS history readily
available.  There are tons of good reasons to do so, one of which is that
it empowers our users to understand and change the software that we
distribute.

I don't think it's productive to try to force the matter legally, but I
think it's a good place to exert effort technically.

I'm dubious that the Debian archive is the best place from which to
distribute full VCS histories for boring technical reasons, but I'm
already convinced that we should be building on the dgit machinery as the
future of how packages will be maintained and uploaded, which also
provides an obvious place from which to make that history available.

> This boat already sailed a long time ago.  Via alioth and now salsa, and
> via the dgit git server, we are in many cases distributing that complete
> history already.

I think it does make a (minor) difference that we're not encouraging third
parties to trust us that it is legally fine to put that material on CDs,
sell them, etc.  The practical risk bar is lower when the material is only
on services that we fully control and therefore for which we can easily
respond to cease-and-desist letters with merit, etc., and other people
aren't trusting our license statements about that material.

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

[toc] | [prev] | [next] | [standalone]

#10794

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Wed, Jul 24, 2019 at 12:49:24AM +0200, Adam Borowski wrote:
> ##################
> I do not consider a flat tarball to be a preferred form for modification. 
> Thus, like any non-source form, it must be accompanied by a way to obtain
> the actual form for modification.  There are many such ways -- unless you
> distribute the software in highly unusual circumstances, a link to a
> network server suffices; see the text of the GPL for further details.
> ##################

I believe transporting whole VCS directory in a tarball is a viable
workaround, though I would argue that expensive data transport (like 4G,
satellite network, etc.) is not highly unusual.

Also, if upstream interpret the clause as "the actual place for making
modification", it could violate dissident test.

Yao Wei

[toc] | [prev] | [next] | [standalone]

#10846

On Tue, Jul 23, 2019 at 09:51:23PM -0300, Yao Wei wrote:
> On Wed, Jul 24, 2019 at 12:49:24AM +0200, Adam Borowski wrote:
> > ##################
> > I do not consider a flat tarball to be a preferred form for modification. 
> > Thus, like any non-source form, it must be accompanied by a way to obtain
> > the actual form for modification.  There are many such ways -- unless you
> > distribute the software in highly unusual circumstances, a link to a
> > network server suffices; see the text of the GPL for further details.
> > ##################
> 
> I believe transporting whole VCS directory in a tarball is a viable
> workaround

Ie, the 3.0 (git) format.

> though I would argue that expensive data transport (like 4G,
> satellite network, etc.) is not highly unusual.

Using real git (rather than a hack to emulate the old scheme) you can do a
shallow clone.

Tunnelling git repos inside tarballs is useful only in rare (yet important)
cases like a desert island, an oppressive country, an air-gapped facility,
an interstellar spaceship, etc.  And once tunnelled, git will works
awesomely within that disconnected from us network.  Including merging back
once connected again.  That's not something a flat tarball can do.

> Also, if upstream interpret the clause as "the actual place for making
> modification", it could violate dissident test.

I'm talking about format, not place.  Git is explicitly a _distributed_ VCS,
meant to solve this very problem.

And mandating git specifically would be non-free, as it'd forbid migrating
to a future better scheme, or an alternative (Hg, Pijul).  Thus, I propose
opt-in banning only a particular obsolete way to convey processed sources.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#10851

What if, one of the upstream authors consider it violating GPL _without_ the clause?  I mean, it could happen. 

Yao Wei

[toc] | [prev] | [next] | [standalone]

#10803

On 24.07.2019 00:49, Adam Borowski wrote:
> Hi!
> In the light of the currently discussed GR proposal, I wonder if the
> following license clause would be considered DFSG-free and GPL-compatible:
> 
> ##################
> I do not consider a flat tarball to be a preferred form for modification.
> Thus, like any non-source form, it must be accompanied by a way to obtain
> the actual form for modification.  There are many such ways -- unless you
> distribute the software in highly unusual circumstances, a link to a
> network server suffices; see the text of the GPL for further details.
> ##################
> 
> I believe such a statement would be GPL-compatible; rationale:
> * by the 2011 Red Hat kernel sources outcry, it is obvious such a tarball
>    is long obsolete
> * a flat tarball deprives the recipient of features of modern VCSes
> * comments giving rationale for a change tend to be written as VCS commit
>    messages
> * future forms are not banned: it is conceivable that next week someone
>    invents a revolutionary new form that wins over git
> 
> Thoughts?

Few comments:

A "flat tarball" cannot be considered a preferred form for modification. 
Few tools allow you to edit a flat tarball (maybe `mc`). It is just a 
form of distribution. We sent to GNU patches, new files, or extract of 
functions.

I think you confuse the "preferred form for modification" to "preferred 
method of distribution of sources".

Compression of tarball often change, so we need "new" (less than 10 year 
old) tools to extract many tarball (tarball format also had few 
improvements).  GPL do not restrict format and compression of tarball. 
Early GNU programs come with many different distribution methods. 'tar' 
is much modern (so initially on "modern GNU" systems). The tar was never 
considered as only (or main) method to obtain sources.

IIRC from very old discussion, you can have a GPL compatible 
distribution method of your choice, if you distribute tools to extract 
sources, or such tools are easy available to the user who bought your 
software. There is no need to have free tools: if you distribute 
binaries for Solaris, it is enough that user could use a proprietary 
Solaris command to get the source.


Note: tarball are often not GPL compliant, because we are lazy. VCS 
solves most of the problems (or helps):

GPL requires us to have and distribute a changelog, so that we can track 
better licenses, modification time, and copyright. Debian requires own 
changelog (we use GPL for Debian stuffs), but as we saw, upstreams often 
forget it.  In such cases (without changelog) a tarball cannot be 
considered fully GPL compliant.

ciao
	cate

[toc] | [prev] | [next] | [standalone]

#10825

* Adam Borowski:

> In the light of the currently discussed GR proposal, I wonder if the
> following license clause would be considered DFSG-free and GPL-compatible:
>
> ##################
> I do not consider a flat tarball to be a preferred form for modification. 
> Thus, like any non-source form, it must be accompanied by a way to obtain
> the actual form for modification.  There are many such ways -- unless you
> distribute the software in highly unusual circumstances, a link to a
> network server suffices; see the text of the GPL for further details.
> ##################
>
> I believe such a statement would be GPL-compatible; rationale:
> * by the 2011 Red Hat kernel sources outcry, it is obvious such a tarball
>   is long obsolete
> * a flat tarball deprives the recipient of features of modern VCSes
> * comments giving rationale for a change tend to be written as VCS commit
>   messages
> * future forms are not banned: it is conceivable that next week someone
>   invents a revolutionary new form that wins over git
>
> Thoughts?

The GPL version 2 already requires that you maintain something like a
ChangeLog:

|   2. You may modify your copy or copies of the Program or any portion
| of it, thus forming a work based on the Program, and copy and
| distribute such modifications or work under the terms of Section 1
| above, provided that you also meet all of these conditions:
| 
|     a) You must cause the modified files to carry prominent notices
|     stating that you changed the files and the date of any change.

On the other hand, not allowing source distribution as a “flat
tarball” sounds like an additional restriction, which would be
incompatible with the GPL.  (Just like parts of glibc used to require
distribution on tapes, only less inconvenient.)

[toc] | [prev] | [next] | [standalone]

#10827

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jul 24, 2019 at 10:28:19PM +0200, Florian Weimer wrote:
> On the other hand, not allowing source distribution as a “flat
> tarball” sounds like an additional restriction, which would be
> incompatible with the GPL.  (Just like parts of glibc used to require
> distribution on tapes, only less inconvenient.)

I believe that "flat" tarball in Adam's question means tarball stripping
out VCS information, not tarball as a format.

Also, the clause doesn't disallow the distribution using tarball, but
only define what "source code == preferred form for making modification"
is.  So, "flat tarball" becomes object code license-wise.

Yao Wei

[toc] | [prev] | [next] | [standalone]

#10847

On Wed, 24 Jul 2019, Yao Wei wrote:
> I believe that "flat" tarball in Adam's question means tarball stripping
> out VCS information, not tarball as a format.
> 
> Also, the clause doesn't disallow the distribution using tarball, but
> only define what "source code == preferred form for making modification"
> is.  So, "flat tarball" becomes object code license-wise.

Just one hint, if this comes in I will upload texlive with about a
70Gb tarball as source ... we have 15 years of history of "flat tarball
of 4Gb".

I don't think that *this* is the preferred form of changes.

Best

Norbert

--
PREINING Norbert                               http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.project

csiph-web