DFSG violations: non-free but no contrib - Debian

This is a discussion on DFSG violations: non-free but no contrib - Debian ; Hi Ben, On Mon, Nov 03, 2008 at 09:17:56AM +1100, Ben Finney wrote: > Anything which we propose to distribute as part of Debian must follow > the DFSG rules; otherwise, we violate our promises in the Social > Contract. ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 48

Thread: DFSG violations: non-free but no contrib

  1. Re: DFSG violations: non-free but no contrib

    Hi Ben,

    On Mon, Nov 03, 2008 at 09:17:56AM +1100, Ben Finney wrote:
    > Anything which we propose to distribute as part of Debian must follow
    > the DFSG rules; otherwise, we violate our promises in the Social
    > Contract. There's nothing special about the *vendor-intended use* of a
    > collection of bits that exempts it from the standard that we apply to
    > the rest of the operating system.


    I think you've made that point clear now, thanks.


    Michael


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Re: DFSG violations: non-free but no contrib

    Aurelien Jarno writes:
    > On Mon, Nov 03, 2008 at 08:03:15AM +1100, Robert Collins wrote:
    >> On Sun, 2008-11-02 at 14:51 +0100, Aurelien Jarno wrote:
    >> > Everyone agrees that firmwares are a bit special

    >> I don't think they are at all special.

    > Bull****.


    --
    Gruesse/greetings,
    Reinhard Tartler, KeyID 945348A4


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Re: DFSG violations / buyers guide.

    Frank Lin PIAT writes:

    > On Thu, 2008-10-30 at 11:29 +0000, Robert Lemmen wrote:
    >> On Thu, Oct 30, 2008 at 12:07:52PM +0100, Josselin Mouette wrote:
    >> > Wrong. You can help Ben Finney testing his packages. That would be much
    >> > more useful than useless babbling on mailing lists.

    >>
    >> if you are talking about these [0], i certainly do not own any of these
    >> pieces of hardware...

    >
    > I would be very pleased to have a "Buyers guide" on the wiki (i.e list
    > devices that are current, supported and dfsg-free).


    the problem with those list is that they often become outdated and
    incomplete (who know if this no-name cheap card is supported or not ?),
    but if it is updated regularly, it can be good idea.

    --
    Rémi Vanicat


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: DFSG violations: non-free but no contrib

    Michael Banck writes:

    > Hi Ben,
    >
    > On Mon, Nov 03, 2008 at 09:17:56AM +1100, Ben Finney wrote:
    > > Anything which we propose to distribute as part of Debian must
    > > follow the DFSG rules; otherwise, we violate our promises in the
    > > Social Contract. There's nothing special about the
    > > *vendor-intended use* of a collection of bits that exempts it from
    > > the standard that we apply to the rest of the operating system.

    >
    > I think you've made that point clear now, thanks.


    I'd love it if that were true; then there wouldn't be fallacious
    statements about “everyone agrees some bitstreams are special, so
    deserve special standards of freedom”.

    --
    \ “It is far better to grasp the universe as it really is than to |
    `\ persist in delusion, however satisfying and reassuring.” —Carl |
    _o__) Sagan |
    Ben Finney


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: DFSG violations: non-free but no contrib

    On Mon, Nov 03, 2008 at 02:28:45AM -0600, Manoj Srivastava wrote:
    > On Sun, Nov 02 2008, Aurelien Jarno wrote:
    >
    >
    > > This look complicated. Everyone agrees that firmwares are a bit
    > > special in the world of software due to the fact they don't run on the
    > > host CPU.

    >
    > Can you explain to me why it matters which processing unit the
    > software runs on? Why does it matter whether the software being
    > executed on the central unit matters, and that on the peripheral
    > processing unit gets off scott free?
    >
    > Why should it matter that the software is executed on a
    > processing unit that lives on a daughter board instead of the mother
    > board?


    I haven't say that because they are not executed on by the CPU they are
    more free. What I mean is that we have those discussions because they
    are not executed on the main CPU, which makes them different than other
    non-DFSG compliant software. Then some people consider that acceptable,
    some other not.

    At least having a separate section kills the argument that moving all
    firmwares to non-free means that a lot of people will then use non-free
    and install non-free stuff by mistake.

    It also allows more easily to put all firmwares on a separate media for
    use by debian installer (AFAIK there is no other reason to use non-free
    in d-i).

    --
    .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
    : :' : Debian developer | Electrical Engineer
    `. `' aurel32@debian.org | aurelien@aurel32.net
    `- people.debian.org/~aurel32 | www.aurel32.net


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Re: DFSG violations: non-free but no contrib

    Manoj Srivastava wrote:
    > Can you explain to me why it matters which processing unit the
    > software runs on? Why does it matter whether the software being
    > executed on the central unit matters, and that on the peripheral
    > processing unit gets off scott free?
    >


    I don't think it does matter.

    On a related note though, compare to hardware vendors:

    A) provides all firmware, in binary only form, without source code, on
    board device ROM that cannot be changed.

    B) provides all firmware on disk, in binary only form, without source
    code, in form that must be downloaded to device after every boot.

    A hardware is usable with Debian main. B is not.

    Is this really a win? Have we gained anything for freedom? I suspect
    not. In both cases the firmware cannot be modified. At least for B there
    is some hope because the open source code to perform the downloading of
    the firmware has been written, where as doing that for A that might be
    harder.

    The only benefit I see is a technical one - it is easy to draw the line
    and say Debian must exclude all binary blobs that don't comply with the
    DFSG. I can't see it helping in any practical manner achieve the goal of
    the DFSG by increasing the freedoms we get with Debian. Users will still
    have the same restrictions and not be able to make modifications. Not
    until we can get open source hardware will this change.

    I haven't heard a good answer to the problem that some types of firmware
    can only be legally endorsed if the manufacturer ensures users can't
    change it - e.g. firmware for wireless interfaces.

    Brian May


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  7. Re: DFSG violations: non-free but no contrib

    On Mon, Nov 03, 2008, Robert Collins wrote:
    > I don't think they are at all special. What interprets the software - be
    > it a 'cpu', a 'vm' or a co-processor like many video cards, or something
    > like an arduino doesn't alter the basic attributes - there is machine
    > code for one or more machines, which is usually derived from some more
    > editable source (more can be quite a range though) though compilation.


    It's hard to define how they are special, but I think they are.

    And I can think of other data bits in the grey area.

    Consider SSL certificates for e.g. Verisign. It makes no sense to
    change them and we don't have the ultimate source for them. These are
    generated data files for which we have the tools to build them, but not
    the ultimate source data (private key). And if we had the private key,
    they would be worthless. These are effectively static data enabling
    SSL communications with sites using these SSL certs providers.
    I could make another argument about RFCs, it's even easier to change
    them.

    Firmwares can be considered somewhat the same: static data enabling the
    use of your hardware. You can perhaps change them. Perhaps we have
    the tools to change them. Perhaps we can change them usefully. But
    they are useful as such and we don't need to fight for their freedom as
    we fight for the freedom of the main OS.

    With requiring the freedom of firmwares, we're putting our finger in a
    completely new problem: the one of free hardware. To build an useful
    firmware, we will need information about registers, the operation of
    the hardware, it's hardware architecture, limits, caracteristics, test
    results.

    Perhaps someday we will port Debian to our graphics cards, just like
    it's ported to wifi aps. This would be a new port, we don't need to
    require Debian to be running on your ap to use it so why not enable the
    distribution of useful data which doesn't taint the main OS if we have
    the permissions to do so and it benefits our users?

    I don't see Debian as a free harware and computers project. We need to
    leave some hard problems to others to solve!

    --
    Loc Minier


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  8. Re: DFSG violations: non-free but no contrib

    Le lundi 03 novembre 2008 * 10:12 +0100, Aurelien Jarno a écrit :
    > I haven't say that because they are not executed on by the CPU they are
    > more free. What I mean is that we have those discussions because they
    > are not executed on the main CPU, which makes them different than other
    > non-DFSG compliant software. Then some people consider that acceptable,
    > some other not.


    This case is very similar to non-free documentation, which is not
    executed on any CPU at all. It sounds bogus to split firmware in a
    specific archive and to not do it for documentation, data, etc.

    If you want to make a specific distinction for software for which we
    don’t have a source and which is executed on the host CPU, I’d prefer to
    see the non-free rules updated to ban such software from our archive,
    and to add restrictions to it such as:
    * availability of source code (for binaries meant for the host
    CPU);
    * legal possibility to autobuild the package (for arch-any ones);
    * legal possibility to add patches for security updates.

    This way we could add the non-free archive to sources.list without
    wondering whether installing stuff from it will introduce an unfixable
    root security hole. If more and more systems need non-free because of
    firmware, this is a move that I’d like to see.

    --
    .''`.
    : :' : We are debian.org. Lower your prices, surrender your code.
    `. `' We will add your hardware and software distinctiveness to
    `- our own. Resistance is futile.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBJDszcrSla4ddfhTMRAkc6AKC9odg7HatmtfdiN87Bju ueSOOeXgCgvDmN
    3CmMef75TdoDAfgUCkH0Fsg=
    =aVL3
    -----END PGP SIGNATURE-----


  9. Re: DFSG violations: non-free but no contrib

    Le lundi 03 novembre 2008 * 10:58 +0100, Loïc Minier a écrit:
    > And I can think of other data bits in the grey area.
    >
    > Consider SSL certificates for e.g. Verisign. It makes no sense to
    > change them and we don't have the ultimate source for them. These are
    > generated data files for which we have the tools to build them, but not
    > the ultimate source data (private key). And if we had the private key,
    > they would be worthless. These are effectively static data enabling
    > SSL communications with sites using these SSL certs providers.


    Since SSL certificates are randomly generated data, they are not subject
    to copyright law, so I don’t think they are in any grey area. We can
    change them without any licensing issue, it’s just that they won’t
    fulfill their job if we do.

    > Firmwares can be considered somewhat the same: static data enabling the
    > use of your hardware. You can perhaps change them. Perhaps we have
    > the tools to change them. Perhaps we can change them usefully. But
    > they are useful as such and we don't need to fight for their freedom as
    > we fight for the freedom of the main OS.


    Firmware images are very different. They are binary code, only code not
    meant for execution on the host CPU. They are similar to non-free data
    for games: stuff that we cannot modify and with which we can live
    without modifying, but it would be useful to be able to, and it is
    impossible to distribute it in main.

    Cheers,
    --
    .''`.
    : :' : We are debian.org. Lower your prices, surrender your code.
    `. `' We will add your hardware and software distinctiveness to
    `- our own. Resistance is futile.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBJDs5frSla4ddfhTMRAvH+AKDaZra5UHGi1ja6YHBRPp Agvgk+mwCfayJ4
    eNU1VLIObIWH6BU/nrJjijI=
    =ev/B
    -----END PGP SIGNATURE-----


  10. Re: DFSG violations: non-free but no contrib

    On Mon, Nov 03, 2008, Josselin Mouette wrote:
    > > Consider SSL certificates for e.g. Verisign. It makes no sense to
    > > change them and we don't have the ultimate source for them. These are
    > > generated data files for which we have the tools to build them, but not
    > > the ultimate source data (private key). And if we had the private key,
    > > they would be worthless. These are effectively static data enabling
    > > SSL communications with sites using these SSL certs providers.

    >
    > Since SSL certificates are randomly generated data, they are not subject
    > to copyright law, so I don’t think they are in any grey area. We can
    > change them without any licensing issue, it’s just that they won’t
    > fulfill their job if we do.


    I'm not arguing about their copyright(-ability): just that we can't
    usefully modify them; and still, the private key is the source to
    create the certificate (even if it's random data), and we don't have it
    in main. The same goes with firmware: we might have the right to
    distribute modified binary firmwares, and they are sufficiently useful
    as they are, even without accompanying ultimate source. Their form is
    sufficient for a free OS, not for free hardware though; just like
    certificates are sufficient for a free OS, not for an open
    certification chain.

    > > Firmwares can be considered somewhat the same: static data enabling the
    > > use of your hardware. You can perhaps change them. Perhaps we have
    > > the tools to change them. Perhaps we can change them usefully. But
    > > they are useful as such and we don't need to fight for their freedom as
    > > we fight for the freedom of the main OS.

    >
    > Firmware images are very different. They are binary code, only code not
    > meant for execution on the host CPU. They are similar to non-free data
    > for games: stuff that we cannot modify and with which we can live
    > without modifying, but it would be useful to be able to, and it is
    > impossible to distribute it in main.


    The non-free games data I know of is non-free because we may not modify
    it because the license doesn't explicitely allow it; what specific
    example did you have in mind? This is IMO different from firmware
    binaries which we may well be allowed to change, but don't have the
    tools/doc to do so.

    --
    Loïc Minier


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  11. Re: DFSG violations: non-free but no contrib

    On Mon, Nov 03, 2008, Josselin Mouette wrote:
    > Le lundi 03 novembre 2008 10:12 +0100, Aurelien Jarno a crit :
    > > I haven't say that because they are not executed on by the CPU they are
    > > more free. What I mean is that we have those discussions because they
    > > are not executed on the main CPU, which makes them different than other
    > > non-DFSG compliant software. Then some people consider that acceptable,
    > > some other not.

    > This case is very similar to non-free documentation, which is not
    > executed on any CPU at all. It sounds bogus to split firmware in a
    > specific archive and to not do it for documentation, data, etc.


    Which non-free documentation specifically? The GFDL has this invariant
    sections concept which prevents us from modifying the doc, so you can
    not e.g. fork a software and rename/update doc in the invariant
    sections. However I wouldn't mind having modifiable documentation in a
    format which isn't the ultimate source but is maintainable, e.g. html
    format if that's maintainable over time, even if originally it was
    built from docbook and we don't have the docbook source.

    IOW, I don't mind with picking up autogenerated contents to include in
    Debian if we can maintain it in this form.

    --
    Loc Minier


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  12. Re: DFSG violations: non-free but no contrib

    Le lundi 03 novembre 2008 * 13:33 +0100, Loïc Minier a écrit:
    > On Mon, Nov 03, 2008, Josselin Mouette wrote:
    > > Since SSL certificates are randomly generated data, they are not subject
    > > to copyright law, so I don’t think they are in any grey area. We can
    > > change them without any licensing issue, it’s just that they won’t
    > > fulfill their job if we do.

    >
    > I'm not arguing about their copyright(-ability): just that we can't
    > usefully modify them; and still, the private key is the source to
    > create the certificate (even if it's random data), and we don't have it
    > in main. The same goes with firmware: we might have the right to
    > distribute modified binary firmwares, and they are sufficiently useful
    > as they are, even without accompanying ultimate source.


    Ah, firmwares without source but with a free (e.g. MIT) license are
    another story. This is definitely a grey area, since I guess many
    upstreams are working on the binary directly, but there are also some
    who compile it from C sources or assembly. For some of them the tools
    are available, for some of them they are in-house, for some of them the
    tool is a hex editor. And I don’t think we can easily distinguish
    between them.

    Firmwares without a free license should go to non-free, regardless of
    their format.

    > > Firmware images are very different. They are binary code, only code not
    > > meant for execution on the host CPU. They are similar to non-free data
    > > for games: stuff that we cannot modify and with which we can live
    > > without modifying, but it would be useful to be able to, and it is
    > > impossible to distribute it in main.

    >
    > The non-free games data I know of is non-free because we may not modify
    > it because the license doesn't explicitely allow it; what specific
    > example did you have in mind? This is IMO different from firmware
    > binaries which we may well be allowed to change, but don't have the
    > tools/doc to do so.


    Yes, I didn’t understand you were talking about “free” firmware without
    sources.

    --
    .''`.
    : :' : We are debian.org. Lower your prices, surrender your code.
    `. `' We will add your hardware and software distinctiveness to
    `- our own. Resistance is futile.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBJDvT/rSla4ddfhTMRAruOAJ9L0SzkK5Oah41t0VBjasvD1bO3WgCfTr As
    I1C9Tcjqi6hKXVPvbozclEk=
    =uuhu
    -----END PGP SIGNATURE-----


  13. Re: DFSG violations / buyers guide.

    On Mon, 2008-11-03 at 08:42 +0100, Rémi Vanicat wrote:
    > Frank Lin PIAT writes:
    >
    > > On Thu, 2008-10-30 at 11:29 +0000, Robert Lemmen wrote:
    > >> On Thu, Oct 30, 2008 at 12:07:52PM +0100, Josselin Mouette wrote:
    > >> > Wrong. You can help Ben Finney testing his packages. That would be much
    > >> > more useful than useless babbling on mailing lists.
    > >>
    > >> if you are talking about these [0], i certainly do not own any of these
    > >> pieces of hardware...

    > >
    > > I would be very pleased to have a "Buyers guide" on the wiki (i.e list
    > > devices that are current, supported and dfsg-free).

    >
    > the problem with those list is that they often become outdated and
    > incomplete


    Such buyer guide could list the supported-and-free chipsets (not laptop
    model or device name).
    Also, it should be limited to DebianLenny devices... Such page would
    quiet "stable".

    Depending on the device type, it could be either be a white-list or a
    black list :
    - All LAN adapter, except X,Y
    - Only the X and Y Wifi adapter.

    Franklin


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  14. Re: DFSG violations: non-free but no contrib

    Loïc Minier dijo [Mon, Nov 03, 2008 at 10:58:16AM +0100]:
    > > I don't think they are at all special. What interprets the software - be
    > > it a 'cpu', a 'vm' or a co-processor like many video cards, or something
    > > like an arduino doesn't alter the basic attributes - there is machine
    > > code for one or more machines, which is usually derived from some more
    > > editable source (more can be quite a range though) though compilation.

    >
    > It's hard to define how they are special, but I think they are.
    >
    > And I can think of other data bits in the grey area.
    >
    > Consider SSL certificates for e.g. Verisign. It makes no sense to
    > change them and we don't have the ultimate source for them. These are
    > generated data files for which we have the tools to build them, but not
    > the ultimate source data (private key). And if we had the private key,
    > they would be worthless. These are effectively static data enabling
    > SSL communications with sites using these SSL certs providers.


    The thing is, some things are simply not OK for us to distribute as
    part of our project, because they don't meet our requirements. That
    does not mean "don't use that device" - It means only that "if you are
    going to use that device, you should get the firmware". And probably
    that statement will be followed by "You can get the firmware in a
    nice, packaged way at http://nonfree-firmware.debian.net/yourfunnycard
    or by adding non-free to your APT sources list, and installing
    yourfunnycard-firmware".

    What's the distinction regarding SSL certificates? Well, the
    certificates are not the result of the creative process of a person
    (unless you consider "creating just the right entropy for your
    computer" as a creative process.

    > I could make another argument about RFCs, it's even easier to change
    > them.


    RFCs are, indeed, a very interesting case. I understand the motivation
    of the IETF on requesting them to be distributed verbatim and
    disallowing distribution of modified formats - Well then, even if it
    is nice to have everything in your system and packaged for Debian, I
    agree that the ultimate reference point for RFCs is ietf.org - so if I
    need to study a given protocol, I'll go to their website and grab the
    needed bytes.

    > Firmwares can be considered somewhat the same: static data enabling the
    > use of your hardware. You can perhaps change them. Perhaps we have
    > the tools to change them. Perhaps we can change them usefully. But
    > they are useful as such and we don't need to fight for their freedom as
    > we fight for the freedom of the main OS.


    I agree with you. But we cannot see them as part of our system, which
    is mostly defined by its freedom. We can adjust our system to allow
    you to load the firmware (probably under the name "drivers", to which
    many people are more used) in a painless and intuitive fashion. But I
    have yet to see a real reason (besides the work that must go into
    sweeping them out of the current and future kernel tree - Thanks to
    everybody involved into that!) for Debian to make the needed
    exceptions to distribute them as part of main.

    Greetings,

    --
    Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
    PGP key 1024D/8BB527AF 2001-10-23
    Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  15. Re: DFSG violations: non-free but no contrib

    On Mon, Nov 03, 2008, Gunnar Wolf wrote:
    > I agree with you. But we cannot see them as part of our system, which
    > is mostly defined by its freedom. We can adjust our system to allow
    > you to load the firmware (probably under the name "drivers", to which
    > many people are more used) in a painless and intuitive fashion. But I
    > have yet to see a real reason (besides the work that must go into
    > sweeping them out of the current and future kernel tree - Thanks to
    > everybody involved into that!) for Debian to make the needed
    > exceptions to distribute them as part of main.


    Your post made me see the issue under a different light: I must agree
    that this can't be considered on par with the rest of Debian so I wish
    we would distribute it while making clear that these particular files
    are not with accompanying source.


    Why not come up with a new system which would be more convenient than
    sections (or separate archives as you suggest)?


    e.g. trivial but not very flexible: /lib/no-source-code/firmwares/blah
    and a symlink /lib/firmware/foo -> /lib/no-source-code/firmwares/blah.

    Or a list of "not fully-free" files, provided by the packages
    themselves, e.g. /usr/share/doc/$pkg/btw-these-files-are-firmwares.

    Or complex, but might be cleaner: a new type of dpkg meta-information,
    just like we have conffiles, shlibs, we'd have "licensing" and would be
    able to express that /lib/firmware/foo is free to distribute but
    doesn't come with source code, and you probably don't care.


    I'm not happy that people would enable non-free on most systems just
    for the convenience of getting some files which most people will need
    and for which providing a source is not critical. Fetching them
    dynamically from $site isn't ok for live CDs, or when you actually try
    to provide the firmware to get network to work. :-/

    --
    Loc Minier


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  16. Re: DFSG violations: non-free but no contrib

    Loc Minier wrote:

    > On Mon, Nov 03, 2008, Josselin Mouette wrote:
    >> Le lundi 03 novembre 2008 10:12 +0100, Aurelien Jarno a crit :
    >> > I haven't say that because they are not executed on by the CPU they are
    >> > more free. What I mean is that we have those discussions because they
    >> > are not executed on the main CPU, which makes them different than other
    >> > non-DFSG compliant software. Then some people consider that acceptable,
    >> > some other not.

    >> This case is very similar to non-free documentation, which is not
    >> executed on any CPU at all. It sounds bogus to split firmware in a
    >> specific archive and to not do it for documentation, data, etc.

    >
    > Which non-free documentation specifically?


    e.g. PDF files with a DFSG-free license to them, the document source
    available as a LaTeX file, but LaTeX will typeset the document using a
    non-free font.

    Here, you can even modify the content as you like, you just can't
    reproduce the original PDF, and it would maybe be hard to make sure that
    the typesetting still looks nice and readable with a free replacement
    font with different metrics.

    Regards, Frank

    --
    Frank Kster
    Debian Developer (TeXLive)
    ADFC Miltenberg
    B90/Grne KV Miltenberg


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  17. Re: DFSG violations: non-free but no contrib

    On Mon, 2008-11-03 at 21:20 +0100, Loc Minier wrote:
    ....
    > for which providing a source is not critical.

    ....

    I wish I understood the reasoning here - putting aside the fact that
    most of the software in Debian is under a copyleft licence and so we
    *must* provide the source. Why is the source for the radio on my wifi
    card any *less* critical than the source for the driver for my wifi
    card?

    And please, no handwaving about 'different' or 'its hardware
    enablement'.

    And if the answer reduces down to 'firmware is made by proprietary
    vendors and does something many people need and we don't have a
    replacement yet' - well thats fine, but at various points we didn't have
    a free kernel, or a free libc, or a free graphic desktop environment.

    -Rob


    --
    GPG key available at: .

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBJD2p0hnv5qfvT644RAhSgAJ44iBJ/oTqWhiWOMZpZlBvl50zq9ACgl0O5
    PGE3KhLRDsUOSRC88PJjmbs=
    =yyIR
    -----END PGP SIGNATURE-----


  18. Re: DFSG violations: non-free but no contrib

    On Tue, Nov 04, 2008, Robert Collins wrote:
    > I wish I understood the reasoning here - putting aside the fact that
    > most of the software in Debian is under a copyleft licence and so we
    > *must* provide the source. Why is the source for the radio on my wifi
    > card any *less* critical than the source for the driver for my wifi
    > card?


    Because I can consider the wifi firmware a subsystem which doesn't
    contaminate my main OS; there's a clear interface between the two
    systems -- it's like talking to another computer, talking to your hard
    disk, talking to your keyboard: something proprietary or free might
    well be inside, I don't care as long as I can run a free OS on the main
    CPU. I'd *prefer* if it was free, but I can start another project to
    fulfill this goal. I don't want the freedom requirements for the main
    OS to require using free hardware, just like I want the freedom
    requirements to require talking to computers running free software.

    Now if Debian can distribute a blob which allows my hardware to run as
    indicated by a clear interface with my free OS, that's good enough for
    me. If something breaks, I can look at the interface and fix the OS or
    blame the hardware (+ firmware). I don't personally feel like I need
    the freedom to fix the firmware more than the hardware.
    (However, I acknowledge that we must make it clear that particular
    files are only distributed as enablement tools, and don't come with
    ultimate source, tools, and doc.)

    And if we don't require the hardware to be freely modifiable, why
    require the firmware to be so?

    > And if the answer reduces down to 'firmware is made by proprietary
    > vendors and does something many people need and we don't have a
    > replacement yet' - well thats fine, but at various points we didn't have
    > a free kernel, or a free libc, or a free graphic desktop environment.


    And we didn't have Debian or OpenMoko; and the glibc, linux, and
    Xorg/GNOME/KDE/Xfce are huge separate projects and we could start new
    projects to free more things up.

    Google.com is run with software I don't have access to, but I use it
    daily, as well as my microwave, or my wifi card.

    --
    Loc Minier


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  19. Re: DFSG violations: non-free but no contrib

    Loïc Minier dijo [Tue, Nov 04, 2008 at 03:11:18PM +0100]:
    > (...)
    > And if we don't require the hardware to be freely modifiable, why
    > require the firmware to be so?


    So we can ship it coherently with our policies?

    Because users have expectations we have a way to give support to what
    we ship? If it is a program, we can fix bugs. If it is documentation,
    we can fix typos. If it is an image, we can deuglify it. If it is a
    sound, we can make it sound... hmm... better? If it is
    firmware... Well, we cannot do a thing to it.

    It is better and more honest to our users to tell them, "that's not
    ours and we cannot fix it. We cannot pledge to support it. Here it is,
    it is a nice blob, but it is NOT ours, go bug your hardware
    manufacturer for support".

    It is not that I want Debian to ship a system with no hardware support
    - But that I'd prefer it to be kept visibly separate. We might have a
    nonfree-firmware file that can be just copied over at install time (as
    Lenny's d-i already allows for) if your devices are needed for
    installation. It is not -in my POV- antiethical to have non-free
    hardware (i.e. hardware requiring non-free software), but shipping its
    supporting firmware it does not allow us to keep our promises.

    > > And if the answer reduces down to 'firmware is made by proprietary
    > > vendors and does something many people need and we don't have a
    > > replacement yet' - well thats fine, but at various points we didn't have
    > > a free kernel, or a free libc, or a free graphic desktop environment.

    >
    > And we didn't have Debian or OpenMoko; and the glibc, linux, and
    > Xorg/GNOME/KDE/Xfce are huge separate projects and we could start new
    > projects to free more things up.
    >
    > Google.com is run with software I don't have access to, but I use it
    > daily, as well as my microwave, or my wifi card.


    Nothing to argue there. I use Google every day, and I provide the
    infrastructure for my users to run their non-free programs on every
    day. Still, I do not advocate distributing them as part of Debian.

    And not because they are inherently evil or anything, but because
    Debian is not the right place to distribute them from. See what I
    wrote regarding the RFCs - I agree with the IETF, the RFCs server much
    better their purpose being non-free than if they were DFSG-free. But
    that's not a reason to bend Debian's principles and ship IETF RFCs in
    main.

    --
    Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
    PGP key 1024D/8BB527AF 2001-10-23
    Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  20. Re: DFSG violations: non-free but no contrib

    Lo+AO8-c Minier writes:

    > On Tue, Nov 04, 2008, Robert Collins wrote:
    > > I wish I understood the reasoning here - putting aside the fact
    > > that most of the software in Debian is under a copyleft licence
    > > and so we *must* provide the source. Why is the source for the
    > > radio on my wifi card any *less* critical than the source for the
    > > driver for my wifi card?

    >
    > Because I can consider the wifi firmware a subsystem which doesn't
    > contaminate my main OS


    It seems to me that you can only honestly consider it so if it
    *actually does not* contaminate the main OS. The situation we're faced
    with is that non-free works *do* contaminate the main OS; that's the
    reason we're having these discussions about DFSG violation at all.

    > Now if Debian can distribute a blob which allows my hardware to run
    > as indicated by a clear interface with my free OS, that's good
    > enough for me.


    The result can't be called free, though. So long as Debian is promised
    to be free, I expect that promise to be met. It seems, from what you
    say here, that you do not expect that promise to be met.

    > And if we don't require the hardware to be freely modifiable, why
    > require the firmware to be so?


    Because it's distributed in an operating system +IBQ- Debian +IBQ- that its
    distributor +IBQ- the Debian project +IBQ- promises is freely modifiable
    (among other freedoms).

    When someone distributes hardware to me and promises it is freely
    modifiable, I require *that* promise to be upheld also.

    --
    +AFw- +IBw-I don't like country music, but I don't mean to denigrate |
    `+AFw- those who do. And for the people who like country music, |
    _o__) denigrate means +IBg-put down+IBk-.+IB0- +IBQ-Bob Newhart |
    Ben Finney


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast