1 |
Hi |
2 |
|
3 |
> They're legal licenses. As with anything involved with lawyers and the |
4 |
> legal system you really need to decide for yourself what needs to be |
5 |
> done (most people to be safe would contact a lawyer.) |
6 |
|
7 |
Thanks for your feedback - however, again you are mentioning lawyers. |
8 |
My understanding is that even in the USA, lawyers aren't the best people |
9 |
write build scripts? |
10 |
|
11 |
The (main) question is a technical one, not a legal one. I think we are |
12 |
all clear that the general provision is to supply all code to downstream |
13 |
users. If you check my original question, I'm looking for technical |
14 |
suggestions to wrap portage and ensure that all patches, source files, |
15 |
etc are supplied in a neat and useful form (I'm trying to avoid the big |
16 |
code dump and keep things as well documented as possible) |
17 |
|
18 |
That said I'm grateful for the clarifications on interpretations of the |
19 |
GPL such as with regards to linking to other sources of code. Thanks |
20 |
(Mike/Peter?) |
21 |
|
22 |
> If you're at a company releasing a product then the company most likely |
23 |
> has a legal dept or legal consultant. They certainly would here in the |
24 |
> US (I know you said you're not in the US so perhaps that's not the |
25 |
> case.) |
26 |
|
27 |
In the UK you would generally be quite a large company to have an |
28 |
expensive person such as a lawyer on your book full time (or have some |
29 |
special reason to be needing one every day...). Generally we just rent |
30 |
them as they are needed. Same also for accountants, you only need them |
31 |
once a year, so rent them rather than owning them full time... |
32 |
|
33 |
|
34 |
> I'm not a lawyer (by a far shot) but what's the problem with creating a |
35 |
> script that when run pulls the upstream files from |
36 |
> /usr/portage/distfiles, the files and ebuilds from /usr/portage for |
37 |
> whatever packages you have installed on whatever you're releasing? |
38 |
|
39 |
Please see original question. Yes, this is basically what I'm trying to do |
40 |
|
41 |
However, it's not quite as straightforward as you state. For a build |
42 |
process you would need to clear distfiles at some point, then scrape it |
43 |
later in order to infer what some package had used. |
44 |
|
45 |
However, yes, you are on the right lines for the kind of thing I'm |
46 |
looking for. Note that it's the corner cases which are important, hence |
47 |
the reason for my question (I really don't want to learn about how many |
48 |
lawyers every US company owns...) |
49 |
|
50 |
|
51 |
> If I were releasing commercial software I'd want all that on a local |
52 |
> mirror (in source control too) so that I could recreate any released |
53 |
> versions. |
54 |
|
55 |
Agreed. See - my question was sensible! I'm using git for all that |
56 |
right now. |
57 |
|
58 |
However, I think you are being a bit handwaving about the details. For |
59 |
example, how would you handle this in practice, for example we need to |
60 |
clean distfiles before we start building a fresh image otherwise we |
61 |
don't know what is new, on the flip side we don't want to download some |
62 |
existing file which is unchanged and already in source control? So a |
63 |
kind of two level distfiles would be helpful... |
64 |
|
65 |
At the moment I'm tackling it a slightly different way by grabbing $A |
66 |
and the ./files dir during the build, via a bashrc script (basically as |
67 |
suggested by Mike Frysinger). I think I'm coming to the conclusion that |
68 |
this is the most complete solution, but obviously grabs additional |
69 |
pieces that might not be used. |
70 |
|
71 |
However, please, if anyone else has tackled this and has some notes then |
72 |
please share? Some technical challenges have been exposed from some of |
73 |
the answers so far. |
74 |
|
75 |
Cheers |
76 |
|
77 |
Ed W |