[Buildroot] Saving

[Yann E. MORIN]

Nicolas, All,

On 2023-01-12 16:55 +0000, Nicolas Carrier spake thusly:
> > On 12/01/2023 16:46, Nicolas Carrier wrote:
> > > I'm having a look at legal-info generation, the source saving step saves neither local nor
> > > override
> > > packages.
> > > 
> > > This is a problem, because it's those packages, when forked from OSS, which would require
> > > publishing
> > > the modified sources.
> > > Is there a technical / philosophical / whatever reason for no supporting them?
> >   I think the reason is purely technical: for these packages, we don't have a
> > tarball available that can be readily used. Sine we now have post_process_repack
> > in support/download/helpers, it's actually fairly easy to add this feature.
> It is not clear to me yet how I can use post_process_repack. I'll try to grok the code tomorrow and
> see if I can understand that.

So, first, I'd say that override packages really should not be accoutned
for: override is really to be used during development. If one want to
have local packages, there is the 'local' _SITE_METHOD for that. Which
brings up the second topic...

Now: IANAL, and all disclaimers that may apply, the folowing are only my
uninformed opinion, do not base legal decisions solely on those, consult
an actual lawyer, etc...

Then, for "local" packages, I would think we could assume that they are
part of the Buildroot tree (or of a br2-external tree). [0]

One could argue that, to comply with licenses like the GPL (v2 or v3,
lesser or not) of said open-source pacakages, the "scripts used to
control compilation and installation of the executable" are part of the
compliance delivery, and in that case, one may argue that Buildroot (and
the associated br2-external tree if any) would fall into that category,
and thus would have to be provided for to-the-letter and to-the-spirit
compliance eith the license of said packages.

So, the sources for those components are thus available as part of the
delivery of the Buildroot (and associated br2-external if any)
archive(s).

Ergo, there would be no reason to actually handle those local packages
in a specific way because they are already handled.

[0] if they are not in the same repository as Buildroot (or a
br2-external tree), then there is a mechanism to bring them in-tree,
like git submodules, and thus that means there is a mechanism to update
the version pointed to for those packages, which is exactly akin to
updating the _VERSION in the .mk, so there is no benefit to that (yeah,
I know "repo", but that's a whole other discussion...) So, assuming
"local" packages are in-tree is just good sense.

> >   A secondary reason is that the idea for "local" packages was that they're
> > probably proprietary. However, in reality there isn't too much correlation
> > between download method and proprietary. And we anyway have FOO_REDISTRIBUTE to
> > handle this.
> 
> Yes, we have a mix of proprietary and open source packages, for example, linuxptp or the linux
> kernel, for which we have a couple of patches we'd like to redistribute properly.

But then you have patches. Just redistribute the unpatched (original)
linuxptp and linux archives, and your Buildroot tree and br2-external if
any, and you should be all set to comply with the requirement of the
licenses of those packages...

> But even for proprietary ones, if they could be handled "properly" that is, with _REDISTRIBUTE = NO
> being honored and avoiding the generation of a warning, that would be helpful when wanting to list
> the real legal-info warnings in order to fix them.

What warning are you referring to?

I once in the past tried to push changes that to the legal-info infra,
that would also allow for a package to declare that it should simply be
ignored completely from the list of packages stored in legal-info.
However, we discussed that back in the day, and I also now totally
adhere to that conclusion: filtering things should be done with local
scripts that are run on the output of legal-info.

In any case, the output of legal-info is not guaranteed to be either
correct or exhaustive (not that we should not pursue that goal, but we
can't guarantee it), and will always require that a human look at it for
completness and correctness before it can be used as a means of
compliance.

Regards,
Yann E. MORIN.

> >   Regards,
> >   Arnout
> > 
> 
> Thank you very much for your answer!
> 
> > 
> > > If none, I'd be willing to develop support for that, if anyone has pointers as how to proceed /
> > > where to patch / mistakes to avoid, don't hesitate to share :)
> > > 
> > > FTR, I'm using a (lightweight) fork of 2022.02.
> > > 
> > > Thank you by advance!
> > > _______________________________________________
> > > buildroot mailing list
> > > buildroot at buildroot.org
> > > https://lists.buildroot.org/mailman/listinfo/buildroot
> 
> _______________________________________________
> buildroot mailing list
> buildroot at buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'