[4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

Hi, just continuing this discussion here... This is the state we left
it in the other thread:

>> Maybe because there is no difference in the LICENSE for source and binary packages?
>
>The binary package bundles extra 3rd party jars such as Saxon which is MPL licensed [1],
>that requires  change to LICENSE right? The MPL was removed from LICENSE in this
>release. Also both Xerces and Xalan jars are bundled and content in their NOTICE files
>that looks like they need to be in our binary NOTICE file. See the content in LICENSE.bin
>which looks like a good attempt to take into account of this but may not be 100% correct.

Thanks,

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> This is a great find.  I only found Saxon to not have Category A license.
> Did you find the others?

Here what I just checked:

commons-collections.jar Apache 1.1
commons-discovery.jar Apache 1.1
commons-logging.jar Apache 2.0  has NOTICE no with no downstream effects
javacc.jar version 5 BSD copyright Sun 
saxon9.jar MPL (Michael Kay) and multiple NOTICES that effect downstream
xalan.jar Apache 2.0 and NOTICE that effects downstream
xercesImpl.jar Apache 2.0 and NOTICE that effects downstream
xercesPatch.jar Apache 2.0 and NOTICE that effects downstream
xml-apis-ext.jar Apache 2.0 and WC3 and NOTICE file that effects downstream
xml-apis.jar Apache 2.0 and WC3 and NOTICE file that effects downstream
velocity-dep-1.4-flex.jar Apache 2.0 and NOTICE file that effects downstream*
batik-all-flex.jar Apache 2.0 and NOTICE file that effects downstream

Are there any other jars or 3rd party files included in the binary that are not in the source distribution?

* NOTICE file may not be correct as velocity original NOTICE file has no downstream effects.

So looks like for the binary license we would need to add pointers to the following licenses:
- Apache 1.1
- BSD
- W3C
- MPL

And add multiple pointers to NOTICE. Most of the existing LICENSE and NOTICE files are in /lib/external with the exception of Velocity and Batik.

We may have a possible issue with saxon in particular this lib/external/saxon9-NOTICES/GPL+CLASSPATH.txt? Do we know what this refers to? At a guess (and hopefully) it may not apply as it's only in the .NET version of saxon which I assume we're not using. [1]

I've not looked at transitive dependencies which are likely to also have some effect on our NOTICE file.

I also noticed that most of the flex jars have a LICENSE and NOTICE that is probably incorrect for the jar itself e.g. compc.jar or flex-compiler-oem.jar  as t contains the full Flex LICENSE and NOTICE file not just what is in the jar

Thanks,
Justin

1. https://svn.kuali.org/repos/kits/local/ditac/trunk/LEGAL/saxon9.LICENSE

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 12/29/14, 1:16 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> -Can a binary package bundle a binary without its source?
>
>The answer is yes to that, and in fact we a little unusual as we do
>include the SDK  source in a binary release.

According to what documents?  I see that my question was ambiguous.  The
question is whether a binary dependency can simply be downloaded and
packaged or must we download the its source and compile it in order to
package it in the binary package?

>
>> -Was there any past discussion that caused the Installer to ask about
>> accepting SWFObject’s MIT License?
>
>At worse it's a licensing issue but it not an licensing error as either
>way the minimal licensing requirements have been met. I don't think it's
>required for the user to accept it license but we can still release with
>asking that.

Agree that it isn’t an error which is why I think it is the RM’s decision.

>
>> Meanwhile, I’m still puzzling over which Saxon NOTICES apply.
>
>That seems reasonably  straight forward, from a quick look some of them
>have no effect (eg ant apache as there's no bundling and resolver is
>public domain) and some need to be aded to LICENSE  (cern(?), frijters,
>james clark, legal + license and unicode) and only that I can see to
>notice (xerces). Cern might be a concern. I'll have some time later this
>week to check.

How did you determine that no source from Ant is mixed into the saxon jar?
 I didn’t see any whole classes with org.apache.ant in the package, but
that may not be the full story.

-Alex

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> -Can a binary package bundle a binary without its source?

The answer is yes to that, and in fact we a little unusual as we do include the SDK  source in a binary release.

> -Was there any past discussion that caused the Installer to ask about
> accepting SWFObject’s MIT License?

At worse it's a licensing issue but it not an licensing error as either way the minimal licensing requirements have been met. I don't think it's required for the user to accept it license but we can still release with asking that.

> Meanwhile, I’m still puzzling over which Saxon NOTICES apply.

That seems reasonably  straight forward, from a quick look some of them have no effect (eg ant apache as there's no bundling and resolver is public domain) and some need to be aded to LICENSE  (cern(?), frijters, james clark, legal + license and unicode) and only that I can see to notice (xerces). Cern might be a concern. I'll have some time later this week to check.

Thanks,
Justin

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

Oops... a little - minor? - 'major/minor' error there ;-)

EdB



On Mon, Dec 29, 2014 at 5:14 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>>>>> Can you give me a (realistic) worst case scenario if we were to
>>>>> release without making any changes?
>>>>
>>>> IMO Worse case we can't make a release until this is resolved.
>>>
>>>No, I meant what would happen if we went ahead a binary release
>>>without fixing this... Tempting, because we did that nearly a dozen
>>>times without the world coming to an end.
>>
>> That was my point.  Unless we find out that Saxon has some unfriendly
>> dependencies, the question of whether a binary dependency in the package
>> was compiled from sources or not or whether the Installer should ask about
>> MPL and MIT dependencies probably doesn't put the foundation at risk, so
>> the worst case is you hit send on the announcement and we hear back at
>> that moment that there is a rule like that and we have start in on fixing
>> that, but I would be surprised if we have to pull it back.
>
> OK, thanks. I'll proceed under the assumption that this will be
> resolved before we release, but that if it isn't, we don't treat this
> as a blocking issue.
>
> I plan to start a 14.4.1 branch right after we release 14.4.0, just in
> case we need it to fix e.g. this issue or some TLF related emergency.
> That should bring down the lead time when an issue arises
> considerably.
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

>>>> Can you give me a (realistic) worst case scenario if we were to
>>>> release without making any changes?
>>>
>>> IMO Worse case we can't make a release until this is resolved.
>>
>>No, I meant what would happen if we went ahead a binary release
>>without fixing this... Tempting, because we did that nearly a dozen
>>times without the world coming to an end.
>
> That was my point.  Unless we find out that Saxon has some unfriendly
> dependencies, the question of whether a binary dependency in the package
> was compiled from sources or not or whether the Installer should ask about
> MPL and MIT dependencies probably doesn't put the foundation at risk, so
> the worst case is you hit send on the announcement and we hear back at
> that moment that there is a rule like that and we have start in on fixing
> that, but I would be surprised if we have to pull it back.

OK, thanks. I'll proceed under the assumption that this will be
resolved before we release, but that if it isn't, we don't treat this
as a blocking issue.

I plan to start a 14.4.1 branch right after we release 14.4.0, just in
case we need it to fix e.g. this issue or some TLF related emergency.
That should bring down the lead time when an issue arises
considerably.

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> That was my point.  Unless we find out that Saxon has some unfriendly
> dependencies, the question of whether a binary dependency in the package
> was compiled from sources or not or whether the Installer should ask about
> MPL and MIT dependencies probably doesn't put the foundation at risk, so
> the worst case is you hit send on the announcement and we hear back at
> that moment that there is a rule like that and we have start in on fixing
> that, but I would be surprised if we have to pull it back.

You seem to be be forgetting that the LICENSE and NOTICE files are currently incorrect. That's generally a release blocker.

Justin

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 12/29/14, 1:40 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>>> Can you give me a (realistic) worst case scenario if we were to
>>> release without making any changes?
>>
>> IMO Worse case we can't make a release until this is resolved.
>
>No, I meant what would happen if we went ahead a binary release
>without fixing this... Tempting, because we did that nearly a dozen
>times without the world coming to an end.

That was my point.  Unless we find out that Saxon has some unfriendly
dependencies, the question of whether a binary dependency in the package
was compiled from sources or not or whether the Installer should ask about
MPL and MIT dependencies probably doesn't put the foundation at risk, so
the worst case is you hit send on the announcement and we hear back at
that moment that there is a rule like that and we have start in on fixing
that, but I would be surprised if we have to pull it back.

-Alex

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 12/30/14, 1:03 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> Digging into Saxon, I’m stuck on the CERN NOTICE.  We are going to have
>>to
>> ask on legal-discuss to get approval to use Saxon.  I will open a LEGAL
>> JIRA shortly.
>
>Do we know if the CERN license actually applies to anything in the jar?
>The GPL "notice" for instance refers to the .net version of Saxon which
>we are not using.

I downloaded the source.  CERN is in the source for one of the classes in
the jar.

>
>> I think we have the option of not bundling Saxon and downloading it as
>> part of the install if we want to go down that road.
>
>Which also probably mean we would need to remove all old versions of the
>SDK and modify them and the installer to do the same.

We’ll ask about that after we figure out what the right thing to do is.
The legal JIRA is
https://issues.apache.org/jira/browse/LEGAL-213
Lots of other projects seem to be using Saxon, but I still haven’t found
one that bundles it in their binary packages.

-Alex

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Digging into Saxon, I’m stuck on the CERN NOTICE.  We are going to have to
> ask on legal-discuss to get approval to use Saxon.  I will open a LEGAL
> JIRA shortly.

Do we know if the CERN license actually applies to anything in the jar? The GPL "notice" for instance refers to the .net version of Saxon which we are not using.

> I think we have the option of not bundling Saxon and downloading it as
> part of the install if we want to go down that road.

Which also probably mean we would need to remove all old versions of the SDK and modify them and the installer to do the same.

Thanks,
Justin

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

Digging into Saxon, I’m stuck on the CERN NOTICE.  We are going to have to
ask on legal-discuss to get approval to use Saxon.  I will open a LEGAL
JIRA shortly.

A CERN license for something called COLT got approved, but instructions
seem to be to ask for any other CERN code.

I think we have the option of not bundling Saxon and downloading it as
part of the install if we want to go down that road.  IMO, it could be the
quickest way to get out the door.  I don’t know how often these smaller
downloads fail during the install vs the big ones like the main package or
the AIR SDK.

-Alex

On 12/29/14, 1:43 PM, "Alex Harui" <ah...@adobe.com> wrote:

>Other than Saxon, I think I’m mostly done fixing up LICENSE and NOTICE so
>that it matches the way we packaged prior releases.  I hope to finish
>Saxon and check it all in tonight or tomorrow.  Then it needs review and
>we might find a few more things we need to change.
>
>Then we need to decide whether we want the install scripts to prompt folks
>to accept Saxon or not, and whether we should continue to have folks
>approve OSMF and SWFObject like we currently do.  Again, if we guess wrong
>here, I can’t imagine it would be seen as putting the foundation at risk,
>but maybe we’ll get lucky and someone will provide an answer or Om will
>remember some conversation about it when creating the Installer.
>
>-Alex
>
>On 12/29/14, 1:15 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>>Hi,
>>
>>> Do you have the cycles to create a suggested fix for both?
>>
>>As I said I will have later this week, but Alex is currently looking into
>>it and would need to check in what he's done first I think.
>>
>>One of my earlier posts in this thread had details on what the likely
>>changes would be.
>>
>>Thanks,
>>Justin
>

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

And while this is still a work in progress you may want to read this [1] as it makes a few things clearer.

Justin

1. https://github.com/rectang/asfrelease/blob/master/release.md

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Why did you decide to call it SAX2 and not just SAX or SAX 2.0?

That's the product name eg http://shop.oreilly.com/product/9780596002374.do

>  And should we also be putting version numbers on all of the other dependencies?

We could, and it is useful, but AFAIK not required.

> Also, I fixed “produce” and one other typo so pull before you make any
> further changes.

Thanks.

> Of all the legal notices that come with Saxon, I’m pretty sure Ant is not included in
> the jar we are using but Resolver and Xerces are, but you can double check
> that if you want.  I didn’t check the others.

I'll check and add what I think is required to NOTICE, should be able to do that tonight.

Justin

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

HI,

Interesting enough it ends up we only bundle one of the nine Saxon jars but have included all of the NOTICE files. Unhelpfully the saxon jar we do use doesn't include any LICENSE or NOTICE.

Justin

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

HI,

When looking for stuff find is your friend - you can use to to search for none Apache licenses or other stuff:

In the source this:
 find . -name "*.*" -exec grep -i "James" {} \; -print 2>/dev/null

Shows this:
./net/sf/saxon/regex/JDK15RegexTranslator.java

And in the binary:
find . -name "*.*" -exec grep -i "JDK15RegexTranslator" {} \; -print 2>/dev/null

Shows:
./saxon9.jar

Justin

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 1/5/15, 10:48 AM, "Harbs" <ha...@gmail.com> wrote:

>My eyes kind of glazed over at the beginning of the discussion, so I’m
>kind of with Erik on this…

Well, at least you are trying to follow.  Hopefully, reviewing is easier
than figuring out what changes to make.  While it would be great to have
other PMC members scour everything carefully, it will be helpful if you at
least take a quick look.  Here’s my ‘short’ summary:

-Fundamentally, the LICENSE needs to mention any non-ASF or non-Apache
Licensed 2.0 source code or other materials in any zip or tar.gz you
review when voting.
-All licenses, including ASF-based Apache 2.0 licensed dependencies may
mention certain things they want the user to be notified of.  Those go in
NOTICE.

-Since the binary zip or tar.gz contains things we download that aren’t in
the source zip or tar.gz, we need to have different LICENSE and NOTICE
files in the binary vs source packages.
-Apache also wants every jar we create to have a LICENSE and NOTICE in
META-INF that is tuned to the contents of that jar and not the collection
of licenses for the release.

So, the review should be something like:
1) get a source package, expand it.
2) look at LICENSE.  See list of Subcomponents.
  2a) Are any listed that aren’t actually in the package?
  2b) Do you know of anything that is missing?
Note that source code that belongs to another Apache project that is
licensed under Apache 2.0 doesn’t need to be listed here.  It does if it
is under an older Apache license like 1.1, or is under Apache 2.0 but not
an Apache project, like if we borrowed some code from GoogleCode or
something like that.
3) look at NOITCE.  It will have some copyright info about Adobe.  That’s
ok.
  3a) Is the year right?
  3b) Where did the rest of the text come from?  It should come from the
licenses and/or notices for other source code and fonts and images we have
included in the source package.
  3c) Did we miss anything?

This whole thing started because I noticed we mentioned MPL in LICENSE
even though we only download OSMF (and Saxon).  The OSMF source doesn’t
get included in our source package.  Then on further digging, Justin found
more issues, especially with the binary package.

The binary package review works just like the source package review,
except that the stuff in NOTICE will also come from any jars we’ve
downloaded and included in the package.  Sometimes the jar’s LICENSE and
NOTICES are located in a folder near the jar, other times the jar has the
LICENSE and NOTICE packaged in the jar.  To extract files from a jar, run
jar -xf <jar>.  It will put the files in the current folder so maybe do
that in a temporary folder.  Most jars put LICENSE and NOTICE in a
META-INF folder, but some put it elsewhere and some don’t include it at
all.  So yeah, that’s painful, but basically, the process is to look for
jars, look for legal files near the jars, dump jars, look for things in
the dump that look like legal stuff that implies that we have to notify
the customer about something and make sure we’ve mentioned it in NOTICE.
Sometimes notices are in README files as well.  Saxon is tricky in that it
has some legal files for code that isn’t in the actual jar we use so it
doesn’t matter.

Another part of the binary package review is to dump each Flex jar and
make sure it has a LICENSE and NOTICE and the contents of those files
makes sense for the contents of the jar.

And, BTW, it might be easier for folks to wait for Justin to fix up the
Saxon stuff and build script before reviewing all of this.  Right now the
LICENSE points to places that don’t exist.  But I really think we need
folks to actually look or maybe divide up the review.  Given that Justin
and I voted +1 on many releases with these or similar problems in the
past, you can’t trust us to find everything every time.

Also, I am hopeful that this could be the last time we have to go digging
this hard.  In theory, if we try to keep track of major new developments
in between releases, then we have an idea if any serious review of LICENSE
and NOTICE might even be required for the next release, so it shouldn’t
always take this kind of time before you vote in future releases.  Our
mail archives seem to show that the binary package never got any sort of
review from the mentors which is why it had this many issues.  The mentors
probably didn’t bother because binary packages aren’t official Apache
products so it may have just gotten lost in the noise.

HTH,
-Alex

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

> Maybe you need to repost or bump the vote thread, because I know I've just

We're not voting yet. There are a few fixes forthcoming for the
installer scripts, if I understand the situation correctly.

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

HI,

> I think we are waiting on Justin go fix up the build scripts so we can see
> how it all the new license and notice changes look in the release
> candidate packages.

I was hoping to get to this tomorrow but looks like it going to be Friday.

Justin

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

My supremely incapable eyes were thoroughly impressed by the amount of
legalese, and all those fancy words sounded true, so the docs must be
OK!

;-)

EdB



On Wed, Jan 14, 2015 at 3:19 PM, Alex Harui <ah...@adobe.com> wrote:
> I took a quick look.  Looked good enough for me.
>
> On 1/13/15, 11:44 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>I have some time today, I'll try to make sense of what there is to see...
>>
>>EdB
>>
>>
>>
>>On Mon, Jan 12, 2015 at 2:39 AM, Justin Mclean <ju...@classsoftware.com>
>>wrote:
>>> HI,
>>>
>>>> I think we are waiting on Justin go fix up the build scripts so we can
>>>>see
>>>> how it all the new license and notice changes look in the release
>>>> candidate packages.
>>>
>>> Done and checked. Looks good to me but if other PMC members can review
>>>that would be helpful.
>>>
>>> Thanks,
>>> Justin
>>
>>
>>
>>--
>>Ix Multimedia Software
>>
>>Jan Luykenstraat 27
>>3521 VB Utrecht
>>
>>T. 06-51952295
>>I. www.ixsoftware.nl
>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

I took a quick look.  Looked good enough for me.

On 1/13/15, 11:44 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>I have some time today, I'll try to make sense of what there is to see...
>
>EdB
>
>
>
>On Mon, Jan 12, 2015 at 2:39 AM, Justin Mclean <ju...@classsoftware.com>
>wrote:
>> HI,
>>
>>> I think we are waiting on Justin go fix up the build scripts so we can
>>>see
>>> how it all the new license and notice changes look in the release
>>> candidate packages.
>>
>> Done and checked. Looks good to me but if other PMC members can review
>>that would be helpful.
>>
>> Thanks,
>> Justin
>
>
>
>-- 
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

I have some time today, I'll try to make sense of what there is to see...

EdB



On Mon, Jan 12, 2015 at 2:39 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> HI,
>
>> I think we are waiting on Justin go fix up the build scripts so we can see
>> how it all the new license and notice changes look in the release
>> candidate packages.
>
> Done and checked. Looks good to me but if other PMC members can review that would be helpful.
>
> Thanks,
> Justin



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

HI,

> I think we are waiting on Justin go fix up the build scripts so we can see
> how it all the new license and notice changes look in the release
> candidate packages.

Done and checked. Looks good to me but if other PMC members can review that would be helpful.

Thanks,
Justin

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 1/6/15, 12:58 AM, "Tom Chiverton" <tc...@extravision.com> wrote:

>And no body is going to die if it's (still) wrong despite what looks
>like heroic efforts over the Christmas break.
>We can always amend it again in future if we notice anything.

Nobody will die, but we really do have a responsibility to do our best to
get this right before releasing.

I think we are waiting on Justin go fix up the build scripts so we can see
how it all the new license and notice changes look in the release
candidate packages.  I think we can proceed as though Saxon is ok to use
as Category B.

I think we are ready to remove some of the license check boxes in the
install for 4.14.

What is the status on mustella?  Do we need to get it to run without
errors before releasing?

-Alex

Re: [4.14] binary vs. source package legal docs

[Tom Chiverton <tc...@extravision.com>]

And no body is going to die if it's (still) wrong despite what looks 
like heroic efforts over the Christmas break.
We can always amend it again in future if we notice anything.

Maybe you need to repost or bump the vote thread, because I know I've 
just marked everything read as of yesterday when I got back to work.
I think other people may also do similar at the start of a new year. 
December seems a long time ago !

Tom

On 05/01/15 18:48, Harbs wrote:
> My eyes kind of glazed over at the beginning of the discussion, so I’m kind of with Erik on this…
>
> On Jan 5, 2015, at 8:33 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
>>> FWIW, in case anybody is actually still following this thread, IMO, we
>>> need at least one more PMC member who plans to vote on this release to
>>> review these changes.  That’s a reason behind the requirement of 3 +1
>>> votes, that 3 sets of eyes are better than 1 or 2.  We need more PMC
>>> members to understand these rules.
>> I really hope I'm wrong, but I think everyone else is as lost as I am.
>> Unless one of you (Alex & Justin) writes a summary of the changes and
>> the 'why' of them, in TL;DR style, I'm afraid the other voting
>> contributors will - out of necessity, because we just don't grok -
>> vote +1 on your word (at least, with regard to these legal changes).
>>
>> EdB
>>
>>
>>
>> -- 
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
>

Re: [4.14] binary vs. source package legal docs

[Harbs <ha...@gmail.com>]

My eyes kind of glazed over at the beginning of the discussion, so I’m kind of with Erik on this…

On Jan 5, 2015, at 8:33 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:

>> FWIW, in case anybody is actually still following this thread, IMO, we
>> need at least one more PMC member who plans to vote on this release to
>> review these changes.  That’s a reason behind the requirement of 3 +1
>> votes, that 3 sets of eyes are better than 1 or 2.  We need more PMC
>> members to understand these rules.
> 
> I really hope I'm wrong, but I think everyone else is as lost as I am.
> Unless one of you (Alex & Justin) writes a summary of the changes and
> the 'why' of them, in TL;DR style, I'm afraid the other voting
> contributors will - out of necessity, because we just don't grok -
> vote +1 on your word (at least, with regard to these legal changes).
> 
> EdB
> 
> 
> 
> -- 
> Ix Multimedia Software
> 
> Jan Luykenstraat 27
> 3521 VB Utrecht
> 
> T. 06-51952295
> I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

> FWIW, in case anybody is actually still following this thread, IMO, we
> need at least one more PMC member who plans to vote on this release to
> review these changes.  That’s a reason behind the requirement of 3 +1
> votes, that 3 sets of eyes are better than 1 or 2.  We need more PMC
> members to understand these rules.

