[haiku-development] Re: Write access to haiku-files.org?

  • From: Matt Madia <mattmadia@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 7 Jul 2009 14:35:33 +0000

On Tue, Jul 7, 2009 at 13:49, Ingo Weinhold<ingo_weinhold@xxxxxx> wrote:
> How about a "Sources:" field to the .OptionalPackageDescription, a URL that
> AboutSystem would link to? I suppose linking to the original source plus
> (if applicable) the Haiku specific patch would work, too. Or even just to
> the HaikuPorts portlog page.

A much more elegant solution indeed :)

Basically, we need to link to the source, any patches, and possibly
instructions (as is the case for GPLv3). This even applies for
binaries that do not require patching.

Externally linking to a server outside of our control is discouraged,
as the owner of the site may shutdown the site or (re)move the source

For physically distributed mediums -- CD, USB, pre-installed on
computers: a written offer is required. Optionally, we could include
the sources/patches/instructions alongside the physical medium and
then not need to concern ourselves with needing to reply to written
requests for source code.  This is one of the reasons why I was
excited about Andreas F's Jam-based system for HaikuPorts and why I
suggested the build system modification to download the source.

Here's some snippets from www.fsf.org :

Yes. The general rule is, if you distribute binaries, you must
distribute the complete corresponding source code too. The exception
for the case where you received a written offer for source code is
quite limited.

    Version 3 of the GPL allows this; see option 6(b) for the full
details. Under version 2, you're certainly free to offer source via
FTP, and most users will get it from there. However, if any of them
would rather get the source on physical media by mail, you are
required to provide that.

    If you distribute binaries via FTP, you should distribute source
via FTP : 

Yes. Section 6(d) allows this. However, you must provide clear
instructions people can follow to obtain the source, and you must take
care to make sure that the source remains available for as long as you
distribute the object code.

    This is a well-meaning request, but this method of providing the
source doesn't really do the job.

    A user that wants the source a year from now may be unable to get
the proper version from another site at that time. The standard
distribution site may have a newer version, but the same diffs
probably won't work with that version.

    So you need to provide complete sources, not just diffs, with the binaries.

    If you make object code available on a network server, you have to
provide the Corresponding Source on a network server as well. The
easiest way to do this would be to publish them on the same server,
but if you'd like, you can alternatively provide instructions for
getting the source from another server, or even a version control
system. No matter what you do, the source should be just as easy to
access as the object code, though. This is all specified in section
6(d) of GPLv3.

    The sources you provide must correspond exactly to the binaries.
In particular, you must make sure they are for the same version of the
program—not an older version and not a newer version.
: http://www.fsf.org/licensing/licenses/gpl-faq.html#SourceInCVS

    No. Some of the requirements in GPLv3, such as the requirement to
provide Installation Information, do not exist in GPLv2. As a result,
the licenses are not compatible: if you tried to combine code released
under both these licenses, you would violate section 6 of GPLv2.

    However, if code is released under GPL “version 2 or later,” that
is compatible with GPLv3 because GPLv3 is one of the options it

Other related posts: