Re: SRP

[Russ Allbery]

Andrew Suffield <[EMAIL PROTECTED]> writes:

> Oh wow, a bastard child of the MIT and 4-clause BSD licenses. Somebody
> was on the really good crack when they did that.

Yeah, don't get me started on Stanford and software licenses.  Our more
recent stuff, at least in the central IT organization, is using sane MIT
licenses, thank heavens

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: SRP

[Russ Allbery]

MiguelGea <[EMAIL PROTECTED]> writes:

> Hello debian-legal,
> I'm thinking about packaging SRP for debian. 

> Question 1: I'm not sure if there are any problem on packaging it. What
> do you think about?

Please note that SRP is patented; that's part of SRP's licensing that
tends to make people nervous.  The most current information that I have on
the SRP patent is at:



under licensing.  Please see the attached license grant; I haven't
reviewed it to determine whether it is suitable for Debian.  (Note that
there is also some debate over whether other patents cover the same
techniques, about which I cannot comment since I know very little.)

While I am at Stanford, I fear I have no influence over the licensing of
SRP, the status of the patent, or any good way to get more information
that isn't equally accessible to any of you.  I just happen to be fairly
familiar with some of the issues around SRP because it has a long and
controversial history locally here.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: GPL-compatible, copyleft documentation license

[Glenn Maynard]

