BOINC: lib/cal.h license issue agree with the DFSG?
Fernando C. Estrada
In the #debian-devel channel, Nicolás Álvarez ask about this BOINC's
license issue, and in the pkg-boinc-devel team want to know your
opinion:
The BOINC source code were debianized to packages that meet the DFSG,
and the Copyright include only compatible licenses (discarding all the
files that don't comply with the DFSG from the Debian packages). Now,
the doubt is in the lib/cal.h file, because includes the "license"
pasted at the end of this message.
My personal opinion is that this license is agree with the DFSG, because
it says: "This license does not affect any ownership, rights, title, or
interest in, or relating to, this material", so I think that the purpose
of this, is to not guarantee this software and avoid lawsuits about any
problem in the use of this.
Of course, my knowledge about legal concepts is very limited, so I
appreciate any comment to give us in the team an argument about this,
and of course, the tranquility that BOINC packages are agree with the
DFSG.
Thanks in advance and Best Regards!
P.S. Please keep in the answer the CC to the Debian BOINC Maintainers
Team.
/* ============================================================
Copyright (c) 2007 Advanced Micro Devices, Inc. All rights reserved.
Redistribution and use of this material is permitted under the following
conditions:
Redistributions must retain the above copyright notice and all terms of
this
license.
In no event shall anyone redistributing or accessing or using this
material
commence or participate in any arbitration or legal action relating to
this
material against Advanced Micro Devices, Inc. or any copyright holders
or
contributors. The foregoing shall survive any expiration or termination
of
this license or any agreement or access or use related to this material.
ANY BREACH OF ANY TERM OF THIS LICENSE SHALL RESULT IN THE IMMEDIATE
REVOCATION
OF ALL RIGHTS TO REDISTRIBUTE, ACCESS OR USE THIS MATERIAL.
THIS MATERIAL IS PROVIDED BY ADVANCED MICRO DEVICES, INC. AND ANY
COPYRIGHT
HOLDERS AND CONTRIBUTORS "AS IS" IN ITS CURRENT CONDITION AND WITHOUT
ANY
REPRESENTATIONS, GUARANTEE, OR WARRANTY OF ANY KIND OR IN ANY WAY
RELATED TO
SUPPORT, INDEMNITY, ERROR FREE OR UNINTERRUPTED OPERATION, OR THAT IT IS
FREE
FROM DEFECTS OR VIRUSES. ALL OBLIGATIONS ARE HEREBY DISCLAIMED -
WHETHER
EXPRESS, IMPLIED, OR STATUTORY - INCLUDING, BUT NOT LIMITED TO, ANY
IMPLIED
WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
ACCURACY, COMPLETENESS, OPERABILITY, QUALITY OF SERVICE, OR
NON-INFRINGEMENT.
IN NO EVENT SHALL ADVANCED MICRO DEVICES, INC. OR ANY COPYRIGHT HOLDERS
OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
PUNITIVE,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT
OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, REVENUE, DATA, OR PROFITS;
OR
BUSINESS INTERRUPTION) HOWEVER CAUSED OR BASED ON ANY THEORY OF
LIABILITY
ARISING IN ANY WAY RELATED TO THIS MATERIAL, EVEN IF ADVISED OF THE
POSSIBILITY
OF SUCH DAMAGE. THE ENTIRE AND AGGREGATE LIABILITY OF ADVANCED MICRO
DEVICES,
INC. AND ANY COPYRIGHT HOLDERS AND CONTRIBUTORS SHALL NOT EXCEED TEN
DOLLARS
(US $10.00). ANYONE REDISTRIBUTING OR ACCESSING OR USING THIS MATERIAL
ACCEPTS
THIS ALLOCATION OF RISK AND AGREES TO RELEASE ADVANCED MICRO DEVICES,
INC. AND
ANY COPYRIGHT HOLDERS AND CONTRIBUTORS FROM ANY AND ALL LIABILITIES,
OBLIGATIONS, CLAIMS, OR DEMANDS IN EXCESS OF TEN DOLLARS (US $10.00).
THE
FOREGOING ARE ESSENTIAL TERMS OF THIS LICENSE AND, IF ANY OF THESE TERMS
ARE
CONSTRUED AS UNENFORCEABLE, FAIL IN ESSENTIAL PURPOSE, OR BECOME VOID OR
DETRIMENTAL TO ADVANCED MICRO DEVICES, INC. OR ANY COPYRIGHT HOLDERS OR
CONTRIBUTORS FOR ANY REASON, THEN ALL RIGHTS TO REDISTRIBUTE, ACCESS OR
USE
THIS MATERIAL SHALL TERMINATE IMMEDIATELY. MOREOVER, THE FOREGOING SHALL
SURVIVE ANY EXPIRATION OR TERMINATION OF THIS LICENSE OR ANY AGREEMENT
OR
ACCESS OR USE RELATED TO THIS MATERIAL.
NOTICE IS HEREBY PROVIDED, AND BY REDISTRIBUTING OR ACCESSING OR USING
THIS
MATERIAL SUCH NOTICE IS ACKNOWLEDGED, THAT THIS MATERIAL MAY BE SUBJECT
TO
RESTRICTIONS UNDER THE LAWS AND REGULATIONS OF THE UNITED STATES OR
OTHER
COUNTRIES, WHICH INCLUDE BUT ARE NOT LIMITED TO, U.S. EXPORT CONTROL
LAWS SUCH
AS THE EXPORT ADMINISTRATION REGULATIONS AND NATIONAL SECURITY CONTROLS
AS
DEFINED THEREUNDER, AS WELL AS STATE DEPARTMENT CONTROLS UNDER THE U.S.
MUNITIONS LIST. THIS MATERIAL MAY NOT BE USED, RELEASED, TRANSFERRED,
IMPORTED,
EXPORTED AND/OR RE-EXPORTED IN ANY MANNER PROHIBITED UNDER ANY
APPLICABLE LAWS,
INCLUDING U.S. EXPORT CONTROL LAWS REGARDING SPECIFICALLY DESIGNATED
PERSONS,
COUNTRIES AND NATIONALS OF COUNTRIES SUBJECT TO NATIONAL SECURITY
CONTROLS.
MOREOVER, THE FOREGOING SHALL SURVIVE ANY EXPIRATION OR TERMINATION OF
ANY
LICENSE OR AGREEMENT OR ACCESS OR USE RELATED TO THIS MATERIAL.
NOTICE REGARDING THE U.S. GOVERNMENT AND DOD AGENCIES: This material is
provided with "RESTRICTED RIGHTS" and/or "LIMITED RIGHTS" as applicable
to
computer software and technical data, respectively. Use, duplication,
distribution or disclosure by the U.S. Government and/or DOD agencies is
subject to the full extent of restrictions in all applicable
regulations,
including those found at FAR52.227 and DFARS252.227 et seq. and any
successor
regulations thereof. Use of this material by the U.S. Government and/or
DOD
agencies is acknowledgment of the proprietary rights of any copyright
holders
and contributors, including those of Advanced Micro Devices, Inc., as
well as
the provisions of FAR52.227-14 through 23 regarding privately developed
and/or
commercial computer software.
This license forms the entire agreement regarding the subject matter
hereof and
supersedes all proposals and prior discussions and writings between the
parties
with respect thereto. This license does not affect any ownership,
rights, title,
or interest in, or relating to, this material. No terms of this license
can be
modified or waived, and no breach of this license can be excused, unless
done
so in a writing signed by all affected parties. Each term of this
license is
separately enforceable. If any term of this license is determined to be
or
becomes unenforceable or illegal, such term shall be reformed to the
minimum
extent necessary in order for this license to remain in effect in
accordance
with its terms as modified by such reformation. This license shall be
governed
by and construed in accordance with the laws of the State of Texas
without
regard to rules on conflicts of law of any state or jurisdiction or the
United
Nations Convention on the International Sale of Goods. All disputes
arising out
of this license shall be subject to the jurisdiction of the federal and
state
courts in Austin, Texas, and all defenses are hereby waived concerning
personal
jurisdiction and venue of these courts.
============================================================ */
--
Fernando C. Estrada http://www.fcestrada.com
fces...@fcestrada.com 4096R/C6E0F4B8 2009-11-14
B750 A96F 3A33 2CBA 7871 5BD0 C2FB E9BD C6E0 F4B8
Francesco Poli
> Hi
Hi! :)
[...]
> Now,
> the doubt is in the lib/cal.h file, because includes the "license"
> pasted at the end of this message.
I personally see various problems with this file.
Assuming that the license you quoted constitutes the whole set of
permissions granted on this file, I think that lib/cal.h does *not*
comply with the DFSG.
I think that the copyright holder should be contacted and asked for a
more permissive license, so that lib/cal.h can meet the DFSG and be
compatible with the other licenses of parts that are linked with
lib/cal.h ...
Other possible solutions are: drop lib/cal.h from the Debian package,
if at all possible.
Or move the package to non-free, while moving all the packages that
depend or recommend it to contrib.
My detailed comments may be found below.
Needless to say, they represent my own personal opinion; other
debian-legal participants may or may not agree...
[...]
> Thanks in advance and Best Regards!
You're welcome.
>
> P.S. Please keep in the answer the CC to the Debian BOINC Maintainers
> Team.
Done.
>
> /* ============================================================
>
> Copyright (c) 2007 Advanced Micro Devices, Inc. All rights reserved.
>
> Redistribution and use of this material is permitted under the following
> conditions:
I cannot find any permission to modify or distribute modified versions
of the file.
This seems to fail DFSG#3.
[...]
> In no event shall anyone redistributing or accessing or using this
> material
> commence or participate in any arbitration or legal action relating to
> this
> material against Advanced Micro Devices, Inc. or any copyright holders
> or
> contributors. The foregoing shall survive any expiration or termination
> of
> this license or any agreement or access or use related to this material.
This takes away a right I would have in the absence of any license.
That is to say, in order to get the permission to redistribute or use,
I must surrender my right to commence or participate in any legal
action related to this work.
I see this as a fee required for getting the permission to
redistribute: the presence of such a fee makes the work fail DFSG#1.
[...]
> THE
> FOREGOING ARE ESSENTIAL TERMS OF THIS LICENSE AND, IF ANY OF THESE TERMS
> ARE
> CONSTRUED AS UNENFORCEABLE, FAIL IN ESSENTIAL PURPOSE, OR BECOME VOID OR
> DETRIMENTAL TO ADVANCED MICRO DEVICES, INC. OR ANY COPYRIGHT HOLDERS OR
> CONTRIBUTORS FOR ANY REASON, THEN ALL RIGHTS TO REDISTRIBUTE, ACCESS OR
> USE
> THIS MATERIAL SHALL TERMINATE IMMEDIATELY.
This is also worrisome, from my point of view.
Typical limitation of liability clauses found in Free Software licenses
say something to effect of "no liability, unless required by law or
agreed to in writing".
This clause, instead, seems to say that, if any limitation of liability
is unenforceable, then, boom!, the whole grant of permission is void.
This could discriminate against people living in jurisdictions where
local law forbids too extreme limitations of liability.
If this is the case, then it fails DFSG#5.
[...]
> THIS MATERIAL MAY NOT BE USED, RELEASED, TRANSFERRED,
> IMPORTED,
> EXPORTED AND/OR RE-EXPORTED IN ANY MANNER PROHIBITED UNDER ANY
> APPLICABLE LAWS,
> INCLUDING U.S. EXPORT CONTROL LAWS REGARDING SPECIFICALLY DESIGNATED
> PERSONS,
> COUNTRIES AND NATIONALS OF COUNTRIES SUBJECT TO NATIONAL SECURITY
> CONTROLS.
Enforcing export control laws (or other laws), through a copyright
license is not a good thing to do, IMHO.
I think that, if I violate some export control law, I should be
prosecuted for breaching that law, without *also* having to face
copyright violation suits.
[...]
> This license forms the entire agreement regarding the subject matter
> hereof and
> supersedes all proposals and prior discussions and writings between the
> parties
> with respect thereto.
It really seems that no other grant of permission may be considered
valid...
> This license does not affect any ownership,
> rights, title,
> or interest in, or relating to, this material.
I think that this means that, if I hold some right (e.g.: copyright)
on a part of the work, then I am not constrained by the license, for
that part of the work.
This seems to be superfluous to say.
[...]
> All disputes
> arising out
> of this license shall be subject to the jurisdiction of the federal and
> state
> courts in Austin, Texas, and all defenses are hereby waived concerning
> personal
> jurisdiction and venue of these courts.
This is a choice of venue clause.
Choice of venue clauses are controversial and have been discussed to
death in the past on debian-legal: my personal opinion is that they
fail to meet the DFSG.
--
New location for my website! Update your bookmarks!
http://www.inventati.org/frx
..................................................... Francesco Poli .
GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Sean Kellogg
> > /* ============================================================
> >
> > Copyright (c) 2007 Advanced Micro Devices, Inc. All rights reserved.
> >
> > Redistribution and use of this material is permitted under the following
> > conditions:
>
> I cannot find any permission to modify or distribute modified versions
> of the file.
> This seems to fail DFSG#3.
What?! The grant is /right/ there... "Redistribution and use of this material is permitted" provided the following criteria are met, and then it lists the criteria. I suppose it could be its own little bullet point, but that sure seems explicit to me. That you failed to see that as a grant really calls into question the neutrality of the rest of your license evaluation.
> [...]
> > In no event shall anyone redistributing or accessing or using this
> > material
> > commence or participate in any arbitration or legal action relating to
> > this
> > material against Advanced Micro Devices, Inc. or any copyright holders
> > or
> > contributors. The foregoing shall survive any expiration or termination
> > of
> > this license or any agreement or access or use related to this material.
>
> This takes away a right I would have in the absence of any license.
> That is to say, in order to get the permission to redistribute or use,
> I must surrender my right to commence or participate in any legal
> action related to this work.
> I see this as a fee required for getting the permission to
> redistribute: the presence of such a fee makes the work fail DFSG#1.
The GPL takes away all sorts of rights... this can't possible be what DFSG #1 is intended on prohibiting.
> [...]
> > THE
> > FOREGOING ARE ESSENTIAL TERMS OF THIS LICENSE AND, IF ANY OF THESE TERMS
> > ARE
> > CONSTRUED AS UNENFORCEABLE, FAIL IN ESSENTIAL PURPOSE, OR BECOME VOID OR
> > DETRIMENTAL TO ADVANCED MICRO DEVICES, INC. OR ANY COPYRIGHT HOLDERS OR
> > CONTRIBUTORS FOR ANY REASON, THEN ALL RIGHTS TO REDISTRIBUTE, ACCESS OR
> > USE
> > THIS MATERIAL SHALL TERMINATE IMMEDIATELY.
>
> This is also worrisome, from my point of view.
> Typical limitation of liability clauses found in Free Software licenses
> say something to effect of "no liability, unless required by law or
> agreed to in writing".
> This clause, instead, seems to say that, if any limitation of liability
> is unenforceable, then, boom!, the whole grant of permission is void.
> This could discriminate against people living in jurisdictions where
> local law forbids too extreme limitations of liability.
> If this is the case, then it fails DFSG#5.
This continues to be a laughable argument. The GPL discriminates against countries who jail anyone who uses software licensed under the GPL. Is that discrimination?
> [...]
> > THIS MATERIAL MAY NOT BE USED, RELEASED, TRANSFERRED,
> > IMPORTED,
> > EXPORTED AND/OR RE-EXPORTED IN ANY MANNER PROHIBITED UNDER ANY
> > APPLICABLE LAWS,
> > INCLUDING U.S. EXPORT CONTROL LAWS REGARDING SPECIFICALLY DESIGNATED
> > PERSONS,
> > COUNTRIES AND NATIONALS OF COUNTRIES SUBJECT TO NATIONAL SECURITY
> > CONTROLS.
>
> Enforcing export control laws (or other laws), through a copyright
> license is not a good thing to do, IMHO.
> I think that, if I violate some export control law, I should be
> prosecuted for breaching that law, without *also* having to face
> copyright violation suits.
Not saying I disagree, but your position on how export laws should be enforced really isn't at issue here. The problem AMD is addressing here is third party liability if someone where to violate US export laws. Is this clause really any different than "you aren't allowed to do anything illegal with this software?" And, if so, does the DFSG really prohibit a developer from proscribing the use in that manner and thus exposing the developer to a whole RANGE of contributory liability?
> [...]
> > This license forms the entire agreement regarding the subject matter
> > hereof and
> > supersedes all proposals and prior discussions and writings between the
> > parties
> > with respect thereto.
>
> It really seems that no other grant of permission may be considered
> valid...
How do you reach that conclusion?!
> > This license does not affect any ownership,
> > rights, title,
> > or interest in, or relating to, this material.
>
> I think that this means that, if I hold some right (e.g.: copyright)
> on a part of the work, then I am not constrained by the license, for
> that part of the work.
> This seems to be superfluous to say.
The license is just being very clear that the license in now way diminishes the ownership rights of AMD in the underlying code. Hardly superfluous if you are AMD.
> [...]
> > All disputes
> > arising out
> > of this license shall be subject to the jurisdiction of the federal and
> > state
> > courts in Austin, Texas, and all defenses are hereby waived concerning
> > personal
> > jurisdiction and venue of these courts.
>
> This is a choice of venue clause.
> Choice of venue clauses are controversial and have been discussed to
> death in the past on debian-legal: my personal opinion is that they
> fail to meet the DFSG.
A fight that has been lost many times... choice of venue is fine.
-Sean
--
Sean Kellogg
e: skel...@probonogeek.org
w: http://blog.probonogeek.org
--
To UNSUBSCRIBE, email to debian-leg...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve Langasek
> On Friday 01 January 2010 2:57:18 pm Francesco Poli wrote:
> > > /* ============================================================
> > >
> > > Copyright (c) 2007 Advanced Micro Devices, Inc. All rights reserved.
> > >
> > > Redistribution and use of this material is permitted under the following
> > > conditions:
> >
> > I cannot find any permission to modify or distribute modified versions
> > of the file.
> > This seems to fail DFSG#3.
> What?! The grant is /right/ there... "Redistribution and use of this
> material is permitted" provided the following criteria are met, and then
> it lists the criteria. I suppose it could be its own little bullet point,
> but that sure seems explicit to me. That you failed to see that as a grant
> really calls into question the neutrality of the rest of your license
> evaluation.
The grant covers redistribution and use. It's my understanding that neither
"redistribution" nor "use" encompasses modifications under copyright law,
and Debian has consistently required an explicit grant of permission to
modify and to distribute the resulting modified works in order to be
considered DFSG-compliant.
> > > THIS MATERIAL MAY NOT BE USED, RELEASED, TRANSFERRED,
> > > IMPORTED,
> > > EXPORTED AND/OR RE-EXPORTED IN ANY MANNER PROHIBITED UNDER ANY
> > > APPLICABLE LAWS,
> > > INCLUDING U.S. EXPORT CONTROL LAWS REGARDING SPECIFICALLY DESIGNATED
> > > PERSONS,
> > > COUNTRIES AND NATIONALS OF COUNTRIES SUBJECT TO NATIONAL SECURITY
> > > CONTROLS.
> > Enforcing export control laws (or other laws), through a copyright
> > license is not a good thing to do, IMHO.
> > I think that, if I violate some export control law, I should be
> > prosecuted for breaching that law, without *also* having to face
> > copyright violation suits.
>
> Not saying I disagree, but your position on how export laws should be
> enforced really isn't at issue here. The problem AMD is addressing here is
> third party liability if someone where to violate US export laws. Is this
> clause really any different than "you aren't allowed to do anything
> illegal with this software?"
No, it's not different at all - and a license that says "you aren't allowed
to do anything illegal with this software" is *not* DFSG-compliant. Civil
disobedience should not result in violations of the copyright licenses of
software in Debian.
> And, if so, does the DFSG really prohibit a developer from proscribing the
> use in that manner and thus exposing the developer to a whole RANGE of
> contributory liability?
Yes, it really does (assuming there's any contributory liability to be found
here, anyway).
> > This is a choice of venue clause.
> > Choice of venue clauses are controversial and have been discussed to
> > death in the past on debian-legal: my personal opinion is that they
> > fail to meet the DFSG.
> A fight that has been lost many times... choice of venue is fine.
Yes. I don't like choice of venue clauses, but the project has decided they
are acceptable, and it's not appropriate to inject one's personal dissenting
opinions into a license analysis on this list.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Sean Kellogg
> On Fri, Jan 01, 2010 at 03:13:58PM -0800, Sean Kellogg wrote:
> > On Friday 01 January 2010 2:57:18 pm Francesco Poli wrote:
> > > > /* ============================================================
> > > >
> > > > Copyright (c) 2007 Advanced Micro Devices, Inc. All rights reserved.
> > > >
> > > > Redistribution and use of this material is permitted under the following
> > > > conditions:
> > >
> > > I cannot find any permission to modify or distribute modified versions
> > > of the file.
> > > This seems to fail DFSG#3.
>
> > What?! The grant is /right/ there... "Redistribution and use of this
> > material is permitted" provided the following criteria are met, and then
> > it lists the criteria. I suppose it could be its own little bullet point,
> > but that sure seems explicit to me. That you failed to see that as a grant
> > really calls into question the neutrality of the rest of your license
> > evaluation.
>
> The grant covers redistribution and use. It's my understanding that neither
> "redistribution" nor "use" encompasses modifications under copyright law,
> and Debian has consistently required an explicit grant of permission to
> modify and to distribute the resulting modified works in order to be
> considered DFSG-compliant.
You are quite right... I failed to notice Francesco was talking just about /modification/. That certainly is a problem and clearly runs afoul of DFSG #3. My apologies.
> > > > THIS MATERIAL MAY NOT BE USED, RELEASED, TRANSFERRED,
> > > > IMPORTED,
> > > > EXPORTED AND/OR RE-EXPORTED IN ANY MANNER PROHIBITED UNDER ANY
> > > > APPLICABLE LAWS,
> > > > INCLUDING U.S. EXPORT CONTROL LAWS REGARDING SPECIFICALLY DESIGNATED
> > > > PERSONS,
> > > > COUNTRIES AND NATIONALS OF COUNTRIES SUBJECT TO NATIONAL SECURITY
> > > > CONTROLS.
>
> > > Enforcing export control laws (or other laws), through a copyright
> > > license is not a good thing to do, IMHO.
> > > I think that, if I violate some export control law, I should be
> > > prosecuted for breaching that law, without *also* having to face
> > > copyright violation suits.
> >
> > Not saying I disagree, but your position on how export laws should be
> > enforced really isn't at issue here. The problem AMD is addressing here is
> > third party liability if someone where to violate US export laws. Is this
> > clause really any different than "you aren't allowed to do anything
> > illegal with this software?"
>
> No, it's not different at all - and a license that says "you aren't allowed
> to do anything illegal with this software" is *not* DFSG-compliant. Civil
> disobedience should not result in violations of the copyright licenses of
> software in Debian.
Really?! How delightfully libertarian. I guess all I can do is reiterate my position that I don't think the DFSG should be read that way and hope that the FTP masters continue to show less political and more pragmatic evaluation :)
Francesco Poli
> On Fri, Jan 01, 2010 at 03:13:58PM -0800, Sean Kellogg wrote:
> > On Friday 01 January 2010 2:57:18 pm Francesco Poli wrote:
[...]
> > > This is a choice of venue clause.
> > > Choice of venue clauses are controversial and have been discussed to
> > > death in the past on debian-legal: my personal opinion is that they
> > > fail to meet the DFSG.
>
> > A fight that has been lost many times... choice of venue is fine.
>
> Yes. I don't like choice of venue clauses, but the project has decided they
> are acceptable,
I don't remember seeing such a decision.
Where was it taken?
By whom?
Could you please cite some URL?
> and it's not appropriate to inject one's personal dissenting
> opinions into a license analysis on this list.
This continues to come up from you, again and again.
See for example the following sub-thread:
http://lists.debian.org/debian-legal/2009/05/msg00042.html
http://lists.debian.org/debian-legal/2009/05/msg00047.html
http://lists.debian.org/debian-legal/2009/05/msg00077.html
http://lists.debian.org/debian-legal/2009/06/msg00003.html
I re-iterate: how can policy or practice be refined or discussed, if
*any* disagreement is banned from Debian mailing lists?
Moreover, in the present case, I think that I honestly stated that the
DFSG-freeness of choice of venue clauses is controversial and then I
provided my own personal opinion, *explicitly* labeling it as such.
I don't remember any clear decision by the Debian Project on this
matter, otherwise I would have cited it (as I often do with the GR on
the GFDL, for instance).
Francesco Poli
[...]
> You are quite right... I failed to notice Francesco was talking
> just about /modification/. That certainly is a problem and clearly
> runs afoul of DFSG #3. My apologies.
Apologies accepted, but please try and avoid jumping up so fast when
something does not look right to you...
Francesco Poli
> On Friday 01 January 2010 2:57:18 pm Francesco Poli wrote:
> > > /* ============================================================
> > >
> > > Copyright (c) 2007 Advanced Micro Devices, Inc. All rights reserved.
> > >
> > > Redistribution and use of this material is permitted under the following
> > > conditions:
> >
> > I cannot find any permission to modify or distribute modified versions
> > of the file.
> > This seems to fail DFSG#3.
>
> What?! The grant is /right/ there... "Redistribution and use of this
> material is permitted" provided the following criteria are met, and
> then it lists the criteria. I suppose it could be its own little bullet
> point, but that sure seems explicit to me.
As has already been pointed out by Steve Langasek, redistribution and
use does not clearly cover modification and redistribution of modified
versions, which is what I was talking about.
> That you failed to see that as a grant really calls into question the
> neutrality of the rest of your license evaluation.
Neutrality? We are not on Wikipedia, here!
I clearly stated that I was going to express my own personal opinion...
[...]
> > This takes away a right I would have in the absence of any license.
> > That is to say, in order to get the permission to redistribute or use,
> > I must surrender my right to commence or participate in any legal
> > action related to this work.
> > I see this as a fee required for getting the permission to
> > redistribute: the presence of such a fee makes the work fail DFSG#1.
>
> The GPL takes away all sorts of rights... this can't possible be what
> DFSG #1 is intended on prohibiting.
Which rights (that I would have in the absence of any license) does the
GPL take away?
[...]
> > This clause, instead, seems to say that, if any limitation of liability
> > is unenforceable, then, boom!, the whole grant of permission is void.
> > This could discriminate against people living in jurisdictions where
> > local law forbids too extreme limitations of liability.
> > If this is the case, then it fails DFSG#5.
>
> This continues to be a laughable argument. The GPL discriminates against
> countries who jail anyone who uses software licensed under the GPL.
> Is that discrimination?
I don't think so: in your example, that law is *specifically* designed
to attack the GPL, whatever the GPL text may say. As a consequence, the
discrimination is not caused by the GPL, but by the law-makers.
[...]
> Is this clause really any different than "you aren't allowed to do
> anything illegal with this software?"
Steve Langasek has already explained that such a clause is equally
non-free.
>
> > [...]
> > > This license forms the entire agreement regarding the subject matter
> > > hereof and
> > > supersedes all proposals and prior discussions and writings between the
> > > parties
> > > with respect thereto.
> >
> > It really seems that no other grant of permission may be considered
> > valid...
>
> How do you reach that conclusion?!
Since "this license [...] supersedes all proposals and prior
discussions and writings [...]", it seems that I cannot consider any
other *prior* grant of permission as valid.
Maybe *later* grants of permission can be valid and I should have been
less fast in generalizing my sentence to *any* other grant...
If this is actually your objection, then point taken.
>
> > > This license does not affect any ownership,
> > > rights, title,
> > > or interest in, or relating to, this material.
> >
> > I think that this means that, if I hold some right (e.g.: copyright)
> > on a part of the work, then I am not constrained by the license, for
> > that part of the work.
> > This seems to be superfluous to say.
>
> The license is just being very clear that the license in now way
> diminishes the ownership rights of AMD in the underlying code. Hardly
> superfluous if you are AMD.
I think it is superfluous, since no part of the license seems to do
things like transfers of copyright ownerships or such.
Hence, it looks like a clause that makes it very clear what is already
rather clear: in this sense, I think it is superfluous.
I may be wrong, of course.
The clause seems to be harmless, anyway.
Nicolas Alvarez
> The BOINC source code were debianized to packages that meet the DFSG,
> and the Copyright include only compatible licenses (discarding all the
> files that don't comply with the DFSG from the Debian packages). Now,
> the doubt is in the lib/cal.h file, because includes the "license"
> pasted at the end of this message.
Note that cal.h is a header file containing only function declarations and
no actual code (although I guess what counts as 'actual code' is debatable).
The matching function definitions are in a proprietary library that the
BOINC client loads at runtime with dlopen/dlsym. Dynamically linking to a
proprietary library like that is OK for BOINC since it is licensed under the
LGPL, but I don't know whether it's OK for Debian.
--
Nicolas
(I read mailing lists through Gmane. Please don't Cc me on replies; it makes
me get one message on my newsreader and another on email.)
Sean Kellogg
The problem with this line of argument is that it sounds very similar to the climate skeptics / intelligent design crowd. The approach seems to be, "continue to inject controversy even when there is community consensus, in hopes of giving the appearance of true division." Sure, it's their right to believe as they wish, and to speak as they wish, but to the community that has moved on it sure is awfully annoying and dilatory. The FUD strategy has a way of getting of people's nerves awfully quickly :)
-Sean
--
Sean Kellogg
e: skel...@probonogeek.org
w: http://blog.probonogeek.org
Sean Kellogg
> On Fri, 1 Jan 2010 15:13:58 -0800 Sean Kellogg wrote:
>
> > On Friday 01 January 2010 2:57:18 pm Francesco Poli wrote:
> > > > /* ============================================================
> > > >
> > > > Copyright (c) 2007 Advanced Micro Devices, Inc. All rights reserved.
> > > >
> > > > Redistribution and use of this material is permitted under the following
> > > > conditions:
> > >
> > > I cannot find any permission to modify or distribute modified versions
> > > of the file.
> > > This seems to fail DFSG#3.
> >
> > What?! The grant is /right/ there... "Redistribution and use of this
> > material is permitted" provided the following criteria are met, and
> > then it lists the criteria. I suppose it could be its own little bullet
> > point, but that sure seems explicit to me.
>
> As has already been pointed out by Steve Langasek, redistribution and
> use does not clearly cover modification and redistribution of modified
> versions, which is what I was talking about.
>
> > That you failed to see that as a grant really calls into question the
> > neutrality of the rest of your license evaluation.
>
> Neutrality? We are not on Wikipedia, here!
> I clearly stated that I was going to express my own personal opinion...
Which is exactly why d-l still has a bad reputation in Debian...
> [...]
> > > This takes away a right I would have in the absence of any license.
> > > That is to say, in order to get the permission to redistribute or use,
> > > I must surrender my right to commence or participate in any legal
> > > action related to this work.
> > > I see this as a fee required for getting the permission to
> > > redistribute: the presence of such a fee makes the work fail DFSG#1.
> >
> > The GPL takes away all sorts of rights... this can't possible be what
> > DFSG #1 is intended on prohibiting.
>
> Which rights (that I would have in the absence of any license) does the
> GPL take away?
GPLv3 sections 15 and 16. The presence of such waivers are often seen by courts as a form of consideration, which implies it is either a fee or a forbearance. Since it's not a fee in this case, it must be a forbearance, which is the taking away of a right. It's the common position among law professors where I attended that the GPL is a contract, as opposed to a straight up license, because of these very clauses.
> [...]
> > > This clause, instead, seems to say that, if any limitation of liability
> > > is unenforceable, then, boom!, the whole grant of permission is void.
> > > This could discriminate against people living in jurisdictions where
> > > local law forbids too extreme limitations of liability.
> > > If this is the case, then it fails DFSG#5.
> >
> > This continues to be a laughable argument. The GPL discriminates against
> > countries who jail anyone who uses software licensed under the GPL.
> > Is that discrimination?
>
> I don't think so: in your example, that law is *specifically* designed
> to attack the GPL, whatever the GPL text may say. As a consequence, the
> discrimination is not caused by the GPL, but by the law-makers.
>
> [...]
> > Is this clause really any different than "you aren't allowed to do
> > anything illegal with this software?"
>
> Steve Langasek has already explained that such a clause is equally
> non-free.
While looking up the specific clauses for disclaimer and liability, I noticed section 12 of GPLv3. Curious as to how that clause is not essentially the same as the non-export clause? As a resident of the United States, I am bound by its laws. As I read (s)12, if those laws prohibited me from complying with a clause of the GPL, I lose the license granted by the GPL. Sure sounds like a "don't do anything illegal" clause to me.
> > > [...]
> > > > This license forms the entire agreement regarding the subject matter
> > > > hereof and
> > > > supersedes all proposals and prior discussions and writings between the
> > > > parties
> > > > with respect thereto.
> > >
> > > It really seems that no other grant of permission may be considered
> > > valid...
> >
> > How do you reach that conclusion?!
>
> Since "this license [...] supersedes all proposals and prior
> discussions and writings [...]", it seems that I cannot consider any
> other *prior* grant of permission as valid.
>
> Maybe *later* grants of permission can be valid and I should have been
> less fast in generalizing my sentence to *any* other grant...
Ah, perhaps I mistakenly read your comment to suggest there was /no/ grant of permission, as in this clause negated the grant at the top. But, yes, this is a very common contractual construction, since oral agreements are (a) easy to make and (b) binding, this sort of "four corners of the agreement" clause that explicitly excludes any previous negotiations is to be expected in nearly any contract. What's more interesting is it doesn't go on to prohibit modification of the agreement without consent of identified agents.
I guess my question is, do you feel it in someway presents a DFSG problem?
> If this is actually your objection, then point taken.
>
> >
> > > > This license does not affect any ownership,
> > > > rights, title,
> > > > or interest in, or relating to, this material.
> > >
> > > I think that this means that, if I hold some right (e.g.: copyright)
> > > on a part of the work, then I am not constrained by the license, for
> > > that part of the work.
> > > This seems to be superfluous to say.
> >
> > The license is just being very clear that the license in now way
> > diminishes the ownership rights of AMD in the underlying code. Hardly
> > superfluous if you are AMD.
>
> I think it is superfluous, since no part of the license seems to do
> things like transfers of copyright ownerships or such.
> Hence, it looks like a clause that makes it very clear what is already
> rather clear: in this sense, I think it is superfluous.
Then perhaps you did not go to law school, where they drill into your head that words are cheep, but litigation is expensive. Always better to err on the side over verbosity if there is ever a doubt... and given the FUD that circulates regarding FOSS licenses "stealing" code, I can't say I'm surprised a corporate lawyer would add this extra clarification.
> I may be wrong, of course.
> The clause seems to be harmless, anyway.
--
Francesco Poli
[...]
> Note that cal.h is a header file containing only function declarations and
> no actual code (although I guess what counts as 'actual code' is debatable).
> The matching function definitions are in a proprietary library that the
> BOINC client loads at runtime with dlopen/dlsym. Dynamically linking to a
> proprietary library like that is OK for BOINC since it is licensed under the
> LGPL, but I don't know whether it's OK for Debian.
I am a bit puzzled now.
Package boinc seems to be in Debian (main):
http://packages.qa.debian.org/b/boinc.html
Where is this proprietary library distributed?
I do not seem to able to find it in
http://packages.debian.org/changelogs/pool/main/b/boinc/boinc_6.10.17+dfsg-2/copyright
I hope that this means it is *not* included in the package.
Is it shipped in one of boinc dependencies/recommendations/suggestions?
BTW, there are some files listed in the above cited copyright file,
released under a license that seems to be really troublesome:
The files are
api/texfont.[cpp|h], samples/glut/glutbitmap.h
samples/glut/glut.h
samples/glut/win32_util.[ch] samples/glut/win32_x11.[ch]
The license is
| License: other
| This program is freely distributable without licensing fees and is
| provided without guarantee or warrantee expressed or implied.
| This program is -not- in the public domain.
I cannot see any permission to modify or distribute modified versions:
these files do *not* seem to comply with DFSG#3.
Andrew Dalke
> No, it's not different at all - and a license that says "you aren't allowed
> to do anything illegal with this software" is *not* DFSG-compliant. Civil
> disobedience should not result in violations of the copyright licenses of
> software in Debian.
Civil disobedience works by appealing to the general public. You don't
simply break the law and claim it was rightful civil disobedience.
Those who choose not the follow the law must know the consequences of
what they do.
By that reasoning, if your cause is indeed just, and worthy, then I
don't see why the same view doesn't apply to possible copyright suits.
Who's to say that the copyright owner doesn't agree with you? Why would
the potential threat of an infringement suit dissuade you more than, say,
10 years in jail? Because you can be sued and forced to declare
bankruptcy?
Or put it this way, if the software said "you may use this for illegal
purposes" then that could be seen as promoting breaking the law. And
doesn't the GPL depend on people, you know, following the law? Otherwise
I'm going to say that my not following the GPL is justifiable civil
disobedience against (rolls dice) "the hegemony of" (rolls again)
"oppressive communistic" (rolls again) "techno-weenies."
If the copyright owners of embedded software for vehicles, and of GPS
systems, had the same clause, do you think they would be suing people for
copyright infringement every time you went over the speed limit?
Andrew
da...@dalkescientific.com
Nicolas Alvarez
> Where is this proprietary library distributed?
In AMD website.
If the user downloads it and installs it, BOINC will use it, and will be
able to detect your ATI cards. In order to use the proprietary library, it
uses the function declarations in the cal.h header distributed with the
package.
Don Armstrong
> Francesco Poli wrote:
> > Where is this proprietary library distributed?
>
> In AMD website.
>
> If the user downloads it and installs it, BOINC will use it, and will be
> able to detect your ATI cards. In order to use the proprietary library, it
> uses the function declarations in the cal.h header distributed with the
> package.
It seems like AMD should really be distributing these header files
with a maximum permissive license like MIT/Expat or similar. Perhaps
someone should contact them and try to get it to happen?
Don Armstrong
--
Judge if you want.
We are all going to die.
I intend to deserve it.
-- a softer world #421
http://www.asofterworld.com/index.php?id=421
http://www.donarmstrong.com http://rzlab.ucr.edu
Steve Langasek
> By that reasoning, if your cause is indeed just, and worthy, then I
> don't see why the same view doesn't apply to possible copyright suits.
Because I'm arguing from the position that modern copyright regime is, as a
whole, just, and that it's warranted for software authors to have limited
monopoly rights over their works. If the copyright system is just, then
authors have a right to ask you not to use their works in violation of the
law, *even when that law is itself unjust*. An ethical citizen engaged in
an act of civil disobedience should not have to worry about whether he's
violating the wishes of a copyright holder by using Debian in the process.
But this all follows directly from DFSG #6, anyway. Licenses must not
discriminate against fields of endeavour to be considered free - even fields
of endeavour that are illegal.
> Who's to say that the copyright owner doesn't agree with you?
The copyright owner might agree with me, but that's DFSG #8 - if the
copyright owner gives me a personal license to use his software in acts of
civil disobedience that she agrees with, that's still not sufficient for
including the work in main.
> Or put it this way, if the software said "you may use this for illegal
> purposes" then that could be seen as promoting breaking the law.
That would be an absurd thing to put in a license, because *by default* your
compliance with the law is a matter between you and the state, not between
you and the copyright holder. So the license can remain mute on the
question, as all DFSG-free licenses I've seen are.
> Otherwise I'm going to say that my not following the GPL is justifiable
> civil disobedience
Er, go ahead and say that, but then you're entirely missing the point.
> If the copyright owners of embedded software for vehicles, and of GPS
> systems, had the same clause, do you think they would be suing people for
> copyright infringement every time you went over the speed limit?
What I think is that the possibility that they *could* sue means such a
license fails the DFSG.
Steve Langasek
> While looking up the specific clauses for disclaimer and liability, I
> noticed section 12 of GPLv3. Curious as to how that clause is not
> essentially the same as the non-export clause? As a resident of the United
> States, I am bound by its laws. As I read (s)12, if those laws prohibited
> me from complying with a clause of the GPL, I lose the license granted by
> the GPL. Sure sounds like a "don't do anything illegal" clause to me.
On the contrary, the GPL only says that you can't use the /law/ as an excuse
for not complying with the /license/. The language leaves open the
possibility that you might choose to continue distributing a work in
compliance with the GPL but in violation of the law. :)
Francesco Poli
> [dropping pkg-boi...@lists.alioth.debian.org as I don't think they care about this...]
[Yes, I agree.]
[Please also avoid Cc:ing me, since I am subscribed to debian-legal...]
[While you are at it, could you please set a sane wrap value? Long
lines in your e-mail messages are unpractical to read on web archives
and to reply to...]
> On Saturday 02 January 2010 10:38:52 am Francesco Poli wrote:
[...]
> > I re-iterate: how can policy or practice be refined or discussed, if
> > *any* disagreement is banned from Debian mailing lists?
> >
> > Moreover, in the present case, I think that I honestly stated that the
> > DFSG-freeness of choice of venue clauses is controversial and then I
> > provided my own personal opinion, *explicitly* labeling it as such.
> > I don't remember any clear decision by the Debian Project on this
> > matter, otherwise I would have cited it (as I often do with the GR on
> > the GFDL, for instance).
>
> The problem with this line of argument is that it sounds very similar
> to the climate skeptics / intelligent design crowd. The approach seems
> to be, "continue to inject controversy even when there is community
> consensus, in hopes of giving the appearance of true division."
I don't think this comparison is fair.
IMHO, there's much more uncertainty in DFSG interpretation and license
clause effect prediction, than in validation of scientific theories.
Also, my goal is not to "inject controversy".
I just express my opinion, in the sincere hope that it can help in
enhancing Debian. When decision-makers disagree with me, I still hope
I can persuade them to change their minds. Whenever I am *aware* that
my opinion is not in line with the official position of the Debian
Project, I try to explicitly point this out.
--
http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
Need some pdebuild hook scripts?
Francesco Poli
> On Saturday 02 January 2010 10:15:19 am Francesco Poli wrote:
> > On Fri, 1 Jan 2010 15:13:58 -0800 Sean Kellogg wrote:
[...]
> > Neutrality? We are not on Wikipedia, here!
> > I clearly stated that I was going to express my own personal opinion...
>
> Which is exactly why d-l still has a bad reputation in Debian...
As I already said in the past, I am not the FTP-masters' spokesperson:
if you want to know *their* opinion, you should ask it to *them*.
On debian-legal you can get opinions from people who care about
DFSG-freeness issues and spend time in reviewing licenses and such, for
the benefit of the Debian Project.
BTW, being attacked for spending one's own time in analyzing licenses
to contribute to the Debian Project is getting more and more
frustrating...
[...]
> > > The GPL takes away all sorts of rights... this can't possible be what
> > > DFSG #1 is intended on prohibiting.
> >
> > Which rights (that I would have in the absence of any license) does the
> > GPL take away?
>
> GPLv3 sections 15 and 16. The presence of such waivers are often seen
> by courts as a form of consideration, which implies it is either a fee
> or a forbearance. Since it's not a fee in this case, it must be a
> forbearance, which is the taking away of a right. It's the common
> position among law professors where I attended that the GPL is a
> contract, as opposed to a straight up license, because of these very
> clauses.
I think that depicting this as taking away "all sorts of rights" is a
bit exaggerated.
Disclaimers of warranty and limitations of liability are commonly found
in Free Software licenses: it's technically true that they can be seen
as rights taken away (and thus some sort of exception to my DFSG#1
interpretation), but I don't see them as comparable to the clause we
were talking about, where *any* suit against the copyright holder is
forbidden.
[...]
> > Steve Langasek has already explained that such a clause is equally
> > non-free.
>
> While looking up the specific clauses for disclaimer and liability,
> I noticed section 12 of GPLv3.
[...]
Again, Steve Langasek has already replied.
[...]
> > Since "this license [...] supersedes all proposals and prior
> > discussions and writings [...]", it seems that I cannot consider any
> > other *prior* grant of permission as valid.
> >
> > Maybe *later* grants of permission can be valid and I should have been
> > less fast in generalizing my sentence to *any* other grant...
>
> Ah, perhaps I mistakenly read your comment to suggest there was /no/
> grant of permission, as in this clause negated the grant at the top.
> But, yes, this is a very common contractual construction [...]
>
> I guess my question is, do you feel it in someway presents a DFSG problem?
It would not be a DFSG-freeness issue, if the rest of the license were
OK. But the rest of the license is not enough to meet the DFSG, so I
was hoping I was not reading the whole story...
Instead, it seems I was reading the entire grant of permission.
[...]
> > I think it is superfluous, since no part of the license seems to do
> > things like transfers of copyright ownerships or such.
> > Hence, it looks like a clause that makes it very clear what is already
> > rather clear: in this sense, I think it is superfluous.
>
> Then perhaps you did not go to law school,
Definitely not. I am a mechanical engineer...
> where they drill into your head that words are cheep, but litigation is
> expensive. Always better to err on the side over verbosity if there is
> ever a doubt...
OK, so you agree that this clause was added just to make it sure that
the concept is crystal clear, but that the concept is already
implicitly present in the rest of the license...
This is basically what I meant by "superfluous".
--
http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
Need some pdebuild hook scripts?
MJ Ray
> > Moreover, in the present case, I think that I honestly stated that the
> > DFSG-freeness of choice of venue clauses is controversial and then I
>
> The problem with this line of argument is that it sounds very
> similar to the climate skeptics / intelligent design crowd.
So objecting to agreeing to travel to Texas from Europe (or be judged
in one's absence which I believe means you almost always lose) is very
similar to a religious argument to you?
Wow, it seems an utterly practical matter to me.
> The
> approach seems to be, "continue to inject controversy even when
> there is community consensus, in hopes of giving the appearance of
> true division." Sure, it's their right to believe as they wish, and
> to speak as they wish, but to the community that has moved on it
> sure is awfully annoying and dilatory. The FUD strategy has a way of
> getting of people's nerves awfully quickly :)
I'm not convinced that there is consensus on choice-of-venue being
acceptable. I suspect there's a mix of considering it acceptable,
thinking we can fight it when needed and ignorance.
Returning to the intelligent design analugy, it's like the difference
between outlawing promotion of it completely and stopping it being
taught as the One True Way.
Hope that explains,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Anthony W. Youngman
<m...@phonecoop.coop> writes
>I'm not convinced that there is consensus on choice-of-venue being
>acceptable. I suspect there's a mix of considering it acceptable,
>thinking we can fight it when needed and ignorance.
Actually, I believe choice-of-venue is unenforceable in our jurisdiction
:-)
Under UK law, in a person-vs-corporation situation, the person has
choice of venue. END OF.
Quite how that would pan out if it was a US corp, I don't know.
Certainly I think, if I demanded change of venue, it would instantly
make any US judgement unenforceable on me (or MJ if he demanded change
of venue).
Cheers,
Wol
--
Anthony W. Youngman - ant...@thewolery.demon.co.uk
Michael Poole
> In message <201001041231...@nail.towers.org.uk>, MJ Ray
> <m...@phonecoop.coop> writes
>>I'm not convinced that there is consensus on choice-of-venue being
>>acceptable. I suspect there's a mix of considering it acceptable,
>>thinking we can fight it when needed and ignorance.
>
> Actually, I believe choice-of-venue is unenforceable in our
> jurisdiction :-)
That's convenient for you (assuming it's true). I live in Virginia,
which has enacted a law called UCITA that gives almost unlimited scope
to shrink-wrap and click-wrap licenses; but even without that, US courts
generally uphold choice-of-venue clauses in software licenses. I hope
that those situated similarly to me count for something when evaluating
DFSG compliance -- just going through discovery in one lawsuit venued on
the far side of the country was more than enough for me. (Setting aside
the cost of retaining a lawyer in a jurisdiction with slightly different
laws than I'm familiar with, the three-hour time zone difference made it
a pain to coordinate things without disrupting my working schedule.
IMO, software users don't deserve to have far-away lawsuits against them
made easier.)
Michael Poole
Sean Kellogg
> Sean Kellogg wrote:
> > > Moreover, in the present case, I think that I honestly stated that the
> > > DFSG-freeness of choice of venue clauses is controversial and then I
> > > provided my own personal opinion, *explicitly* labeling it as such. [...]
> >
> > The problem with this line of argument is that it sounds very
> > similar to the climate skeptics / intelligent design crowd.
>
> So objecting to agreeing to travel to Texas from Europe (or be judged
> in one's absence which I believe means you almost always lose) is very
> similar to a religious argument to you?
>
> Wow, it seems an utterly practical matter to me.
You can object all you want. I'm not say that choice-of-venue clauses are somehow "great"... just saying that aren't prohibited by the DFSG. The DFSG does not give you everything you want, only what you need :)
> > The
> > approach seems to be, "continue to inject controversy even when
> > there is community consensus, in hopes of giving the appearance of
> > true division." Sure, it's their right to believe as they wish, and
> > to speak as they wish, but to the community that has moved on it
> > sure is awfully annoying and dilatory. The FUD strategy has a way of
> > getting of people's nerves awfully quickly :)
>
> I'm not convinced that there is consensus on choice-of-venue being
> acceptable. I suspect there's a mix of considering it acceptable,
> thinking we can fight it when needed and ignorance.
I can't speak to the makeup of the d-l list, or the DD membership... but I'm /fairly/ certain that there are packages in main right now with choice-of-venue clauses that have been approved by the FTP masters. Sounds like a settled matter to me, unless someone wants to bring the matter to a vote of the DD membership. But, in my observation, the d-l hardline position tends to not carry the day in such votes.
> Returning to the intelligent design analugy, it's like the difference
> between outlawing promotion of it completely and stopping it being
> taught as the One True Way.
Who said anything about outlawing? I didn't ask for Francesco to be banned from the mailing list... goodness, he does more license analysis than anyone else, and generally he's quite good at it. He's welcome to say whatever he likes, just as I'm welcome to say he's wrong :)
--
Sean Kellogg
e: skel...@probonogeek.org
Sean Kellogg
> On Sat, 2 Jan 2010 12:28:32 -0800 Sean Kellogg wrote:
>
> > [dropping pkg-boi...@lists.alioth.debian.org as I don't think they care about this...]
>
> [Yes, I agree.]
> [Please also avoid Cc:ing me, since I am subscribed to debian-legal...]
Noted... though, my mail client handles such things.
> [While you are at it, could you please set a sane wrap value? Long
> lines in your e-mail messages are unpractical to read on web archives
> and to reply to...]
The archive looks fine [1], and in my experience more mail clients prefer to wrap on their own than my client doing it for them. Yes, this is a particular problem with Outlook... and yes, that's what most of the recipients of my email use.
[1] http://www.mail-archive.com/debian...@lists.debian.org/msg40546.html
> > On Saturday 02 January 2010 10:38:52 am Francesco Poli wrote:
> [...]
> > > I re-iterate: how can policy or practice be refined or discussed, if
> > > *any* disagreement is banned from Debian mailing lists?
> > >
> > > Moreover, in the present case, I think that I honestly stated that the
> > > DFSG-freeness of choice of venue clauses is controversial and then I
> > > provided my own personal opinion, *explicitly* labeling it as such.
> > > I don't remember any clear decision by the Debian Project on this
> > > matter, otherwise I would have cited it (as I often do with the GR on
> > > the GFDL, for instance).
> >
> > The problem with this line of argument is that it sounds very similar
> > to the climate skeptics / intelligent design crowd. The approach seems
> > to be, "continue to inject controversy even when there is community
> > consensus, in hopes of giving the appearance of true division."
>
> I don't think this comparison is fair.
> IMHO, there's much more uncertainty in DFSG interpretation and license
> clause effect prediction, than in validation of scientific theories.
>
> Also, my goal is not to "inject controversy".
> I just express my opinion, in the sincere hope that it can help in
> enhancing Debian. When decision-makers disagree with me, I still hope
> I can persuade them to change their minds. Whenever I am *aware* that
> my opinion is not in line with the official position of the Debian
> Project, I try to explicitly point this out.
I hear what you're saying, and I sympathize with your plight. Changing minds in Debian is a hurculean task. But the dude asking the question wasn't a Debian decision-maker, he was just some guy asking about the DFSG-ness of a license as applied to a particular piece of software. I my opinion, the mailing list should provide him as direct and politics-free answer as possible. At least, that's what I would want to receive if I had asked the question.
-Sean
--
Sean Kellogg
e: skel...@probonogeek.org
Michael Poole
> You can object all you want. I'm not say that choice-of-venue clauses
> are somehow "great"... just saying that aren't prohibited by the
> DFSG. The DFSG does not give you everything you want, only what you
> need :)
The usual argument is that choice of venue violates DFSG #5 by
discriminating against people who live outside the venue. Is there some
tenable argument that these license actually don't discriminate against
these users?
(People have been known to overlook details in the past. The fact that
some works currently in Debian have choice-of-venue license clauses does
not in itself make those clauses DFSG-compliant.)
Michael Poole
Sean Kellogg
> Anthony W. Youngman writes:
>
> > In message <201001041231...@nail.towers.org.uk>, MJ Ray
> > <m...@phonecoop.coop> writes
> >>I'm not convinced that there is consensus on choice-of-venue being
> >>acceptable. I suspect there's a mix of considering it acceptable,
> >>thinking we can fight it when needed and ignorance.
> >
> > Actually, I believe choice-of-venue is unenforceable in our
> > jurisdiction :-)
>
> That's convenient for you (assuming it's true). I live in Virginia,
> which has enacted a law called UCITA that gives almost unlimited scope
> to shrink-wrap and click-wrap licenses; but even without that, US courts
> generally uphold choice-of-venue clauses in software licenses. I hope
> that those situated similarly to me count for something when evaluating
> DFSG compliance -- just going through discovery in one lawsuit venued on
> the far side of the country was more than enough for me. (Setting aside
> the cost of retaining a lawyer in a jurisdiction with slightly different
> laws than I'm familiar with, the three-hour time zone difference made it
> a pain to coordinate things without disrupting my working schedule.
> IMO, software users don't deserve to have far-away lawsuits against them
> made easier.)
Choice of venue clauses are uber complicated in the United States, and UCITA certainly doesn't help. Having said that, if a suit is to be brought it is going to be brought somewhere. With the GPL, which of course has no choice of venue clause, the litigants get to look forward to a series of back-and-forth briefs about the venue before they even get to the merits of the suit... which is just that much more expense. To say nothing of international cases and choice-of-law issues :(
--
Sean Kellogg
e: skel...@probonogeek.org
Sean Kellogg
> Sean Kellogg writes:
>
> > You can object all you want. I'm not say that choice-of-venue clauses
> > are somehow "great"... just saying that aren't prohibited by the
> > DFSG. The DFSG does not give you everything you want, only what you
> > need :)
>
> The usual argument is that choice of venue violates DFSG #5 by
> discriminating against people who live outside the venue. Is there some
> tenable argument that these license actually don't discriminate against
> these users?
The discrimination clause is so very overblown on this list... it seems it is used to defend against any license clause these days. Heaven help us if the DFSG #10 didn't explicitly say the GPL was covered.
I don't consider choice-of-venue to be discrimination, it simple pre-determines a question that /must/ be answered before the a possible law suit can begin. That the decision is made to the disadvantage of the user isn't discrimination, it just /is/. But let's consider this clause for just a moment.
1) You download the code in some EU country and promptly violate the terms of the license (though, how you would actually violate them in a way they would pursue is really beyond me).
2) AMD brings suit against you in some US district court.
3) You decide the case is stupid and refuse to attend, as is your legal right.
4) A default judgment is entered against you for failure to show up for $1 million!!!
5) AMD can't do squat at this point. Unless the court that issued the judgment has control over assets you own, they can't actually do anything to you. So now AMD has to go and sue you at your home anyway.
But in those situations where the user does have assets under jurisdiction of the court in question, they have previously chosen to have some ties to that jurisdiction. And /now/ it really is a question of which venue, because both sides of interests to protect. As I stated before, we can either have venue pre-decided, or we can have a round of expensive legal briefs.
> (People have been known to overlook details in the past. The fact that
> some works currently in Debian have choice-of-venue license clauses does
> not in itself make those clauses DFSG-compliant.)
Except that this issue has been debated at length many times and has never, to my knowledge, resulted in a package being excluded. For my money, I don't think it's a case of overlooking.
-Sean
--
Sean Kellogg
e: skel...@probonogeek.org
Nicolas Alvarez
> I'm not convinced that there is consensus on choice-of-venue being
> acceptable. I suspect there's a mix of considering it acceptable,
> thinking we can fight it when needed and ignorance.
This choice-of-venue discussion looks like it won't get consensus soon, and
it is getting us away from the original thread topic.
How about we try this? Let's assume for a moment that choice-of-venue is
both acceptable and allowed by the DFSG. Then look at the *rest* of the
cal.h license terms instead of continuing the argument about this one.
After all, if one clause is DFSG-incompatible, the file is DFSG-
incompatible. That's enough to take action (remove the file, contact
upstream to remove the file, contact AMD to change header license, move
package to non-free, etc); it's irrelevant whether the other clauses are
compatible or not.
--
Nicolas
(I read mailing lists through Gmane. Please don't Cc me on replies; it makes
me get one message on my newsreader and another on email.)
Marco d'Itri
>The usual argument is that choice of venue violates DFSG #5 by
>discriminating against people who live outside the venue. Is there some
The usual argument of the DFSG revisionists is that everything is a
restriction or a discrimination, so it's not really helpful.
--
ciao,
Marco
Michael Poole
> MJ Ray wrote:
>> I'm not convinced that there is consensus on choice-of-venue being
>> acceptable. I suspect there's a mix of considering it acceptable,
>> thinking we can fight it when needed and ignorance.
>
> This choice-of-venue discussion looks like it won't get consensus soon, and
> it is getting us away from the original thread topic.
>
> How about we try this? Let's assume for a moment that choice-of-venue is
> both acceptable and allowed by the DFSG. Then look at the *rest* of the
> cal.h license terms instead of continuing the argument about this one.
Reserving the choice-of-venue issue for other discussion, this is near
the start of the license (reflowed for ease of reading):
In no event shall anyone redistributing or accessing or using this
material commence or participate in any arbitration or legal action
relating to this material against Advanced Micro Devices, Inc. or any
copyright holders or contributors. The foregoing shall survive any
expiration or termination of this license or any agreement or access
or use related to this material.
According to this, downloading and reading the file to evaluate whether
it infringes copyright would render one unable to file suit if one
decides that it does infringe copyright. If I recall correctly, similar
anti-lawsuit provisions have been deemed DFSG-noncompliant in the past.
Michael
Marco d'Itri
>How about we try this? Let's assume for a moment that choice-of-venue is
>both acceptable and allowed by the DFSG. Then look at the *rest* of the
>cal.h license terms instead of continuing the argument about this one.
As explained, the license does not really matter since function
definitions usually are not subject to copyright.
--
ciao,
Marco
Nicolas Alvarez
> nicolas...@gmail.com wrote:
>
>>How about we try this? Let's assume for a moment that choice-of-venue is
>>both acceptable and allowed by the DFSG. Then look at the *rest* of the
>>cal.h license terms instead of continuing the argument about this one.
>
> As explained, the license does not really matter since function
> definitions usually are not subject to copyright.
[function definitions are the actual code, so I'll assume you meant
declarations]
When was that said? I couldn't find anyone in this thread saying
declarations aren't subject to copyright.
--
Nicolas
(I read mailing lists through Gmane. Please don't Cc me on replies; it makes
me get one message on my newsreader and another on email.)
Walter Landry
> On Sunday 03 January 2010 09:52:04 am Francesco Poli wrote:
>> [While you are at it, could you please set a sane wrap value? Long
>> lines in your e-mail messages are unpractical to read on web archives
>> and to reply to...]
>
> The archive looks fine [1],
The official archive does not
http://lists.debian.org/debian-legal/2010/01/msg00030.html
> and in my experience more mail clients prefer to wrap on their own
> than my client doing it for them. Yes, this is a particular problem
> with Outlook... and yes, that's what most of the recipients of my
> email use.
Many people on this list prefer for you to line wrap. Most people
on this list do not use Outlook, since it is not packaged for Debian.
Cheers,
Walter Landry
wla...@caltech.edu
Francesco Poli
> On Sunday 03 January 2010 09:52:04 am Francesco Poli wrote:
[...]
> > [While you are at it, could you please set a sane wrap value? Long
> > lines in your e-mail messages are unpractical to read on web archives
> > and to reply to...]
>
> The archive looks fine [1]
[...]
> [1] http://www.mail-archive.com/debian...@lists.debian.org/msg40546.html
[...]
Walter Landry has already pointed out that this is not the official
archive...
[...]
> > Also, my goal is not to "inject controversy".
> > I just express my opinion, in the sincere hope that it can help in
> > enhancing Debian. When decision-makers disagree with me, I still hope
> > I can persuade them to change their minds. Whenever I am *aware* that
> > my opinion is not in line with the official position of the Debian
> > Project, I try to explicitly point this out.
>
> I hear what you're saying, and I sympathize with your plight. Changing
> minds in Debian is a hurculean task. But the dude asking the question
> wasn't a Debian decision-maker, he was just some guy asking about the
> DFSG-ness of a license as applied to a particular piece of software. I
> my opinion, the mailing list should provide him as direct and
> politics-free answer as possible.
That's what I was trying to provide, but I cannot quote the official
position when I do not know there's one.
For the choice of venue issue, I depicted the situation I was aware of
(long discussions, no clear consensus, but many people against such
clauses, including me!).
Steve Langasek
> This choice-of-venue discussion looks like it won't get consensus soon, and
> it is getting us away from the original thread topic.
> How about we try this? Let's assume for a moment that choice-of-venue is
> both acceptable and allowed by the DFSG. Then look at the *rest* of the
> cal.h license terms instead of continuing the argument about this one.
This has already been done. The license doesn't permit modification, so it
fails the DFSG.
However, it's been pointed out that the header file may not be copyrightable
*at all* because it only contains interface definitions.
> After all, if one clause is DFSG-incompatible, the file is DFSG-
> incompatible. That's enough to take action (remove the file, contact
> upstream to remove the file, contact AMD to change header license, move
> package to non-free, etc); it's irrelevant whether the other clauses are
> compatible or not.
Well, if one of the possible courses of action is to ask AMD to change the
license, I recommend having an exhaustive list of DFSG problems with the
license ready to hand, lest you find that they try to solve this by editing
their license to address *only* the issue you've mentioned.
Sean Kellogg
> Sean Kellogg <skel...@probonogeek.org> wrote:
> > On Sunday 03 January 2010 09:52:04 am Francesco Poli wrote:
> >> [While you are at it, could you please set a sane wrap value? Long
> >> lines in your e-mail messages are unpractical to read on web archives
> >> and to reply to...]
> >
> > The archive looks fine [1],
>
> The official archive does not
>
> http://lists.debian.org/debian-legal/2010/01/msg00030.html
>
> > and in my experience more mail clients prefer to wrap on their own
> > than my client doing it for them. Yes, this is a particular problem
> > with Outlook... and yes, that's what most of the recipients of my
> > email use.
>
> Many people on this list prefer for you to line wrap. Most people
> on this list do not use Outlook, since it is not packaged for Debian.
Wow... what a truly brilliant discovery! Using kmail in the only way that doesn't cause massive unreadability issues on a huge number of mail clients in the world and has zero problems on the major web email clients or Thunderbird or kmail itself breaks the debian official archive? Yet works fine on an unofficial archive!?
Truth be told, I've been looking for a good reason to jump off this list for years (I think I've been a subscriber under one address or another for like nine years now).
I'll spare you the diatribe, you know the song and dance already.
Ciao,
Sean
--
Sean Kellogg
e: skel...@probonogeek.org
Michael Poole
> On Monday 04 January 2010 09:15:20 am Michael Poole wrote:
>> Sean Kellogg writes:
>>
>> > You can object all you want. I'm not say that choice-of-venue clauses
>> > are somehow "great"... just saying that aren't prohibited by the
>> > DFSG. The DFSG does not give you everything you want, only what you
>> > need :)
>>
>> The usual argument is that choice of venue violates DFSG #5 by
>> discriminating against people who live outside the venue. Is there some
>> tenable argument that these license actually don't discriminate against
>> these users?
>
> The discrimination clause is so very overblown on this list... it
> seems it is used to defend against any license clause these
> days. Heaven help us if the DFSG #10 didn't explicitly say the GPL was
> covered.
Argument by flat assertion tends not to change many minds. What
problems would the GPL have under the reading of "discrimination" that I
suggested? Rather than just saying it's an undesirable reading of
DFSG#5, can you propose a better reading or explain why it is so
undesirable?
> I don't consider choice-of-venue to be discrimination, it simple
> pre-determines a question that /must/ be answered before the a
> possible law suit can begin. That the decision is made to the
> disadvantage of the user isn't discrimination, it just /is/. But let's
> consider this clause for just a moment.
That question /must/ be answered, indeed -- but what business does a
software license have in dictating how it should be answered? We do not
allow software licenses to dictate the side of road on which users
drive. (Having to drive on the left side of the road does not
discriminate against some users, it just /is/!)
Step back and look at your argument. You argue that the license *does*
make that determination, and that in doing so it *does* disadvantage
some users, but that it does not matter if it does. Your reason for
saying that it does not matter seems to hinge on it being potentially
expensive to answer the question. The goal of the DFSG is not to
minimize overall cost -- it is to increase users' software freedoms, and
the analysis should be couched in those terms rather than in overall
cost avoidance.
(I can tell you almost for certain that it is cheaper for a user to use
the default venue rules, and litigate that issue, than to have enforced
foreign venue. In my single data point -- admittedly not revolving
around copyright or a software license -- dismissal for lack of personal
jurisdiction would have run several thousand dollars and a full civil
Federal trial would have cost about twenty times as much. If that case
were in my local jurisdiction, I could have gone pro se.)
> 1) You download the code in some EU country and promptly violate the terms of the license (though, how you would actually violate them in a way they would pursue is really beyond me).
>
> 2) AMD brings suit against you in some US district court.
>
> 3) You decide the case is stupid and refuse to attend, as is your legal right.
>
> 4) A default judgment is entered against you for failure to show up for $1 million!!!
>
> 5) AMD can't do squat at this point. Unless the court that issued the judgment has control over assets you own, they can't actually do anything to you. So now AMD has to go and sue you at your home anyway.
>
> But in those situations where the user does have assets under jurisdiction of the court in question, they have previously chosen to have some ties to that jurisdiction. And /now/ it really is a question of which venue, because both sides of interests to protect. As I stated before, we can either have venue pre-decided, or we can have a round of expensive legal briefs.
Under the Hague Convention on Foreign Judgments in Civil and Commercial
Matters[1], many countries (including the US, most or all of the EU, and
others) have agreed to enforce foreign judgments in their own courts.
While I have heard of one case where UK courts declined to enforce a US
default judgment against a UK resident, it does not appear that default
judgments are inherently excepted from the Convention.
As I am sure you are aware, it is easier for a plaintiff to enforce an
existing judgment than to win a case ab initio.
[1]- http://www.legallanguage.com/resources/treaties/hague/1971-february-1st-convention-1/
Michael
Ben Finney
> On Sunday 03 January 2010 09:52:04 am Francesco Poli wrote:
> > [Please also avoid Cc:ing me, since I am subscribed to debian-legal...]
>
> Noted... though, my mail client handles such things.
You appear to be using KMail. You should use the “reply to list”
feature, which AFAICT is bound to the ‘L’ key. (This will also do the
right thing on any standards-compliant mailing list, so you don't need
to treat Debian's mailing lists specially.)
--
\ “Not to be absolutely certain is, I think, one of the essential |
`\ things in rationality.” —Bertrand Russell |
_o__) |
Ben Finney
MJ Ray
> mdp...@troilus.org wrote:
> >The usual argument is that choice of venue violates DFSG #5 by
> >discriminating against people who live outside the venue. Is there some
I feel it's some combination of DFSG 5 (discriminating on location)
and DFSG 1 (non-monetary cost of use), so it's not really clear-cut.
> The usual argument of the DFSG revisionists is that everything is a
> restriction or a discrimination, so it's not really helpful.
DFSG-revisionist Marco d'Itri posts much nonsense, from misattributed
quotes, to accusations that myself and others joining debian-legal since
2003 introduced new interpretations of the DFSG, including things which
had apparently been common since before 1999. Debunk him if you want
to try to quieten him for a bit.
See http://lists.debian.org/debian-legal/2006/12/msg00161.html for
more detail.
Regards,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
--
MJ Ray
> MJ Ray wrote:
> > I'm not convinced that there is consensus on choice-of-venue being
> > acceptable. I suspect there's a mix of considering it acceptable,
> > thinking we can fight it when needed and ignorance.
>
> This choice-of-venue discussion looks like it won't get consensus soon, and
> it is getting us away from the original thread topic.
>
> How about we try this? Let's assume for a moment that choice-of-venue is
> both acceptable and allowed by the DFSG. Then look at the *rest* of the
> cal.h license terms instead of continuing the argument about this one.
I agree that one failure makes it fail to follow the DFSG, but if
someone's going to contact AMD, it seems worth addressing all problems
and not let things like choice-of-venue get dismissed because they're
usually merely controversial rather than clear-cut REJECT reasons.
Given the number of problems and possible problems, requesting a
switch to something Expat-like seems a good option to me.
Hope that helps,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Mike Hommey
> On Sat, 02 Jan 2010, Nicolas Alvarez wrote:
> > Francesco Poli wrote:
> > > Where is this proprietary library distributed?
> >
> > In AMD website.
> >
> > If the user downloads it and installs it, BOINC will use it, and will be
> > able to detect your ATI cards. In order to use the proprietary library, it
> > uses the function declarations in the cal.h header distributed with the
> > package.
>
> It seems like AMD should really be distributing these header files
> with a maximum permissive license like MIT/Expat or similar. Perhaps
> someone should contact them and try to get it to happen?
Or maybe nobody should care, because they don't contain anything
copyrightable ? (except maybe comments)
Mike
Michael Poole
> On Sat, Jan 02, 2010 at 03:43:53PM -0800, Don Armstrong wrote:
>> On Sat, 02 Jan 2010, Nicolas Alvarez wrote:
>> > Francesco Poli wrote:
>> > > Where is this proprietary library distributed?
>> >
>> > In AMD website.
>> >
>> > If the user downloads it and installs it, BOINC will use it, and will be
>> > able to detect your ATI cards. In order to use the proprietary library, it
>> > uses the function declarations in the cal.h header distributed with the
>> > package.
>>
>> It seems like AMD should really be distributing these header files
>> with a maximum permissive license like MIT/Expat or similar. Perhaps
>> someone should contact them and try to get it to happen?
>
> Or maybe nobody should care, because they don't contain anything
> copyrightable ? (except maybe comments)
One can agree to, and be bound by, a license that has nothing to do with
copyright. Some open source software licenses (including, I believe,
some generally DFSG-compliant licenses) use contract-based structures to
impose limits on behaviors that are not reserved rights under copyright
law.
The license does not specifically prohibit reverse engineering, so
someone could (at least potentially, if they were careful enough) create
a compatible header file that did not fall under this license -- but no
one has done so, and until (a) someone does that and (b) these software
packages use that file instead of the current one, the license in the
current file is very relevant.
Michael Poole
Don Armstrong
> On Sat, Jan 02, 2010 at 03:43:53PM -0800, Don Armstrong wrote:
> > It seems like AMD should really be distributing these header files
> > with a maximum permissive license like MIT/Expat or similar.
> > Perhaps someone should contact them and try to get it to happen?
>
> Or maybe nobody should care, because they don't contain anything
> copyrightable ?
Whether the code bits are copyrightable or not is necessarily a
jurisdiction-dependent question. While I'd hope that the code bits
weren't copyrightable (at least in the US), I'm not aware of case law
which has dealt with the copyrightability of interfaces and header
files which have a degree of flexibility as to their implementation.
As such, when the author states that the work is indeed copyrighted,
our default position should be that they are correct, and we should
attempt to obtain a license to use the work that satisfies the DFSG.
Alternatively, since the interface itself shouldn't be copyrighted,
though a particular representation of it may be, a chinese wall
implementation of the interface can be enacted.
> (except maybe comments)
In this case, the comments are rather copious, so they are certainly
copyrighted. We definetly cannot distribute the file as it exists
upstream in BOINC.[1]
Don Armstrong
1: http://boinc.berkeley.edu/svn/trunk/boinc/lib/cal.h
--
I really wanted to talk to her.
I just couldn't find an algorithm that fit.
-- Peter Watts _Blindsight_ p294
http://www.donarmstrong.com http://rzlab.ucr.edu