No copyright information in executable
Ben Bucksch
copyright in the finished product.
In MPL 1.1 section 3.3, there is a clause that mandates to describe the
right ownership, and that's entirely gone in section 3.2 of the new
license.
I maintain the stance that if I create a work or part of it, the least I
should get for it is that somebody else who uses it needs to inform the
users that it's me/us and not him alone who created it. That's for me
the bare minimum of fairness.
The link to the source code, and the copyright holder being in the
source code is not sufficient.
For me, MPL 2 license is entirely unacceptable without this. I have
raised this concern before, but it has not been addressed at all. I
believe it's a legitimate concern to have the copyright of the product
properly represented to end users.
---
Furthermore, I do not agree to have to pay anything at all to be able to
get third party bug fixes to software I wrote. In fact, I think they
should be rather be required to actively push these changes back to me.
http://mpl.mozilla.org/wp-content/uploads/2011/08/MPL-RC1-typography.html
Pandu Poluan
copyright notice inside an executable (or any binary form compiled
from the source) depends on whether the original source code actually
embeds such text string.
Maybe it will be better to 'require' the licensee to not alter any
copyright notice inside the source code and/or compiled binary form.
As the second part of your email... after some thinking on my part, I
can see your point: A 3rd party may acquire code someone write, fixes
some bugs, re-releases it under a different trademark but
commercially. Thus, the original creator is deprived of the bugfixes
unless she/he pays for the commercialized work (and thus acquires the
right for the modified source code).
Did I get that right?
Rgds,
> _______________________________________________
> governance-mpl-update mailing list
> governance...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance-mpl-update
>
--
--
Pandu E Poluan - IT Optimizer
My website: http://pandu.poluan.info/
Ben Bucksch
> I agree with the first part of your email. However, the presence of a
> copyright notice inside an executable (or any binary form compiled
> from the source) depends on whether the original source code actually
> embeds such text string.
>
> Maybe it will be better to 'require' the licensee to not alter any
> copyright notice inside the source code and/or compiled binary form.
This doesn't work, because our main product is Gecko, the rendering
engine. If I wanted to avoid the existing notice in the code, I'd just
write another about dialog (then I didn't remove any code) or write my
own browser window/frontend.
The old wording was good, it required to show the Mozilla copyright in
the same place where the publisher shows his own copyright. Given that
Mozilla is typically a substantial part of the product, I find that fair.
> the original creator is deprived of the bugfixes
> unless she/he pays for the commercialized work (and thus acquires the
> right for the modified source code).
> Did I get that right?
No. The GPL has that clause, but not the MPL 2.0, the MPL only says the
source code has to be available. It allows a "nominal charge" for the
source code, though. Having seen many problems involving payment,
though, including rejection of foreign credit cards and similar, I don't
agree with this. I don't see a good reason for the source code to cost
money. It should be just a file on an HTTP server.
Michael Kay
>I maintain the stance that if I create a work or part of it, the least
I should get for it is that somebody else who uses it needs to inform
the users that it's me/us and not him alone who created it.
I like this principle too, but it's becoming increasingly impractical
with the growth of repositories like Maven, where products are assembled
automatically from open source components and the end user doesn't even
know what components are being used let alone who wrote them. Producing
a long list of rolling credits when everyone has left the cinema
achieves little other than allowing the Best Boy to tell his mates
"that's me!".
>Furthermore, I do not agree to have to pay anything at all to be able
to get third party bug fixes to software I wrote. In fact, I think they
should be rather be required to actively push these changes back to me.
I was rather surprised when I discovered that MPL (all versions)
requires modifications to MPL source code to be made available only to
purchasers of the binary, and to no-one else including the original
copyright holder. In practice though, trying to force anything else
could be counter-productive. People making modifications could always
replace a whole chunk of original code by a call to a function/method in
a non-open-source module, and they would satisfy the letter of the law
even though the published modification would be of no use to anyone.
Michael Kay
Saxonica
Gervase Markham
> I was rather surprised when I discovered that MPL (all versions)
> requires modifications to MPL source code to be made available only to
> purchasers of the binary, and to no-one else including the original
> copyright holder.
This is standard open source practice for copyleft licences. Licences
which require more than this fail the "desert island test":
http://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines#debian-legal_tests_for_DFSG_compliance
The Free Software Definition has a clause on which that test is based:
"You should also have the freedom to make modifications and use them
privately in your own work or play, without even mentioning that they
exist. If you do publish your changes, you should not be required to
notify anyone in particular, or in any particular way."
http://www.gnu.org/philosophy/free-sw.html
Of course, people who receive the binary have the freedom to
redistribute the source they have been given, at no charge if they wish,
and the person who gave them the binary is legally disbarred from
preventing them from exercising that right.
Gerv
Ben Bucksch
> On 20/08/11 16:40, Michael Kay wrote:
>> I was rather surprised when I discovered that MPL (all versions)
>> requires modifications to MPL source code to be made available only to
>> purchasers of the binary, and to no-one else including the original
>> copyright holder.
> This is standard open source practice for copyleft licences. Licences
> which require more than this fail the "desert island test":
> http://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines#debian-legal_tests_for_DFSG_compliance
>
> The Free Software Definition has a clause on which that test is based:
>
> "You should also have the freedom to make modifications and use them
> privately in your own work or play, without even mentioning that they
> exist. If you do publish your changes, you should not be required to
> notify anyone in particular, or in any particular way."
> http://www.gnu.org/philosophy/free-sw.html
Just for the record, this is a SHOULD, not MUST requirement of the FSD.
"A program is free software if users have all of these freedoms", and
the paragraph you quote is not part of these essential requirements.
Also, "anyone in particular" could also be the receiver of the source
code, obviously they can and should be notified. The receiver is just as
much a role as the author, though, not "anyone in particular", like "you
must notify Netscape Corp".
I think it would be a good thing if the downstream user was required to
upstream bugfixes. *Esp.* because of projects like Debian which severely
lack in these areas, and commercial users of course.
In any case, I am not offended by "only the receiver of the binary", but
by the "nominal charge", given my bad experiences with international
payment.
Michael Kay
> In any case, I am not offended by "only the receiver of the binary",
> but by the "nominal charge", given my bad experiences with
> international payment.
I suspect that's a local problem. We receive international payments all
the time and it's usually very straightforward. We occasionally come
across customers in the US whose credit cards are only valid for
domestic payments, but a phone call to the credit card issuer usually
solves the problem. (The problem is particular to the US, because US
residents travel abroad so rarely.) And PayPal is seamless, and other
payment vehicles (like mobile) are on the way. I don't think this
problem can be used to justify any change in the license policy.
Michael Kay
Saxonica
Ben Bucksch
>
>> In any case, I am not offended by "only the receiver of the binary",
>> but by the "nominal charge", given my bad experiences with
>> international payment.
>
> I suspect that's a local problem. We receive international payments
> all the time and it's usually very straightforward.
Sure, it may well work in your shop, for many customers.
But I've tried to pay with an EU credit card at US merchants, and it
usually gets rejected.
Or the merchant only accepts payments systems that I don't want or
boycott, like PayPal.
That may not be the majority, but it may well be the case for getting
the source code from some vendor. The vendor will then shrug and say
"not our problem, you *can* pay, it's a problem with *you*". Now, you
can say I could use someone else as proxy. But I don't want to be in
that situation to get the changes to ***my*** code. I must get them for
free and painless.
"Freely you have received; freely give." (Mat 10:8)
Ben
Gervase Markham
> Just for the record, this is a SHOULD, not MUST requirement of the FSD.
I don't think the FSD uses the RFC 2119 definitions for the words
"should" and "must" :-) E.g.:
"A program is free software if users have all of these freedoms. Thus,
you _should_ be free to redistribute copies, either with or without
modifications, either gratis or charging a fee for distribution, to
anyone anywhere."
Note the "should", in a place where (if RFC 2119 was used) you would
clearly have a MUST.
> I think it would be a good thing if the downstream user was required to
> upstream bugfixes. *Esp.* because of projects like Debian which severely
> lack in these areas, and commercial users of course.
If you mandate this, then the guy on the desert island would not be
allowed to modify the software, and it would not be free software for him.
Gerv
Ben Bucksch
> I can't find any word whatsoever about even requiring the mention of
> my copyright in the finished product.
>
> In MPL 1.1 section 3.3, there is a clause that mandates to describe
> the right ownership, and that's entirely gone in section 3.2 of the
> new license.
>
> I maintain the stance that if I create a work or part of it, the least
> I should get for it is that somebody else who uses it needs to inform
> the users that it's me/us and not him alone who created it. That's for
> me the bare minimum of fairness.
Let me add a fine distinction which makes this maybe more
understandable: I do not absolutely need to have my name in the About
box (although I like it). I scream "foul" when somebody else puts *his*
name or copyright on the product, without also listing me, therefore
implicitly claiming credit for my parts of the work as well. This
creates a false impression, no matter the legal rights, and is therefore
for me a no-go.
The About dialog of the current Firefox is OK for me. There is no
"copyright" anywhere, no Credits list, and on the further links where
such information is stated, the relevant names from Mozilla are
included. That's fair.
The old (2.0?) Firefox About dialog that stated only some, handpicked
Firefox developers, but not all the other contributors, was for me
unfair. And it created a serious embarrassment for me when I told my
friends or clients that I work on Firefox, and they check About, and
they do not see my name in the list, because then *I* look like I'm an
imposter, and I hate that. In contrast, the current About dialog is OK.
The MPL 1.1 covers this nicely: If you don't state your own rights, you
don't have to state mine either. If you state yours, you have to state
mine in the same place. Fair, clear, no loopholes.
Luis Villa
<ben.buck...@beonex.com> wrote:
> On 19.08.2011 18:35, Ben Bucksch wrote:
>>
>> copyright in the finished product.
>>
>> In MPL 1.1 section 3.3, there is a clause that mandates to describe the
>> right ownership, and that's entirely gone in section 3.2 of the new license.
>>
>> I maintain the stance that if I create a work or part of it, the least I
>> should get for it is that somebody else who uses it needs to inform the
>> users that it's me/us and not him alone who created it. That's for me the
>> bare minimum of fairness.
>
> do not absolutely need to have my name in the About box (although I like
> it). I scream "foul" when somebody else puts *his* name or copyright on the
> product, without also listing me, therefore implicitly claiming credit for
> my parts of the work as well. This creates a false impression, no matter the
> legal rights, and is therefore for me a no-go.
Ben, others, would this resolve your concerns?
3.4. Notices.
You may not remove or alter the content of any license notices
(including copyright notices, patent notices, disclaimers of warranty,
or limitations of liability) contained within the Source Code Form of
the Covered Software, or displayed to users by the Executable Form of
the Covered Software, except that You may:
(a) alter any license notices to the extent required to remedy known
factual inaccuracies; or
(b) supplement any license notices displayed to users by the
Executable Form with additional notices that are compliant with the
requirements of Section 3.1; or
(c) remove all license notices displayed to users by the Executable
Form, if the Executable Form You distribute does not display any such
notices.
Ben Bucksch
> Ben, others, would this resolve your concerns?
>
> 3.4. Notices.
>
> You may not remove or alter the content of any license notices
> the Covered Software, except that You may:
That doesn't help, because as I mentioned earlier, our main product (90%
of the code) is Gecko, the rendering engine. You can just create
another, new frontend, and then you didn't remove any notices.
The MPL 1.1 wasn't vulnerable to that.
Ben