On Tue, Jul 27, 2004 at 02:53:25AM +0100, Andrew Suffield wrote:
> On Tue, Jul 27, 2004 at 01:13:44AM +0200, Florian Weimer wrote:
> > However, even though the GPL allows for a broad interpretation of
> > "Program", the GPL hasn't been designed to be applied to non-programs
> > which are often distributed in a form that is not machine-readable
> > (see Francesco's message).
> 
> This is a non-issue. It's also silly. There is no infrastructure for
> distributing things that aren't machine-readable in Debian.

I think it's critical that I have permission to sell hardcopies of manuals;
the lack of Debian infrastructure for that doesn't make it any less
important.

(Whether or not this is an issue with using the GPL for manuals, I have
no idea.)

-- 
Glenn Maynard

Re: GPL-compatible, copyleft documentation license

[Evan Prodromou]

Andrew Suffield wrote:


This is a non-issue. It's also silly. There is no infrastructure for
distributing things that aren't machine-readable in Debian.


Well, sometimes we do that T-shirt thing.



We *sell* those :P


/me starts drafting a GR

~ESP


signature.asc
Description: OpenPGP digital signature

Re: GPL-compatible, copyleft documentation license

[Andrew Suffield]

On Mon, Jul 26, 2004 at 09:59:45PM -0400, Evan Prodromou wrote:
> Andrew Suffield wrote:
> 
> >>However, even though the GPL allows for a broad interpretation of
> >>"Program", the GPL hasn't been designed to be applied to non-programs
> >>which are often distributed in a form that is not machine-readable
> >>(see Francesco's message).
> >
> >This is a non-issue. It's also silly. There is no infrastructure for
> >distributing things that aren't machine-readable in Debian.
> 
> Well, sometimes we do that T-shirt thing.

We *sell* those :P

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: GPL-compatible, copyleft documentation license

[Evan Prodromou]

Andrew Suffield wrote:


However, even though the GPL allows for a broad interpretation of
"Program", the GPL hasn't been designed to be applied to non-programs
which are often distributed in a form that is not machine-readable
(see Francesco's message).


This is a non-issue. It's also silly. There is no infrastructure for
distributing things that aren't machine-readable in Debian.


Well, sometimes we do that T-shirt thing.

~ESP


signature.asc
Description: OpenPGP digital signature

Re: RPSL and DFSG-compliance

[Andrew Suffield]

On Mon, Jul 26, 2004 at 03:12:44PM -0700, Rob Lanphier wrote:
> In broad strokes, what we're trying to accomplish with the patent clause
> is this:  we're giving a license to our patents (and our copyright) in
> exchange for not being sued by the licensee over patent infringment. 
> Note that this isn't a license to the licensee's patents.  This just
> basically says that we can revoke our patent grants if the licensee
> chooses to take legal action against us.

That may be what you meant to say, but it's not what the license
actually says. What it currently says is:

If you initiate a lawsuit against anybody that stipulates this program
infringes any patent, then you immediately lose all rights to modify
and distribute the software (would be "use" as well, except that
absent idiotic DMCA-like laws, that can't be restricted).

Which is quite gratuitous.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: GPL-compatible, copyleft documentation license

[Andrew Suffield]

On Tue, Jul 27, 2004 at 01:13:44AM +0200, Florian Weimer wrote:
> However, even though the GPL allows for a broad interpretation of
> "Program", the GPL hasn't been designed to be applied to non-programs
> which are often distributed in a form that is not machine-readable
> (see Francesco's message).

This is a non-issue. It's also silly. There is no infrastructure for
distributing things that aren't machine-readable in Debian.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Termination clauses, was: Choice of venue

[Glenn Maynard]

On Sun, Jul 25, 2004 at 09:15:44AM -0700, Josh Triplett wrote:
> > More clearly (according to my understanding), the resulting binary
> > is--it pulls in pieces of readline--but the source is not.  (I'm not sure
> > if this impacts your point, but it's an important distinction.)
> 
> That's debatable.  If your program is written against a library, and
> there is only one implementation of that library, I would argue that the
> source is a derivative of the library as well.  Things get more complex
> if there are multiple implementations, of course.

LGPL clause 5 seems to express the FSF's view on this, which seems
correct and reasonable to me:

"  5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library".  Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.

  However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library".  The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables."

-- 
Glenn Maynard

Re: [htdig-dev] Licensing issues...

[Glenn Maynard]

On Mon, Jul 26, 2004 at 03:11:52PM -0600, Neal Richter wrote:
> > 2) Can I reasonably argue that htdig is gpl (or lgpl) if its linked
> > against a 3 or a 4 cloause BSD license? - htdig .3.1.6 builds static
> > libraries (.a) it links against.
> 
>   Sure you can!
> 
>   Note that although the Free Software Foundation may say that a 4-clause
> BSD license is incompatible with the GPL (and they do). that opinion only
> applies to code that the FSF holds the copyright for.

Not quite.  I believe that opinion derives directly from the text of the
license.  The GPL prohibits adding further restrictions (GPL#6), and the
4-clause BSD license does so.  Unless a copyright holder specifically says
that he considers the 4-clause BSD license consistent with the GPL, it's
not safe for Debian to assume otherwise.

That is, the "default" interpretation, lacking a statement from (all of)
the copyright holders of a work, should be the one that follows from the
license text, and that's the FSF's interpretation, at least in this case.

>   As a matter of copyright law, any copyright holder that licenses their
> code under the GPL is free to interpret the GPL themselves.  And if that
> person/group decides that a 4-clause BSD license is OK to include in THEIR
> code... then the FSF's opinion on license compatibility is irrelevant
> legally.

Right.  However, if a license clarification doesn't follow from the license
text, and/or differs from the common interpretation, then we must be careful.
For example, if somebody licenses their work under the GPL, and says "by my
interpretation of the GPL, you don't have to make source available to people
you send binaries to", then their stated interpretation is clearly inconsistent
with the actual text of the license.  In those cases, it's best to step
carefully and conservatively.

My recommendation to those authors would be to issue a specific exception,
to the effect of "advertising clauses are permitted without being in
violation of GPL#6", rather than using an unusual interpretation of the
GPL itself.

I'm sure somebody else on d-legal can offer a better statement than I can,
though.

>   Note that I intend no disrespect for any FSF people on this list!  This
> is just basic copyright law.  A third party can't dictate how a copyright
> holder interprets any license to it's own code.

And I no disrespect for the authors of htdig, of course.  It's just best to
be careful and explicit with issues like this.

For example, all (known) GPL projects in Debian which link against OpenSSL
have such an exception, because it has an advertising clause, as well as
forced-renaming and a forced-acknowledgement clauses.

-- 
Glenn Maynard

Re: GPL-compatible, copyleft documentation license

[Florian Weimer]

* Andrew Suffield:

> All of which is belied by the fact that the GPL contains a very
> careful definition of "Program" which has obviously been crafted to
> apply to any literary work.

The definition of "Program" in the GPL is about as precise as the
definition of "Point" in Euclidean Geometry.

However, even though the GPL allows for a broad interpretation of
"Program", the GPL hasn't been designed to be applied to non-programs
which are often distributed in a form that is not machine-readable
(see Francesco's message).

Re: Web application licenses

[Florian Weimer]

* Josh Triplett:

> How about something vaguely like:
>
> """
> If you make the software or a work based on the software available for
> direct use by another party, without actually distributing the software
> to that party, you must either:
>
> a) Distribute the complete corresponding machine-readable source code
> publically under this license, or
> b) Make the source code available to that party, under the all the same
> conditions you would need to meet in GPL section 3 if you were
> distributing a binary to that party.
> """

I can understand the rationale behind such clauses, but I consider
them a severe threat to free software.  Right now, I'm not forced to
deal with license issues if I'm not distributing anything, and I
really like this aspect.

Re: RE-PROPOSED: The Dictator Test

[Florian Weimer]

* Branden Robinson:

> On Mon, Jul 12, 2004 at 10:02:25AM +0200, Florian Weimer wrote:
>> I think the Dictator Test itself is highly questionable, and even more
>> its rationale.  It's a disguised attack on copyleft in general.
>
> As the proposer of the Dictator Test, I call bullshit.
>
> I'm perfectly happy with the concept of copyleft, and endorse it.

In this case, you should reword the rationale:

| License grantors do not have a private right of legislation; that
| is, they are not dictators who can subject you to their personal
| jurisdiction through a license.

This is awfully similar to another line of reasoning which basically
claims that the GPL is void because it tries to seize legislative
power from Congress (and quite frankly, it does to some extent).

> I'll thank you to not profess to being able to read my mind when you
> clearly cannot.

Please give us a better rationale for the test, or better, propose a
version of the test that doesn't rule out any licenses that are widely
accepted to be free software licenses.

The GPL fails it for another reason: If I distribute GPLed software
and I'm not its sole author, the GPL prevents me from settling
independently any patent infringement claims concerning the software.
This is clearly a non-copyright restriction imposed by a copyright
license.

Re: The Sv*n L*th*r drinking game

[Lewis Jardine]

Sven Luther wrote:

On Sun, Jul 25, 2004 at 10:15:23AM -0700, Josh Triplett wrote:


I apologize if I failed to respond to arguments in your initial mail; I
can assure you it was not intentional.  Unfortunately, I cannot seem to
find the subthread you are referring to.


My post may have been : Message-ID: <[EMAIL PROTECTED]>
And your reply to it was : Message-ID: <[EMAIL PROTECTED]>

And said :

  debian-legal is currently analyzing the QPL, and working on a license
  summary.  See http://lists.debian.org/debian-legal/2004/07/msg00157.html
  for the DRAFT summary, and feel free to offer your comments,
  suggestions, or statements of whether the draft represents your
  position.  The consensus seems to be that the license is non-free, and
  the only thing left is to work out the full details of the summary.  I
  am currently writing the second draft, based on the responses to the first.

  It would certainly be reasonable to wait until the summary is completed
  before acting on this bug.

  Also, to the best of my knowledge, programs under only the QPL are rare
  in Debian.

  (Incidentally, a quick grep through /usr/share/doc/*/copyright on my
  system to check that statement turned up mdetect, which appears to be
  mixing QPLed and GPLed code in the same program.)

So, you clearly dismisses my arguments, even if those where weak since it was
in early participation to this, and may have missed some argumentation, and
was already passably irritated with Brian over this.

In particular the " The consensus seems to be that the license is non-free,
and the only thing left is to work out the full details of the summary.",
Seemed a bit harsh and premature to me, given that you ignored my objections.

Friendly,

Sven Luther




If you read the original post (
http://lists.debian.org/debian-legal/2004/07/msg00424.html ) carefully,
you'll find that the real arguments are hidden in the quoted message
appended to the post. Quite easily missable, in my opinion.

The only argument in the first two paragraphs (


I don't know why, but Brian has been bothering me about claiming the
QPL is non-free. I agree with the emacs thing, and am working on a
solution to it when time permits, and upstream has also agreed to it
in principle, so this should be solved before the now imminent
(whatever this means for debian release cycle :) sarge release.

Anyway, it would rightly surprise me if the QPL would be reveled
non-free after all this years of use and the KDE controversy it was
linked to, and i believe that we have more than just ocaml as QPLed
programs in debian. So i request the help of debian-legal to help me
clarify this thing, and either make an official statement that the QPL
is non-free, or shut Brian up, and let me back to work on my packages.


) is that the QPL must be free, as it has been considered by many to be
free for ages. This is, I believe, the fallacy of "Appeal to Common
Practice".

There are other, non-fallacious arguments in the body of the quoted
message, but I suspect many people didn't realise they were there.

Also, "shut Brian up, and let me back to work on my packages." is, in my
opinion, a rather hostile phrase to use when opening a conversation.
--
Lewis Jardine
IANAL IANADD

Re: RPSL and DFSG-compliance

[Rob Lanphier]

Hi Matthew,

Yes, it probably was me you spoke to at GUADEC, though there were so
many new faces, I have to admit to losing track of everyone I met.

In broad strokes, what we're trying to accomplish with the patent clause
is this:  we're giving a license to our patents (and our copyright) in
exchange for not being sued by the licensee over patent infringment. 
Note that this isn't a license to the licensee's patents.  This just
basically says that we can revoke our patent grants if the licensee
chooses to take legal action against us.

It's hard to be more specific than that.  I could envision us narrowing
the scope to "software patents" or something along those lines, but
beyond that, it's very difficult to be more narrow without unilaterally
disarming ourselves in a defensive patent stand.

Rob

On Mon, 2004-07-26 at 13:17, Matthew Garrett wrote:
> Rob Lanphier <[EMAIL PROTECTED]> wrote:
> 
> > I would love to work with the Debian project on making sure RPSL is
> > Debian-free.  However, it makes it really difficult to engage the
> > RealNetworks Legal department when there's a lot of discussion about
> > personal tastes, but no mapping back to DFSG clauses.  That just makes
> > everyone here believe that there will be an endless stream of
> > manufactured excuses as to why future versions of the RPSL will also not
> > be considered Debian-free.
> 
> Hi Rob,
> 
> I think I spoke to you at GUADEC, though I had enough of a headache the
> next morning that I could easily be mistaken.
> 
> As others have pointed out, the RPSL requires widespread provision of
> source even if you're not distributing binaries to the world. I don't
> think that's a problem. Others disagree. It's certainly not clearly tied
> to the DFSG except in slightly tortuous ways.
> 
> What is possibly more of a problem is the patent termination stuff. You
> could argue that it discriminates against a field of endeavour (ie,
> people who have created patents that Real happen to be in violation of)
> - I think this is less tenuous than making the same claim for the
> dissident test (which isn't actually the license discriminating against
> people, it's their own government). Effectively, the license as it
> stands allows Real to make use of other people's intellectual property
> without their consent if the patent holder's business model (or
> whatever) happens to depend on using the Helix code. 
> 
> Obviously Real want to be able to protect themselves against patent
> actions. I'm not convinced that doing so in the way the RPSL does is the
> best way of doing so. If we set aside the desert island/dissident stuff,
> would you be willing to discuss what Real want to achieve by the patent
> clauses so we can try to find some sort of acceptable terms?
> 
> New licenses seem very keen on providing patent termination clauses.
> It's really a discussion that we have to have at some point, especially
> since the DFSG as it currently stands really doesn't cover the area too
> well.
-- 
Rob Lanphier, Development Support Manager - RealNetworks
Helix Community: http://helixcommunity.org 
Development Support:
http://www.realnetworks.com/products/support/devsupport

Re: RPSL and DFSG-compliance

[Rob Lanphier]

Hi Brian,

Thanks for the detailed reply.  Some comments inline.  Some will have to
wait for later, as there's a lot going on here in the next couple of
weeks (two conferences, and we're short staffed...if anyone is
interested in a job in Seattle, drop me a line...)

On Mon, 2004-07-26 at 13:26, Brian Thomas Sniffen wrote:
> Wow!  I hadn't realized there was somebody from Real interested in
> addressing this.  If there's a prospect of seeing the RPSL evolve into
> something Debian can consider free, that's likely to motivate a *lot*
> more work from those here.

Glad to hear that.

> Given that gloomy warning, let's dive in to some specific problems:
> 
> RPSL 1 says that nothing grants me permission to use the software.
> That's not true.  US copyright law doesn't restrict that, and the
> contract of sale under which I bought a CD containing the software --
> or downloaded it -- gives me that permission.  If you take the word
> "use" out of there, that problem goes away.  Take a look at how the
> GPL phrases a similar clause.  In general, similarity makes analysis
> much, much easier.  This doesn't really tie back to any DFSG points,
> it's just one of those points so obvious it isn't written.  The
> software has to be usable; also, if the license says things which are
> blatantly not true, we can't be sure that the licensor has anything
> like the same understanding of copyright law we have.

One key difference between the GPL and RPSL is that the GPL deals
strictly with copyright, whereas RPSL deals with copyright and patents. 
RealNetworks is specifically granting patent rights in section 2.3, and
restricts use as covered under those patent rights.

> RPSL 1 also says that acceptance is indicated by clicking an "Accept"
> button or downloading the software; that binds mirrors and all sorts
> of other people who distribute Debian software blind to this license.
> Given the bulk of section 1, this last part ("In addition...software")
> really doesn't help Real at all, does it?

That's not a terribly important clause in the license, but not one that
we're inclined to take out, either.  As far as I'm recall, there's not
any clause requiring distributors to present users with a clickwrap.

> RPSL 1.7 defines "Externally Deploy" in ways that are going to matter
> later.  The easiest way to clean those up *may* be by fixing this
> definition.  If I put some data into a video file, wait a month, then
> stream it out and watch it using Helix DNA, and having thus jogged my
> memory I provide a service to somebody else, it looks like that counts
> as External Deployment.  That seems like *any* deployment, if I
> interact with others or provide services to them, is External
> Deployment.  This definition isn't necessarily non-free, depending on
> what's below.  But we'll get to that later.
> 
> RPSL 1.5 and 1.11 define Personal Use.  Because DFSG 6 prohibits
> discrimination by endeavor, we can't use *anything* which is only
> granted for personal use.  Those grants, generous as they are and as
> much as I do use them in my personal work, don't count for making the
> software Free.

The idea behind 1.5 and 1.11 is to define what it means to Deploy, so
that it's clear what it means to "Externally Deploy" as defined in 1.8. 
It doesn't discriminate against external deployment, since external
deployment is allowed.  It calls for the release of source code upon
external deployment.

The rest of my reply will have to wait for later, I'm afraid.

Rob

> RPSL 2.1a *might* be non-free.  It prohibits some sorts of
> modifications -- not only those necessary to prevent fraud and
> preserve copyright notices, but many others.  It depends on whether
> there are notices in the original code which refer to the license, and
> which serve some functional purpose.  If they're just in comments,
> then this is a no-op -- I hope you wouldn't mind altering it, in that
> case, since it isn't gaining you anything either.  But if it prevents
> some functional modifications from being made, then it's certainly
> non-free.
> 
> RPSL 2.1d is going to be the Big Problem, isn't it?  That's really the
> teeth of the meta-copyleft in the RPSL, and I imagine it's very
> important to Real that it continue in its effect.  But I don't see any
> way to call it Free.  I expect several other debian-legal regulars to
> jump in and disagree at this point, and maybe we'll convince each
> other and can then get back to you.
> 
> But here's my draft of what's non-free about RPSL 2.1d:
> 
> > You must make Source Code of all Your Externally Deployed
> > Modifications publicly available under the terms of this License,
> > including the license grants set forth in Section 3 below, for as
> > long as you Deploy the Covered Code or twelve (12) months from the
> > date of initial Deployment, whichever is longer.
> 
> The timing is a problem.  That means that I can have forsworn
> computers entirely, and yet be obliged to lug around some vast lump of
> code to d

Re: DRAFT: debian-legal summary of the QPL

[Glenn Maynard]

On Mon, Jul 26, 2004 at 03:50:22PM -0400, David Nusinow wrote:
> I'm not sure I agree here. I feel like the DFSG has special casing of
> individual clauses scattered throughout the document, such as 6 and 8, and 
> that
> adding a choice of venue clause guideline would fit with those just fine. That

We can skip debating this for now ...

> said, I'd rather any sort of amendment be written according to the real meat 
> of
> the issue, rather than simply saying "The license can't have a choice of venue
> clause."

... because that's the more fundamental issue that was bothering me, and one
which we're agreed on.

-- 
Glenn Maynard

Re: RPSL and DFSG-compliance

[Matthew Garrett]

Rob Lanphier <[EMAIL PROTECTED]> wrote:

> I would love to work with the Debian project on making sure RPSL is
> Debian-free.  However, it makes it really difficult to engage the
> RealNetworks Legal department when there's a lot of discussion about
> personal tastes, but no mapping back to DFSG clauses.  That just makes
> everyone here believe that there will be an endless stream of
> manufactured excuses as to why future versions of the RPSL will also not
> be considered Debian-free.

Hi Rob,

I think I spoke to you at GUADEC, though I had enough of a headache the
next morning that I could easily be mistaken.

As others have pointed out, the RPSL requires widespread provision of
source even if you're not distributing binaries to the world. I don't
think that's a problem. Others disagree. It's certainly not clearly tied
to the DFSG except in slightly tortuous ways.

What is possibly more of a problem is the patent termination stuff. You
could argue that it discriminates against a field of endeavour (ie,
people who have created patents that Real happen to be in violation of)
- I think this is less tenuous than making the same claim for the
dissident test (which isn't actually the license discriminating against
people, it's their own government). Effectively, the license as it
stands allows Real to make use of other people's intellectual property
without their consent if the patent holder's business model (or
whatever) happens to depend on using the Helix code. 

Obviously Real want to be able to protect themselves against patent
actions. I'm not convinced that doing so in the way the RPSL does is the
best way of doing so. If we set aside the desert island/dissident stuff,
would you be willing to discuss what Real want to achieve by the patent
clauses so we can try to find some sort of acceptable terms?

New licenses seem very keen on providing patent termination clauses.
It's really a discussion that we have to have at some point, especially
since the DFSG as it currently stands really doesn't cover the area too
well.
-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: handling Mozilla with kid gloves [was: GUADEC report]

[Branden Robinson]

On Mon, Jul 19, 2004 at 01:30:36PM -0500, Branden Robinson wrote:
> I'll do this in the next day or so.

It took me a week to get to this, but I've done it (message attached).
I'll pass along whatever I learn.

-- 
G. Branden Robinson|  When dogma enters the brain, all
Debian GNU/Linux   |  intellectual activity ceases.
[EMAIL PROTECTED] |  -- Robert Anton Wilson
http://people.debian.org/~branden/ |
--- Begin Message ---
Mr. Markham,

First of all, my apologies for sending this unsolicited mail.

I'm a developer for the Debian Project[1], and in the course of a recent
discussion, some of us became curious as to what the progress of the
triple-licensing effort was.

I did attempt to research the answer for myself.  I checked the minutes of
the weekly Mozilla staff meetings, and found that on 24 November 2003[2], it
was believed that all necessary permissions had been obtained.

Later, in January, I understand that you said in an email discussion that
the relicensing was well underway, and that the only files you couldn't get
permission to relicense were not important[3].

I've looked for more information, and I did check the Mozilla Relicensing
FAQ[4], but it claims to have not been updated since 7 December, and I
cannot determine the current status of the relicensing.  I also checked the
"copyright" file of Debian's mozilla-browser package, but it is either
outdated, or perhaps that something has held up the relicensing effort:

  Some files in this source package are under the Netscape Public License
  Others, under the Mozilla Public license, and just to confuse you even·
  more, some are dual licensed MPL/GPL.

Given the content of the Relicensing FAQ, I suspect this information is out
of date, so I am CCing the Debian Mozilla package maintainers.

If you could advise me where to look for the answers I seek, I sure would
appreciate it.  I'm sorry to take up your time with this.

[1] http://www.debian.org/
[2] http://groups.google.com/groups?as_umsgid=3FCB8B00.5070604%40mozilla.org
[3] 
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=3FFC952B.2020302%40mozilla.org
[4] http://www.mozilla.org/MPL/relicensing-faq.html

-- 
G. Branden Robinson|  The more you do, the more people
Debian GNU/Linux   |  will dislike what you do.
[EMAIL PROTECTED] |  -- Gerfried Fuchs
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature
--- End Message ---


signature.asc
Description: Digital signature

Re: RPSL and DFSG-compliance

[Andrew Suffield]

On Mon, Jul 26, 2004 at 04:26:39PM -0400, Brian Thomas Sniffen wrote:
> RPSL 2.1a *might* be non-free.  It prohibits some sorts of
> modifications -- not only those necessary to prevent fraud and
> preserve copyright notices,

Not that such restrictions are okay, or even necessary. These things
were illegal to start with. They do not become *more* illegal because
the license says something about them.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: MySQL FOSS Exception

[Jim Marhaus]

Andreas wrote:

>>> The MySQL folks have a *new* statement [...]
> http://zak.greant.com:/licensing/rlog?f=licensing/FLOSS-exception.txt

I think requirement 0.b(ii), as introduced in version 1.5 of the exception,
might need extra work to fulfill, since Debian vendors do not always provide
source and binaries on the same medium:

| 0. You are free to distribute a Derivative Work that is formed entirely from
|   the Program and one or more works (each, a "FLOSS Work") licensed under
|   one or more of the licenses listed below in section 1, as long as:

|   b. all identifiable sections of the Derivative Work which are not
|  derived from the Program, and which can reasonably be considered
|  independent and separate works in themselves,
|
|   (i) are distributed subject to one of the FLOSS licenses listed
|   below, and
|
|  (ii) the object code or executable form of those sections are
|   accompanied by the complete corresponding machine-readable
|   source code for those sections on the same medium and under the
---^^
|   same FLOSS license as the corresponding object code or
|   executable forms of those sections, and

For example, if proftpd-mysql were distributed under this exception, vendors
might have to provide the source for proftpd-mysql on the same CD (or CD set)
as the executable. The requirement might also affect how the work can be
distributed online: for example, source and binaries might have to be provided
on the same server, or through the same protocol.

-Jim

Re: RPSL and DFSG-compliance

[Brian Thomas Sniffen]

Wow!  I hadn't realized there was somebody from Real interested in
addressing this.  If there's a prospect of seeing the RPSL evolve into
something Debian can consider free, that's likely to motivate a *lot*
more work from those here.

I should preface what I'm about to say with this:  the DFSG do not
have exclusive requirements.  There are many non-free licenses which
do not violate any points of the DFSG -- for example, a license which
allowed all those freedoms in the dfsg, but said users must pay $1
to the author before running the program would be non-free.
Similarly, a license which let you use the program as much as you
want, but claimed to demand $1 before letting you *terminate* the
program would be non-free.

Some things, like the right to use the software, are so obviously
necessary to freedom of software that they were never written down in
the DFSG.  But maybe the RPSL won't turn out to have any problems like
that.  I hope it won't.  But I'd feel dishonest if I didn't start out
with this sort of sentence, and then found such problems.

Given that gloomy warning, let's dive in to some specific problems:

RPSL 1 says that nothing grants me permission to use the software.
That's not true.  US copyright law doesn't restrict that, and the
contract of sale under which I bought a CD containing the software --
or downloaded it -- gives me that permission.  If you take the word
"use" out of there, that problem goes away.  Take a look at how the
GPL phrases a similar clause.  In general, similarity makes analysis
much, much easier.  This doesn't really tie back to any DFSG points,
it's just one of those points so obvious it isn't written.  The
software has to be usable; also, if the license says things which are
blatantly not true, we can't be sure that the licensor has anything
like the same understanding of copyright law we have.

RPSL 1 also says that acceptance is indicated by clicking an "Accept"
button or downloading the software; that binds mirrors and all sorts
of other people who distribute Debian software blind to this license.
Given the bulk of section 1, this last part ("In addition...software")
really doesn't help Real at all, does it?

RPSL 1.7 defines "Externally Deploy" in ways that are going to matter
later.  The easiest way to clean those up *may* be by fixing this
definition.  If I put some data into a video file, wait a month, then
stream it out and watch it using Helix DNA, and having thus jogged my
memory I provide a service to somebody else, it looks like that counts
as External Deployment.  That seems like *any* deployment, if I
interact with others or provide services to them, is External
Deployment.  This definition isn't necessarily non-free, depending on
what's below.  But we'll get to that later.

RPSL 1.5 and 1.11 define Personal Use.  Because DFSG 6 prohibits
discrimination by endeavor, we can't use *anything* which is only
granted for personal use.  Those grants, generous as they are and as
much as I do use them in my personal work, don't count for making the
software Free.

RPSL 2.1a *might* be non-free.  It prohibits some sorts of
modifications -- not only those necessary to prevent fraud and
preserve copyright notices, but many others.  It depends on whether
there are notices in the original code which refer to the license, and
which serve some functional purpose.  If they're just in comments,
then this is a no-op -- I hope you wouldn't mind altering it, in that
case, since it isn't gaining you anything either.  But if it prevents
some functional modifications from being made, then it's certainly
non-free.

RPSL 2.1d is going to be the Big Problem, isn't it?  That's really the
teeth of the meta-copyleft in the RPSL, and I imagine it's very
important to Real that it continue in its effect.  But I don't see any
way to call it Free.  I expect several other debian-legal regulars to
jump in and disagree at this point, and maybe we'll convince each
other and can then get back to you.

But here's my draft of what's non-free about RPSL 2.1d:

> You must make Source Code of all Your Externally Deployed
> Modifications publicly available under the terms of this License,
> including the license grants set forth in Section 3 below, for as
> long as you Deploy the Covered Code or twelve (12) months from the
> date of initial Deployment, whichever is longer.

The timing is a problem.  That means that I can have forsworn
computers entirely, and yet be obliged to lug around some vast lump of
code to distribute.  What happens if a patent's granted on that?  Then
I can't distribute it without breaking the law, but can't stop without
breaking the license.  That doesn't even reach to the DFSG level.

Additionally, forced distribution for using modifications is itself
non-free.  This can be drawn back to several points of the DFSG: the
unfortunately-fuzzy Discrimination clauses:

  5. No Discrimination Against Persons or Groups: The license must not
 discriminate against any person or 

Re: DRAFT: debian-legal summary of the QPL

[David Nusinow]

On Mon, Jul 26, 2004 at 02:25:13PM -0400, Glenn Maynard wrote:
> On Sun, Jul 25, 2004 at 11:02:57PM +0100, Steve McIntyre wrote:
> > After some discussion, if there is significant opinion here that such
> > a clause *is* non-free, a DFSG change should be proposed to make that
> > explicit. That way we can get the opinion and mandate of the general
> > population of DDs to *actually* *explicitly* claim that such clauses
> > are non-free. When something is in the DFSG, we have much more of a
> > case to make to upstream authors than " on debian-legal doesn't
> > like it.
> > 
> > I'm not saying that disagreement *itself* should cause a GR (as
> > somehow you seemed to believe I was saying). Do you understand me now?
> 
> Regardless of the trigger, adding "choice of venue is non-free" to the
> DFSG will start a tendency to enumerate non-free things.  Adjusting the
> DFSG to better express our intentions is useful; special casing individual
> clauses is a hack.

I'm not sure I agree here. I feel like the DFSG has special casing of
individual clauses scattered throughout the document, such as 6 and 8, and that
adding a choice of venue clause guideline would fit with those just fine. That
said, I'd rather any sort of amendment be written according to the real meat of
the issue, rather than simply saying "The license can't have a choice of venue
clause."

 - David Nusinow

Re: RPSL and DFSG-compliance

[Evan Prodromou]

Rob Lanphier wrote:


I would really like someone to map one of the cited problems with the
RPSL to a stated requirement in the DFSG.


It's understandably frustrating to come into a debian-legal discussion about a 
license without having been on the list for a while, since in fact we don't 
usually reference DFS guidelines by name.


Most problems with licenses map either to DFSG 1 (distribution) or DFSG 3 
(modified versions). A key part of discussions here is deciding whether 
restrictions imposed on licensees raise the bar too high for them to 
realistically exercise the freedom to distribute and modify.  When a license 
says, "You can distribute as long as you do X, Y, and Z", we need to evaluate 
whether X, Y and Z are too heavy a restriction to be acceptable under DFSG 1.



That just makes
everyone here believe that there will be an endless stream of
manufactured excuses as to why future versions of the RPSL will also not
be considered Debian-free.


I don't think our project has any interest in keeping RPSL-licensed packages out 
of Debian. We don't usually like new licenses, not least because they make us 
slog through a lot of legalese and have long boring discussions about various 
minutiae. But if a package is Free Software, it's usually accepted into Debian.


It's also probably worth waiting until there's at least a draft summary of the 
license before responding or making changes to the license. Discussions like 
this take time.


~ESP


signature.asc
Description: OpenPGP digital signature

Re: DRAFT: debian-legal summary of the QPL

[Glenn Maynard]

On Sun, Jul 25, 2004 at 11:02:57PM +0100, Steve McIntyre wrote:
> There might be a case where we are seeing a common clause in licenses
> where there is significant belief on -legal that it might make a
> license non-free but it cannot be clearly, explicitly (unanimously?)
> tied back to existing clauses in the DFSG. Current topical examples
> would "choice of venue" and "clashes with some national laws".
> 
> After some discussion, if there is significant opinion here that such
> a clause *is* non-free, a DFSG change should be proposed to make that
> explicit. That way we can get the opinion and mandate of the general
> population of DDs to *actually* *explicitly* claim that such clauses
> are non-free. When something is in the DFSG, we have much more of a
> case to make to upstream authors than " on debian-legal doesn't
> like it.
> 
> I'm not saying that disagreement *itself* should cause a GR (as
> somehow you seemed to believe I was saying). Do you understand me now?

Regardless of the trigger, adding "choice of venue is non-free" to the
DFSG will start a tendency to enumerate non-free things.  Adjusting the
DFSG to better express our intentions is useful; special casing individual
clauses is a hack.

> Quite. As time goes on with me following -legal, I'm understanding
> more and more why most DDs really have no inclination to pay any
> attention at all to the pointless discussions that go on here. The
> rest of Debian actually gets on with productive work...

As does d-legal.  (By your tone, you clearly have no interest in being
convinced otherwise, so I won't waste time debating this.)

-- 
Glenn Maynard

Re: RPSL and DFSG-compliance

[Andrew Suffield]

On Mon, Jul 26, 2004 at 11:44:32AM -0700, Rob Lanphier wrote:
> I would really like someone to map one of the cited problems with the
> RPSL to a stated requirement in the DFSG.

Trying to treat the DFSG as a set of rules *will not work*. That's
what the "G" means. It's not written in that style and nobody really
knows how to do it; furthermore, that road leads to an endless arms
race.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: RPSL and DFSG-compliance

[Rob Lanphier]

I would really like someone to map one of the cited problems with the
RPSL to a stated requirement in the DFSG.  We might be willing to engage
in a conversation about changing the RPSL, but not in an environment
where it is clearly subject to the whims of whoever happens to be
discussing the issues on the list.

I would love to work with the Debian project on making sure RPSL is
Debian-free.  However, it makes it really difficult to engage the
RealNetworks Legal department when there's a lot of discussion about
personal tastes, but no mapping back to DFSG clauses.  That just makes
everyone here believe that there will be an endless stream of
manufactured excuses as to why future versions of the RPSL will also not
be considered Debian-free.

Rob

On Mon, 2004-07-26 at 11:31, Brian Thomas Sniffen wrote:
> Thomas Maurer <[EMAIL PROTECTED]> writes:
> 
> > Well, thanks to all repliers, unfortunately the useful answer to my
> > question has missed. You're replies don't really help me, so if someone
> > finds the time to give me a short answer what I should do, then I would
> > be happy. Otherwise I rely on the statements of Rob Lanphier and put the
> > helix stuff into main.
> 
> It's non-free, but appears distributable -- though more on that
> later.  It claims to restrict use of the software, which is non-Free.
> It restricts how lawsuits can happen between those bound by the
> license, which is also non-Free.  And it requires that "externally
> deployed" code be distributed -- so if I use it to set up some big
> televisions showing data provided through this system, I have to
> provide all my modifications despite the fact that nobody but me gets
> to see the network -- just lots of people looking at the TVs.  That
> isn't *clearly* non-free.  There are people here who will argue that
> it is OK.  But there are a lot of people here who think that is non-free,
> and have moderately compelling arguments.
> 
> Fortunately, from a rhetorical point of view, there are enough other
> problems with this license that it is clearly non-free.
> 
> -Brian
> 
> -- 
> Brian Sniffen   [EMAIL PROTECTED]
-- 
Rob Lanphier, Development Support Manager - RealNetworks
Helix Community: http://helixcommunity.org 
Development Support:
http://www.realnetworks.com/products/support/devsupport

Re: RPSL and DFSG-compliance

[Brian Thomas Sniffen]

Thomas Maurer <[EMAIL PROTECTED]> writes:

> Well, thanks to all repliers, unfortunately the useful answer to my
> question has missed. You're replies don't really help me, so if someone
> finds the time to give me a short answer what I should do, then I would
> be happy. Otherwise I rely on the statements of Rob Lanphier and put the
> helix stuff into main.

It's non-free, but appears distributable -- though more on that
later.  It claims to restrict use of the software, which is non-Free.
It restricts how lawsuits can happen between those bound by the
license, which is also non-Free.  And it requires that "externally
deployed" code be distributed -- so if I use it to set up some big
televisions showing data provided through this system, I have to
provide all my modifications despite the fact that nobody but me gets
to see the network -- just lots of people looking at the TVs.  That
isn't *clearly* non-free.  There are people here who will argue that
it is OK.  But there are a lot of people here who think that is non-free,
and have moderately compelling arguments.

Fortunately, from a rhetorical point of view, there are enough other
problems with this license that it is clearly non-free.

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]

Re: RPSL and DFSG-compliance

[Thomas Maurer]

Well, thanks to all repliers, unfortunately the useful answer to my
question has missed. You're replies don't really help me, so if someone
finds the time to give me a short answer what I should do, then I would
be happy. Otherwise I rely on the statements of Rob Lanphier and put the
helix stuff into main.

Thanks,

Thomas

Re: Web application licenses

[Brian Thomas Sniffen]

Andrew Suffield <[EMAIL PROTECTED]> writes:

> On Mon, Jul 26, 2004 at 10:22:37AM -0400, Brian Thomas Sniffen wrote:
>> I just don't see how compelling source
>> distribution from a networked provider actually increases freedom --
>> since I don't care about changing the code I have, I care about
>> changing the code *they* have.
>
> Here's the loophole:
>
> Take a GPLed application. Modify it. Do not release the source, or the
> binaries. Run the application on your own servers, and sell accounts
> to use it (via ssh, vnc, or whatever).

Yes, that's fine.  I don't see that as a loophole.  Because you're not
just providing me with access to the program -- you're providing the
CPU cycles to run it, and maybe the database it operates on, and
access to other resources which are important for its operation.

And you've got to *keep* deploying more servers to make this work, and
can't sell or rent any of these servers to others without your code
getting out.  Several people tried this model during the .com boom.
It didn't work.  They ended up switching to entirely proprietary
software so they could lease and sell hardware without losing control
of their code.

> All these sort of licenses are trying to block this, and variations on
> it. I've never actually seen one that worked without being grossly
> overbearing to the point of being non-free.

Even if that business model did work, and this were an active threat
to freedom, how does forcing distribution of the source code get
freedom to the users?  If it did, as in the case of the GPL -- they
already have and can run the software, so getting them source lets
them modify it -- then I'd reluctantly support this.  I'd believe you
when you say it's necessary to protect freedom.

But in the current circumstances, I don't see anybody losing freedom
to this hole, and I don't see a way to get those hypothetical people
freedom by compelling source distribution

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]

Re: Web application licenses

[Andrew Suffield]

On Mon, Jul 26, 2004 at 10:22:37AM -0400, Brian Thomas Sniffen wrote:
> I just don't see how compelling source
> distribution from a networked provider actually increases freedom --
> since I don't care about changing the code I have, I care about
> changing the code *they* have.

Here's the loophole:

Take a GPLed application. Modify it. Do not release the source, or the
binaries. Run the application on your own servers, and sell accounts
to use it (via ssh, vnc, or whatever).

All these sort of licenses are trying to block this, and variations on
it. I've never actually seen one that worked without being grossly
overbearing to the point of being non-free.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: ocaml, QPL and the DFSG : QPL 3b argumentation.

[Sven Luther]

On Mon, Jul 26, 2004 at 11:05:09AM -0400, Brian Thomas Sniffen wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > If they did not pick on this, there is sane reason to say this is
> > ok.
> 
> I don't think that is a safe assumption to make in the general case,
> and I know it doesn't apply here.
> 
> Immutable notices have been rejected from Debian before, for this same reason.

So propose something reasonable with as little as possible change of wording.
> 
> > We should concentrate on the real problems, namely the clause of
> > venue and QPL 6c, which i have ground to believe will be no problem
> > for upstream anymore, altough i have no official answer yet, and QPL
> > 3b, which still remains problematic.
> 
> Does that actually mean QPL 6 will be removed from the OCaml license?
> Oh Frabjuous Day!
> 
> Or just QPL 6c?  That would not be frabjuous, but I still might
> callay.

The jury is still out, but there is chance that it may move in the good
direction. Now, i think removing just QPL 6c is better than removing all of
QPL 6, since QPL 6a+b allow you to distributed linked work under any free
licence, while you would have to QPL it under QPL3 only.

> >> My assumption is that they wanted to ban certain modifications of
> >> their work, and were more concerned about maximizing credit than
> >> writing free software.
> >
> > They just wanted to make sure someone didn't remove the copyright notice, or
> > alter it to remove older contributors. Adding new contributors should be
> > permitted, but that is the extent of it. 
> 
> Yes, but a ban on removing all and any copyright notices is not Free.
> It's fine for an author to require that there *be* a copyright notice,
> but forbidding translation or addition is not Free.

So, find a wording saying that you can only add or translate or something
such.

> Requiring a specific dialog box isn't either -- it doesn't translate
> to systems without a GUI.  Requiring specific text output also isn't
> free, as it doesn't work with non-interactive or embedded systems.

What has that to do with it here ? 

Friendly,

Sven Luther

Re: ocaml, QPL and the DFSG : QPL 3b argumentation.

[Brian Thomas Sniffen]

Sven Luther <[EMAIL PROTECTED]> writes:

>> And if you don't want to deal with binaries there, then rip that
>> clause off and just say:
>> 
>> "You must include an appropriate, accurate, and complete copyright
>> notice on each source file."
>
> But what is an accurate, appropriate and complete copyright notice ? 

There are lots.  The statement I wrote is intentionally definitive,
not proscriptive.  It tells you what must be the case, not how to do
it.  It's like functional programming for licenses.

For any (copyright notice, work) pair, it is clear whether it is
accurate, appropriate, and complete.  True, it provides no guidance
about how to write one -- but that's intentional.  In most cases,
adding your own name to the notice in modified files is probably the
right choice.  But the license shouldn't tell you to do that, just
describe what must happen and let the end-user or modifier do it.

That way, the license easily adapts to unanticipated technologies or
freedoms, or to unanticipated uses of the work.

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]

Re: ocaml, QPL and the DFSG : QPL 3b argumentation.

[Sven Luther]

On Mon, Jul 26, 2004 at 11:00:01AM -0400, Brian Thomas Sniffen wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> >> "You must include appropriate and accurate copyright notices on each
> >> source file, and in a reasonable and appropriate place in any binary
> >> file."
> >
> > Not clear enough. A quick reader would read that you can replace the 
> > copyright
> > notice by another. Also, QPL 3 deals with source modification and
> > distribution as patches, not binaries.
> 
> Well, you can -- as long as it's appropriate and accurate.  If I take
> Linux and write "Copyright (c) 1902 Brian Sniffen" on it, that's not
> appropriate or accurate, is it?

Sure, but it is best to clarify it, or we will get another flamewar about it a
few years from now.

> And if you don't want to deal with binaries there, then rip that
> clause off and just say:
> 
> "You must include an appropriate, accurate, and complete copyright
> notice on each source file."

But what is an accurate, appropriate and complete copyright notice ? 

Friendly,

Sven Luther

Re: ocaml, QPL and the DFSG : QPL 3b argumentation.

[Brian Thomas Sniffen]

Sven Luther <[EMAIL PROTECTED]> writes:

> If they did not pick on this, there is sane reason to say this is
> ok.

I don't think that is a safe assumption to make in the general case,
and I know it doesn't apply here.

Immutable notices have been rejected from Debian before, for this same reason.

> We should concentrate on the real problems, namely the clause of
> venue and QPL 6c, which i have ground to believe will be no problem
> for upstream anymore, altough i have no official answer yet, and QPL
> 3b, which still remains problematic.

Does that actually mean QPL 6 will be removed from the OCaml license?
Oh Frabjuous Day!

Or just QPL 6c?  That would not be frabjuous, but I still might
callay.

>> My assumption is that they wanted to ban certain modifications of
>> their work, and were more concerned about maximizing credit than
>> writing free software.
>
> They just wanted to make sure someone didn't remove the copyright notice, or
> alter it to remove older contributors. Adding new contributors should be
> permitted, but that is the extent of it. 

Yes, but a ban on removing all and any copyright notices is not Free.
It's fine for an author to require that there *be* a copyright notice,
but forbidding translation or addition is not Free.

Requiring a specific dialog box isn't either -- it doesn't translate
to systems without a GUI.  Requiring specific text output also isn't
free, as it doesn't work with non-interactive or embedded systems.


-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]

Re: ocaml, QPL and the DFSG : QPL 3b argumentation.

[Brian Thomas Sniffen]

Sven Luther <[EMAIL PROTECTED]> writes:

>> "You must include appropriate and accurate copyright notices on each
>> source file, and in a reasonable and appropriate place in any binary
>> file."
>
> Not clear enough. A quick reader would read that you can replace the copyright
> notice by another. Also, QPL 3 deals with source modification and
> distribution as patches, not binaries.

Well, you can -- as long as it's appropriate and accurate.  If I take
Linux and write "Copyright (c) 1902 Brian Sniffen" on it, that's not
appropriate or accurate, is it?

And if you don't want to deal with binaries there, then rip that
clause off and just say:

"You must include an appropriate, accurate, and complete copyright
notice on each source file."

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]

Re: Web application licenses

[Brian Thomas Sniffen]

Josh Triplett <[EMAIL PROTECTED]> writes:

> How about something vaguely like:
>
> """
> If you make the software or a work based on the software available for
> direct use by another party, without actually distributing the software
> to that party, you must either:
>
> a) Distribute the complete corresponding machine-readable source code
> publically under this license, or
> b) Make the source code available to that party, under the all the same
> conditions you would need to meet in GPL section 3 if you were
> distributing a binary to that party.
> """

So if I use software under such a license in a network switch, to whom
am I obliged to distribute source?  How about a web proxy?

I do wonder what "publically" means.  If I'm offering to hand a CD to
anyone who asks me for one in person, is that public enough?  Or must
I run a web server to distribute it, and thus (assuming this license
is broadly used) have to distribute a web server too?

Does the Department of Transportation need to make stoplight software
generally available?

Does google have to make its source code available?  If so, why?  It's
not going to do anybody else any *good*, since we don't have
100 kilomachine clusters sitting around idle to use.  So this doesn't
get us Freedom; we can't change the google interface we use in
practice.

Slashdot *does* publish its code, but this doesn't give me freedom
with respect to Slashdot.  I just don't see how compelling source
distribution from a networked provider actually increases freedom --
since I don't care about changing the code I have, I care about
changing the code *they* have.

I think it's great that some sites publish their code.  But I don't
see any benefit to freedom from compelling them to do so.  On the
other hand, a compulsive *open interface* would be a useful thing.
Say, if Google were using a weirdly licensed web server which
compelled them to provide an RPC function allowing arbitrary queries,
so that others could access their data in surprising new ways.

As it happens, *they* do this anyway.  But nytimes.com doesn't, and
msnbc doesn't, etc.

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]

Re: ocaml, QPL and the DFSG : QPL 3b argumentation.

[Sven Luther]

On Mon, Jul 26, 2004 at 09:57:20AM -0400, Brian Thomas Sniffen wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> >> The plain reading says you may not alter or remove copyright
> >> notices.  That means, as far as I can tell, that you can not alter
> >> or remove such notices without breaking the license.  If it was
> >> supposed to mean something else, surely they would have written
> >> something else.
> >
> > So why didn't they ? 
> 
> What?  Why are you asking *me* this?  You're the one claiming to have
> knowledge of what was really meant by the license, if it's read at a
> proper angle through a lens of absinthe.

Brian. The licence in question was written by TrollTech lawyers, _and_
reviewed by all free software/open source/distro/whatever guys back then.
Also, there was a big thread about the QPL in 99 on this same list.

If they did not pick on this, there is sane reason to say this is ok. We
should concentrate on the real problems, namely the clause of venue and QPL
6c, which i have ground to believe will be no problem for upstream anymore,
altough i have no official answer yet, and QPL 3b, which still remains
problematic.

> My assumption is that they wanted to ban certain modifications of
> their work, and were more concerned about maximizing credit than
> writing free software.

They just wanted to make sure someone didn't remove the copyright notice, or
alter it to remove older contributors. Adding new contributors should be
permitted, but that is the extent of it. 

Friendly,

Sven Luther

Re: ocaml, QPL and the DFSG : QPL 3b argumentation.

[Sven Luther]

On Mon, Jul 26, 2004 at 09:58:16AM -0400, Brian Thomas Sniffen wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> >> > Also, consider the annotation :
> >> >
> >> >   This doesn't really need to be stated, since to do so would be 
> >> > fraudulent.
> >> >
> >> > Do we really need to continue arguing about this close ? 
> >> 
> >> Yes -- the annotation is incorrect.  This is much more restrictive
> >> than the law requires.  There are many honest activities which break
> >> this clause.
> >
> > Ok, propose an alternate concise writing of this, please ? 
> 
> "You must include appropriate and accurate copyright notices on each
> source file, and in a reasonable and appropriate place in any binary
> file."

Not clear enough. A quick reader would read that you can replace the copyright
notice by another. Also, QPL 3 deals with source modification and
distribution as patches, not binaries.

Friendly,

Sven Luther

Re: ocaml, QPL and the DFSG : QPL 3b argumentation.

[Brian Thomas Sniffen]

Sven Luther <[EMAIL PROTECTED]> writes:

>> > Also, consider the annotation :
>> >
>> >   This doesn't really need to be stated, since to do so would be 
>> > fraudulent.
>> >
>> > Do we really need to continue arguing about this close ? 
>> 
>> Yes -- the annotation is incorrect.  This is much more restrictive
>> than the law requires.  There are many honest activities which break
>> this clause.
>
> Ok, propose an alternate concise writing of this, please ? 

"You must include appropriate and accurate copyright notices on each
source file, and in a reasonable and appropriate place in any binary
file."

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]

Re: ocaml, QPL and the DFSG : QPL 3b argumentation.

[Brian Thomas Sniffen]

Sven Luther <[EMAIL PROTECTED]> writes:

>> The plain reading says you may not alter or remove copyright
>> notices.  That means, as far as I can tell, that you can not alter
>> or remove such notices without breaking the license.  If it was
>> supposed to mean something else, surely they would have written
>> something else.
>
> So why didn't they ? 

What?  Why are you asking *me* this?  You're the one claiming to have
knowledge of what was really meant by the license, if it's read at a
proper angle through a lens of absinthe.

My assumption is that they wanted to ban certain modifications of
their work, and were more concerned about maximizing credit than
writing free software.

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]

Re: MySQL FOSS Exception

[Francesco P. Lovergine]

On Sun, Jul 25, 2004 at 12:20:22PM +, Andreas Metzler wrote:
> Francesco Paolo Lovergine  debian.org> writes:
> > On Sat, Jul 24, 2004 at 07:04:32PM -0400, Andres Salomon wrote:
> > > The MySQL folks have a *new* statement, that should satisfy the DFSG, and
> > > should be released w/ the next version of mysql. 
> [...]
> > Pointers?
> 
> http://zak.greant.com:/licensing/rlog?f=licensing/FLOSS-exception.txt
>  cu andreas
> 

Uhm, if they would add OpenSSL license explicitly it would be nice.
In its current draft I see almost the same problems, but for
a better definition of 'Opensource Initiative Compatible'.
Anyway, I think that using external references to validate
a license is quite weird. They should simply list principia
and possibly add a few additional well-known licenses.

-- 
Francesco P. Lovergine

Re: the meaning of 'the same terms" in DFSG 3, and why the QPL fails it (was: An old question of EGE's)

[Edmund GRIMLEY EVANS]

Branden Robinson <[EMAIL PROTECTED]>:

> DFSG 3 was intended to forbid licensors from placing themselves in a
> specially advantaged position.  If not, why doesn't DSFG 3 simply say:
> 
>   The license must allow modifications and derived works.
> 
> ...hmm?

Perhaps DFSG 3 is looking at it from the point of view of the receiver
of the modified work rather than the modifer: A creates a QPL work, B
modifies it and gives the modified version to C. Then C gets the
modified work under the same licence as the original work was
distributed. However, if you really want to know how DFSG 3 was
intended then you must talk to the people who wrote it.

Re: ocaml, QPL and the DFSG : QPL 3b argumentation.

[Sven Luther]

On Sun, Jul 25, 2004 at 06:58:28PM -0400, Brian Thomas Sniffen wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > On Sun, Jul 25, 2004 at 02:38:18PM -0400, Brian Thomas Sniffen wrote:
> >> Sven Luther <[EMAIL PROTECTED]> writes:
> >> 
> >> > On Sun, Jul 25, 2004 at 12:22:04PM -0400, Brian Thomas Sniffen wrote:
> >> >> The law already makes it illegal to tamper with copyright notices; a
> >> >> license doesn't need to say that in order to make it wrong to do so.
> >> >> Perhaps it could just be left out?
> >> >
> >> > Given that lawyer wrote this licence, why did they add it. And in any 
> >> > case,
> >> > what harm is there to do so ?
> >> 
> >> I don't know why they added it.  Maybe you could ask them.  The usual
> >> reason is to make such a change not merely a crime, but also copyright
> >> infringement, so as to extract punitive damages as well.
> >> 
> >> But as a side effect, it also makes a bunch of good things violate the
> >> license -- like translating "Copyright (c) 2004 Bob Smith" to whatever
> >> language is appropriate.
> >
> > Notice this other wording for basically the same thing : 
> >
> >   1. You may copy and distribute verbatim copies of the Program's
> >   source code as you receive it, in any medium, provided that you
> >   conspicuously and appropriately publish on each copy an appropriate
> >   copyright notice and disclaimer of warranty; keep intact all the
> >   notices that refer to this License and to the absence of any warranty;
> >   and give any other recipients of the Program a copy of this License
> >   along with the Program.
> 
> That's very different; that allows me to write a new and different
> copyright notice, so long as it's complete and accurate, and also
> appropriate.
> 
> > It may be not exactly the same wording, but the intent is clearly the same. 
> > I
> > know that ocaml upstream chose the QPL in part because it was less verbose 
> > and
> > easier to understand that other licences out there. Sure, you may loose some
> > details in this simplicity, but the intent is clear.
> 
> And yet we don't argue much about the GPL, MIT/X11, or other Free
> licenses, and there has been well over a week and hundreds of messages
> on the QPL.  If the idea is that it's easier to understand, they
> really screwed up.

Because you don'ty dare give those well known the kind of abuse you give the
QPL, or half of what is in debian, including X, the kernel, the toolchain,
etc, would be thrown out of debian :).

> > Also, consider the annotation :
> >
> >   This doesn't really need to be stated, since to do so would be fraudulent.
> >
> > Do we really need to continue arguing about this close ? 
> 
> Yes -- the annotation is incorrect.  This is much more restrictive
> than the law requires.  There are many honest activities which break
> this clause.

Ok, propose an alternate concise writing of this, please ? 

Friendly,

Sven Luther

Re: ocaml, QPL and the DFSG: QPL 6c argumentation.

[Sven Luther]

On Mon, Jul 26, 2004 at 09:32:01AM +0100, Edmund GRIMLEY EVANS wrote:
> Sven Luther <[EMAIL PROTECTED]>:
> 
> > > I create a program P that consists of an executable X linked with a
> > > library L. X links with L, but P is a modification of L, albeit a
> > > modification that was made by adding material to L.
> > 
> > Ok, in this case, you can either distribute it together in the L tarball, 
> > and
> > it is a modification, or you can distribute it separatedly, and in this case
> > it is a work linked with the software.
> 
> And the first option may be sufficient for DFSG-freedom.
> 
> > In any case, if you consider it as a modification, you have to provide a 
> > patch
> > for it, and if you make binaries, they have to be QPLed. If you provide it
> > separatedly, you can chose a more liberal free licence, but you must honor 
> > the
> > upstream request covered by 6c.
> 
> Then you're agreeing with me. The first way (QPL 3) is on the face of
> it very restrictive compared with the second way (QPL 6) - as you say,
> you have to QPL the whole thing - but if the first way is free, then
> the licence is free, and if the first way isn't free, then the licence
> isn't free, or at least that's the point of view I'm trying to argue
> for in this subthread.

No, because there are software which you cannot distribute under the QPL 3,
and fall only under the QPL 6. In the Qt case, you can't in any way argue that
KDE is a modified work of Qt, and thus distribute the whole of it as part of
the Qt tarball, can you ?

> > original modified work.
> 
> (The "original modified work" is almost as good as granting additional
> restrictions. I think we should do a new licence using both those
> expressions!)

He. modified original work it should have said.

I have reason to believe that this issue will be solved soon, and that we only
need to concentrate on the QPL 3 now. Let's do this, ok ? 

Friendly,

Sven Luther

Re: ocaml, QPL and the DFSG: QPL 6c argumentation.

[Edmund GRIMLEY EVANS]

Sven Luther <[EMAIL PROTECTED]>:

> > I create a program P that consists of an executable X linked with a
> > library L. X links with L, but P is a modification of L, albeit a
> > modification that was made by adding material to L.
> 
> Ok, in this case, you can either distribute it together in the L tarball, and
> it is a modification, or you can distribute it separatedly, and in this case
> it is a work linked with the software.

And the first option may be sufficient for DFSG-freedom.

> In any case, if you consider it as a modification, you have to provide a patch
> for it, and if you make binaries, they have to be QPLed. If you provide it
> separatedly, you can chose a more liberal free licence, but you must honor the
> upstream request covered by 6c.

Then you're agreeing with me. The first way (QPL 3) is on the face of
it very restrictive compared with the second way (QPL 6) - as you say,
you have to QPL the whole thing - but if the first way is free, then
the licence is free, and if the first way isn't free, then the licence
isn't free, or at least that's the point of view I'm trying to argue
for in this subthread.

> original modified work.

(The "original modified work" is almost as good as granting additional
restrictions. I think we should do a new licence using both those
expressions!)