Re: [IBPP-DISCUSS] IBPP license 1.0
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.
>
> >> 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?
> >> 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.
> >> 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.
[...]
> >> * 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?
> >> 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.
> 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.
> >> * 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?
[...]
> The MIT License (in case there would be multiple versions, I'm =20
> referring to this one: http://www.opensource.org/licenses/mit-=20
> license.html) is indeed very close to the wishes of the IBPP authors. =20=
I think that's the one. There are several often called MIT. Someone
has moved the copy on X.org to which
http://www.fr.debian.org/legal/licenses/ links - has anyone
a new URL besides the failed open source initiative, please?
> 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.
> 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.
> 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.
Hope that helps,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Reply to: