License file

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

License file

kiwiwings
Hi Devs,

do we really need that long LICENSE file?

Junit / Jacoco and few others aren't necessary to run POI and only used to build it.

Do utility libraries need to be included in the official LICENSE file?

May we create an additional LICENSE file for development with POI.

Andi


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: License file

Nick Burch-2
On Tue, 12 Jan 2021, Andreas Beeker wrote:
> do we really need that long LICENSE file?
>
> Junit / Jacoco and few others aren't necessary to run POI and only used to
> build it.
>
> Do utility libraries need to be included in the official LICENSE file?

If we ship them we need to detail them

> May we create an additional LICENSE file for development with POI.

I seem to recall that some projects do have different license files for
their source and binary releases, to account for the different components
at build and run time

The best advice on license files at the ASF can be normally found in the
Incubator, as they're always helping new incoming projects get it right.
If you can't get a clear answer from reading the stuff at
<https://www.apache.org/dev/#licenses> and
<https://infra.apache.org/licensing-howto.html> I'd suggest ping'ing
general@incubator and asking one of the experts there for a hand!

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: License file

David Fisher-6


> On Jan 12, 2021, at 10:42 AM, Nick Burch <[hidden email]> wrote:
>
> On Tue, 12 Jan 2021, Andreas Beeker wrote:
>> do we really need that long LICENSE file?
>>
>> Junit / Jacoco and few others aren't necessary to run POI and only used to build it.
>>
>> Do utility libraries need to be included in the official LICENSE file?
>
> If we ship them we need to detail them

Exactly.

>
>> May we create an additional LICENSE file for development with POI.
>
> I seem to recall that some projects do have different license files for their source and binary releases, to account for the different components at build and run time

Yes. Since it has been sometime since we reviewed Licensing. It is important to do so.


>
> The best advice on license files at the ASF can be normally found in the Incubator, as they're always helping new incoming projects get it right. If you can't get a clear answer from reading the stuff at <https://www.apache.org/dev/#licenses> and <https://infra.apache.org/licensing-howto.html> I'd suggest ping'ing general@incubator and asking one of the experts there for a hand!

I have mentored many podlings in the Incubator.

Let’s start with an audit to generate three lists:

(1) What added code do we currently include in our codebase.
(2) What are the dependencies in our builds. What is brought in - not our build tools.
(3) What is included in our binaries. (2) and (3) should be the same, but ...

Once we have those lists we review what licenses and notices are required. We then revisit our LICENSE and NOTICE files, and we will decide if we should have a separate LICENSE and NOTICE for binary releases.

What are the current build instructions for trunk?

Regards,
Dave

>
> Nick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: License file

kiwiwings
Maybe I should have added that I reviewed and updated our LICENSE file.

Although I somehow intended to rush the release, I think I can put some cycles in to adapt our LICENSE strategy, especially as it's added to each maven artifact. Specifically I'd like to get rid of EPL 2.0 (https://www.apache.org/legal/resolved.html#weak-copyleft-licenses)

> Let’s start with an audit to generate three lists:
>
> (1) What added code do we currently include in our codebase.
> (2) What are the dependencies in our builds. What is brought in - not our build tools.
> (3) What is included in our binaries. (2) and (3) should be the same, but ...
(1) mostly Apache project code - the rest is mentioned in the NOTICE file
(2) I've separated the dependencies and so this is somewhat shown in the /lib subdirectories - /lib/ooxml-provided should be now taken as mandatory dependencies. /lib/main-test, /lib/ooxml-tests, /lib/util are our build tools.
(3) Binary doesn't contain /lib/main-test, /lib/ooxml-tests, /lib/util
Source doesn't contain any libs

I guess, I don't have to do transitive license checks here, as long as our library runs with the included dependencies.


> Once we have those lists we review what licenses and notices are required. We then revisit our LICENSE and NOTICE files, and we will decide if we should have a separate LICENSE and NOTICE for binary releases.

So I conclude, I remove the junit / jacoco / hamcrest entry.
Although I thought differently first, this makes it unnecessary to provide two LICENSE files :)
Thank you for the guideline!

> What are the current build instructions for trunk?
http://poi.apache.org/devel/index.html



Andi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]