I really hope I'm wrong, but I think everyone else is as lost as I am.
Unless one of you (Alex & Justin) writes a summary of the changes and
the 'why' of them, in TL;DR style, I'm afraid the other voting
contributors will - out of necessity, because we just don't grok -
vote +1 on your word (at least, with regard to these legal changes).

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 1/5/15, 9:47 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>While you guys are busy (and please don't let me distract you), a
>quick theoretical question:
>
>Why don't we just throw in each and every license we might possibly
>need, and call it a day? What's wrong with one or two too many
>licenses?

The how-to document [1] says: "LICENSE and NOTICE must exactly represent
the contents of the distribution", although having too many probably isn’t
nearly as bad as having too few.  For Saxon, one of the “too many” implies
a GPL dependency which would be bad.

FWIW, in case anybody is actually still following this thread, IMO, we
need at least one more PMC member who plans to vote on this release to
review these changes.  That’s a reason behind the requirement of 3 +1
votes, that 3 sets of eyes are better than 1 or 2.  We need more PMC
members to understand these rules.

[1] http://www.apache.org/dev/licensing-howto.html

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

While you guys are busy (and please don't let me distract you), a
quick theoretical question:

Why don't we just throw in each and every license we might possibly
need, and call it a day? What's wrong with one or two too many
licenses?

EdB



On Mon, Jan 5, 2015 at 6:29 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 1/5/15, 1:05 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>>JAMESCLARK notice - used in saxon9-xpath.jar
>>
>>Any differing opinions?
>
> I did get a slightly different result.  I agree with all of the other
> findings, but I think I see James Clark in saxon9.jar.  You tend to be
> better at digging through this stuff, so I’ll just explain my technique
> which could be flawed.
>
> I went and grabbed the sources for SaxonB from [1]
> Then I used grep to look for words that would indicate usage in the source
> for a particular notice file.
> Then I ran jar -tf saxon9.jar to get the list of classes in the jar we use.
> If I saw that grep showed usage in a source file, and that source file was
> listed as a class in saxon9.jar, then I would consider that ‘usage’.
>
> This technique shows that James Clark is the author of:
> net/sf/saxon/java/JDK14RegexTranslator.java
> net/sf/saxon/java/JDK15RegexTranslator.java
>
>
>
> And those classes are in saxon9.jar, but I haven’t studied the
> JAMESCLARK.txt notice or other supporting documents in detail to know if
> that notice only applies to a particular work of his.
>
> -Alex
>
> [1]
> http://sourceforge.net/projects/saxon/files/Saxon-B/9.1.0.8/saxonb9-1-0-8so
> urce.zip/download
>
>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 1/5/15, 1:56 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>I've made the changes to NOTICE and LICENSE for saxon9 but there may be a
>further legal issue we need to resolve. The James Clark license is
>MIT/X11 (or similar) license with an anti  advertising clause. I think
>this is a reaction to the BSD license with the advertising clause and
>should be OK but not 100% sure.

IMO, it isn’t a reaction but either way I think we’re ok.  [1][2] don’t
place any restrictions on the variants of MIT licenses, and [4] says the
text you call an “anti-advertising” clause is in some of these variants.

-Alex

>
>1.http://www.apache.org/dev/licensing-howto.html#permissive-deps
>2. http://www.apache.org/legal/resolved.html#category-a
>3. https://www.gnu.org/philosophy/bsd.html

[4] https://fedoraproject.org/wiki/Licensing:MIT?rd=Licensing/MIT

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

I've made the changes to NOTICE and LICENSE for saxon9 but there may be a further legal issue we need to resolve. The James Clark license is MIT/X11 (or similar) license with an anti  advertising clause. I think this is a reaction to the BSD license with the advertising clause and should be OK but not 100% sure.

Both [1][2] state that only the BSD license without the advertising clause is allowed. Here's a good (non Apache) explanation as to why the BSD clause is an issue. [3]

Justin

1.http://www.apache.org/dev/licensing-howto.html#permissive-deps
2. http://www.apache.org/legal/resolved.html#category-a
3. https://www.gnu.org/philosophy/bsd.html

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@me.com>]

Hi,

> I did get a slightly different result.  I agree with all of the other
> findings, but I think I see James Clark in saxon9.jar.

Yep agree that required, looks like he also contributed the RegExp code.

Thanks,
Justin

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 1/5/15, 1:05 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>JAMESCLARK notice - used in saxon9-xpath.jar
>
>Any differing opinions?

I did get a slightly different result.  I agree with all of the other
findings, but I think I see James Clark in saxon9.jar.  You tend to be
better at digging through this stuff, so I’ll just explain my technique
which could be flawed.

I went and grabbed the sources for SaxonB from [1]
Then I used grep to look for words that would indicate usage in the source
for a particular notice file.
Then I ran jar -tf saxon9.jar to get the list of classes in the jar we use.
If I saw that grep showed usage in a source file, and that source file was
listed as a class in saxon9.jar, then I would consider that ‘usage’.

This technique shows that James Clark is the author of:
net/sf/saxon/java/JDK14RegexTranslator.java
net/sf/saxon/java/JDK15RegexTranslator.java



And those classes are in saxon9.jar, but I haven’t studied the
JAMESCLARK.txt notice or other supporting documents in detail to know if
that notice only applies to a particular work of his.

-Alex

[1] 
http://sourceforge.net/projects/saxon/files/Saxon-B/9.1.0.8/saxonb9-1-0-8so
urce.zip/download

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

> Still to do:
> - Modify the binary notice file
> - Changes to the build script to copy the new licences into lib external
> - Changes to the installer script for the SDK

You are working on the first two, correct? And the third, is that an
Alex thing, or are you 'on that' as well?

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Since the only other 'opinion' has just gone to bed, please commit.

I still have to work out the contents that go into the NOTICE but that's reasonably straight forward.

> Am I correct that after these changes all known licensing and other
> legal issues have been resolved - for this release at least?

Not all resolved, but probably OK for the release. 

Some of the still important outstanding items are:
- Do we need to prompt for Saxon as we do for OSMF?
- Do we need to remove the SWObject prompt?
- Can we release without making any changers to the installer? Probably but there's a fews bugs in the existing one that may be effected by these licensing changes.

Still to do:
- Modify the binary notice file
- Changes to the build script to copy the new licences into lib external
- Changes to the installer script for the SDK

Thanks,
Justin

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

Thank you, Justin.

Since the only other 'opinion' has just gone to bed, please commit.
Waiting for his response will add a delay I'd like to avoid. Alex will
review during his morning, and the last time he found no issues in
your commit, so I'm sure these changes will be fine as well.

Am I correct that after these changes all known licensing and other
legal issues have been resolved - for this release at least?

EdB


On Mon, Jan 5, 2015 at 10:05 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> After a look at the notices and peeking inside all of the jars I think I've worked out what we need to add.
>
> The following are used in saxon.jar:
> UNICODE notice
> CERN notice
> Resolver notice
> THAI notice
>
> The following are not use or used in other jars:
> ANT notice - not used
> Xerces notice - used in saxon9-dom.jar
> JAMESCLARK notice - used in saxon9-xpath.jar
>
> And there are  only in the .net version of the software:
> FRIJTERS notice
> GPL + Classpath notice
>
> From  http://www.oxygenxml.com/archives/xsl-list/200602/msg00576.html:
> "and also to Jeroen Frijters who produced the IKVMC cross-compiler
> on which the technology depends. The Saxon code is still written in 100%
> Java, except for the new API front-end which is in C#. The Java code is
> compiled as normal, and the byte-code is then translated into native MSIL
> for the .NET platform using the IKVMC compiler"
>
> See also http://www.ikvm.net/userguide/ikvmc.html
>
> Any differing opinions?
>
> Thanks,
> Justin
>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

After a look at the notices and peeking inside all of the jars I think I've worked out what we need to add.

The following are used in saxon.jar:
UNICODE notice
CERN notice
Resolver notice
THAI notice

The following are not use or used in other jars:
ANT notice - not used
Xerces notice - used in saxon9-dom.jar
JAMESCLARK notice - used in saxon9-xpath.jar

And there are  only in the .net version of the software:
FRIJTERS notice
GPL + Classpath notice

From  http://www.oxygenxml.com/archives/xsl-list/200602/msg00576.html:
"and also to Jeroen Frijters who produced the IKVMC cross-compiler
on which the technology depends. The Saxon code is still written in 100%
Java, except for the new API front-end which is in C#. The Java code is
compiled as normal, and the byte-code is then translated into native MSIL
for the .NET platform using the IKVMC compiler"

See also http://www.ikvm.net/userguide/ikvmc.html

Any differing opinions? 

Thanks,
Justin

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

OK, I went through the changes.  I didn’t see anything that looked wrong.

A question or two for this:
+This produce bundles SAX2 available under a Public Domain license.
+For more details see lib/external/LICENSE.sax.txt


Why did you decide to call it SAX2 and not just SAX or SAX 2.0?  And
should we also be putting version numbers on all of the other dependencies?
Also, I fixed “produce” and one other typo so pull before you make any
further changes.


And regarding Saxon:  I think it is the same sort code from COLT so we
should proceed as if Saxon is ok to use under Category B.  Of all the
legal notices that come with Saxon, I’m pretty sure Ant is not included in
the jar we are using but Resolver and Xerces are, but you can double check
that if you want.  I didn’t check the others.

Thanks for cranking through all of this.
-Alex

On 1/4/15, 11:53 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>HI,
>
>>  I think some changes need to be made to the build script to pull out
>>the W3C licenses to where they are supposed to be.
>
>That's correct - I've not done that yet.
>
>Justin

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

HI,

>  I think some changes need to be made to the build script to pull out the W3C licenses to where they are supposed to be.

That's correct - I've not done that yet.

Justin

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

I should have thought of this sooner, but I went and looked at COLT and it
includes a GenericSorter!  I’m short on time today to verify this is the
same one as Saxon uses, but assuming it is, I’d say then Saxon should be
ok.

Also, I haven’t reviewed Justin’s changes to L & N in detail, but from the
check-in notes, I don’t see anything that looks wrong.  I did just
download the binary package.  I think some changes need to be made to the
build script to pull out the W3C licenses to where they are supposed to be.

-Alex

On 1/4/15, 6:32 AM, "Alex Harui" <ah...@adobe.com> wrote:

>From [1], I would interpret the following:
>
>For the purposes of being a dependency to an Apache product, which
>licenses are considered to be similar in terms to the Apache License
>2.0?Works under the following licenses may be included within Apache
>products:
>
>* Apache License 2.0 <http://apache.org/licenses/LICENSE-2.0>
><many licenses skipped>
>* License for CERN packages in COLT
><http://acs.lbl.gov/software/colt/license.html> but note that this applies
>only to CERN packages in COLT and not others
>
>to mean that we need approval to use the CERN sort algorithm bundled in
>Saxon.  I agree with Justin that Legal really should approve, but
>technically they haven’t.  But if approved, then yes, we need to change
>NOTICE as Justin said.  There is a complex set of NOTICES that come with
>Saxon.  I think Justin and I agree that some don’t need to be in our
>NOTICE.
>
>
>[1] http://www.apache.org/legal/resolved.html
>
>
>On 1/4/15, 5:54 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>That is awesome!
>>
>>So, just change NOTICE and we're done with this?
>>
>>EdB
>>
>>
>>
>>On Sun, Jan 4, 2015 at 2:51 PM, Justin Mclean <ju...@classsoftware.com>
>>wrote:
>>> Hi,
>>>
>>>> If you and Alex keep on disagreeing
>>>
>>> I actually don't think there's any disagreement here.
>>>
>>> Justin
>>
>>
>>
>>-- 
>>Ix Multimedia Software
>>
>>Jan Luykenstraat 27
>>3521 VB Utrecht
>>
>>T. 06-51952295
>>I. www.ixsoftware.nl
>

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

From [1], I would interpret the following:

For the purposes of being a dependency to an Apache product, which
licenses are considered to be similar in terms to the Apache License
2.0?Works under the following licenses may be included within Apache
products:

* Apache License 2.0 <http://apache.org/licenses/LICENSE-2.0>
<many licenses skipped>
* License for CERN packages in COLT
<http://acs.lbl.gov/software/colt/license.html> but note that this applies
only to CERN packages in COLT and not others

to mean that we need approval to use the CERN sort algorithm bundled in
Saxon.  I agree with Justin that Legal really should approve, but
technically they haven’t.  But if approved, then yes, we need to change
NOTICE as Justin said.  There is a complex set of NOTICES that come with
Saxon.  I think Justin and I agree that some don’t need to be in our
NOTICE.


[1] http://www.apache.org/legal/resolved.html


On 1/4/15, 5:54 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>That is awesome!
>
>So, just change NOTICE and we're done with this?
>
>EdB
>
>
>
>On Sun, Jan 4, 2015 at 2:51 PM, Justin Mclean <ju...@classsoftware.com>
>wrote:
>> Hi,
>>
>>> If you and Alex keep on disagreeing
>>
>> I actually don't think there's any disagreement here.
>>
>> Justin
>
>
>
>-- 
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

That is awesome!

So, just change NOTICE and we're done with this?

EdB



On Sun, Jan 4, 2015 at 2:51 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> If you and Alex keep on disagreeing
>
> I actually don't think there's any disagreement here.
>
> Justin



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> If you and Alex keep on disagreeing

I actually don't think there's any disagreement here.

Justin

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

>> Currently, Saxon is bundled, right? And you and Alex disagree on if it
>> can stay that way?
>
> Well we can go ether way but I would prefer it was bundled as it currently is. If it is bundled we need to modify NOTICE and I can make the changes to NOTICE to accommodate that

That's what I said.

>> I will call a vote on the solution that looks to me to be the least intrusive
>
> Sorry to say but you can't vote the PMC legal responsibilities away. As per the guiding principle the LICENSE and NOTICE must match what is bundled. [1] And currently it's not in alignment.

If you and Alex keep on disagreeing, and the Apache legal people don't
feel this is important enough to jump in, we'll have to resolve the
deadlock between the two interpretations, and a vote is exactly the
tool to do that.

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

HI,

> Currently, Saxon is bundled, right? And you and Alex disagree on if it
> can stay that way?

Well we can go ether way but I would prefer it was bundled as it currently is. If it is bundled we need to modify NOTICE and I can make the changes to NOTICE to accommodate that

> I will call a vote on the solution that looks to me to be the least intrusive

Sorry to say but you can't vote the PMC legal responsibilities away. As per the guiding principle the LICENSE and NOTICE must match what is bundled. [1] And currently it's not in alignment.
.
Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#guiding-principle

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

> Blocking issues:
> - saxon9 if bundled NOTICE will needs to be modified. I look into that depending on if we decide to bundle it or not.
> - saxon9 if not not bundled in the binary release will need to be removed from LICENSE

Currently, Saxon is bundled, right? And you and Alex disagree on if it
can stay that way? IIUC, you think it can remain bundled, but in order
to make that 'legal', we would need to change NOTICE?

I would prefer it if we do not change any 'tech', but 'simply' correct
the legal docs... So, Alex, what are your objections to Justin's
argument that a change to NOTICE would allow us to keep using Saxon
the way we are?

I will try to keep my patience for one more round of arguments on
this. If you two can't agree on a solution in the next couple of days,
I will call a vote on the solution that looks to me to be the least
intrusive, for both the code base and the user.

Thanks,

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

HI,

Committed the changes to LICENSE and NOTICE files.

Changed:
- Fixed date and intro of NOTICE to be consistent.
- Remove unneeded lines in Xerces NOTICE
- Removed commons-logging from LICENSE.bin as per [1]
- Remove xalan from LICENSE.bin as per [1] 
- Removed Xerces (2.9.1) from LICENSE as per [1] 
- Added WC3 licenses in short form for xml-apis-ext.jar  and xml-apis.jar 
- Added a few extra Xalan licenses to LICENSE we had missed (all compatible)
- Fixed Xerces notices
- Added XML commons notices

Re the missing licences it seem back in the Apache 1.1 days it was common practise not to append to LICENSE and have separate LICENSE files. Moral of the story is just unpack the jar and see what inside. You can quite often find multiple licensing and notice files.

Open issues (that can be delt with later).
- Could use short/pointer form of BSD in LICENSE for easing equations
- Is posisble that "Copyright 2001 Robert Penner." is not required in NOTICE as it is BSD licensed. This violates keeping notice as simple as possible and not including anything that may be be required.
- Could use short/pointer form of BSD for lib/external/java-cc.jar in LICENSE.bin
- The README file section under Xalan should be cut down. It not required in a notice and some of it has been covered by required license changes and we're miing some of the files it reference.

Blocking issues:
- saxon9 if bundled NOTICE will needs to be modified. I look into that depending on if we decide to bundle it or not.
- saxon9 if not not bundled in the binary release will need to be removed from LICENSE
- I still need to add the missing licence files (from their respective jars) to lib externals

We also need to decide to we want to assemble LICENSE/NOTICE or not. Down side of assembling is you need to build the binary to see the full NOTICE/LICENSE.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#alv2-dep

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 1/3/15, 11:03 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>>>> IMO, it would be better if I keep making changes and Justin does the
>>>> review.  He’s a much better reviewer and the results will have one
>>>> authoring style.
>>>
>>>Your viewpoints are different enough that discussing this until you've
>>>reached agreement - which is basically what one person editing and one
>>>reviewing would be - would take ages, if it happened at all.
>>
>> AIUI, the only missing required pieces are the W3C and xml-api*.jar
>> notices.
>
>So, no worries then, Justin seems to have a clear understanding of how
>these should be handled, and he plans to tackle some other stuff (low
>hanging fruit, IIUC) at the same time. Win-win?

OK, I guessed wrong that you’d want the minimum set of changes.  If you’re
willing to take on more and Justin has the time, I’ll go back to other
things and wait for his version.

>
>>>I think this exercise in legal wrangling has gone on long enough. This
>>>stuff has been unchanged for 7 releases without the world coming to an
>>>end and to be honest my patience is running thin.
>>
>> Yes, well, we could have just unbundled these jars and been done a long
>> time ago, but we are going through all of this because we’re afraid of
>> potential download failures.
>
>From the little I understand of this whole thread, that would've meant
>adding another user nag message, which I don't think is trivial.

No, that’s not true, especially if we’re not going to nag on OSMF and
SWFObject anymore.

-Alex

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

>>> IMO, it would be better if I keep making changes and Justin does the
>>> review.  He’s a much better reviewer and the results will have one
>>> authoring style.
>>
>>Your viewpoints are different enough that discussing this until you've
>>reached agreement - which is basically what one person editing and one
>>reviewing would be - would take ages, if it happened at all.
>
> AIUI, the only missing required pieces are the W3C and xml-api*.jar
> notices.

So, no worries then, Justin seems to have a clear understanding of how
these should be handled, and he plans to tackle some other stuff (low
hanging fruit, IIUC) at the same time. Win-win?

>>I think this exercise in legal wrangling has gone on long enough. This
>>stuff has been unchanged for 7 releases without the world coming to an
>>end and to be honest my patience is running thin.
>
> Yes, well, we could have just unbundled these jars and been done a long
> time ago, but we are going through all of this because we’re afraid of
> potential download failures.

>From the little I understand of this whole thread, that would've meant
adding another user nag message, which I don't think is trivial.

You had a shot at this, and now Justin gets a shot at this. That means
that by Monday we should have an implementation of both visions in the
repo and we can have one more round of negotiation before we close
this discussion.

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 1/3/15, 10:35 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>> IMO, it would be better if I keep making changes and Justin does the
>> review.  He’s a much better reviewer and the results will have one
>> authoring style.
>
>Your viewpoints are different enough that discussing this until you've
>reached agreement - which is basically what one person editing and one
>reviewing would be - would take ages, if it happened at all.

AIUI, the only missing required pieces are the W3C and xml-api*.jar
notices.

>
>I think this exercise in legal wrangling has gone on long enough. This
>stuff has been unchanged for 7 releases without the world coming to an
>end and to be honest my patience is running thin.

Yes, well, we could have just unbundled these jars and been done a long
time ago, but we are going through all of this because we’re afraid of
potential download failures.

-Alex

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

> IMO, it would be better if I keep making changes and Justin does the
> review.  He’s a much better reviewer and the results will have one
> authoring style.

Your viewpoints are different enough that discussing this until you've
reached agreement - which is basically what one person editing and one
reviewing would be - would take ages, if it happened at all.

I think this exercise in legal wrangling has gone on long enough. This
stuff has been unchanged for 7 releases without the world coming to an
end and to be honest my patience is running thin.

So: commit, then review.

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

IMO, it would be better if I keep making changes and Justin does the
review.  He’s a much better reviewer and the results will have one
authoring style.


I found the LICENSE and NOTICE for xml-api*.jar (they weren’t in META-INF)
so I know what changes to make there.  I think we may need to package some
of the README’s that come along with it.

-Alex

On 1/3/15, 4:24 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>>> IMO, if it ain’t broke, don’t fix it.
>
>And it's currently broken - so we need to fix it.
>
>> Justin, with this comment of Alex in mind, please commit and we'll
>> review.
>
>I'll have some time tomorrow to do this.
>
>Justin

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

>> IMO, if it ain’t broke, don’t fix it.

And it's currently broken - so we need to fix it.

> Justin, with this comment of Alex in mind, please commit and we'll
> review.

I'll have some time tomorrow to do this.

Justin

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

> IMO, if it ain’t broke, don’t fix it.  But I’ll let Erik make the call
> since he’s the RM.  Every change made risks another mistake.  I’m signing

Justin, with this comment of Alex in mind, please commit and we'll
review. Less is more!

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Are you proposing to add the entire text of W3C to LICENSE or a pointer to
> a separate file stored somewhere?

 A pointer is the preferred method.

>  Are you also claiming that Batik’s NOTICE is wrong?

It most likely wrong- but either way we bundle the xml-* jars so need to modify LICENSE and NOTICE accordingly.

> The portion below is already in for Xalan isn’t it?  It is unclear whether
> it needs to be duplicated or not.

It would be clearer if it was duplicated and  what it applies to mentioned.

> Did you get this from the jar or somewhere else?

From the jar.

Justin

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

IMO, if it ain’t broke, don’t fix it.  But I’ll let Erik make the call
since he’s the RM.  Every change made risks another mistake.  I’m signing
off for tonight.  I’ll see what you guys think when I wake up.

A few more comments in-line.

On 1/3/15, 12:07 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Any Apache 2.0 should not be normally added to license. As the document
>states under "Bundling an Apache-2.0-licensed Dependency"  there is no
>need to modify LICENSE.

Yes, but separately, Sebb recommended listing subcomponents.
http://s.apache.org/2uz



>>>6. Need to add WC3 see [6]
>> 
>> I puzzled over this for a while and still am not sure of the answer.
>
>Basically if we omit it's most likely a licensing error (as the LICENSE
>file must contain all licenses of all bundled software), but if we add it
>there's no error.  I can add this. Look at the W3C licensing in
>xml-apis-ext.jar and xml-apis.jar.

Are you proposing to add the entire text of W3C to LICENSE or a pointer to
a separate file stored somewhere?  Are you also claiming that Batik’s
NOTICE is wrong?  That’s where we get xml-apis*.jar.

>>I don’t think it is our problem to resolve issues in Xalan’s NOTICE.  The
>> README files don’t seem to be in the binary package we use.
>
>We can point it out to them and it easy to fix ie remove a few lines.
>Again I can do that.

What changes are you proposing to make here?

>
>>> 6. Missing some notices from xerces (there are several NOTICE files)
>> 
>> I think I got them all.  Which ones did I miss?
>
>It should be:
>   Portions of this software were originally based on the following:
>     - software copyright (c) 1999, IBM Corporation., http://www.ibm.com.
>     - software copyright (c) 1999, Sun Microsystems., http://www.sun.com.
>     - voluntary contributions made by Paul Eng on behalf of the
>       Apache Software Foundation that were originally developed at
>iClick, Inc.,
>       software copyright (c) 1999.

Yep, missed that.  Checked it in.

>
>Portions of this code are derived from classes placed in the
>public domain by Arbortext on 10 Apr 2000. See:
>http://www.arbortext.com/customer_support/updates_and_technical_notes/cata
>logs/docs/README.htm

The portion below is already in for Xalan isn’t it?  It is unclear whether
it needs to be duplicated or not.

>
>   Portions of this software was originally based on the following:
>     - software copyright (c) 1999-2002, Lotus Development Corporation.,
>       http://www.lotus.com.
>     - software copyright (c) 2001-2002, Sun Microsystems.,
>       http://www.sun.com.
>     - software copyright (c) 2003, IBM Corporation.,
>       http://www.ibm.com.


>
>>> 7. Missing required notices from XML commons extensions
>
>xml-apis-ext.jar
>
>The NOTICE should include:
>   Portions of this software were originally based on the following:
>     - software copyright (c) 1999, IBM Corporation., http://www.ibm.com.
>     - software copyright (c) 1999, Sun Microsystems., http://www.sun.com.
>     - software copyright (c) 2000 World Wide Web Consortium,
>http://www.w3.org

Did you get this from the jar or somewhere else?

Thanks,
-Alex

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> In looking around, AOO seems to have it in pieces.  Other projects have
> the full AL in the various versions.

Remember other project may not be correct and or predate the current advice. Given it very easy to put the full license in and that is clearer to anyone looking at the code in source control. I'm happy to make the changes.

>  IMO, not an error, no need to change it.  The more we change, the more energy gets
> spent.

The change is simple and again I can do it, a shorter licence is better for users IMO.

> Well, now that it is 2015, a full scrub for 2014 needs to happen.

It's now recommended that a date range be given. Again easy to change and again I do that if you want.

>> 3. There is no need for the Xerces Patch developed at Apache lines [4]
> 
> The instructions at [4] say “It is not necessary”, but doesn’t prohibit it.

"It is not necessary to duplicate the line "This product includes software developed at the Apache Software Foundation..." is fairly clean again an easy fix. Also from the same document "It is important to keep NOTICE as brief and simple as possible,"

> When concatenated to LICENSE, these items are added to the SUBCOMPONENTS
> section.  

Any Apache 2.0 should not be normally added to license. As the document states under "Bundling an Apache-2.0-licensed Dependency"  there is no need to modify LICENSE.

> We mention other AL2.0 subcomponents in LICENSE already.

For different reason as the license of the (binary) font files are unclear.

>> 6. Need to add WC3 see [6]
> 
> I puzzled over this for a while and still am not sure of the answer. 

Basically if we omit it's most likely a licensing error (as the LICENSE file must contain all licenses of all bundled software), but if we add it there's no error.  I can add this. Look at the W3C licensing in xml-apis-ext.jar and xml-apis.jar.

> Rat also doesn’t flag W3C files it finds in the scan.

That may be because it implementation of a standard and/or API. See 1/2 way down http://xerces.apache.org.

> I’m wondering if W3C code has some special status

Unlikely as it compatible it's most likely treated the same as BSD/MIT. Also see the license files in the 2 xml jars. The W3C license states "the W3C Software Short Notice should be included (hypertext is preferred, text is permitted) within the body of any redistributed or derivative code."

> I don’t think it is our problem to resolve issues in Xalan’s NOTICE.  The
> README files don’t seem to be in the binary package we use.

We can point it out to them and it easy to fix ie remove a few lines. Again I can do that.

>> 6. Missing some notices from xerces (there are several NOTICE files)
> 
> I think I got them all.  Which ones did I miss?

It should be:
   Portions of this software were originally based on the following:
     - software copyright (c) 1999, IBM Corporation., http://www.ibm.com.
     - software copyright (c) 1999, Sun Microsystems., http://www.sun.com.
     - voluntary contributions made by Paul Eng on behalf of the 
       Apache Software Foundation that were originally developed at iClick, Inc.,
       software copyright (c) 1999.

Portions of this code are derived from classes placed in the
public domain by Arbortext on 10 Apr 2000. See:
http://www.arbortext.com/customer_support/updates_and_technical_notes/catalogs/docs/README.htm

   Portions of this software was originally based on the following:
     - software copyright (c) 1999-2002, Lotus Development Corporation.,
       http://www.lotus.com.
     - software copyright (c) 2001-2002, Sun Microsystems.,
       http://www.sun.com.
     - software copyright (c) 2003, IBM Corporation., 
       http://www.ibm.com.

>> 7. Missing required notices from XML commons extensions

xml-apis-ext.jar

The NOTICE should include:
   Portions of this software were originally based on the following:
     - software copyright (c) 1999, IBM Corporation., http://www.ibm.com.
     - software copyright (c) 1999, Sun Microsystems., http://www.sun.com.
     - software copyright (c) 2000 World Wide Web Consortium, http://www.w3.org

>> 8. Missing required notices from XML commons

xml-apis.jar

Looks to be the same as xml-apis-ext.jar

Thanks,
Justin

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

After reading your notes and reviewing the links, I’m not sure I’m that
far off from being “good enough”.  My goal is to make the fewest and
easiest changes possible to get us into compliance, so I opted for copying
entire NOTICE files instead of picking apart pieces of it, leveraging the
build script code that appends the .bin file, and not fixing anything that
I didn’t think was truly broken.

More comments in-line.

On 1/2/15, 1:40 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>This is for discussion before I make any changes to the current files
>after a first pass. They still need a bit of work IMO.
>
>I assume LICENSE.bin is appended to LICENSE as part of the build process,
>this does mean that if you look at the LICENSE.bin in svn it's not
>correct. Would it be  better to not assemble it but have it contain the
>full LICENSE? Same for NOTICE.bin.

In looking around, AOO seems to have it in pieces.  Other projects have
the full AL in the various versions.  I chose pieces so that if we add a
license or notice to the source package, it automatically gets propagated
to the binary. I’ll go with whatever the majority wants to do.

>
>LICENSE
>1. Could use short form of BSD [1]

Funny, you argued against using a pointer for Squiggly.  IMO, not an
error, no need to change it.  The more we change, the more energy gets
spent.

>
>NOTICE
>1. Year is wrong, recommend it's a range btw [2]

Well, now that it is 2015, a full scrub for 2014 needs to happen.

>2. There's probably no need for the copyright notice from Robert Penner.
>The code is BSD licensed, and in that case it shouldn't be added to
>notice.[1][3] The only reason it could possibly be there was if copyright
>notices were removed from source files.

I will have to check next time I’m back in the office.  I know that his
work got flagged when we were scrubbing the Adobe code for donation to
Apache but my records for that are on a different computer. I can’t see
his copyright in the Adobe source for 4.6, but his AS1 examples do have a
copyright, so at some point it got moved.

>3. There is no need for the Xerces Patch developed at Apache lines [4]

The instructions at [4] say “It is not necessary”, but doesn’t prohibit it.

>
>LICENSE.bin
>1. No need for lib/external/commons-logging.jar as it's Apache 2.0
>licensed [5]
>2. Could use the short form of the BSD license for
>lib/external/java-cc.jar
>3. No need for lib/external/xercesImpl.jar as it's Apache 2.0. [5]
>4. No need for lib/external/xalan.jar as it's Apache 2.0. [5]
>5. No need for lib/external/xml-apis-ext.jar as it's Apache 2.0. [5]

When concatenated to LICENSE, these items are added to the SUBCOMPONENTS
section.  We mention other AL2.0 subcomponents in LICENSE already.

>6. Need to add WC3 see [6]

I puzzled over this for a while and still am not sure of the answer.  Both
Batik and Xerces seem to use W3C code, but don’t mention/point to W3C
directly in the LICENSE. Batik doesn’t mention it at all and Xerces has
these separate license files like you show in [6] but no pointer.  Rat
also doesn’t flag W3C files it finds in the scan. I’m wondering if W3C
code has some special status that it doesn’t have to be pointed to from
LICENSE.

>
>NOTICE.bin
>1. No need for the xalan copyright notice [3]
>2. No need to list Apache under "This product includes software developed
>by the following:" [4] Looks to be an error in their NOTICE file.
>3. No need for W3C under "This product includes software developed by the
>following:" as it a compatible license. (Should be in LICENSE not
>NOTICE). Again an error in their NOTICE file.
>4. The referenced xxxx.README.txt files are missing. We are probably need
>to add these.

I don’t think it is our problem to resolve issues in Xalan’s NOTICE.  The
README files don’t seem to be in the binary package we use.

>5. No need for the XML commons resolver copyright or this software
>developed at lines [3][4]
>6. Missing some notices from xerces (there are several NOTICE files)

I think I got them all.  Which ones did I miss?

>7. Missing required notices from XML commons extensions
>8. Missing required notices from XML commons

Which files are you referring to here?

>
>Re the Saxon and the CERN issue it may not be an issue as according to
>this [7]. The Cern code in question is a  generic sorter [8]. I can't see
>why the CERN license in question wouldn't be compatible with Apache. I'll
>add this to the JIRA.

I agree that Apache Legal should rule that Saxon is ok.  But they haven’t
yet and until they do, separating it out is our only option, IMO.

-Alex

>
>1. http://www.apache.org/dev/licensing-howto.html#permissive-deps
>2. http://www.apache.org/dev/licensing-howto.html#simple
>3. http://www.apache.org/dev/licensing-howto.html#mod-notice
>4. http://www.apache.org/dev/licensing-howto.html#bundle-asf-product
>5. http://www.apache.org/dev/licensing-howto.html#alv2-dep
>6. 
>https://svn.apache.org/repos/asf/xerces/java/trunk/LICENSE.DOM-software.ht
>ml
>7. http://www.saxonica.com/documentation9.5/conditions/
>8. 
>http://www.saxonica.com/documentation9.5/conditions/third-party-components
>.html

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 1/2/15, 4:16 PM, "Justin Mclean" <ju...@me.com> wrote:
>>I’m not clear most of your suggestions are required.'
>
>Correct not everything there is a licensing error but there several that
>would be IMO release blockers.

Which ones in your opinion are release blockers?  IMO, the rest aren’t
worth the energy.

-Alex

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@me.com>]

Hi,

> I don’t have time to reply to all of these points right now but I will later.

Once you do I'll make the changes.

> I’m not clear most of your suggestions are required.'

Correct not everything there is a licensing error but there several that would be IMO release blockers. But as we're changing it we might as well try and get it right.

> In the meantime, can you explain what is a “short form of BSD”.

License pointers are preferred to full licenses in the LICENSE file. eg BSD license in [1] Not a blocker but very easy to fix, assuming you agree to the change.

>  Also, I think I’ve seen other projects “assemble” LICENSE and NOTICE. 

They do but as per [2][3] you don't copy the full contents of the Apache 3rd party NOTICE file into our NOTICE file. You only need the parts you're required to copy. IMO it's also easier to have the full licence and notice in version control so you can see the license without have to build the software. (30 minutes or so in the case of the binary).

Thanks,
Justin

1 http://www.apache.org/dev/licensing-howto.html#permissive-deps
2 http://www.apache.org/dev/licensing-howto.html#bundle-asf-product
3.http://www.apache.org/dev/licensing-howto.html#mod-notice

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 1/2/15, 1:40 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>This is for discussion before I make any changes to the current files
>after a first pass. They still need a bit of work IMO.

I didn’t expect to get it fully right.  I don’t have time to reply to all
of these points right now but I will later.  I’m not clear most of your
suggestions are required.

In the meantime, can you explain what is a “short form of BSD”.  Also, I
think I’ve seen other projects “assemble” LICENSE and NOTICE.  Maybe you
can look at what they do.

-Alex

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

This is for discussion before I make any changes to the current files after a first pass. They still need a bit of work IMO.

I assume LICENSE.bin is appended to LICENSE as part of the build process, this does mean that if you look at the LICENSE.bin in svn it's not correct. Would it be  better to not assemble it but have it contain the full LICENSE? Same for NOTICE.bin.

LICENSE
1. Could use short form of BSD [1]

NOTICE
1. Year is wrong, recommend it's a range btw [2]
2. There's probably no need for the copyright notice from Robert Penner. The code is BSD licensed, and in that case it shouldn't be added to notice.[1][3] The only reason it could possibly be there was if copyright notices were removed from source files.
3. There is no need for the Xerces Patch developed at Apache lines [4]

LICENSE.bin
1. No need for lib/external/commons-logging.jar as it's Apache 2.0 licensed [5]
2. Could use the short form of the BSD license for lib/external/java-cc.jar
3. No need for lib/external/xercesImpl.jar as it's Apache 2.0. [5]
4. No need for lib/external/xalan.jar as it's Apache 2.0. [5]
5. No need for lib/external/xml-apis-ext.jar as it's Apache 2.0. [5]
6. Need to add WC3 see [6]

NOTICE.bin
1. No need for the xalan copyright notice [3]
2. No need to list Apache under "This product includes software developed by the following:" [4] Looks to be an error in their NOTICE file.
3. No need for W3C under "This product includes software developed by the following:" as it a compatible license. (Should be in LICENSE not NOTICE). Again an error in their NOTICE file.
4. The referenced xxxx.README.txt files are missing. We are probably need to add these.
5. No need for the XML commons resolver copyright or this software developed at lines [3][4]
6. Missing some notices from xerces (there are several NOTICE files)
7. Missing required notices from XML commons extensions
8. Missing required notices from XML commons

Re the Saxon and the CERN issue it may not be an issue as according to this [7]. The Cern code in question is a  generic sorter [8]. I can't see why the CERN license in question wouldn't be compatible with Apache. I'll add this to the JIRA.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#permissive-deps 
2. http://www.apache.org/dev/licensing-howto.html#simple
3. http://www.apache.org/dev/licensing-howto.html#mod-notice
4. http://www.apache.org/dev/licensing-howto.html#bundle-asf-product
5. http://www.apache.org/dev/licensing-howto.html#alv2-dep
6. https://svn.apache.org/repos/asf/xerces/java/trunk/LICENSE.DOM-software.html
7. http://www.saxonica.com/documentation9.5/conditions/
8. http://www.saxonica.com/documentation9.5/conditions/third-party-components.html

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 1/2/15, 11:30 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>> We cannot bundle Saxon in the binary package because there are classes
>>in
>> the Saxon jar that haven’t been approved as Apache-compatible.  While
>> other Apache projects “use” Saxon, the first four I looked at don’t
>>appear
>> to bundle it in their binary packages.  At least, I don’t see saxon*.jar
>> in the binary packages or mention of Saxon in the LICENSE and NOTICE
>>files
>> of those packages.
>
>So, the others get to use Saxon without any mention of it in their
>legal docs, and we have to remove it or at least bother the user about
>downloading it?

By removing Saxon from our binary package, we’d be able to remove mention
of it from our legal docs as well.

I am not familiar with details of the projects I looked at, but it appears
that for some and maybe all, Saxon is just a choice of XSLT processor.
Users of those projects might have to manually download Saxon and modify
configuration file.  We probably don’t want to make our users manually
download Saxon, so offering to download it during the build and/or install
seems better.

-Alex

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

> We cannot bundle Saxon in the binary package because there are classes in
> the Saxon jar that haven’t been approved as Apache-compatible.  While
> other Apache projects “use” Saxon, the first four I looked at don’t appear
> to bundle it in their binary packages.  At least, I don’t see saxon*.jar
> in the binary packages or mention of Saxon in the LICENSE and NOTICE files
> of those packages.

So, the others get to use Saxon without any mention of it in their
legal docs, and we have to remove it or at least bother the user about
downloading it?

At least we got rid of those other ones; two steps forward, one step
back, I guess ;-)

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 1/2/15, 3:44 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>So, if I understand correctly, the current 'consensus' is that there
>need to be fixes to LICENSE and NOTICE. Alex has these all but done.
>Then there is the issue about the various installer prompts: we either
>include a Saxon prompt, or we decide not to and to be consistent we
>remove the OSMF prompt. My vote would be for option 2: less prompts
>improves user experience. And if we're removing prompt anyway, then
>the one for SWFObject seems to be an easy target, since that seems to
>be unneeded anyway.

My current summary is this:

We cannot bundle Saxon in the binary package because there are classes in
the Saxon jar that haven’t been approved as Apache-compatible.  While
other Apache projects “use” Saxon, the first four I looked at don’t appear
to bundle it in their binary packages.  At least, I don’t see saxon*.jar
in the binary packages or mention of Saxon in the LICENSE and NOTICE files
of those packages.

The safest option, IMO, is to not bundle Saxon and have the build and
install scripts download after a prompt just like we do for the Adobe font
jars.  That’s because Saxon is only used for ASDoc and many folks don’t
need to generate ASDoc for their Flex apps, so it can be seen as an
optional feature and the decision on whether Saxon is Apache-compatible
can be deferred.  IMO, we haven’t heard back from our questions because
folks are still on holiday break.  I was going to wait until Monday to
ping folks on these questions.

Independently, we can decide to remove the OSMF and SWFObject prompts
unless Om can recall some discussion or the reason why we currently have
prompts.  Removal of these should be as simple as deleting some things
from apache-flex-sdk-installer-config.xml.

Anyway, I’ve checked in what I think we need to do to the build scripts,
LICENSE and NOTICE for the source package and jars and the binary package
other than Saxon.  We can make changes later about prompts for downloads.

-Alex

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

>> Then we need to decide whether we want the install scripts to prompt folks
>> to accept Saxon or not, and whether we should continue to have folks
>> approve OSMF and SWFObject like we currently do.
>
> We should probably be consistent. If we ask for OSMF we should for Saxon. It seems clear to me that theirs no need to ask if we only include the jar, as the source code isn't included, it can't be modified, and so the week copy left provisions of MPL don't apply. But either way (if we ask or not) it's not a blocker as the license requirements have been met. (Assuming it's added to LICENSE.)
>
> Re SWFObject (MIT licensed) there no need to ask but again it's not a blocker if we do, just unnecessary.

So, if I understand correctly, the current 'consensus' is that there
need to be fixes to LICENSE and NOTICE. Alex has these all but done.
Then there is the issue about the various installer prompts: we either
include a Saxon prompt, or we decide not to and to be consistent we
remove the OSMF prompt. My vote would be for option 2: less prompts
improves user experience. And if we're removing prompt anyway, then
the one for SWFObject seems to be an easy target, since that seems to
be unneeded anyway.

As RM, I choose to interpret the lack of response from both
"general@incubator.apache.org" and "LEGAL-on-JIRA" as these issues
being very much edge cases, and the Board won't disband the current
PMC for publishing a release with the above best efforts.

So: Alex, if you can please commit your suggested changes to LICENSE
and NOTICE so Justin can review? And what would it take to remove the
prompts for OSMF and SWFObject from the install scripts?

Thanks,

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Then we need to decide whether we want the install scripts to prompt folks
> to accept Saxon or not, and whether we should continue to have folks
> approve OSMF and SWFObject like we currently do.  

We should probably be consistent. If we ask for OSMF we should for Saxon. It seems clear to me that theirs no need to ask if we only include the jar, as the source code isn't included, it can't be modified, and so the week copy left provisions of MPL don't apply. But either way (if we ask or not) it's not a blocker as the license requirements have been met. (Assuming it's added to LICENSE.)

Re SWFObject (MIT licensed) there no need to ask but again it's not a blocker if we do, just unnecessary. 

I've pointed this out before but seems like a good time to mention it again Firefox had a big issue with this [1][2][3]

Thanks,
Justin

1. https://www.mozilla.org/en-US/about/legal/eula/
2. http://blog.lizardwrangler.com/2008/09/15/ubuntu-firefox-and-license-issues/
3. http://blog.lizardwrangler.com/2008/09/16/

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

Other than Saxon, I think I’m mostly done fixing up LICENSE and NOTICE so
that it matches the way we packaged prior releases.  I hope to finish
Saxon and check it all in tonight or tomorrow.  Then it needs review and
we might find a few more things we need to change.

Then we need to decide whether we want the install scripts to prompt folks
to accept Saxon or not, and whether we should continue to have folks
approve OSMF and SWFObject like we currently do.  Again, if we guess wrong
here, I can’t imagine it would be seen as putting the foundation at risk,
but maybe we’ll get lucky and someone will provide an answer or Om will
remember some conversation about it when creating the Installer.

-Alex

On 12/29/14, 1:15 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> Do you have the cycles to create a suggested fix for both?
>
>As I said I will have later this week, but Alex is currently looking into
>it and would need to check in what he's done first I think.
>
>One of my earlier posts in this thread had details on what the likely
>changes would be.
>
>Thanks,
>Justin

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Do you have the cycles to create a suggested fix for both?

As I said I will have later this week, but Alex is currently looking into it and would need to check in what he's done first I think.

One of my earlier posts in this thread had details on what the likely changes would be.

Thanks,
Justin

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

> Currently the LICENSE and NOTICE files are incorrect, the simple solution is to fix them.

Do you have the cycles to create a suggested fix for both?

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> OK. A little bit dramatic, and half those options exist anyway, as
> previous releases have the same issues.

Yep as discussed we need to fix those as well.

Can be summed up in one line:

Currently the LICENSE and NOTICE files are incorrect, the simple solution is to fix them.

Justin

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

>> No, I meant what would happen if we went ahead a binary release
>> without fixing this...
>
> We can't as we now know it would be against Apache policy. Worse cases include the board taking action and ask us to remove the releases or disbanding the PMC, a 3rd party could take us to court, businesses wouldn't use the software because it's not correctly licensed.

OK. A little bit dramatic, and half those options exist anyway, as
previous releases have the same issues.

But, moving forward, let's start with this:

Alex, Justin, if you can each write one paragraph summarizing the
problem, and one paragraph with the most workable way out, please. I
will then try to figure out a solution that we can all agree upon, or
start a vote if we can't.

Thanks for your cooperation,

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> No, I meant what would happen if we went ahead a binary release
> without fixing this...

We can't as we now know it would be against Apache policy. Worse cases include the board taking action and ask us to remove the releases or disbanding the PMC, a 3rd party could take us to court, businesses wouldn't use the software because it's not correctly licensed.

While all of those are unlikely it's about risk, It not too hard to fix this so lets do that rather than expose ourselves to the risk.

Justin

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

>> Can you give me a (realistic) worst case scenario if we were to
>> release without making any changes?
>
> IMO Worse case we can't make a release until this is resolved.

No, I meant what would happen if we went ahead a binary release
without fixing this... Tempting, because we did that nearly a dozen
times without the world coming to an end.

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

HI,

> Can you give me a (realistic) worst case scenario if we were to
> release without making any changes?

IMO Worse case we can't make a release until this is resolved.  We could make a source release without any changes but given the installer uses the binary that's hardly ideal.

Justin

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

Can you give me a (realistic) worst case scenario if we were to
release without making any changes? In other words: is this issue a
blocker for the 4.14 release or just an issue that we need to take
care of for a future release?

EdB



On Mon, Dec 29, 2014 at 9:42 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 12/28/14, 12:29 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>>Hi,
>>
>>>  Since binary packages are not an act of the foundation, other than the
>>>explicit
>>> statement that LICENSE and NOTICE must match the contents of the binary
>>> package, I can’t imagine that it puts the foundation at risk if we guess
>>> wrong about packaging external jars that are otherwise open source or if
>>> we ask too many or too few questions during the install about the open
>>> source licenses for those jars.
>>
>>I'm really not sure that is correct, from [1]:
>>
>>"What applies to canonical source distributions also applies to all
>>redistributions, including binary redistributions:"
>>
>>and
>>
>>"Any redistribution must obey the licensing requirements of the contents."
>>
>>We can't ignore the licensing requirements of bundled jar just because
>>it's a binary release. Asking too many questions is not a major issue as
>>the minimal licensing requirements have been met, but asking too few is a
>>licensing error and needs to be corrected before we can release.
>
> [1] is about, as I said, that LICENSE and NOTICE must match the contents
> of the binary package.
>
> The questions I am trying to get answers to are:
>
> -Can a binary package bundle a binary without its source?
> -Was there any past discussion that caused the Installer to ask about
> accepting SWFObject’s MIT License?
>
> The answers may affect what goes in the binary package and thus what goes
> in the LICENSE and NOTICE for the binary package.
>
> Meanwhile, I’m still puzzling over which Saxon NOTICES apply.
>
> -Alex
>
>>
>>1. http://www.apache.org/dev/licensing-howto.html#binary
>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 12/28/14, 12:29 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>>  Since binary packages are not an act of the foundation, other than the
>>explicit
>> statement that LICENSE and NOTICE must match the contents of the binary
>> package, I can’t imagine that it puts the foundation at risk if we guess
>> wrong about packaging external jars that are otherwise open source or if
>> we ask too many or too few questions during the install about the open
>> source licenses for those jars.
>
>I'm really not sure that is correct, from [1]:
>
>"What applies to canonical source distributions also applies to all
>redistributions, including binary redistributions:"
>
>and
>
>"Any redistribution must obey the licensing requirements of the contents."
>
>We can't ignore the licensing requirements of bundled jar just because
>it's a binary release. Asking too many questions is not a major issue as
>the minimal licensing requirements have been met, but asking too few is a
>licensing error and needs to be corrected before we can release.

[1] is about, as I said, that LICENSE and NOTICE must match the contents
of the binary package.

The questions I am trying to get answers to are:

-Can a binary package bundle a binary without its source?
-Was there any past discussion that caused the Installer to ask about
accepting SWFObject’s MIT License?

The answers may affect what goes in the binary package and thus what goes
in the LICENSE and NOTICE for the binary package.

Meanwhile, I’m still puzzling over which Saxon NOTICES apply.

-Alex

>
>1. http://www.apache.org/dev/licensing-howto.html#binary

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

>  Since binary packages are not an act of the foundation, other than the explicit
> statement that LICENSE and NOTICE must match the contents of the binary
> package, I can’t imagine that it puts the foundation at risk if we guess
> wrong about packaging external jars that are otherwise open source or if
> we ask too many or too few questions during the install about the open
> source licenses for those jars.

I'm really not sure that is correct, from [1]:

"What applies to canonical source distributions also applies to all redistributions, including binary redistributions:"

and

"Any redistribution must obey the licensing requirements of the contents."

We can't ignore the licensing requirements of bundled jar just because it's a binary release. Asking too many questions is not a major issue as the minimal licensing requirements have been met, but asking too few is a licensing error and needs to be corrected before we can release.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#binary

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

No response to my query on general@ so far [1] but I think everyone is not
as active because of the holidays.  Maybe Bertrand can give us his
thoughts.

I’m working on fixing up the LICENSE and NOTICE for the source package and
jar files, and will try to provide easy to comment options for the binary
package.

Then, IMO, unless we hear back from someone who has experience in this
area, since you are the RM, you get to decide whether to package
“external” jars in the binary package or not, and what prompts to require
of folks installing this release via Ant and the Installer.  Since binary
packages are not an act of the foundation, other than the explicit
statement that LICENSE and NOTICE must match the contents of the binary
package, I can’t imagine that it puts the foundation at risk if we guess
wrong about packaging external jars that are otherwise open source or if
we ask too many or too few questions during the install about the open
source licenses for those jars.

On 12/28/14, 4:31 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>Even after rereading the thread, I won't pretend to understand what's
>being discussed, but... Are we any closer to a resolution?  if so, is
>this something that absolutely has to be addressed with this release?
>
>EdB
>

[1] http://s.apache.org/zpt

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

Even after rereading the thread, I won't pretend to understand what's
being discussed, but... Are we any closer to a resolution?  if so, is
this something that absolutely has to be addressed with this release?

EdB



On Mon, Dec 22, 2014 at 9:59 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 12/21/14, 1:13 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>>Hi,
>>
>>> Changing the 4.14 LICENSE and NOTICE won’t help older releases.
>>
>>I assume we'll have to make point releases of them.
>
> It might be worth asking on legal-discuss as to whether that is required.
>
>>
>>> 1) I’m wondering if one of the reasons for the Installer having a
>>>checkbox
>>> for SWFObject is because the Installer doesn’t let the customer review
>>> LICENSE and NOTICE of the release before installing, and the checkboxes
>>> effectively take the customer through the LICENSE.
>>
>>Where is this written down as an Apache legal requirement? I think you
>>may be confusing the license with a EULA. If I download the source
>>package I don't have to view the LICENSE or NOTICE. As long as everything
>>is Apache or a compatible license (ie MIT, BSD or W3C) all's good as I
>>have the same rights. In the case of MPL there's an issue if the MPL
>>source is included and the weak copy-left kicks in and then I need to be
>>notified.
>
> I don’t know for sure.  Maybe Om remembers why SWFObject is listed.  I did
> find [3] in the archives where Bertrand says:
>
>   -All required dependencies have compatible licenses as per
>    http://apache.org/legal/resolved.html
>
>   -Users can easily find out what those compatible licenses are
>
> So maybe that’s the history behind it.
>
>
>
>>
>>> 2) I’m for more bundling as well, but I’ve been trying to setup releases
>>> with less bundling because of [2] where it says: "the binary/bytecode
>>> package must have the same version number as the source release and may
>>> only add binary/bytecode files that are the result of compiling that
>>> version of the source code release.”  That sort of implies that we
>>>aren’t
>>> supposed to have 3rd party binaries in the binary package.
>>
>>
>>I'd read that as just saying that you can't have unreleased source
>>compiled into a binary release. Also see LEGAL jiras, for instance Open
>>Office was given permission to add GPL 3rd party files to their binary
>>[1] and this [2] (note the "yes" to adding it as a binary dependancy) and
>>there's probably others. Have you investigated what other projects do?
>
> AOO got an exception for what is more like a data file.  I looked through
> our archives and didn’t see any mentor advice on how to set up a binary
> package so no history to lean on there.  I poked at a few projects, not
> that you can use that as a reference point, but we’d have to examine their
> source packages and compare.  Apache seems to be historically
> source-oriented and maven-oriented, so I’m wondering if binary packages
> that have non-Apache jars got created by downloading the source for those
> non-Apache things and compiling them.  And other consumers of other binary
> packages just fish all the dependencies out of Maven so jars aren’t in the
> package.
>
> I’ll poke around a bit more tomorrow and maybe ask on legal-discuss or
> general@incubator.
>
> -Alex
>
>>
>>1. https://issues.apache.org/jira/browse/LEGAL-117
>>2. https://issues.apache.org/jira/browse/LEGAL-72
>>
>
> [3] http://s.apache.org/TNB
>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

On 12/21/14, 1:13 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> Changing the 4.14 LICENSE and NOTICE won’t help older releases.
>
>I assume we'll have to make point releases of them.

It might be worth asking on legal-discuss as to whether that is required.

>
>> 1) I’m wondering if one of the reasons for the Installer having a
>>checkbox
>> for SWFObject is because the Installer doesn’t let the customer review
>> LICENSE and NOTICE of the release before installing, and the checkboxes
>> effectively take the customer through the LICENSE.
>
>Where is this written down as an Apache legal requirement? I think you
>may be confusing the license with a EULA. If I download the source
>package I don't have to view the LICENSE or NOTICE. As long as everything
>is Apache or a compatible license (ie MIT, BSD or W3C) all's good as I
>have the same rights. In the case of MPL there's an issue if the MPL
>source is included and the weak copy-left kicks in and then I need to be
>notified.

I don’t know for sure.  Maybe Om remembers why SWFObject is listed.  I did
find [3] in the archives where Bertrand says:

  -All required dependencies have compatible licenses as per
   http://apache.org/legal/resolved.html

  -Users can easily find out what those compatible licenses are

So maybe that’s the history behind it.



>
>> 2) I’m for more bundling as well, but I’ve been trying to setup releases
>> with less bundling because of [2] where it says: "the binary/bytecode
>> package must have the same version number as the source release and may
>> only add binary/bytecode files that are the result of compiling that
>> version of the source code release.”  That sort of implies that we
>>aren’t
>> supposed to have 3rd party binaries in the binary package.
>
>
>I'd read that as just saying that you can't have unreleased source
>compiled into a binary release. Also see LEGAL jiras, for instance Open
>Office was given permission to add GPL 3rd party files to their binary
>[1] and this [2] (note the "yes" to adding it as a binary dependancy) and
>there's probably others. Have you investigated what other projects do?

AOO got an exception for what is more like a data file.  I looked through
our archives and didn’t see any mentor advice on how to set up a binary
package so no history to lean on there.  I poked at a few projects, not
that you can use that as a reference point, but we’d have to examine their
source packages and compare.  Apache seems to be historically
source-oriented and maven-oriented, so I’m wondering if binary packages
that have non-Apache jars got created by downloading the source for those
non-Apache things and compiling them.  And other consumers of other binary
packages just fish all the dependencies out of Maven so jars aren’t in the
package.

I’ll poke around a bit more tomorrow and maybe ask on legal-discuss or
general@incubator.

-Alex

>
>1. https://issues.apache.org/jira/browse/LEGAL-117
>2. https://issues.apache.org/jira/browse/LEGAL-72
>

[3] http://s.apache.org/TNB

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Changing the 4.14 LICENSE and NOTICE won’t help older releases.

I assume we'll have to make point releases of them.

> 1) I’m wondering if one of the reasons for the Installer having a checkbox
> for SWFObject is because the Installer doesn’t let the customer review
> LICENSE and NOTICE of the release before installing, and the checkboxes
> effectively take the customer through the LICENSE.

Where is this written down as an Apache legal requirement? I think you may be confusing the license with a EULA. If I download the source package I don't have to view the LICENSE or NOTICE. As long as everything is Apache or a compatible license (ie MIT, BSD or W3C) all's good as I have the same rights. In the case of MPL there's an issue if the MPL source is included and the weak copy-left kicks in and then I need to be notified.

> 2) I’m for more bundling as well, but I’ve been trying to setup releases
> with less bundling because of [2] where it says: "the binary/bytecode
> package must have the same version number as the source release and may
> only add binary/bytecode files that are the result of compiling that
> version of the source code release.”  That sort of implies that we aren’t
> supposed to have 3rd party binaries in the binary package.


I'd read that as just saying that you can't have unreleased source compiled into a binary release. Also see LEGAL jiras, for instance Open Office was given permission to add GPL 3rd party files to their binary [1] and this [2] (note the "yes" to adding it as a binary dependancy) and there's probably others. Have you investigated what other projects do?

Thanks,
Justin

1. https://issues.apache.org/jira/browse/LEGAL-117
2. https://issues.apache.org/jira/browse/LEGAL-72

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

@Justin, thanks for the link to “prominent label”.  IMO, what to do about
older releases is a different topic.  Changing the 4.14 LICENSE and NOTICE
won’t help older releases.

I had two other thoughts on this topic:

1) I’m wondering if one of the reasons for the Installer having a checkbox
for SWFObject is because the Installer doesn’t let the customer review
LICENSE and NOTICE of the release before installing, and the checkboxes
effectively take the customer through the LICENSE.
2) I’m for more bundling as well, but I’ve been trying to setup releases
with less bundling because of [2] where it says: "the binary/bytecode
package must have the same version number as the source release and may
only add binary/bytecode files that are the result of compiling that
version of the source code release.”  That sort of implies that we aren’t
supposed to have 3rd party binaries in the binary package.

If we can in fact bundle more stuff in the binary package, maybe we go all
the way and bundle SWFObject and OSMF too?

-Alex

[2] http://www.apache.org/dev/release.html

On 12/21/14, 1:20 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>Funny thing: I'm with Justin on this ;-)
>
>Let's make this simpler for the end-user, not more complicated. If we
>can reasonable assume that we can either pre-tick something, or leave
>out the option altogether, we want to do that. We don't want to do
>something that affects the user "just to make extra doubly sure we run
>even the slightest chance of having to change this again at some point
>in the future (which is really the worst case scenario)".
>
>EdB
>
>
>
>On Sun, Dec 21, 2014 at 9:38 AM, Justin Mclean <ju...@classsoftware.com>
>wrote:
>> Hi,
>>
>>> I’m ok with pulling out SWFObject when we go tweak the install script
>>> unless someone has a good reason it should stay in there.
>>
>> A possible option would be to pre tick and/or remove the checkbox in
>>the installer?
>>
>>> My temptation is to fix this by making Saxon a download behind a prompt
>>
>> Why do we need a prompt? We're not downloading the source, just the jar
>>right?
>>
>>>  That avoids us having to figure out what “prominent label” means.
>>
>> This has been discussed and seems reasonably clear,  but the JIRA is
>>not marked as closed. [1]
>>
>>> And yet another option is to download all of these jars in the install.
>>
>> We currently are as we are downloading the binary and they are
>>contained in that, but I assume you mean removing them from the binary
>>and downloading them separately via the installer script? In that case
>>how would we handler older versions of the SDK?
>>
>>> It would probably be the fewest changes to the repo to make it work as
>>> then we wouldn’t need to muck with LICENSE and NOTICE as much, but then
>>> there are more downloads that could fail during the install.
>>
>> Given we already have a large number of download failures I'm not sure
>>that's the best option.
>>
>>>> * NOTICE file may not be correct as velocity original NOTICE file has
>>>>no
>>>> downstream effects.
>>>
>>> Not sure I understood what you mean by that.
>>
>> The Velocity NOTICE file in the jar doesn't look like the
>>original/right one and may of been incorrectly replaced.
>>
>>> From the above list, do we need to add W3C if all jars that have W3C
>>>also
>>> have AL licenses?
>>
>> My understanding is that its not dual licensed (ie select the license
>>you want), but different parts of the code are licensed under different
>>licenses. The W3C license is compatible with Apache and I assume you
>>treat it like MIT/BSD license ie just add it to LICENSE.
>>
>> Thanks,
>> Justin
>>
>> 1. https://issues.apache.org/jira/browse/LEGAL-77
>
>
>
>-- 
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Erik de Bruin <er...@ixsoftware.nl>]

Funny thing: I'm with Justin on this ;-)

Let's make this simpler for the end-user, not more complicated. If we
can reasonable assume that we can either pre-tick something, or leave
out the option altogether, we want to do that. We don't want to do
something that affects the user "just to make extra doubly sure we run
even the slightest chance of having to change this again at some point
in the future (which is really the worst case scenario)".

EdB



On Sun, Dec 21, 2014 at 9:38 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> I’m ok with pulling out SWFObject when we go tweak the install script
>> unless someone has a good reason it should stay in there.
>
> A possible option would be to pre tick and/or remove the checkbox in the installer?
>
>> My temptation is to fix this by making Saxon a download behind a prompt
>
> Why do we need a prompt? We're not downloading the source, just the jar right?
>
>>  That avoids us having to figure out what “prominent label” means.
>
> This has been discussed and seems reasonably clear,  but the JIRA is not marked as closed. [1]
>
>> And yet another option is to download all of these jars in the install.
>
> We currently are as we are downloading the binary and they are contained in that, but I assume you mean removing them from the binary and downloading them separately via the installer script? In that case how would we handler older versions of the SDK?
>
>> It would probably be the fewest changes to the repo to make it work as
>> then we wouldn’t need to muck with LICENSE and NOTICE as much, but then
>> there are more downloads that could fail during the install.
>
> Given we already have a large number of download failures I'm not sure that's the best option.
>
>>> * NOTICE file may not be correct as velocity original NOTICE file has no
>>> downstream effects.
>>
>> Not sure I understood what you mean by that.
>
> The Velocity NOTICE file in the jar doesn't look like the original/right one and may of been incorrectly replaced.
>
>> From the above list, do we need to add W3C if all jars that have W3C also
>> have AL licenses?
>
> My understanding is that its not dual licensed (ie select the license you want), but different parts of the code are licensed under different licenses. The W3C license is compatible with Apache and I assume you treat it like MIT/BSD license ie just add it to LICENSE.
>
> Thanks,
> Justin
>
> 1. https://issues.apache.org/jira/browse/LEGAL-77



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> I’m ok with pulling out SWFObject when we go tweak the install script
> unless someone has a good reason it should stay in there.

A possible option would be to pre tick and/or remove the checkbox in the installer?

> My temptation is to fix this by making Saxon a download behind a prompt

Why do we need a prompt? We're not downloading the source, just the jar right?

>  That avoids us having to figure out what “prominent label” means.

This has been discussed and seems reasonably clear,  but the JIRA is not marked as closed. [1]

> And yet another option is to download all of these jars in the install.

We currently are as we are downloading the binary and they are contained in that, but I assume you mean removing them from the binary and downloading them separately via the installer script? In that case how would we handler older versions of the SDK?

> It would probably be the fewest changes to the repo to make it work as
> then we wouldn’t need to muck with LICENSE and NOTICE as much, but then
> there are more downloads that could fail during the install.

Given we already have a large number of download failures I'm not sure that's the best option.

>> * NOTICE file may not be correct as velocity original NOTICE file has no
>> downstream effects.
> 
> Not sure I understood what you mean by that.

The Velocity NOTICE file in the jar doesn't look like the original/right one and may of been incorrectly replaced.

> From the above list, do we need to add W3C if all jars that have W3C also
> have AL licenses?

My understanding is that its not dual licensed (ie select the license you want), but different parts of the code are licensed under different licenses. The W3C license is compatible with Apache and I assume you treat it like MIT/BSD license ie just add it to LICENSE.

Thanks,
Justin

1. https://issues.apache.org/jira/browse/LEGAL-77

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

OK, let me see if I can pull all three responses into one.

On 12/20/14, 5:58 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>Also on this subject I've no idea why we are prompting for SWFObject when
>it is MIT licensed, as MIT is an compatible licence. The same should
>apply to any Category A licenses (ie Apache 1.1, BSD and W3C).
>
>The installer probably needs some changes from this as it is installing
>from the binary release not the source release.

I’m ok with pulling out SWFObject when we go tweak the install script
unless someone has a good reason it should stay in there.

>>It looks like we have not handled Saxon correctly since forever.
>>The install scripts need to prompt for it.

>Not sure we actually do need to prompt as per [1] you only need to
>prompt to download the source not the binary. The week copy left
>aspects of the licence only apply if you include the source.
>The same probably applies to osmf.

>"Software under the following licenses may be included in binary
>form within an Apache product if the inclusion is appropriately labeled"

>"By attaching a prominent label to the distribution and requiring
>an explicit action by the user to get the reciprocally-licensed
>source, users are less likely to be unaware of restrictions
>significantly different from those of the Apache License.
>Please include the URL to the product's homepage in the prominent label."

My temptation is to fix this by making Saxon a download behind a prompt
just like OSMF.  That avoids us having to figure out what “prominent
label” means.  I’d rather not see our packages labelled
“apache-flex-sdk-4.14.0-with-MPL-saxon”.

The source package’s modules/download.xml would also get a prompt before
downloading Saxon.

Another option is to make the asdoc compiler “optional”.  It seems to the
only piece that uses Saxon.

And yet another option is to download all of these jars in the install.
It would probably be the fewest changes to the repo to make it work as
then we wouldn’t need to muck with LICENSE and NOTICE as much, but then
there are more downloads that could fail during the install.

>Here what I just checked:
>
>commons-collections.jar Apache 1.1
>commons-discovery.jar Apache 1.1
>commons-logging.jar Apache 2.0  has NOTICE no with no downstream effects
>javacc.jar version 5 BSD copyright Sun
>saxon9.jar MPL (Michael Kay) and multiple NOTICES that effect downstream
>xalan.jar Apache 2.0 and NOTICE that effects downstream
>xercesImpl.jar Apache 2.0 and NOTICE that effects downstream
>xercesPatch.jar Apache 2.0 and NOTICE that effects downstream
>xml-apis-ext.jar Apache 2.0 and WC3 and NOTICE file that effects
>downstream
>xml-apis.jar Apache 2.0 and WC3 and NOTICE file that effects downstream
>velocity-dep-1.4-flex.jar Apache 2.0 and NOTICE file that effects
>downstream*
>batik-all-flex.jar Apache 2.0 and NOTICE file that effects downstream
>
>Are there any other jars or 3rd party files included in the binary
>that are not in the source distribution?

Not to my knowledge.

>* NOTICE file may not be correct as velocity original NOTICE file has no
>downstream effects.

Not sure I understood what you mean by that.

>So looks like for the binary license we would need to add
>pointers to the following licenses:
>- Apache 1.1
>- BSD
>- W3C
>- MPL

From the above list, do we need to add W3C if all jars that have W3C also
have AL licenses?

>And add multiple pointers to NOTICE. Most of the existing LICENSE and
>NOTICE files are in /lib/external with the exception of Velocity and
>Batik.

Yep

>We may have a possible issue with saxon in particular this
>lib/external/saxon9-NOTICES/GPL+CLASSPATH.txt?
>Do we know what this refers to? At a guess (and hopefully)
>it may not apply as it's only in the .NET version of saxon
>which I assume we're not using. [1]

>I've not looked at transitive dependencies which are likely
>to also have some effect on our NOTICE file.

OK, let us know what you find.

>I also noticed that most of the flex jars have a LICENSE and
>NOTICE that is probably incorrect for the jar itself e.g.
>compc.jar or flex-compiler-oem.jar  as t contains the full
>Flex LICENSE and NOTICE file not just what is in the jar

Probably worth fixing this now as well.



-Alex

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

Hi,

Also on this subject I've no idea why we are prompting for SWFObject when it is MIT licensed, as MIT is an compatible licence. The same should apply to any Category A licenses (ie Apache 1.1, BSD and W3C).

The installer probably needs some changes from this as it is installing from the binary release not the source release.

Justin

Re: [4.14] binary vs. source package legal docs

[Justin Mclean <ju...@classsoftware.com>]

HI,

> It looks like we have not handled Saxon correctly since forever.  The install scripts need to prompt for it.  

Not sure we actually do need to prompt as per [1] you only need to prompt to download the source not the binary. The week copy left aspects of the licence only apply if you include the source. The same probably applies to osmf.

"Software under the following licenses may be included in binary form within an Apache product if the inclusion is appropriately labeled"

"By attaching a prominent label to the distribution and requiring an explicit action by the user to get the reciprocally-licensed source, users are less likely to be unaware of restrictions significantly different from those of the Apache License. Please include the URL to the product's homepage in the prominent label."

Justin

1. http://www.apache.org/legal/resolved.html#category-b

Re: [4.14] binary vs. source package legal docs

[Alex Harui <ah...@adobe.com>]

This is a great find.  I only found Saxon to not have Category A license.
Did you find the others?

It looks like we have not handled Saxon correctly since forever.  The
install scripts need to prompt for it.  Any volunteers to make the changes
or should I do it?

The LICENSE.bin is definitely out of date.

-Alex

On 12/20/14, 12:44 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

>Hi, just continuing this discussion here... This is the state we left
>it in the other thread:
>
>>> Maybe because there is no difference in the LICENSE for source and
>>>binary packages?
>>
>>The binary package bundles extra 3rd party jars such as Saxon which is
>>MPL licensed [1],
>>that requires  change to LICENSE right? The MPL was removed from LICENSE
>>in this
>>release. Also both Xerces and Xalan jars are bundled and content in
>>their NOTICE files
>>that looks like they need to be in our binary NOTICE file. See the
>>content in LICENSE.bin
>>which looks like a good attempt to take into account of this but may not
>>be 100% correct.
>
>Thanks,
>
>EdB
>
>
>
>-- 
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl