You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Henri Yandell <he...@yandell.org> on 2013/05/01 03:13:15 UTC
Re: What constitutes a source release?
On Tue, Apr 30, 2013 at 7:22 AM, Kevan Miller <ke...@gmail.com>wrote:
>
> On Apr 30, 2013, at 9:59 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> > Our license[1] contains the following definitions:
> >
> > "Source" form shall mean the preferred form for making modifications,
> > including but not limited to software source code, documentation
> > source, and configuration files.
> >
> > "Object" form shall mean any form resulting from mechanical
> > transformation or translation of a Source form, including but not
> > limited to compiled object code, generated documentation, and
> > conversions to other media types.
>
> :) I guess our *license* is a pretty good starting point...
>
Though if we're going to take the license as gospel on the subject, I'd
point out that 'media types' suggests your media files are Objects and not
Source. Still, I don't think there's any value in restricting a
source-distribution to not have media files, beyond the reality that
whatever media files we have are probably hard to recreate and the
originals may not even be in our svn.
>
> >
> >> FYI, found the following discussion in Incubator --
> http://s.apache.org/rk5
>
I don't see that the quote from the charter in Roy's old email limits us as
much as he suggests. Community/Industry use of the phrase Open Source
doesn't restrict it to only applying to source, and it covers what we
create/maintain, not what we include. It would be unhealthy for us though
to have a project releasing its core creativity in only binary form, so
there's a lot of importance to the source-only point.
I think there's a decision of hair splitting to decide on (to refer to your
email that I snipped :) ).
If source in tarballs is a critical bar, then we need to decide what
binaries are okay (media etc) and which are not. We also need to decide how
magic distribution (pom.xml and other behind the scene network installs)
can be fine.
Alternatively, the bar is somehow different. To me it feels that the bar is
less that the tar.gz must contain source and more that source must be
obtainable. The Category B text hits that point, though for a different
context than src tarballs. If including a Category B text, you must point
to where the source is installed. So when dependning on JUnit, projects
should be pointing to that. The same is true of one Apache project
depending on another. It should be fine for one project to include another
project in binary form, providing its source is available.
Something to watch for in that second alternative is that we think through
the use of the NOTICE file. Should, as an easy example, Commons Lang's
NOTICE file contain a mention that it depends on JUnit, licensed under the
CPL 1.0? It's definitely true for the source tar.gz, but for a user who
takes the Lang jar it's not true because the Lang jar is independent of the
JUnit use.
Hen
Re: Source form Re: What constitutes a source release?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Sam Ruby wrote on Thu, May 02, 2013 at 16:34:53 -0400:
> On 05/02/2013 03:54 PM, Daniel Shahaf wrote:
>> Sam Ruby wrote on Thu, May 02, 2013 at 15:24:29 -0400:
>>> We may very well have to look at each specific font to determine what
>>> the "preferred form for making modifications" would be.
>>
>> Why are you saying "the" preferred form? Probably because ALv2 says so,
>> but wouldn't it be better to s/the preferred/a preferred/ in the
>> definition below?
>>
>> "Source" form shall mean the preferred form for making modifications,
>> including but not limited to software source code, documentation
>> source, and configuration files.
>
> I suspect that would be considered too weak, ambiguous, and subject to
> mischief. If this ever should become and issue, I would rather push
> back on the relevant PMC and task them with coming to consensus and
> unambiguously documenting what they collectively consider the preferred
Thanks for the reply. I suppose there's a way to backflip out of this
(by adding language that clarifies that the maximum implied in "the
(most) preferred" may not be unique), if we really wanted to.
Is there a place we collect issues to review at ALv3 time at? (like
Subversion's issue tracker has "milestone=2.0" and "milestone=blue-sky")
> form to be. And furthermore, give them the responsibility to provide
> timely updates should this preference ever change.
>
> Should the result seem contentious or subject to second guessing, I
> would also involve counsel at that time.
>
>> Daniel
>> (that's something we could do if/when ALv2.1 happens)
>
> - Sam Ruby
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Source form Re: What constitutes a source release?
Posted by Benson Margulies <bi...@gmail.com>.
Teeing off on one of Sam's remarks, I wish that someone would replace this
thread with a very specific thread that proposes a very specific policy for
a very specific category of fonts, giving a practical justification (here's
why we want one of these in the source tree), and an argument about the
'verifiability risk' (can voters reasonably tell what they are voting on).
On the other hand, I'd note that nothing stops someone from pushing a cat B
font to a repo manager like Maven Central, and having build automation pull
it down. This might obviate the discussion.
RE: Source form Re: What constitutes a source release?
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Regardless of the philosophical musings here about Apache policy (which have long confused me!), copyright law doesn't distinguish between source and object forms unless the license distinguishes. [1] And even then, it should make no difference to the way that software is used or distributed under an open source license. Consider, for most legal purposes, that source and object forms are identical in purpose and effect.
If you need "source code" to understand the software, demand it from the licensor as the FOSS license provides. If you need to distribute "object code" for convenience, do so as the FOSS license provides. Otherwise, who gives a damn whether it is source or object?
/Larry
[1] Copyright law only cares about that distinction when software is protected under the DMCA by licensors distributing binary code as a confidentiality measure. But this has nothing to do with FOSS software.
-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Friday, May 03, 2013 5:22 PM
To: legal-discuss@apache.org
Subject: RE: Source form Re: What constitutes a source release?
The determination by the court is what brings compiled fonts (the binary form) under copyright law by ruling that they are software. That means open-source licenses apply to them. (Trademarks and design patents are also applicable, but not the subject here.)
The licenses all define one way or another what of computer software is source code and what isn't.
@Henri, I don't understand the last sentence. The collision with ASF policy is whether or not Category B fonts are source code or not, and what that means with respect to having them in the SVN and in source tarballs for releases. I assume you don't want them to be source code because Category B source code is definitely forbidden. Therefore ... .
- Dennis
-----Original Message-----
From: hyandell@gmail.com [mailto:hyandell@gmail.com] On Behalf Of Henri Yandell
Sent: Friday, May 03, 2013 16:34
To: ASF Legal Discuss; Dennis Hamilton
Subject: Re: Source form Re: What constitutes a source release?
It's definitely an interesting bit of info, though I think the definition of software here isn't the same as the law courts (ie: the definition on this thread is for the purpose of our policy rather than our license).
It feels very odd for us to consider fonts as software given our current projects, but if we had a project that contained Apache authored fonts (of which there are a bunch, Apache is, gut guessing, the 4th most common font license) then it would suddenly make a lot more sense.
I don't see us ruling out Apache from having font software so fonts are out.
Hen
On Fri, May 3, 2013 at 8:52 AM, Dennis E. Hamilton <de...@acm.org> wrote:
The font (and the executable) case nagged at me, so I researched the topic a little more.
There is an useful account of the situation with fonts (in the US, specifically):
<http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=UNESCO_Font_Lic>.
For fonts having open-source licenses, copyright applies to them as software. Courts have upheld that font files are software. (Attaching an open-source license to those is perhaps more in the manner of an EULA, just as for binary executables.)
In my reading, that does not make either binary executables or font files into source code.
- Dennis
[ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: Source form Re: What constitutes a source release?
Posted by "Dennis E. Hamilton" <de...@acm.org>.
The determination by the court is what brings compiled fonts (the binary form) under copyright law by ruling that they are software. That means open-source licenses apply to them. (Trademarks and design patents are also applicable, but not the subject here.)
The licenses all define one way or another what of computer software is source code and what isn't.
@Henri, I don't understand the last sentence. The collision with ASF policy is whether or not Category B fonts are source code or not, and what that means with respect to having them in the SVN and in source tarballs for releases. I assume you don't want them to be source code because Category B source code is definitely forbidden. Therefore ... .
- Dennis
-----Original Message-----
From: hyandell@gmail.com [mailto:hyandell@gmail.com] On Behalf Of Henri Yandell
Sent: Friday, May 03, 2013 16:34
To: ASF Legal Discuss; Dennis Hamilton
Subject: Re: Source form Re: What constitutes a source release?
It's definitely an interesting bit of info, though I think the definition of software here isn't the same as the law courts (ie: the definition on this thread is for the purpose of our policy rather than our license).
It feels very odd for us to consider fonts as software given our current projects, but if we had a project that contained Apache authored fonts (of which there are a bunch, Apache is, gut guessing, the 4th most common font license) then it would suddenly make a lot more sense.
I don't see us ruling out Apache from having font software so fonts are out.
Hen
On Fri, May 3, 2013 at 8:52 AM, Dennis E. Hamilton <de...@acm.org> wrote:
The font (and the executable) case nagged at me, so I researched the topic a little more.
There is an useful account of the situation with fonts (in the US, specifically):
<http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=UNESCO_Font_Lic>.
For fonts having open-source licenses, copyright applies to them as software. Courts have upheld that font files are software. (Attaching an open-source license to those is perhaps more in the manner of an EULA, just as for binary executables.)
In my reading, that does not make either binary executables or font files into source code.
- Dennis
[ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Source form Re: What constitutes a source release?
Posted by Henri Yandell <he...@yandell.org>.
It's definitely an interesting bit of info, though I think the definition
of software here isn't the same as the law courts (ie: the definition on
this thread is for the purpose of our policy rather than our license).
It feels very odd for us to consider fonts as software given our current
projects, but if we had a project that contained Apache authored fonts (of
which there are a bunch, Apache is, gut guessing, the 4th most common font
license) then it would suddenly make a lot more sense.
I don't see us ruling out Apache from having font software so fonts are out.
Hen
On Fri, May 3, 2013 at 8:52 AM, Dennis E. Hamilton
<de...@acm.org>wrote:
> The font (and the executable) case nagged at me, so I researched the topic
> a little more.
>
> There is an useful account of the situation with fonts (in the US,
> specifically):
> <
> http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=UNESCO_Font_Lic
> >.
>
> For fonts having open-source licenses, copyright applies to them as
> software. Courts have upheld that font files are software. (Attaching an
> open-source license to those is perhaps more in the manner of an EULA, just
> as for binary executables.)
>
> In my reading, that does not make either binary executables or font files
> into source code.
>
> - Dennis
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Friday, May 03, 2013 08:25
> To: legal-discuss@apache.org; 'Santiago Gala'
> Subject: RE: Source form Re: What constitutes a source release?
>
> The GPL goes on and on about this, as does discussion around the Open
> Source Definition. Also, the license will apply to copyrightable subject
> matter, and that is a consideration too.
>
> Basically, the use of preferred form is an instruction to the contributor,
> that the source code be the form that the contributor uses as the form at
> which the contribution is *expressed* and maintained.
>
> The contributor is not supposed to add impediments (including any form of
> obfuscation or use of an intermediate form that is not what the contributor
> uses to maintain the contribution -- now what isn't the original work of
> authorship).
>
> There are cases where the form licensed is mechanically produced and
> downstream contributors of derivatives end up having to work with that form
> since an upstream contributor did not satisfy the source-contribution
> condition. (HTML pages are an example, the text-format tables used in
> spelling checkers is another. In the first case, an HTML page might be
> easily maintained independently, in the second case, only painfully.
>
> There is a problem with assumed tool chains, and tool-specific artifacts
> (e.g., Visual C++ project files, and make files that depend on unique
> features of a particular processor), but that seems to be an issue
> independent of this particular one.
>
> Now that there are compilers for custom languages that now emit JavaScript
> (or Java or C [think YACC/LEX output], ...) it is sometimes desirable to
> provide both forms in a contribution, simply because the contributor
> preferred form might not be usable by downstream recipients. But what the
> preferred source of the contributor is, and what constitutes the licensable
> work under copyright, in fact, does not change.
>
> - Dennis
>
> PS: What I just blurted out does not seem to deal with the case of
> open-source font files very well. Part of it has to do with exactly what
> is the copyrighted work of authorship in the case of fonts, and how does
> that extend to binary forms for digital rendition of those font shapes.
> When is infringement, absent the license? I imagine this has been dealt
> with somewhere, just as it has for binaries of executables (although that
> might be an exception written into the copyright law in the case of the US).
>
> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Sent: Friday, May 03, 2013 05:13
> To: Santiago Gala
> Cc: legal-discuss
> Subject: Re: Source form Re: What constitutes a source release?
>
> Santiago Gala wrote on Fri, May 03, 2013 at 14:09:35 +0200:
> > On Thu, May 2, 2013 at 9:54 PM, Daniel Shahaf <d.s@daniel.shahaf.name
> >wrote:
> >
> > > Sam Ruby wrote on Thu, May 02, 2013 at 15:24:29 -0400:
> > > > We may very well have to look at each specific font to determine what
> > > > the "preferred form for making modifications" would be.
> > >
> > > Why are you saying "the" preferred form? Probably because ALv2 says
> so,
> > > but wouldn't it be better to s/the preferred/a preferred/ in the
> > > definition below?
> > >
> >
> > I'm not a native English speaker, but "a preferred form" does not sound
> > precise. I guess "a suitable form" (versus "the preferred form amongst
> the
> > suitable ones") would be more precise.
> >
>
> Perhaps it should say "A most-preferred form".
>
> *shrug* I guess that's not really important, given that we don't appear
> to be collecting ALv3 issues anywhere.
>
> Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
RE: Source form Re: What constitutes a source release?
Posted by "Dennis E. Hamilton" <de...@acm.org>.
The font (and the executable) case nagged at me, so I researched the topic a little more.
There is an useful account of the situation with fonts (in the US, specifically):
<http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=UNESCO_Font_Lic>.
For fonts having open-source licenses, copyright applies to them as software. Courts have upheld that font files are software. (Attaching an open-source license to those is perhaps more in the manner of an EULA, just as for binary executables.)
In my reading, that does not make either binary executables or font files into source code.
- Dennis
-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Friday, May 03, 2013 08:25
To: legal-discuss@apache.org; 'Santiago Gala'
Subject: RE: Source form Re: What constitutes a source release?
The GPL goes on and on about this, as does discussion around the Open Source Definition. Also, the license will apply to copyrightable subject matter, and that is a consideration too.
Basically, the use of preferred form is an instruction to the contributor, that the source code be the form that the contributor uses as the form at which the contribution is *expressed* and maintained.
The contributor is not supposed to add impediments (including any form of obfuscation or use of an intermediate form that is not what the contributor uses to maintain the contribution -- now what isn't the original work of authorship).
There are cases where the form licensed is mechanically produced and downstream contributors of derivatives end up having to work with that form since an upstream contributor did not satisfy the source-contribution condition. (HTML pages are an example, the text-format tables used in spelling checkers is another. In the first case, an HTML page might be easily maintained independently, in the second case, only painfully.
There is a problem with assumed tool chains, and tool-specific artifacts (e.g., Visual C++ project files, and make files that depend on unique features of a particular processor), but that seems to be an issue independent of this particular one.
Now that there are compilers for custom languages that now emit JavaScript (or Java or C [think YACC/LEX output], ...) it is sometimes desirable to provide both forms in a contribution, simply because the contributor preferred form might not be usable by downstream recipients. But what the preferred source of the contributor is, and what constitutes the licensable work under copyright, in fact, does not change.
- Dennis
PS: What I just blurted out does not seem to deal with the case of open-source font files very well. Part of it has to do with exactly what is the copyrighted work of authorship in the case of fonts, and how does that extend to binary forms for digital rendition of those font shapes. When is infringement, absent the license? I imagine this has been dealt with somewhere, just as it has for binaries of executables (although that might be an exception written into the copyright law in the case of the US).
-----Original Message-----
From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
Sent: Friday, May 03, 2013 05:13
To: Santiago Gala
Cc: legal-discuss
Subject: Re: Source form Re: What constitutes a source release?
Santiago Gala wrote on Fri, May 03, 2013 at 14:09:35 +0200:
> On Thu, May 2, 2013 at 9:54 PM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
>
> > Sam Ruby wrote on Thu, May 02, 2013 at 15:24:29 -0400:
> > > We may very well have to look at each specific font to determine what
> > > the "preferred form for making modifications" would be.
> >
> > Why are you saying "the" preferred form? Probably because ALv2 says so,
> > but wouldn't it be better to s/the preferred/a preferred/ in the
> > definition below?
> >
>
> I'm not a native English speaker, but "a preferred form" does not sound
> precise. I guess "a suitable form" (versus "the preferred form amongst the
> suitable ones") would be more precise.
>
Perhaps it should say "A most-preferred form".
*shrug* I guess that's not really important, given that we don't appear
to be collecting ALv3 issues anywhere.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: Source form Re: What constitutes a source release?
Posted by "Dennis E. Hamilton" <de...@acm.org>.
The GPL goes on and on about this, as does discussion around the Open Source Definition. Also, the license will apply to copyrightable subject matter, and that is a consideration too.
Basically, the use of preferred form is an instruction to the contributor, that the source code be the form that the contributor uses as the form at which the contribution is *expressed* and maintained.
The contributor is not supposed to add impediments (including any form of obfuscation or use of an intermediate form that is not what the contributor uses to maintain the contribution -- now what isn't the original work of authorship).
There are cases where the form licensed is mechanically produced and downstream contributors of derivatives end up having to work with that form since an upstream contributor did not satisfy the source-contribution condition. (HTML pages are an example, the text-format tables used in spelling checkers is another. In the first case, an HTML page might be easily maintained independently, in the second case, only painfully.
There is a problem with assumed tool chains, and tool-specific artifacts (e.g., Visual C++ project files, and make files that depend on unique features of a particular processor), but that seems to be an issue independent of this particular one.
Now that there are compilers for custom languages that now emit JavaScript (or Java or C [think YACC/LEX output], ...) it is sometimes desirable to provide both forms in a contribution, simply because the contributor preferred form might not be usable by downstream recipients. But what the preferred source of the contributor is, and what constitutes the licensable work under copyright, in fact, does not change.
- Dennis
PS: What I just blurted out does not seem to deal with the case of open-source font files very well. Part of it has to do with exactly what is the copyrighted work of authorship in the case of fonts, and how does that extend to binary forms for digital rendition of those font shapes. When is infringement, absent the license? I imagine this has been dealt with somewhere, just as it has for binaries of executables (although that might be an exception written into the copyright law in the case of the US).
-----Original Message-----
From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
Sent: Friday, May 03, 2013 05:13
To: Santiago Gala
Cc: legal-discuss
Subject: Re: Source form Re: What constitutes a source release?
Santiago Gala wrote on Fri, May 03, 2013 at 14:09:35 +0200:
> On Thu, May 2, 2013 at 9:54 PM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
>
> > Sam Ruby wrote on Thu, May 02, 2013 at 15:24:29 -0400:
> > > We may very well have to look at each specific font to determine what
> > > the "preferred form for making modifications" would be.
> >
> > Why are you saying "the" preferred form? Probably because ALv2 says so,
> > but wouldn't it be better to s/the preferred/a preferred/ in the
> > definition below?
> >
>
> I'm not a native English speaker, but "a preferred form" does not sound
> precise. I guess "a suitable form" (versus "the preferred form amongst the
> suitable ones") would be more precise.
>
Perhaps it should say "A most-preferred form".
*shrug* I guess that's not really important, given that we don't appear
to be collecting ALv3 issues anywhere.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Source form Re: What constitutes a source release?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Santiago Gala wrote on Fri, May 03, 2013 at 14:09:35 +0200:
> On Thu, May 2, 2013 at 9:54 PM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
>
> > Sam Ruby wrote on Thu, May 02, 2013 at 15:24:29 -0400:
> > > We may very well have to look at each specific font to determine what
> > > the "preferred form for making modifications" would be.
> >
> > Why are you saying "the" preferred form? Probably because ALv2 says so,
> > but wouldn't it be better to s/the preferred/a preferred/ in the
> > definition below?
> >
>
> I'm not a native English speaker, but "a preferred form" does not sound
> precise. I guess "a suitable form" (versus "the preferred form amongst the
> suitable ones") would be more precise.
>
Perhaps it should say "A most-preferred form".
*shrug* I guess that's not really important, given that we don't appear
to be collecting ALv3 issues anywhere.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Source form Re: What constitutes a source release?
Posted by Sam Ruby <ru...@intertwingly.net>.
On 05/02/2013 03:54 PM, Daniel Shahaf wrote:
> Sam Ruby wrote on Thu, May 02, 2013 at 15:24:29 -0400:
>> We may very well have to look at each specific font to determine what
>> the "preferred form for making modifications" would be.
>
> Why are you saying "the" preferred form? Probably because ALv2 says so,
> but wouldn't it be better to s/the preferred/a preferred/ in the
> definition below?
>
> "Source" form shall mean the preferred form for making modifications,
> including but not limited to software source code, documentation
> source, and configuration files.
I suspect that would be considered too weak, ambiguous, and subject to
mischief. If this ever should become and issue, I would rather push
back on the relevant PMC and task them with coming to consensus and
unambiguously documenting what they collectively consider the preferred
form to be. And furthermore, give them the responsibility to provide
timely updates should this preference ever change.
Should the result seem contentious or subject to second guessing, I
would also involve counsel at that time.
> Daniel
> (that's something we could do if/when ALv2.1 happens)
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Source form Re: What constitutes a source release?
Posted by Santiago Gala <sa...@gmail.com>.
On Thu, May 2, 2013 at 9:54 PM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
> Sam Ruby wrote on Thu, May 02, 2013 at 15:24:29 -0400:
> > We may very well have to look at each specific font to determine what
> > the "preferred form for making modifications" would be.
>
> Why are you saying "the" preferred form? Probably because ALv2 says so,
> but wouldn't it be better to s/the preferred/a preferred/ in the
> definition below?
>
I'm not a native English speaker, but "a preferred form" does not sound
precise. I guess "a suitable form" (versus "the preferred form amongst the
suitable ones") would be more precise.
People could claim that, for instance, non-obfuscated classfile format of
.java files is "a suitable form for making modifications". It is indeed,
for instance, for BCEL and other similar instrumentation tools... Just as
an example of areas where precision can be important. Agreed that for font
files or graphics this concept is not so cleancut, but Sam already outlines
a clear path to solve any such ambiguity...
Regards
Santiago
>
> "Source" form shall mean the preferred form for making modifications,
> including but not limited to software source code, documentation
> source, and configuration files.
>
> Daniel
> (that's something we could do if/when ALv2.1 happens)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Source form Re: What constitutes a source release?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Sam Ruby wrote on Thu, May 02, 2013 at 15:24:29 -0400:
> We may very well have to look at each specific font to determine what
> the "preferred form for making modifications" would be.
Why are you saying "the" preferred form? Probably because ALv2 says so,
but wouldn't it be better to s/the preferred/a preferred/ in the
definition below?
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
Daniel
(that's something we could do if/when ALv2.1 happens)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: What constitutes a source release?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Sam Ruby wrote on Thu, May 02, 2013 at 17:23:11 -0400:
> Taken all together, the original question[2] can now be re-posed thus:
>
> Should ASF policy allow object form Category B artefacts to be
> checked into SVN?
>
> Mark Thomas[3] gave his input yesterday on this topic.
>
> We can chose to collectively accept that input, post it to our
> website, and make it official policy. Or people can chose to
> challenge that input. Or we can seek narrowly crafted exceptions.
It might be wise for people who pursue those options to have infra@ on
the distribution list. (For example, the policy might end up as
"We are allowed by law and by Legal PMC's policy to use svn.a.o as
a maven repository, but for operational reasons we don't do that" ---
aka, "legal says yes, infra says no, policy is no".)
>
> It is not my intent to state that any of those three are the preferred
> approach. I'm merely trying to focus the discussion on the remaining
> issue.
>
> > --kevan
>
> - Sam Ruby
>
> [2] https://issues.apache.org/jira/browse/LEGAL-163
> [3] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201305.mbox/%3C5180D39C.6020401%40apache.org%3E
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: What constitutes a source release?
Posted by Henri Yandell <he...@yandell.org>.
On Fri, May 3, 2013 at 6:30 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> On Fri, May 3, 2013 at 12:53 AM, Henri Yandell <he...@yandell.org> wrote:
> >
> >> On May 2, 2013, at 5:23 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> >> >
> >> > Taken all together, the original question[2] can now be re-posed thus:
> >> >
> >> > Should ASF policy allow object form Category B artefacts to be
> >> > checked into SVN?
> >
> > Thanks for the focus Sam, I think there is a subset of that question
> before
> > us.
> >
> > We've identified that there are three types of file:
> >
> > 1) Source form of software.
> > 2) Binary form of software, created from Source.
> > 3) Other form of file not classed as the above.
>
> I still prefer the terms 'source' and 'object'. It is not clear to me
> that there needs to be a third category.
>
> > Images comfortably fall into #3. Fonts are an open question as to whether
> > they are #2 or #3.
>
> Um, pretty much all of the images on my weblog are in source form. :-)
>
> Depending on how they are produced and maintained, fonts could be
> either source or object. And based on the research that Kevan did,
> the specific fonts in question are clearly object.
>
>
Fair enough, I'm assuming a more archaic world in which all logos came from
EPS or Illustrator files; or PSDs. Using SVG everywhere does solve things.
I don't understand the rationale for being very staunch on source-only yet
allowing scripts that pull binary files from other locations, but no one
else seems concerned by it, so I'll stop being a pain in the butt. :)
Hen
Re: What constitutes a source release?
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, May 3, 2013 at 12:53 AM, Henri Yandell <he...@yandell.org> wrote:
>
>> On May 2, 2013, at 5:23 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>> >
>> > Taken all together, the original question[2] can now be re-posed thus:
>> >
>> > Should ASF policy allow object form Category B artefacts to be
>> > checked into SVN?
>
> Thanks for the focus Sam, I think there is a subset of that question before
> us.
>
> We've identified that there are three types of file:
>
> 1) Source form of software.
> 2) Binary form of software, created from Source.
> 3) Other form of file not classed as the above.
I still prefer the terms 'source' and 'object'. It is not clear to me
that there needs to be a third category.
> Images comfortably fall into #3. Fonts are an open question as to whether
> they are #2 or #3.
Um, pretty much all of the images on my weblog are in source form. :-)
Depending on how they are produced and maintained, fonts could be
either source or object. And based on the research that Kevan did,
the specific fonts in question are clearly object.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: What constitutes a source release?
Posted by Henri Yandell <he...@yandell.org>.
On Thu, May 2, 2013 at 9:09 PM, Kevan Miller <ke...@gmail.com> wrote:
>
> On May 2, 2013, at 5:23 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> > On Thu, May 2, 2013 at 4:00 PM, Kevan Miller <ke...@gmail.com>
> wrote:
> >>
> >> On May 2, 2013, at 3:24 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> >>
> >>> We may very well have to look at each specific font to determine what
> >>> the "preferred form for making modifications" would be.
> >>
> >> FYI, I downloaded the Ubuntu font source
> (ubuntu-font-family-sources_0.80.orig.tar.gz) from
> http://font.ubuntu.com/resources/
> >>
> >> The build process is described in the file sources/SOURCES.txt. The
> "build" process requires tools such as:
> >>
> >> http://www.microsoft.com/typography/tools/vtt.aspx
> >> http://www.microsoft.com/typography/tools/tools.aspx
> >> http://www.fontlab.com/font-editor/fontlab-studio/
> >>
> >> As far as I can tell (and this is all new to me), the files that are
> used in building the final Ubuntu fonts are not contained within the binary
> distribution of the fonts. The binary distribution does not contain the
> "source" (e.g. *.vfb, *-hinting.ttf, and a .cfg file) which is used for
> producing the ubuntu fonts. AFAIK, this doesn't mean you couldn't use the
> ubuntu font family to produce a new font. But does not appear to be the
> preferred form…
> >>
> >> My personal opinion, the exposure seems minimal, here. And I tend to
> think of these files like I might treat other media files (e.g. a .gif file
> produced by a paint application).
> >
> > First, a huge thanks for doing the analysis! It truly is helpful.
> >
> > However, I do want to point out that "exposure" is probably not the
> > right focus here. The license gives permission to distribute these
> > fonts, subject to a number of conditions. I'm satisfied that we both
> > intend to and are capable of meeting those conditions. Assuming that
> > we do so, the exposure is indeed minimal.
>
> Let me clarify my use of 'exposure'. It was from the perspective of the
> "exposed surface area" comment contained within [1] (I'm reusing your
> footnotes).
>
> I would agree that this is probably a moot point… But this was the general
> thread I was tugging at:
>
> We do have an exception for Category B source, if that source is unlikely
> to change (e.g. standards-based .dtd's).
>
> And the source/object characterization of the Ubuntu fonts is hard for me
> to distinguish. So, I could imagine someone trying to make a case to allow
> the fonts...
>
> However, the source/binary distinction does exist. At least for Ubuntu and
> I'm sure others skilled in the art… And I see no reason why we should be
> re-defining their distinction...
>
> >
> > The concern isn't one of exposure, but rather one of ASF policy. I've
> > already updated the website[1] to indicate that we have found
> > consensus on this license being considered Category B, and that page
> > indicates what ASF policy allows PMCs to do with artefacts made
> > available under such a license.
> >
> > Taken all together, the original question[2] can now be re-posed thus:
> >
> > Should ASF policy allow object form Category B artefacts to be
> > checked into SVN?
>
Thanks for the focus Sam, I think there is a subset of that question before
us.
We've identified that there are three types of file:
1) Source form of software.
2) Binary form of software, created from Source.
3) Other form of file not classed as the above.
Images comfortably fall into #3. Fonts are an open question as to whether
they are #2 or #3.
Per Mark/Kevan below:
Source distributions and SVN contain Source (#1). They don't contain Binary
(#2). I'm going to assume that they may contain 'Other' (#3) given said
files exist in httpd-<version>.tar.gz.
I agree with that.
So I think the questions are:
A) Are Fonts 'Other' or 'Binary'?
B) Should ASF policy allow Category B 'Other' files into source
distributions and SVN?
I'm not font expert enough for question A.
I think B is very open ended. The topics on machine learning models and
their data would show up here as I don't think they would be 'Source', but
so would including the images that javadoc produces or some CC-BY licensed
picture. B doesn't need answering yet if the answer to A is 'Binary'.
Hen
(the below kept as I refer to it)
>
> > Mark Thomas[3] gave his input yesterday on this topic.
> >
> > We can chose to collectively accept that input, post it to our
> > website, and make it official policy. Or people can chose to
> > challenge that input. Or we can seek narrowly crafted exceptions.
>
> Well, I don't think infrastructure concerns about infrastructure resource
> constraints is a good reason for establishing a policy. So, I may not
> necessarily agree with the reasoning. However...
>
> IMO, our projects release source. So, our projects should not maintain
> object/binary artifacts in their svn release tree, regardless of license
> (category a or b).
>
Re: What constitutes a source release?
Posted by Kevan Miller <ke...@gmail.com>.
On May 2, 2013, at 5:23 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> On Thu, May 2, 2013 at 4:00 PM, Kevan Miller <ke...@gmail.com> wrote:
>>
>> On May 2, 2013, at 3:24 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>
>>> We may very well have to look at each specific font to determine what
>>> the "preferred form for making modifications" would be.
>>
>> FYI, I downloaded the Ubuntu font source (ubuntu-font-family-sources_0.80.orig.tar.gz) from http://font.ubuntu.com/resources/
>>
>> The build process is described in the file sources/SOURCES.txt. The "build" process requires tools such as:
>>
>> http://www.microsoft.com/typography/tools/vtt.aspx
>> http://www.microsoft.com/typography/tools/tools.aspx
>> http://www.fontlab.com/font-editor/fontlab-studio/
>>
>> As far as I can tell (and this is all new to me), the files that are used in building the final Ubuntu fonts are not contained within the binary distribution of the fonts. The binary distribution does not contain the "source" (e.g. *.vfb, *-hinting.ttf, and a .cfg file) which is used for producing the ubuntu fonts. AFAIK, this doesn't mean you couldn't use the ubuntu font family to produce a new font. But does not appear to be the preferred form…
>>
>> My personal opinion, the exposure seems minimal, here. And I tend to think of these files like I might treat other media files (e.g. a .gif file produced by a paint application).
>
> First, a huge thanks for doing the analysis! It truly is helpful.
>
> However, I do want to point out that "exposure" is probably not the
> right focus here. The license gives permission to distribute these
> fonts, subject to a number of conditions. I'm satisfied that we both
> intend to and are capable of meeting those conditions. Assuming that
> we do so, the exposure is indeed minimal.
Let me clarify my use of 'exposure'. It was from the perspective of the "exposed surface area" comment contained within [1] (I'm reusing your footnotes).
I would agree that this is probably a moot point… But this was the general thread I was tugging at:
We do have an exception for Category B source, if that source is unlikely to change (e.g. standards-based .dtd's).
And the source/object characterization of the Ubuntu fonts is hard for me to distinguish. So, I could imagine someone trying to make a case to allow the fonts...
However, the source/binary distinction does exist. At least for Ubuntu and I'm sure others skilled in the art… And I see no reason why we should be re-defining their distinction...
>
> The concern isn't one of exposure, but rather one of ASF policy. I've
> already updated the website[1] to indicate that we have found
> consensus on this license being considered Category B, and that page
> indicates what ASF policy allows PMCs to do with artefacts made
> available under such a license.
>
> Taken all together, the original question[2] can now be re-posed thus:
>
> Should ASF policy allow object form Category B artefacts to be
> checked into SVN?
>
> Mark Thomas[3] gave his input yesterday on this topic.
>
> We can chose to collectively accept that input, post it to our
> website, and make it official policy. Or people can chose to
> challenge that input. Or we can seek narrowly crafted exceptions.
Well, I don't think infrastructure concerns about infrastructure resource constraints is a good reason for establishing a policy. So, I may not necessarily agree with the reasoning. However...
IMO, our projects release source. So, our projects should not maintain object/binary artifacts in their svn release tree, regardless of license (category a or b).
>
> It is not my intent to state that any of those three are the preferred
> approach. I'm merely trying to focus the discussion on the remaining
> issue.
Understood. And appreciate the focus, as always... I've drawn my line in the sand… See what others have to say.
>
>> --kevan
>
> - Sam Ruby
>
> [1] http://www.apache.org/legal/resolved.html#category-b
> [2] https://issues.apache.org/jira/browse/LEGAL-163
> [3] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201305.mbox/%3C5180D39C.6020401%40apache.org%3E
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: What constitutes a source release?
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, May 2, 2013 at 4:00 PM, Kevan Miller <ke...@gmail.com> wrote:
>
> On May 2, 2013, at 3:24 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>
>> We may very well have to look at each specific font to determine what
>> the "preferred form for making modifications" would be.
>
> FYI, I downloaded the Ubuntu font source (ubuntu-font-family-sources_0.80.orig.tar.gz) from http://font.ubuntu.com/resources/
>
> The build process is described in the file sources/SOURCES.txt. The "build" process requires tools such as:
>
> http://www.microsoft.com/typography/tools/vtt.aspx
> http://www.microsoft.com/typography/tools/tools.aspx
> http://www.fontlab.com/font-editor/fontlab-studio/
>
> As far as I can tell (and this is all new to me), the files that are used in building the final Ubuntu fonts are not contained within the binary distribution of the fonts. The binary distribution does not contain the "source" (e.g. *.vfb, *-hinting.ttf, and a .cfg file) which is used for producing the ubuntu fonts. AFAIK, this doesn't mean you couldn't use the ubuntu font family to produce a new font. But does not appear to be the preferred form…
>
> My personal opinion, the exposure seems minimal, here. And I tend to think of these files like I might treat other media files (e.g. a .gif file produced by a paint application).
First, a huge thanks for doing the analysis! It truly is helpful.
However, I do want to point out that "exposure" is probably not the
right focus here. The license gives permission to distribute these
fonts, subject to a number of conditions. I'm satisfied that we both
intend to and are capable of meeting those conditions. Assuming that
we do so, the exposure is indeed minimal.
The concern isn't one of exposure, but rather one of ASF policy. I've
already updated the website[1] to indicate that we have found
consensus on this license being considered Category B, and that page
indicates what ASF policy allows PMCs to do with artefacts made
available under such a license.
Taken all together, the original question[2] can now be re-posed thus:
Should ASF policy allow object form Category B artefacts to be
checked into SVN?
Mark Thomas[3] gave his input yesterday on this topic.
We can chose to collectively accept that input, post it to our
website, and make it official policy. Or people can chose to
challenge that input. Or we can seek narrowly crafted exceptions.
It is not my intent to state that any of those three are the preferred
approach. I'm merely trying to focus the discussion on the remaining
issue.
> --kevan
- Sam Ruby
[1] http://www.apache.org/legal/resolved.html#category-b
[2] https://issues.apache.org/jira/browse/LEGAL-163
[3] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201305.mbox/%3C5180D39C.6020401%40apache.org%3E
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: What constitutes a source release?
Posted by Kevan Miller <ke...@gmail.com>.
On May 2, 2013, at 3:24 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> We may very well have to look at each specific font to determine what
> the "preferred form for making modifications" would be.
FYI, I downloaded the Ubuntu font source (ubuntu-font-family-sources_0.80.orig.tar.gz) from http://font.ubuntu.com/resources/
The build process is described in the file sources/SOURCES.txt. The "build" process requires tools such as:
http://www.microsoft.com/typography/tools/vtt.aspx
http://www.microsoft.com/typography/tools/tools.aspx
http://www.fontlab.com/font-editor/fontlab-studio/
As far as I can tell (and this is all new to me), the files that are used in building the final Ubuntu fonts are not contained within the binary distribution of the fonts. The binary distribution does not contain the "source" (e.g. *.vfb, *-hinting.ttf, and a .cfg file) which is used for producing the ubuntu fonts. AFAIK, this doesn't mean you couldn't use the ubuntu font family to produce a new font. But does not appear to be the preferred form…
My personal opinion, the exposure seems minimal, here. And I tend to think of these files like I might treat other media files (e.g. a .gif file produced by a paint application).
--kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: What constitutes a source release?
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, May 1, 2013 at 5:42 PM, Dave Fisher <da...@comcast.net> wrote:
>
> Fonts are significant IP for companies.
Hence, the importance of the license under which the font is made available.
> FontForge is an OpenSource tool that could be used to build a binary font
> from source.
Operative words: "could be".
One of the first things I learned[1] when taking this role is that the
answer to most straightforward legal questions is "it depends".
Examples of false statements:
* All text meets the Apache License's definition of "source" form.
* All text meets the Apache License's definition of "object" form.
* All fonts meet the Apache License's definition of "source" form.
* All fonts meet the Apache License's definition of "object" form.
We may very well have to look at each specific font to determine what
the "preferred form for making modifications" would be.
> Regards,
> Dave
- Sam Ruby
[1] http://www.apache.org/legal/ramblings.html
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: What constitutes a source release?
Posted by Dave Fisher <da...@comcast.net>.
On May 1, 2013, at 12:09 PM, Henri Yandell wrote:
>
>
>
> On Wed, May 1, 2013 at 2:36 AM, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Apr 30, 2013, at 11:39 PM, Henri Yandell wrote:
>
>> Taking a stab at the clear policy, I'd propose adding this to resolved.html:
>>
>> "Source distributions must not contain binaries <quiet>(but let's not discuss binaries that are not enforced like http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/icons/)</quiet>. It's fine to have the user run a script to download binaries after they have downloaded the source <quiet>(such as download-binaries-from-svn-tag.sh, or perhaps when first running the application)</quiet>. "
>>
>> Either it's not clear to me, or the current policy is really just a vision towards a policy.
>>
>> Hen
>
> FWIW, I meant the binary object forms of compiled source code.
> That is what "binaries" means to me.
>
> If you think binaries means "anything other than text formats",
> then we are mis-communicating. I don't know why you would think
> that, given character encodings for text are just another
> form of binary encoding, but it might be an age thing.
>
> Good to hear :) This all kicked off from a question (LEGAL-163) of whether a binary font was allowed in a source distribution. Considering a font to be software seemed a stretch.
Adobe Systems might disagree. Fonts are not bitmaps, instead they are shape drawing scripts that have a sense of scale. When I studied the published Type 1 a couple of decades ago deep down the format is not too different from a postscript file.
So, a binary font is in fact compiled from source. There are artifacts from this process and these include Adobe Font Metrics files, etc.
If you've ever studied a PDF with embedded subsets you will know that Adobe went to extremes to make it difficult to reverse engineer a font from the embedded binary code. You are not licensed to do it, and even if you could, it is hard, incomplete, and there are bound to be encoding issues.
Fonts are significant IP for companies.
FontForge is an OpenSource tool that could be used to build a binary font from source.
Regards,
Dave
>
>
>
> Apache releases also contain generated scripts (where
> the source for those generated scripts is also included) and
> assorted other things that don't pose a security risk to
> recipients. The policies are: (1) we only release open source
> that can be distributed under the terms of the Apache License,
> and the PMC release votes are based on individually (2) inspecting
> the source package to ensure that it can be used to build the
> Apache product and corresponds to some version of the source
> that the PMC is maintaining in our version control system(s)
> and (3) verifying that the contents are believed to be safe/legal
> for us to distribute.
>
> Where, I assume, 'release' means the code we author rather than a limiting factor for what we reuse.
>
> Hen
Re: What constitutes a source release?
Posted by Henri Yandell <he...@yandell.org>.
On Wed, May 1, 2013 at 2:36 AM, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Apr 30, 2013, at 11:39 PM, Henri Yandell wrote:
>
> Taking a stab at the clear policy, I'd propose adding this to
> resolved.html:
>
> "Source distributions must not contain binaries <quiet>(but let's not
> discuss binaries that are not enforced like
> http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/icons/)</quiet>.
> It's fine to have the user run a script to download binaries after they
> have downloaded the source <quiet>(such as
> download-binaries-from-svn-tag.sh, or perhaps when first running the
> application)</quiet>. "
>
> Either it's not clear to me, or the current policy is really just a vision
> towards a policy.
>
> Hen
>
>
> FWIW, I meant the binary object forms of compiled source code.
> That is what "binaries" means to me.
>
> If you think binaries means "anything other than text formats",
> then we are mis-communicating. I don't know why you would think
> that, given character encodings for text are just another
> form of binary encoding, but it might be an age thing.
>
Good to hear :) This all kicked off from a question (LEGAL-163) of whether
a binary font was allowed in a source distribution. Considering a font to
be software seemed a stretch.
>
>
> Apache releases also contain generated scripts (where
> the source for those generated scripts is also included) and
> assorted other things that don't pose a security risk to
> recipients. The policies are: (1) we only release open source
> that can be distributed under the terms of the Apache License,
> and the PMC release votes are based on individually (2) inspecting
> the source package to ensure that it can be used to build the
> Apache product and corresponds to some version of the source
> that the PMC is maintaining in our version control system(s)
> and (3) verifying that the contents are believed to be safe/legal
> for us to distribute.
>
Where, I assume, 'release' means the code we author rather than a limiting
factor for what we reuse.
Hen
Re: What constitutes a source release?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Apr 30, 2013, at 11:39 PM, Henri Yandell wrote:
> Taking a stab at the clear policy, I'd propose adding this to resolved.html:
>
> "Source distributions must not contain binaries <quiet>(but let's not discuss binaries that are not enforced like http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/icons/)</quiet>. It's fine to have the user run a script to download binaries after they have downloaded the source <quiet>(such as download-binaries-from-svn-tag.sh, or perhaps when first running the application)</quiet>. "
>
> Either it's not clear to me, or the current policy is really just a vision towards a policy.
>
> Hen
FWIW, I meant the binary object forms of compiled source code.
That is what "binaries" means to me.
If you think binaries means "anything other than text formats",
then we are mis-communicating. I don't know why you would think
that, given character encodings for text are just another
form of binary encoding, but it might be an age thing.
Apache releases also contain generated scripts (where
the source for those generated scripts is also included) and
assorted other things that don't pose a security risk to
recipients. The policies are: (1) we only release open source
that can be distributed under the terms of the Apache License,
and the PMC release votes are based on individually (2) inspecting
the source package to ensure that it can be used to build the
Apache product and corresponds to some version of the source
that the PMC is maintaining in our version control system(s)
and (3) verifying that the contents are believed to be safe/legal
for us to distribute.
....Roy
Re: What constitutes a source release?
Posted by Mark Thomas <ma...@apache.org>.
On 01/05/2013 07:39, Henri Yandell wrote:
>
> Taking a stab at the clear policy, I'd propose adding this to resolved.html:
>
> "Source distributions must not contain binaries <quiet>(but let's not
> discuss binaries that are not enforced like
> http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/icons/)</quiet>.
> It's fine to have the user run a script to download binaries after they
> have downloaded the source <quiet>(such as
> download-binaries-from-svn-tag.sh, or perhaps when first running the
> application)</quiet>. "
>
> Either it's not clear to me, or the current policy is really just a
> vision towards a policy.
With my infra hat on:
Projects must not store 3rd party binaries in svn.
Projects have been found to be hosting entire Maven repos in svn. That
is not good and we don't want to encourage it.
Binaries that projects depend on (like JARs) should be downloaded from
the canonical source (which is never the main ASF svn repo) during the
build.
For projects that need to make binaries (such as JARs) available at
persistent URLs because the original site is not stable / not available
/ etc. then solutions are available but the main svn is not one of them.
Mark
>
> Hen
>
>
> On Tue, Apr 30, 2013 at 10:29 PM, Dennis E. Hamilton
> <dennis.hamilton@acm.org <ma...@acm.org>> wrote:
>
> Would the language from the GPL be preferable? See the first
> definition in section 1 of
> <http://www.gnu.org/licenses/gpl.html>.
>
> From the OSI Definition of the qualities of open-source software?
> See the last two sentences of section 2 at <http://opensource.org/osd>.
>
> This does not mean binary forms are excluded, so long as they *are*
> the primary maintainable forms. In the case of images, modification
> might be by substitution or by editing with suitable tools, so long
> as that is the natural, direct, non-obfuscated way of handling such
> a case.
>
> It seems to me this is questioning of a policy of the ASF. I think
> the policy is clear enough based on this thread. It may be more
> effective to request an exception to policy, rather than struggle to
> lawyer around it. I would give Roy's declaration on the subject
> serious weight before taking any other approach.
>
> - Dennis
>
>
>
> -----Original Message-----
> From: hyandell@gmail.com <ma...@gmail.com>
> [mailto:hyandell@gmail.com <ma...@gmail.com>] On Behalf Of
> Henri Yandell
> Sent: Tuesday, April 30, 2013 18:13
> To: ASF Legal Discuss
> Subject: Re: What constitutes a source release?
>
> [ ... ]
>
> I don't see that the quote from the charter in Roy's old email
> limits us as much as he suggests. Community/Industry use of the
> phrase Open Source doesn't restrict it to only applying to source,
> and it covers what we create/maintain, not what we include. It would
> be unhealthy for us though to have a project releasing its core
> creativity in only binary form, so there's a lot of importance to
> the source-only point.
>
> [ ... ]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> <ma...@apache.org>
> For additional commands, e-mail: legal-discuss-help@apache.org
> <ma...@apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: What constitutes a source release?
Posted by Henri Yandell <he...@yandell.org>.
Taking a stab at the clear policy, I'd propose adding this to resolved.html:
"Source distributions must not contain binaries <quiet>(but let's not
discuss binaries that are not enforced like
http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/icons/)</quiet>.
It's fine to have the user run a script to download binaries after they
have downloaded the source <quiet>(such as
download-binaries-from-svn-tag.sh, or perhaps when first running the
application)</quiet>. "
Either it's not clear to me, or the current policy is really just a vision
towards a policy.
Hen
On Tue, Apr 30, 2013 at 10:29 PM, Dennis E. Hamilton <
dennis.hamilton@acm.org> wrote:
> Would the language from the GPL be preferable? See the first definition
> in section 1 of
> <http://www.gnu.org/licenses/gpl.html>.
>
> From the OSI Definition of the qualities of open-source software? See the
> last two sentences of section 2 at <http://opensource.org/osd>.
>
> This does not mean binary forms are excluded, so long as they *are* the
> primary maintainable forms. In the case of images, modification might be
> by substitution or by editing with suitable tools, so long as that is the
> natural, direct, non-obfuscated way of handling such a case.
>
> It seems to me this is questioning of a policy of the ASF. I think the
> policy is clear enough based on this thread. It may be more effective to
> request an exception to policy, rather than struggle to lawyer around it.
> I would give Roy's declaration on the subject serious weight before taking
> any other approach.
>
> - Dennis
>
>
>
> -----Original Message-----
> From: hyandell@gmail.com [mailto:hyandell@gmail.com] On Behalf Of Henri
> Yandell
> Sent: Tuesday, April 30, 2013 18:13
> To: ASF Legal Discuss
> Subject: Re: What constitutes a source release?
>
> [ ... ]
>
> I don't see that the quote from the charter in Roy's old email limits us
> as much as he suggests. Community/Industry use of the phrase Open Source
> doesn't restrict it to only applying to source, and it covers what we
> create/maintain, not what we include. It would be unhealthy for us though
> to have a project releasing its core creativity in only binary form, so
> there's a lot of importance to the source-only point.
>
> [ ... ]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
RE: What constitutes a source release?
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Would the language from the GPL be preferable? See the first definition in section 1 of
<http://www.gnu.org/licenses/gpl.html>.
>From the OSI Definition of the qualities of open-source software? See the last two sentences of section 2 at <http://opensource.org/osd>.
This does not mean binary forms are excluded, so long as they *are* the primary maintainable forms. In the case of images, modification might be by substitution or by editing with suitable tools, so long as that is the natural, direct, non-obfuscated way of handling such a case.
It seems to me this is questioning of a policy of the ASF. I think the policy is clear enough based on this thread. It may be more effective to request an exception to policy, rather than struggle to lawyer around it. I would give Roy's declaration on the subject serious weight before taking any other approach.
- Dennis
-----Original Message-----
From: hyandell@gmail.com [mailto:hyandell@gmail.com] On Behalf Of Henri Yandell
Sent: Tuesday, April 30, 2013 18:13
To: ASF Legal Discuss
Subject: Re: What constitutes a source release?
[ ... ]
I don't see that the quote from the charter in Roy's old email limits us as much as he suggests. Community/Industry use of the phrase Open Source doesn't restrict it to only applying to source, and it covers what we create/maintain, not what we include. It would be unhealthy for us though to have a project releasing its core creativity in only binary form, so there's a lot of importance to the source-only point.
[ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org