Hi
They're legal licenses. As with anything involved with lawyers and the
legal system you really need to decide for yourself what needs to be
done (most people to be safe would contact a lawyer.)
Thanks for your feedback - however, again you are mentioning lawyers.
My understanding is that even in the USA, lawyers aren't the best people
write build scripts?
The (main) question is a technical one, not a legal one. I think we are
all clear that the general provision is to supply all code to downstream
users. If you check my original question, I'm looking for technical
suggestions to wrap portage and ensure that all patches, source files,
etc are supplied in a neat and useful form (I'm trying to avoid the big
code dump and keep things as well documented as possible)
That said I'm grateful for the clarifications on interpretations of the
GPL such as with regards to linking to other sources of code. Thanks
(Mike/Peter?)
If you're at a company releasing a product then the company most likely
has a legal dept or legal consultant. They certainly would here in the
US (I know you said you're not in the US so perhaps that's not the
case.)
In the UK you would generally be quite a large company to have an
expensive person such as a lawyer on your book full time (or have some
special reason to be needing one every day...). Generally we just rent
them as they are needed. Same also for accountants, you only need them
once a year, so rent them rather than owning them full time...
I'm not a lawyer (by a far shot) but what's the problem with creating a
script that when run pulls the upstream files from
/usr/portage/distfiles, the files and ebuilds from /usr/portage for
whatever packages you have installed on whatever you're releasing?
Please see original question. Yes, this is basically what I'm trying to do
However, it's not quite as straightforward as you state. For a build
process you would need to clear distfiles at some point, then scrape it
later in order to infer what some package had used.
However, yes, you are on the right lines for the kind of thing I'm
looking for. Note that it's the corner cases which are important, hence
the reason for my question (I really don't want to learn about how many
lawyers every US company owns...)
If I were releasing commercial software I'd want all that on a local
mirror (in source control too) so that I could recreate any released
versions.
Agreed. See - my question was sensible! I'm using git for all that
right now.
However, I think you are being a bit handwaving about the details. For
example, how would you handle this in practice, for example we need to
clean distfiles before we start building a fresh image otherwise we
don't know what is new, on the flip side we don't want to download some
existing file which is unchanged and already in source control? So a
kind of two level distfiles would be helpful...
At the moment I'm tackling it a slightly different way by grabbing $A
and the ./files dir during the build, via a bashrc script (basically as
suggested by Mike Frysinger). I think I'm coming to the conclusion that
this is the most complete solution, but obviously grabs additional
pieces that might not be used.
However, please, if anyone else has tackled this and has some notes then
please share? Some technical challenges have been exposed from some of
the answers so far.
Cheers
Ed W
