You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2013/05/02 21:54:31 UTC
Source form Re: What constitutes a source release?
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: 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 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 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 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
>
>