please don't violate rules of upstream sites [LWN.net]

please don't violate rules of upstream sites

Posted Oct 1, 2008 20:50 UTC (Wed) by JoeBuck (subscriber, #2330)
In reply to: Ubuntu debuts its Upstream Report by gmb
Parent article: Ubuntu debuts its Upstream Report

For FSF sites, including bugzilla.gcc.org, links to Launchpad aren't allowed as long as it is non-free software. So please delay implementing that feature until Launchpad is free. If you do it anyway, the GCC web team will have to take any links to Launchpad out again, since we agreed to implement the FSF's linking policy. That policy isn't my preference, and I can't speak for any other projects; Gnome tends to take a looser view, but you'd need to ask them if this is OK. Other projects are likely to object as well.

Alternatively, just make Launchpad free software and all these problems go away.

(Log in to post comments)

Absurd rules of upstream sites

Posted Oct 1, 2008 21:39 UTC (Wed) by tseaver (subscriber, #1544) [Link]

Such a policy is ridiculous and absurd on its face, because it is contrary to the the fundamental principle of free software, which is that users share information about, and fixes and improvements to the software they use. Must links to CVE entries, for instance, must be blocked as well? How would that help the users running the vulnerable-but-free software about which the CVE had been created?

What about bugs originating in systems where the bug tracker is free software, but which happen to be running on a non-free OS? (How would you know? Why would you care?) To take the point further: should GCC ignore bugs from Mac users, who happen not to run a free OS?

Talk about cutting off your nose to spite your face!

Absurd rules of upstream sites

Posted Oct 1, 2008 22:55 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]

GCC has, from the beginning, supported proprietary operating systems, and it's the primary compiler used on the Mac, though Apple seems to be planning a switch to LLVM.

The policy I was talking about only affects links: an FSF site isn't supposed to link to a page that promotes proprietary software.

Absurd rules of upstream sites

Posted Oct 2, 2008 1:42 UTC (Thu) by tseaver (subscriber, #1544) [Link]

> The policy I was talking about only affects links: an FSF site isn't
> supposed to link to a page that promotes proprietary software.

Let's get specific. Here is a Launchpad bug page for Zope (the bug is assigned to me):

https://bugs.launchpad.net/zope2/+bug/143422

In what way does that page "promote proprietary software"? Its entire purpose is to help improve a piece of *free* software (Zope); the only mentions of Launchpad are the home page link (the logo at the top), and a "Help us improve Launchpad" link at the very bottom.

The report contains valuable information, including a patch, about a bug in an application I help maintain. Rejecting a link to this page because LP happens to be closed would be a ludicrously irresponsible policy. Making the report and patch inaccessible to the maintainers of a putative upstream application which applied such a policy would be a disservice both to the maintainers and to the users of the software.

Note that I *do* wish LP were opened up, as I believe its value would be increased. I *don't* think rejecting a link to a bugreport in LP would be sane: it would actively harm the free software ecosystem.

Absurd rules of upstream sites

Posted Oct 2, 2008 17:41 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

Launchpad is itself proprietary software. I didn't make the rule, I'm just telling you what the rule is. Directing someone to Launchpad is seen by the FSF as promoting Launchpad.

Canonical has promised to free Launchpad, and when they do, this issue will be moot.

please don't violate rules of upstream sites

Posted Oct 1, 2008 22:24 UTC (Wed) by gmb (guest, #54452) [Link]

For FSF sites, including bugzilla.gcc.org, links to Launchpad aren't allowed as long as it is non-free software. So please delay implementing that feature until Launchpad is free.

I'm sorry, perhaps I wasn't clear in my original post. For this functionality to work with a Bugzilla or Trac instance, that maintainers of that instance need to install the requisite Launchapd API plugin. Without the plugin, the API isn't available. Since we can assume that bugzilla.gcc.org won't install the plugin (at least until Launchpad is released as free software), this isn't a problem.

Alternatively, just make Launchpad free software and all these problems go away.

We're working on it ;)

please don't violate rules of upstream sites

Posted Oct 1, 2008 22:49 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

Do you have a publicly communicated roadmap later than Aug 28, 2008?
The last thing I read in launchpad's bug tracker is that the roadmap has not been approved.. and I can't seem to find a blueprint or anything describing the roadmap.

If you have an approved roadmap or blueprint or whatever you want to call it....publish it... and provide a link here please.

-jef

please don't violate rules of upstream sites

Posted Oct 2, 2008 7:59 UTC (Thu) by epa (subscriber, #39769) [Link]

What does it mean for a website to be free software? I cannot make a
change to the code for bugzilla.gcc.org and start running it on the site.
I can download a tarball of the Bugzilla source code, but the
bugzilla.gcc.org site remains unmodifiable by me; it is no more free
software than Linux running on a TiVo.

The only people who have the freedom to change bugzilla.gcc.org for their
own requirements are the site's maintainers. And indeed the maintainers of
the Launchpad site have freedom to change their own code, run modified
versions, and even share it with others if they choose to. They currently
choose not to share it, but nothing in RMS's philosophy forces you to
distribute your code to others - just that if you do distribute it, the
others must have the same rights you do. If I made my own private version
of Apache with a few changes, and ran it only on my own website without
giving a copy to anybody else, would the FSF policy forbid linking to that?
What about linking to a website that uses a couple of CGI scripts? Must
those scripts be published somewhere first?

If the policy is only to link to websites implemented using free software
which is also available for public download, that is consistent, but
extremely strict even by FSF standards. Surely even the FSF's own site
uses some scripts and configuration files they have not made public.
Presumably it would rule out linking to a Bugzilla page that happens to be
hosted on AIX or on Linux running inside a non-free virtual machine like an
IBM mainframe.

What does it mean for a website to be free software?

Posted Oct 2, 2008 21:46 UTC (Thu) by grantingram (guest, #18390) [Link]

What does it mean for a website to be free software?

I think that is an excellent question! I've never quite understood the objection to Launchpad - as far I can see it is a web site. Though admittedly I only report bugs in it.

I generally don't demand the source code to websites that I read (like LWN for example!) but perhaps there is a point where the website becomes complex and intermingled enough with your own data that one should... I'm not sure where or how I would draw the line though.

What does it mean for a website to be free software?

Posted Oct 3, 2008 9:22 UTC (Fri) by hppnq (guest, #14462) [Link]

Take a look at the GNU APGLv3. It is meant to address the issue that software (not so much data) can be "locked up" in a website.

What does it mean for a website to be free software?

Posted Oct 3, 2008 9:27 UTC (Fri) by hppnq (guest, #14462) [Link]

What's in an acronym: AGPLv3 of course.

please don't violate rules of upstream sites

Posted Oct 9, 2008 20:07 UTC (Thu) by oak (subscriber, #2786) [Link]

News at FUD.com: RMS "Tivo"s FSF bugzilla; users can get the sources to
it, but they cannot install their modified sources/binaries there! :-)