Re: [IBPP-DISCUSS] IBPP license 1.0
Dear,
First, thanks for your time spent around these questions.
Please see comments below.
Le 20 mars 06 à 03:39, MJ Ray a écrit :
Olivier Mascia <om-lists@tipgroup.com>
MJ Ray <mjr@phonecoop.coop>
Most of the two above should be in README and AUTHORS, in my
opinion.
There is no such files with IBPP. Much easier to have everything in a
single place.
I disagree. The description of the software and the authors will
change if
someone else extends it and it's harder to change in the licence
than in
a README. It's much easier for developers if you follow common
practices
and don't put the README and AUTHORS information into your licence.
Point taken. (There is anyway a readme.txt file, of course, I was
focused on the AUTHORS file.)
o 0.3. Authors
'Authors' is the college of private persons or legal
entities, including TIP, who at least once contributed to IBPP.
College? What law is this drafted for?
Okay, very bad translation from a french word, loosing all its =20
meaning in english.
Is it possible to see the French licence please, if that is the
legally-binding version?
There is no such french official version of the license. The
discussions and work around it were done by people whose native
language is french/dutch/german. The goal is to have a single
license, in english. There is no doubt a 1.01 revision is due for
translations and spelling issues.
College, as used here (probably very mistakenly in english), means an
implied 'group', a 'collection' of multiple people. The idea is that
'Authors' is defined such it automatically includes all the persons
(individuals, companies, other kind of legal / public / whatever
bodies) who at least once contributed to IBPP. The idea is very
simple, harder is to find the right minimalist words to express it.
This is very linked to the IBPP idea that modifications /
enhancements should be contributed back. Such contributors become de-
facto members of that 'Authors' group.
hereby grant the following permissions, free of charge, to any =20
private
person or legal entity (hereafter \"You\"):
Permission not granted to public legal entities (UK =3D plcs,
royal =20=
charter
corporations IIRC). Breaks DFSG 5 (No Discrimination Against =20
Persons) or
6 (No Discrimination Against Fields of Endeavour).
You read it: to any private (person or legal) entity.
Intent was: to any (private person) or (legal entity).
A 'legal entity' includes a 'public legal entity' as well a
'private =20
legal entity', isn't it? [...]
I think this might be just 'legal person' (as a company is a type of
person to the law, just not a natural person), but I am not a lawyer.
So, that wording is merely ambiguous at the moment, not a deliberate
attempt to exclude public companies.
Right, happy we agree. And yes, it will be rewritten to remove
ambiguity.
o 2.1. Right to Use
To use (edit when required, compile and link) the IBPP
source code as part of a larger programming work which
effectively =20=
makes use of some or all of the functionnalities offered by IBPP.
Restriction on use: we might not agree that something is effectively
making use. Lawyerbomb, possibly breaking DFSG 3 (Derived Works).
The final part "which effectively makes use of some or all of the
functionalities offered by IBPP" might be simply dropped. That is not
something really important. Who would find ways to 'use' the code
without actually calling it?
You'd be surprised. Some people print this stuff on t-shirts. Dropping
that and "programming" would solve this.
So that would become:
2.1. Right to Use
To use (edit when required, compile and link) the IBPP source code as
part of a larger work.
* 3. Duties
o 3.1. Duty to give modifications back to IBPP Authors
Any modification or addition done to IBPP will be =20
submitted
to the Authors, so that those modifications or additions can be
reviewed, possibly modified or fixed, and eventually merged in a
new
version of IBPP, if the modification is found by the Authors to
be of
interest to the IBPP users community.
Forced donation upstream of work. I regard this as a payment or
royalty on derived works, breaking DFSG 1 (Free Redistribution).
I know others disagree, but I don't understand their reasoning.
Forced donation, indeed. But not a payment or a royalty. Matter of
=20
reasoning. The authors would simply appreciate to see their 'baby'
=20
benefit from some of the enhancements other people might develop:
for =20=
the benefit of the community of users. It's one thing to release
some =20=
code in the wild without any consideration to what will happen in
the =20=
future, it is another to be responsible and to look for
opportunities =20=
to centralize the evolutions / modifications so that the code can =20
mature.
I don't see why free software should allow the original licensor to
demand
the fruits of the labour of other developers, any more than non-
licensees
should be able to demand source code publication from a licensor.
Even worse, I don't see any reason why this submission should be done
for every modification or addition. That invades my privacy, describes
my programming work to the licensor and submits under-tested work
back to the licensor, because I need to do that in order to copy the
software. This is imposing two costs upon me: the cost of sending the
modifications back and the cost of lost future work if the
modifications
harm my reputation somehow.
It also means you'd get a flood first-attempt modifications, rather
than
a smaller number of well-tested or popular modifications. How much
sand
do you want to sift before you find gold?
Clearly, this point is the unique real issue we have, isn't it?
I can't comment further on this one right now, but I can at least say
that it is under close consideration for a radical change.
If that gets dropped, there will obviously be some new duty to take
its place. Something along the lines that if people modify the code
or enhance it, they *cannot* misrepresent it as being the original
IBPP code, and instead clearly state they have deliberately modified
it. I suppose this would not be an issue for various definitions of
free software.
o 3.2. Duty to play by the rules when publishing the IBPP
source code
When You publish the IBPP source code with your own =20
source
code which uses it, You must also publish this license.txt file =20
and You
must not remove any of the licensing and copyright texts located
near
the beginning of the IBPP source code files.
No-op in many (all?) copyright laws.
Please explain.
If I can't show a valid copyright licence to the work, I can't
publish it legally. Removing copyright notices is also not allowed.
What I really mean is: this clause seems harmless.
So better with it than without. Also, in consideration of the
previous point above, it might all be merged in a single point all
about not misrepresenting the original code when it has been modified.
Why does for instance the MIT license says:
"The above copyright notice and this permission notice shall be =20
included in all copies or substantial portions of the Software."?
No-op?
Not sure. I suspect it is because it predates some changes in USA law,
but I hope someone more familiar with it can explain.
Sounds like a hard motivation to keep it in the license then.
* 5. Disclaimer of Warranty
IBPP IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, =20
[...]
Should not be capitalised, in my opinion. Could it be merged with
3.3?
Why not.
Because it makes it harder to read. I think it may leave you at
risk of a
claim that an injured party did not check the details of the
disclaimer
because you deliberately made it hard to read, depending on what law
this licence is to be judged under (reminder: I am not a lawyer). As
recently noted about the GPLv3 draft, there seems to be no reason in
law for capitalising them (I think this was a comment by Eben Moglen,
but I can't find it now).
Why should it be capitalised?
I really don't insist on it. (I don't care in fact).
It is just that so many licenses, contracts, legally binding texts do
so...
I was always told that some points in legally binding texts were
capitalized to make them easier to read, or at least easier to spot,
so that people can't pretend they couldn't see it and read it. But
you just offer the counter-argument...
I wonder when a Court will agree to proceed on a claim that someone
got injured because the use of some software *had* a license. ;-)
Except for one thing: the idea of at least wishing people or =20
suggesting to people to give back their modifications to IBPP is a
=20
nice useful concept which is missing from the MIT license and many
=20
other open-source free software licenses. Remember, it's free as
in =20
free-speech, not free beer, even if there is no real price or
money =20
in the equation. The idea is: it's free, do whatever you need to
do =20
with it, but if you develop enhancements, make the original =20
community, from who you got it free, benefit from these
enhancement. =20
That's a mean to achieve better open-source free software on the
next =20=
iteration.
Indeed, but it's missing because you shouldn't force this. As you
wrote,
it's free as in free speech, not free beer: this means that the
licensor
doesn't get to demand free beer from the licensees either, which is
how
I see demands to submit my modifications back upstream prematurely, as
outlined above. If it's good, my pride will make me submit it back
when
it's been tested, or if it's popular, you'll be able to find a
licensed
copy easily.
Okay, maybe that should stay a wish and not a requirement.
Please do. I am comfortable with a very strong request to send changes
back, especially generally useful ones, but forcing people seems too
zealous for free software. Including instructions on how to send back
changes in your preferred format(s) should make it more likely that
you
get useful contributions. I think this is often put in the README or a
file called HACKING.
This is under consideration.
To synthesize, for now, this licensing discussion blocks IBPP from
being distributed along with Debian systems, not because IBPP wants
to block that (to the contrary) but because we have different views
on a small number of details and rules that Debian chose to play by.
Nearly: I think this blocks IBPP from being distributed in the Debian
official distribution. Others can distribute it along with Debian
if they wish, because we promise Debian shouldn't put heavy demands
on other software (DFSG 9: Must Not Contaminate Other Software, on
http://www.fr.debian.org/social_contract#guidelines ) and I don't
think your software tries to put restrictions on Debian if they are
distributed together.
Indeed, there is no goal of putting restrictions on Debian if IBPP
and Debian gets distributed together. Regarding IBPP there are no
restrictions too (on IBPP side of things) to let it be in the Debian
official distribution, though we understand that on Debian point of
view they cannot accept IBPP as such.
Note that I consider this a very minor detail. I really don't see
much added value for the IBPP code to be included in the official
distribution of any specific system. As I wrote in an earlier
message, it is not meant to be built as a binary library. That's just
some code, meant to be useful when included in some other work source
code. Finding it pre-distributed along with Debian or having to get
out on the Net (or elsewhere) to get it makes very very few difference.
Now it is very different for programs which happen to use IBPP code.
What we are seeking is that Debian (or any other distribution) won't
refuse program X or Y on the sole fact that the source code of that
program X or Y has some files which comes from IBPP.
Is there anything in the licensing and rules of Debian which would
block someone, anyone, public, legal, private or anything, to browse
the web, find the source code of IBPP and use it in their own
programs, developed, and run on a Debian system?
Not as far as I know. What users do with their Debian systems is
mostly up to them, in my opinion. They will be restricted in
what other programs they could combine with IBPP, though, due
to the combination of IBPP and other copyright licences like GPL.
To the best of my knowledge, someone who want to publish a work under
the GPL license can do so, IBPP clearly gives them the right to use
IBPP. IBPP does not want to be concerned in any way by whatever
license those programs (using IBPP) are distributed under, so does
not want to pollute the licensing of the larger work in which IBPP is
embedded.
--
Olivier Mascia
Reply to: