495620 - License updates for Camino for cvs trunk

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Stuart Morgan]

When I revved Sparkle today I saw that it now includes two external licenses in its license file (mozilla/camino/sparkle/License.txt). One is for OpenSSL, and the other for SSLeay. We'll need to add both of those to about:licenses before 2.0b3.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

When we do this, we'll also want to fix the paths quoted for our Growl usage and rev the copyright date in the xpfe version of the file (I do hope we can get bug 428333 done before the *next* time we need to do this :P ).

I'll try to get this ready today so that we can start reviews and grovelling for approval in order not to hold up b3 more....

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: License updates for Camino 2.0b3 for cvs trunk (1.9.0)

Gerv, these are new and/or updated licenses for code Camino is shipping (or is about to be shipping) on cvs trunk/Gecko 1.9.0.

Specifically:

* Updates the location of Camino's Growl License-licensed code (as well as the copyright date; the copyright for the code we're shipping is actually "2004-2008")

* Updates the Sparkle License text to reflect the current license text shipped by Sparkle for the code we use

* Adds a new license block for new MAAttachedWindow code

* In the xpfe copy of the license file, updates the Moz copyright date to 2009 and removes the section about Talkback, since the Talkback bit was left in for us and we're no longer shipping Talkback (yay!)  (I'm still hopeful I'll get reviews for bug 428333 before Camino 2.0 ships, but for now we need to get these changes in before 2.0b3 imminently, and the xpfe copy is the one we currently use.)

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 380680 [details] [diff] [review]
License updates for Camino 2.0b3 for cvs trunk (1.9.0)

Gerv, please see the previous comment for explanation (you were zapped from the request by bug 315909 or similar).

Comment 4

[Gervase Markham [:gerv]]

I'm afraid we have a problem here :-( The OpenSSL and SSLeay licences both contain "advertising clauses", which are both obnoxious and incompatible with the GPL. One of our licensing goals is to make sure that all code in our repository can be used under any one of the three licences that make up the tri-licence. So this is a problem.

Are you able to say exactly what code is covered by these two licences? How difficult would it be to remove or replace it?

Gerv

Comment 5

[Stuart Morgan]

We're inheriting this from Sparkle; I dug around in the Sparkle code and found that there's no actual source or binary being distributed here. What's happening is that one class (which we do use, to validate our signed updates) uses some of the openssl headers (and links against libcrypto, which implements them) that ship with OS X, and those headers have this license text.

By my reading that means that clauses 1, 2, and 6 don't actually apply to us, which means we can remove that whole section of this patch (although confirmation with someone who actually knows what they are talking about would be good :) )

4 and 5 aren't relevant since we aren't trying to do those things, but that leaves clause 3, which I don't know how to parse. Does "mentioning features or use of this software" mean that we only have to provide that acknowledgement if we say something like "Camino uses super security crypto voodoo to make sure updates are safe and secure!"? (I guess that's beyond the scope of this bug, but it would be helpful to know.)

I checked lxr, by the way, and Breakpad on the Mac also includes some of these headers, so that last question actually applies to Firefox and Camino even if we ignore Sparkle.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #5)
> I checked lxr, by the way, and Breakpad on the Mac also includes some of these
> headers, so that last question actually applies to Firefox and Camino even if
> we ignore Sparkle.

That reminds me; we also need to update the paths for the Breakpad license.

Comment 7

[Stuart Morgan]

(Removing b3 tag given my findings in comment 5; we don't have any critical changes to the license for the beta.)

Comment 8

[Gervase Markham [:gerv]]

So are these headers in our source code repository? Or are they part of some Mac SDK you need to build Camino (or whatever project is using them)?

If they aren't, I'd argue that the whole thing is a system library, and we don't need to include its license in our license terms. So we can remove the OpenSSL licences and forget about this.

But, given that this is a bit complex, CCing Harvey.

Gerv

Comment 9

[Stuart Morgan]

(In reply to comment #8)
> So are these headers in our source code repository? Or are they part of some
> Mac SDK you need to build Camino (or whatever project is using them)?

The headers (and the underlying library) are part of Mac OS X, and we do include them in our tree, nor do we ship their code in binary form.

> If they aren't, I'd argue that the whole thing is a system library, and we
> don't need to include its license in our license terms. So we can remove the
> OpenSSL licences and forget about this.

Sounds like we're on the same page; we can put together a new patch with just the other stuff.

It would be great if we could get a definitive answer to my question about clause 3 in comment 5 though.

Comment 10

[Gervase Markham [:gerv]]

Stuart: might there be a "not" missing in your first sentence? :-)

Re: clause 3: If we aren't shipping code covered by the licence, then the licence terms don't apply. 

Gerv

Comment 11

[Stuart Morgan]

(In reply to comment #10)
> Stuart: might there be a "not" missing in your first sentence? :-)

There absolutely is, sorry about that. It should read: "we do *not* include them in our tree, nor do we ship their code in binary form."

Comment 12

[Stuart Morgan]

Well, I guess I should amend that slightly: we do not ship the *library* in binary form. We do ship binaries (Sparkle and Breakpad) that are compiled against a couple of the *headers* in question. I don't know if compiling against the headers of a dynamic library counts as shipping the code in binary form.

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: License updates for Camino 2.0b3 for cvs trunk (1.9.0) , v1.3

Assuming all of the questions about Sparkle and Breakpad's compiling against these headers are answered successfully, this is what the patch would look like now.

The differences between the first patch and this one are that xpfe's license.html is gone (yay!), there has been no change to Sparkle's license, and I've addressed my own comment 6 and added the additional Breakpad path.

I'll hold off on requesting review until we have a definitive answer on "compiling against the headers of a dynamic library," but the old patch doesn't need to be sitting in Gerv's queue regardless.

Comment 14

[Gervase Markham [:gerv]]

If you have to do another patch for any reason, can you fix bug 479726 while you are there? Thanks :-)

Gerv

Comment 15

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 382160 [details] [diff] [review]
 License updates for Camino 2.0b3 for cvs trunk (1.9.0) , v1.3

See comment 13 for the changes between this and the original patch.

There's been no comment, one way or the other, or indication that the question was under further investigation, on "compiling against the headers of a dynamic library" (comment 8-12) which I'm hoping is a positive sign.  We do need to get these licenses into the tree, so in absence of a "No, and we have to pull breakpad out of the tree, too", going ahead and requesting review.

Comment 16

[Gervase Markham [:gerv]]

Comment on attachment 382160 [details] [diff] [review]
 License updates for Camino 2.0b3 for cvs trunk (1.9.0) , v1.3

Please remove the first two lines of text inside the licence <pre> on checkin; they are superfluous.

Gerv

Comment 17

[Reed Loden [:reed]]

Comment on attachment 382160 [details] [diff] [review]
 License updates for Camino 2.0b3 for cvs trunk (1.9.0) , v1.3

>+    <p class="correctme">This license applies to the files 
>+    <span class="path">camino/src/extensions/MAAttachedWindow.h</span> and
>+    <span class="path">camino/src/extensions/MAAttachedWindow.mm</span>. (This
>+    code only ships in the in the Camino browser or products based on it.)</p>

Drop one of the "in the"s, please.

>+Includes âMAAttachedWindowâ code by Matt Gemmell.

Weird quoting thingies?

Comment 18

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #17)
 
> >+Includes âMAAttachedWindowâ code by Matt Gemmell.
> 
> Weird quoting thingies?

Is that file not coming up UTF-8 for you, Reed?  They are curly quotes, yes.  Regardless, that line was one Gerv asked me to remove, so they won't end up bothering anyone ;)  Good catch on the "in the"; I'll get that on checkin, too.

Comment 19

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 382160 [details] [diff] [review]
 License updates for Camino 2.0b3 for cvs trunk (1.9.0) , v1.3

Requesting 1.9.0.x approval; these are required license additions for new external code Camino is shipping in 1.9.0-based releases.

Comment 20

[Daniel Veditz [:dveditz]]

Comment on attachment 382160 [details] [diff] [review]
 License updates for Camino 2.0b3 for cvs trunk (1.9.0) , v1.3

Approved for 1.9.0.13, a=dveditz for release-drivers

Comment 21

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Checking in toolkit/content/license.html;
/cvsroot/mozilla/toolkit/content/license.html,v  <--  license.html
new revision: 1.28; previous revision: 1.27
done